Colorspace conversions are wrong for anything other than uint8

[tbenst]

Description

I've found what appears to be a severe bug, where colorspace conversions are completely wrong for all dtypes other than uint8.

Way to reproduce

import skimage.data
from skimage.color import rgb2luv
astronaut_uint8 = skimage.data.astronaut()
astronaut_float32 = astronaut_uint8.astype(np.float32)
astronaut_uint16 = astronaut_uint8.astype(np.uint16)
astronaut_uint8.max() # 255
astronaut_float32.max() # 255.0
rgb2luv(astronaut_uint8)[:,:,0].max() # 100.0
rgb2luv(astronaut_float32)[:,:,0].max() # 9341.576
rgb2luv(astronaut_uint16)[:,:,0].max() # 0.272

Note that max(L)=100 by definition, so 9341 is clearly wrong, as is 0.272.

Version information

3.7.3 (default, Mar 27 2019, 22:11:17) 
[GCC 7.3.0]
Linux-4.15.0-156-generic-x86_64-with-debian-buster-sid
scikit-image version: 0.18.1
numpy version: 1.20.3

[rfezzani]

Hello @tbenst, and thank you for your interest in skimage. As the User Guide stipulates:

You should never use astype on an image, because it violates these assumptions about the dtype range...

🙂

>>> import skimage
>>> astronaut_uint8 = skimage.data.astronaut()
>>> astronaut_float32 = skimage.img_as_float32(astronaut_uint8)
>>> astronaut_uint16 = skimage.img_as_uint(astronaut_uint8)
>>> astronaut_uint8.max()
255
>>> astronaut_uint16.max()
65535
>>> astronaut_float32.max()
1.0
>>> rgb2luv(astronaut_uint8)[:,:,0].max()
100.0
>>> rgb2luv(astronaut_float32)[:,:,0].max()
100.0
>>> rgb2luv(astronaut_uint16)[:,:,0].max()
100.0

[rfezzani]

@tbenst, if you don't mind I will convert this issue to conversation.

[grlee77]

prior comments from the deleted Discussion

@mkcor wrote

@tbenst you may also be interested in #5973

@hmaarrfk wrote

I guess the funny thing is that we are planning to move to the suggested behavior in skimage 1.0 (or is it 2.0 now)

@tbenst wrote

Ok, thank you very kindly for the explanation! That makes sense and helps a lot.

I do find the behavior odd / not intuitive, particularly as the function supports invalid inputs. In my actual code, I didn’t call astype but rather have float 0-255 after some simple numpy operations on UIn8 that promote to float. I personally think it’s not very pythonic for operations on numpy arrays to behave so differently depending on numerical precision, especially since (silent) type promotion happens all the time in numpy.

Perhaps the approach taken by Images.jl / Colors.jl would be useful here? It seems like introducing a type would be useful here, as the scikit-image isn’t really interpreting numpy arrays in the traditional way—and for good reasons, as images have different needs! The nice thing about the normalized 0-1 fixed point representation, is it converts to 0-1 float quite naturally. Also, the image float type constructor provides protection from passing invalid values. In Python that could be a type wrapper around a numpy array for minimal performance loss.