Description

astrofrog

opened on Apr 12, 2011

Issue body actions

The following example demonstrates that if imshow uses interpolation='nearest', the dpi= argument in savefig has no effect:

import numpy as np
import matplotlib.pyplot as plt

fig = plt.figure()
ax = fig.add_subplot(1, 1, 1)
ax.imshow(np.random.random((1000, 1000)))
plt.savefig('test1.eps', dpi=1)
plt.savefig('test2.eps', dpi=10)
plt.savefig('test3.eps', dpi=100)

fig = plt.figure()
ax = fig.add_subplot(1, 1, 1)
ax.imshow(np.random.random((1000, 1000)), interpolation='nearest')
plt.savefig('test4.eps', dpi=1)
plt.savefig('test5.eps', dpi=10)
plt.savefig('test6.eps', dpi=100)

because looking at the file sizes gives:

$ du -sh test?.eps
 12K    test1.eps
 16K    test2.eps
620K    test3.eps
5.8M    test4.eps
5.8M    test5.eps
5.8M    test6.eps

Activity

1. ivanov commented on Apr 13, 2011

   

   ivanov

   on Apr 13, 2011

   Member

   More actions

   I don't have a solution, but this sounds similar to this http://www.mail-archive.com/[email protected]/msg12855.html
2. astrofrog commented on Apr 13, 2011

   

   astrofrog

   on Apr 13, 2011

   ContributorAuthor

   More actions

   Thanks for the link. While I agree that a plot with only vector graphics would not change size, this one contains a bitmap from imshow which should be subject to the dpi setting. The size does change correctly with dpi in the default imshow call, and it is only when changing the interpolation mode that the issue occurs.
3. leejjoon commented on Apr 13, 2011

   

   leejjoon

   on Apr 13, 2011

   Contributor

   More actions

   The behavior of "nearest" interpolation has changed (by me) sometime ago.
   When agg and ps backends (and pdf backend in the master branch) are used, the original image is saved as is with NO interpolation if "nearest" is used.

   For low resolution images, I think this is good.
   For high resolution images and if you want to downsample the images when you save the output, this behavior may not fit your need.

   I, personally, think that it is better to let a user do the explicit downsamping in such cases.
   But I want to hear how others think.

   We may have a separate mode of interpolation="no", and restore the old behavior for interpolation="nearest".
4. mdboom commented on Apr 13, 2011

   

   mdboom

   on Apr 13, 2011

   Member

   More actions

   I think @leejjoon 's change to 'nearest' made a lot of sense for low-resolution images -- it avoids changing the image data at all, which is always preferred when one can get away with it, IMHO. But perhaps the behavior should be tweaked so it will downsample, but not upsample.

   Of course -- adding an interpolation="no" option might be less "magical".
5. hamogu commented on Apr 13, 2011

   

   hamogu

   on Apr 13, 2011

   Contributor

   More actions

   As it is now, the setup seems counterintuitive to me. If I didn't want an interpolation, I would not chose interpolation="nearest". Especially for high resolution images, the ps files get quite big and it seems most natural to me to downsample them with the dpi setting in savefig.

   A mode of interpolation="no" would solve that problem nicely and is more transparent to the user.
6. astrofrog commented on Apr 13, 2011

   

   astrofrog

   on Apr 13, 2011

   ContributorAuthor

   More actions

   I agree that for low-res images, upsampling makes no sense, so in that respect, I think the change was a good idea - but I also think that if the effective dpi of the bitmap is larger than the specified dpi, then downsampling would make sense.

   I think the new behavior of 'nearest' is a bit unexpected, since there is interpolation going on, and I agree with @mdboom that maybe this new behavior warrants a new interpolation method (and I would actually say that 'none' would be more consistent with the rest of the API that 'no')
7. leejjoon commented on Apr 13, 2011

   

   leejjoon

   on Apr 13, 2011

   Contributor

   More actions

   Before the change, matplotlib always saved interpolated images. And for me, the interpolation="nearest" was a workaround when I actually didn't want any interpolation. I think that is one of the reason for the current behavior.

   I'm inclined to introduce interpolation="none" (and recover the old behavior for interpolation="nearest"), instead of implementing some "magics".

   For those backends which do not support interpolation="none", we may issue some warning and fall back to interpolation="nearest".
8. astrofrog commented on Apr 13, 2011

   

   astrofrog

   on Apr 13, 2011

   ContributorAuthor

   More actions

   @leejjoon - that sounds like a good plan. I also often used interpolation='nearest' as a workaround, so it will be nice for interpolation='none' to provide a proper mechanism for writing out images at their native resolutions and to use interpolation='nearest' if down or upsampling is required.
9. leejjoon

   closed this as completedin 79ca159on Apr 15, 2011
10. WeatherGod

    added a commit that references this issue on Apr 15, 2011

    recover old behavior for 'nearest' interpolation and introduces 'none'.

    This issue will close once commit 79ca159 is merged into the 'main' branch.

    79ca159
11. magnunor

    added a commit that references this issue on Dec 5, 2013

    Fixes matplotlib#83 and related issues

    This issue will close once commit cb4e24f is merged into the 'master' branch.

    cb4e24f
12. fariza

    added a commit that references this issue on Sep 22, 2016

    Merge pull request matplotlib#83 from fgoudreault/results_doc

    7346bb7

Issue actions