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.
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".
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".
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.
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')
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".
@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.
Activity
ivanov commented on Apr 13, 2011
I don't have a solution, but this sounds similar to this http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg12855.html
astrofrog commented on Apr 13, 2011
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.
leejjoon commented on Apr 13, 2011
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".
mdboom commented on Apr 13, 2011
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".
hamogu commented on Apr 13, 2011
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.
astrofrog commented on Apr 13, 2011
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')
leejjoon commented on Apr 13, 2011
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".
astrofrog commented on Apr 13, 2011
@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.
recover old behavior for 'nearest' interpolation and introduces 'none'.
Fixes matplotlib#83 and related issues
Merge pull request matplotlib#83 from fgoudreault/results_doc