Skip to content
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

Closed
dmcdougall opened this issue Sep 9, 2012 · 15 comments
Closed

dpi= for bitmaps not handled correctly #1223

dmcdougall opened this issue Sep 9, 2012 · 15 comments

Comments

@dmcdougall
Copy link
Member

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:

import matplotlib
matplotlib.use('agg')
import matplotlib.pyplot as plt
fig = plt.figure()
ax = fig.add_subplot(1,1,1)
fig.savefig('test.tif', dpi=1000)

The following code saves a 1000 dpi (correct) bitmap:

import matplotlib
matplotlib.use('agg')
import matplotlib.pyplot as plt
fig = plt.figure()
ax = fig.add_subplot(1,1,1)
fig.savefig('test.png', dpi=1000)

The following saves a 72 dpi (incorrect) bitmap:

import matplotlib
matplotlib.use('cairo')
import matplotlib.pyplot as plt
fig = plt.figure()
ax = fig.add_subplot(1,1,1)
fig.savefig('test.png', dpi=1000)

The following saves a 72 dpi (incorrect) bitmap:

import matplotlib
matplotlib.use('cairo')
import matplotlib.pyplot as plt
fig = plt.figure()
ax = fig.add_subplot(1,1,1)
fig.savefig('test.tif', dpi=1000)
@efiring
Copy link
Member

efiring commented Sep 9, 2012

@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.

@dmcdougall
Copy link
Member Author

@efiring Weird. I even nuked my matplotlibrc file and reinstalled a fresh mpl build from master. My results don't change.

@efiring
Copy link
Member

efiring commented Sep 9, 2012

@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.

@dmcdougall
Copy link
Member Author

@efiring I am not even using pylab. They are each their own standalone script.

@efiring
Copy link
Member

efiring commented Sep 9, 2012

@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.

@dmcdougall
Copy link
Member Author

@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.

@efiring
Copy link
Member

efiring commented Sep 9, 2012

@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.

@efiring
Copy link
Member

efiring commented Sep 9, 2012

PR #1226 takes care of the tiff dpi metadata problem with the agg and cairo backends.
The cairo png problem remains; I don't see any obvious way to fix this. Again, the problem is incorrect metadata, not an incorrect image.

@pelson
Copy link
Member

pelson commented Sep 12, 2012

The cairo png problem remains; I don't see any obvious way to fix this

@efiring : On that basis, are you happy to move this out of "v1.2.x" and into the "v1.2.x known bugs" milestone?

@mdboom
Copy link
Member

mdboom commented Sep 12, 2012

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.

@efiring
Copy link
Member

efiring commented Sep 12, 2012

On 2012/09/12 4:07 AM, Michael Droettboom wrote:

I agree with @pelson https://github.com/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.

Good. The bug is relatively minor and obscure.

@dmcdougall
Copy link
Member Author

On Wed, Sep 12, 2012 at 7:27 PM, Eric Firing notifications@github.comwrote:

On 2012/09/12 4:07 AM, Michael Droettboom wrote:

I agree with @pelson https://github.com/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.

Good. The bug is relatively minor and obscure.

Agreed.


Reply to this email directly or view it on GitHubhttps://github.com//issues/1223#issuecomment-8504821.

Damon McDougall
http://www.damon.is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

@pelson
Copy link
Member

pelson commented May 22, 2013

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?

@mdboom
Copy link
Member

mdboom commented May 22, 2013

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.

@pelson
Copy link
Member

pelson commented May 22, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants