matplotlib.pyplot.imread silently fails on uint16 images.

[jni]

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'

[WeatherGod]

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

[jni]

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

[jni]

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

[jni]

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!

[jni]

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!

[WeatherGod]

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

[cgohlke]

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

[jni]

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

@WeatherGod 👍

[mdboom]

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?

[jni]

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

[tacaswell]

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

[jni]

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

[tacaswell]

In that case, yes.