New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dpi= for bitmaps not handled correctly #1223
Comments
@dmcdougall, I cannot reproduce your result. Using exactly your code above, with the sole exception of changing the file names to test_agg.png etc so I can keep track of which is which, I get the same result for all four: a genuine 1000 dpi image. For each test I started a fresh ipython with no arguments (no pylab mode). The tiff files are identical; the png files are nearly identical. This makes sense, because the tiff files are generated from code in backend_bases, via agg and PIL, but the cairo backend overrides the backend_bases code for png, using its own renderer instead. |
@efiring Weird. I even nuked my matplotlibrc file and reinstalled a fresh mpl build from master. My results don't change. |
@dmcdougall, I can reproduce your result if I use ipython --pylab on a mac. In that case, the backend is actually macosx, and the matplotlib.use command has no effect other than to issue a warning. I conclude that the dpi problem on macosx extends to images as well as linewidth. |
@efiring I am not even using pylab. They are each their own standalone script. |
@dmcdougall I get the same thing with a standalone script. With the agg backend, I get -rw-rw-r-- 1 efiring efiring 192000142 Sep 9 11:39 test1_agg.tif -rw-rw-r-- 1 efiring efiring 269671 Sep 9 11:39 test2_agg.png efiring@manini2:~$ file test2_agg.png test2_agg.png: PNG image data, 8000 x 6000, 8-bit/color RGBA, non-interlaced efiring@manini2:~$ convert test1_agg.tif test1_agg_tif.png efiring@manini2:~$ file test1_agg_tif.png test1_agg_tif.png: PNG image data, 8000 x 6000, 8-bit grayscale, non-interlaced I don't have any idea what might be different between your setup and mine that could account for your incorrect dpi in the tiff file. |
@efiring Open the tiff and the png in Preview. Click Tools->Show Inspector. What does it say the dpi is? And for the png? Mine says 72 and 1000, respectively. |
@dmcdougall, aha! OK, so the file is being generated with the correct dpi (hence the expected number of pixels), but the dpi meta-data is being set incorrectly (to 72). Strangely, the Inspector is showing 999.98 pixels per inch for the png file. At least it's close. I see where the tiff problem is, and how to fix it. I will produce a PR shortly. |
PR #1226 takes care of the tiff dpi metadata problem with the agg and cairo backends. |
@efiring : On that basis, are you happy to move this out of "v1.2.x" and into the "v1.2.x known bugs" milestone? |
I agree with @pelson here. The cairo shortcoming is obviously long standing, and probably shouldn't hold up the release candidate. I'm going to change the milestone on this bug. |
On 2012/09/12 4:07 AM, Michael Droettboom wrote:
Good. The bug is relatively minor and obscure. |
On Wed, Sep 12, 2012 at 7:27 PM, Eric Firing notifications@github.comwrote:
Agreed.
Damon McDougall |
I'm tempted to close this issue in favour of a more specialised issue entitled: "cairo png output lacks dpi metadata". Does that summarise the remaining issue suitably? |
Yeah -- my understanding is that Cairo doesn't have an API for this. I think any workaround probably involves opening the output file after the fact and updating the metadata. |
Maybe this is a wontfix then... at the least I'm going to close this. If somebody want to keep it around, we can open a new, targeted, issue. |
On further inspection of #113, it appears this is not an issue with the osx backend in particular, it's a wider problem. The dpi kwarg in savefig is not respected when saving certain types of bitmaps.
The following code saves a 72 (incorrect) dpi bitmap:
The following code saves a 1000 dpi (correct) bitmap:
The following saves a 72 dpi (incorrect) bitmap:
The following saves a 72 dpi (incorrect) bitmap:
The text was updated successfully, but these errors were encountered: