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

matplotlib.pyplot.imread silently fails on uint16 images. · Issue #3616 · matplotlib/matplotlib · GitHub

Repository navigation

matplotlib.pyplot.imread silently fails on uint16 images. #3616

Closed

Description

It assumes the image is uint8 and incorrectly wraps the input at 255:

In [1]: from skimage import io

In [15]: io.imsave('io3.png', np.array([[0, 1], [0, 4196]], dtype=np.uint16),
            plugin='pil')

In [19]: from matplotlib.pyplot import imread

In [20]: imread('io3.png')
Out[20]: 
array([[ 0.        ,  0.00392157],
       [ 0.        ,  0.39215687]], dtype=float32)

In [21]: import matplotlib as mpl

In [22]: mpl.__version__
Out[22]: '1.3.1'

Activity

  1. WeatherGod commented on Oct 4, 2014

    Member

    Could you double-check with matplotlib 1.4.0? I think this might have already been fixed.

  2. jni commented on Oct 4, 2014

    ContributorAuthor

    @WeatherGod No such luck:

    In [1]: import matplotlib as mpl
    
    In [2]: mpl.pyplot.imread('Desktop/io3.png')
    Out[2]: 
    array([[ 0.        ,  0.00392157],
           [ 0.        ,  0.39215687]], dtype=float32)
    
    In [3]: mpl.__version__
    Out[3]: u'1.4.0'
  3. jni commented on Oct 4, 2014

    ContributorAuthor

    BLEURG! I had a horrible thought and it seems to have panned out: the imsave had already messed up the image!

    In [1]: from skimage import io
    
    In [4]: io.imread('Desktop/io3.png', plugin='pil')
    Out[4]: 
    array([[  0,   1],
           [  0, 100]], dtype=uint8)

    I'll investigate further...

  4. jni commented on Oct 4, 2014

    ContributorAuthor

    Looks like there is a lot of IO voodoo going on everywhere:

    In [8]: mpl.pyplot.imsave('io4.png', np.array([[0, 1], [0, 4196]], dtype=np.uint16))
    
    In [9]: mpl.pyplot.imread('io4.png')
    Out[9]: 
    array([[[ 0.        ,  0.        ,  0.49803922,  1.        ],
            [ 0.        ,  0.        ,  0.49803922,  1.        ]],
    
           [[ 0.        ,  0.        ,  0.49803922,  1.        ],
            [ 0.49803922,  0.        ,  0.        ,  1.        ]]], dtype=float32)
    
    In [10]: im4 = mpl.pyplot.imread('io4.png')
    
    In [11]: im4.shape
    Out[11]: (2, 2, 4)
    
    In [12]: np.rollaxis(im4, -1) # display the three channels + alpha of the array
    Out[12]: 
    array([[[ 0.        ,  0.        ],
            [ 0.        ,  0.49803922]],
    
           [[ 0.        ,  0.        ],
            [ 0.        ,  0.        ]],
    
           [[ 0.49803922,  0.49803922],
            [ 0.49803922,  0.        ]],
    
           [[ 1.        ,  1.        ],
            [ 1.        ,  1.        ]]], dtype=float32)

    That save/read roundtrip outcome seems highly undesirable!

  5. jni commented on Oct 4, 2014

    ContributorAuthor

    That's hilarious, looking at the actual image I just realised what happened: mpl silently remapped the uint16 values to Jet and then saved that!

  6. WeatherGod commented on Oct 4, 2014

    Member

    Jet strikes again!

    "With my last breath, I curse Jet!"

    On Fri, Oct 3, 2014 at 10:31 PM, Juan Nunez-Iglesias <
    notifications@github.com> wrote:

    That's hilarious, looking at the actual image I just realised what
    happened: mpl silently remapped the uint16 values to Jet and then saved
    that!

    —
    Reply to this email directly or view it on GitHub
    #3616 (comment)
    .

  7. cgohlke commented on Oct 4, 2014

    Contributor

    The uint16 array is not a valid input for skimage.io.imsave when using the PIL plugin. See https://github.com/scikit-image/scikit-image/blob/master/skimage/io/_plugins/pil_plugin.py#L144

  8. jni commented on Oct 5, 2014

    ContributorAuthor

    @cgohlke that should change soon, but thanks for the pointer! =)

    @WeatherGod 👍

  9. mdboom commented on Oct 5, 2014

    Member

    So, if I'm reading the above correctly, this is not an issue with matplotlib's imread, but skimage.io.imsave? Should we close this then?

  10. jni commented on Oct 5, 2014

    ContributorAuthor

    @mdboom well, that "saving as jet" thing is bugging me to no end, but perhaps that belongs in a separate issue?

  11. tacaswell commented on Oct 17, 2014

    Member

    @jni Yes, jet-related griping should go in #875.

  12. jni commented on Oct 17, 2014

    ContributorAuthor

    @tacaswell that's not really the right issue. The issue is colormapping a grayscale image at save time instead of either saving it as-is or raising an error. It's the colormapping that's the problem, not jet. (Jet is the icing on the cake.) Should I raise a new issue?

  13. tacaswell commented on Oct 17, 2014

    Member

    In that case, yes.

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