color spaces

[Ralf Gommers]

2009/10/23 Stéfan van der Walt <stefan at sun.ac.za>

>
> 2009/10/23 Ralf Gommers <ralf.gommers at googlemail.com>:
> > For float images I think we should not assume anything. Rescaling loses
> > information that is valuable, like absolute light intensity. Is there a
> need
> > to make an assumption like this?
>
> I'm pretty sure those assumptions will have to me made sooner rather
> than later.  You didn't need to do any scaling during colour
> conversion?  Lucky, I guess, but it's something that pops up all over
> the place.
>

Most color conversions were simply matrix multiplication. But you're right,
the RGB -> HSV conversion assumes values in the [0, 1] interval. I will add
a note. And I agree your 0-255 and 0.-1. defaults are sensible.

I still think it is dangerous to automatically scale images. To take the
rgb2hsv function as an example, a way to scale would be to check the dtype
and then if it is uint8, divide by 255. Now what if the image is 16bit? Or
it was uint8 but the user happened to convert it to float already without
changing the data range? Say the range is [0.5 - 127.], do you map it to [0.
- 1.] or [0.5 - 127.] / 255?

When you need to assume a range, I think it should be in the docs, maybe
even use a warning or a scale(=False) parameter if it's important. Provide
some utility functions for users to scale to different data ranges. But
automatic scaling is tricky and will usually not do the right thing for all
users.

Cheers,
Ralf


> Cheers
> Stéfan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20091023/3aceb6e5/attachment.html>