FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

dpi in savefig ignored if imshow uses interpolation='nearest' · Issue #83 · matplotlib/matplotlib · GitHub

Repository navigation

dpi in savefig ignored if imshow uses interpolation='nearest' #83

Closed

Description

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

    Member

    I don't have a solution, but this sounds similar to this http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg12855.html

  2. astrofrog commented on Apr 13, 2011

    ContributorAuthor

    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

    Contributor

    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

    Member

    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

    Contributor

    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

    ContributorAuthor

    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

    Contributor

    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

    ContributorAuthor

    @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. added a commit that references this issue on Apr 15, 2011
    79ca159
  10. added a commit that references this issue on Dec 5, 2013
    cb4e24f
  11. added a commit that references this issue on Sep 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL