matplotlib.pyplot.imread silently fails on uint16 images.

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'

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

@WeatherGod

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

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

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!

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!

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

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

@cgohlke

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

@WeatherGod 👍

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?

@mdboom

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

@jni

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

@tacaswell

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

In that case, yes.

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

WeatherGod commented on Oct 4, 2014

jni commented on Oct 4, 2014

jni commented on Oct 4, 2014

jni commented on Oct 4, 2014

jni commented on Oct 4, 2014

WeatherGod commented on Oct 4, 2014

cgohlke commented on Oct 4, 2014

jni commented on Oct 5, 2014

mdboom commented on Oct 5, 2014

jni commented on Oct 5, 2014

tacaswell commented on Oct 17, 2014

jni commented on Oct 17, 2014

tacaswell commented on Oct 17, 2014

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions