Hi all, I'm working on the color spaces, and would like some feedback. Doing color space conversions is very simple, but finding the right references and making sure things are correct is a real pain. So I'm wondering what spaces are useful and unambiguously defined. So far I have ----------------- - RGB : sRGB with D65 whitepoint, the "central" color space in the API. - HSV : unambiguous - XYZ : unambiguous - CIE RGB : unambiguous - RGB NTSC : from Travis' code, not sure what it is. Not equal to YIQ, which is the color space used for NTSC. Will delete again unless I figure it out. Some code, seems clearly defined ---------------------------------------------- - CIE LAB - CIE LUV Some code, but not sure about ----------------------------------------- - RGBP : gamma corrected sRGB. I am usually interested in intensities / photon counts, so I have a natural aversion to this one. Anyone care? - YIQ : see RGB NTSC above - RGB SB : Stiles and Burch (1955) 2-degree RGB color space. seems obsolete. - UVW : seems obsolete - YUV / YCbCr / YCC / YPbPr / 8-bit YCbCr : these are all similar and often confused. A mess. No code yet, but commonly used -------------------------------------------- - HSL - CMYK The code I have so far lives here: http://github.com/rgommers/scikits.image/tree/color I'm afraid adding color spaces that are not clearly defined does more harm than good, so please let me know which color spaces are useful for you. Cheers, Ralf
Hi Ralf 2009/10/21 Ralf Gommers <ralf.gommers@googlemail.com>:
I'm working on the color spaces, and would like some feedback. Doing color space conversions is very simple, but finding the right references and making sure things are correct is a real pain. So I'm wondering what spaces are useful and unambiguously defined.
Let's stick to the unambiguous cases and see what feedback we get. If the user requirements are more ambitious, we'll await patches :) We should definitely link to Poynton's FAQ in the docs: http://www.poynton.com/ColorFAQ.html Good stuff! Cheers Stéfan
2009/10/21 Stéfan van der Walt <stefan@sun.ac.za>
Hi Ralf
2009/10/21 Ralf Gommers <ralf.gommers@googlemail.com>:
I'm working on the color spaces, and would like some feedback. Doing
color > space conversions is very simple, but finding the right references and > making sure things are correct is a real pain. So I'm wondering what spaces > are useful and unambiguously defined.
Let's stick to the unambiguous cases and see what feedback we get. If the user requirements are more ambitious, we'll await patches :)
Sure. I'm done for now, we have support for four spaces: RGB, HSV, XYZ, RGB
CIE. Other spaces that could be included are HSL, CMYK, LAB and LUV, but let's wait till what is there now gets some usage first.
We should definitely link to Poynton's FAQ in the docs:
Yes, very useful doc. Cheers, Ralf
Good stuff!
Cheers Stéfan
Looks Good, I will hold off then on cvCvtColor unless it's requested... Cheers! Chris On Thu, Oct 22, 2009 at 12:00 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
2009/10/21 Stéfan van der Walt <stefan@sun.ac.za>
Hi Ralf
2009/10/21 Ralf Gommers <ralf.gommers@googlemail.com>:
I'm working on the color spaces, and would like some feedback. Doing color space conversions is very simple, but finding the right references and making sure things are correct is a real pain. So I'm wondering what spaces are useful and unambiguously defined.
Let's stick to the unambiguous cases and see what feedback we get. If the user requirements are more ambitious, we'll await patches :)
Sure. I'm done for now, we have support for four spaces: RGB, HSV, XYZ, RGB CIE.
Other spaces that could be included are HSL, CMYK, LAB and LUV, but let's wait till what is there now gets some usage first.
We should definitely link to Poynton's FAQ in the docs:
Yes, very useful doc.
Cheers, Ralf
Good stuff!
Cheers Stéfan
Hi Ralf 2009/10/21 Ralf Gommers <ralf.gommers@googlemail.com>:
The code I have so far lives here: http://github.com/rgommers/scikits.image/tree/color
Thanks for cleaning up the colour conversion routines! Here are some review comments: - Add this contribution to CONTRIBUTORS.txt - Do not check types explicitly against ndarray. A safer route is to use "asanyarray". - "float32" is not a valid dtype descriptor -- use np.float32 instead - Question: why are there NaN's in the output? A question that pertains to the scikit as a whole: what do we assume the limits of images to be? I think a common convention is 0-255 for type uint8 and 0-1 for type float. These need to be handled in all functions, and we may soon see patterns emerging that can be captured in standard utility functions. Regards Stéfan
for the limit for uint8 regardless of what may be routine is 255 ;) that said, I think a more important question is how should we handle overflow on uint8 images? and should we even bother trying? The numpy standard is to wrap, the opencv standard is to threshold at 255. I don't see any easy way to make either of these two do it the other way. Chris 2009/10/22 Stéfan van der Walt <stefan@sun.ac.za>:
Hi Ralf
2009/10/21 Ralf Gommers <ralf.gommers@googlemail.com>:
The code I have so far lives here: http://github.com/rgommers/scikits.image/tree/color
Thanks for cleaning up the colour conversion routines! Here are some review comments:
- Add this contribution to CONTRIBUTORS.txt - Do not check types explicitly against ndarray. A safer route is to use "asanyarray". - "float32" is not a valid dtype descriptor -- use np.float32 instead - Question: why are there NaN's in the output?
A question that pertains to the scikit as a whole: what do we assume the limits of images to be? I think a common convention is 0-255 for type uint8 and 0-1 for type float. These need to be handled in all functions, and we may soon see patterns emerging that can be captured in standard utility functions.
Regards Stéfan
Hi Stefan, Thanks for reviewing. 2009/10/22 Stéfan van der Walt <stefan@sun.ac.za>
Hi Ralf
2009/10/21 Ralf Gommers <ralf.gommers@googlemail.com>:
The code I have so far lives here: http://github.com/rgommers/scikits.image/tree/color
Thanks for cleaning up the colour conversion routines! Here are some review comments:
- Add this contribution to CONTRIBUTORS.txt - Do not check types explicitly against ndarray. A safer route is to use "asanyarray". - "float32" is not a valid dtype descriptor -- use np.float32 instead
all done.
- Question: why are there NaN's in the output?
I assume you mean the two isnan checks? I removed the one in hsv2rgb, it was not necessary. The one in rgb2hsv should be there, because there are some divisions (see for example the S channel) that can be zero. Setting those NaN elements to zero is correct, and more efficient than doing a check for zeros beforehand. If you meant you see actual NaN's in the output that would be a bug. Cheers, Ralf
Regards Stéfan
On Thu, Oct 22, 2009 at 7:06 PM, Chris Colbert <sccolbert@gmail.com> wrote:
for the limit for uint8 regardless of what may be routine is 255 ;)
that said, I think a more important question is how should we handle overflow on uint8 images? and should we even bother trying?
The numpy standard is to wrap, the opencv standard is to threshold at 255. I don't see any easy way to make either of these two do it the other way.
Indeed not easy to do, and there's very little one can do with uint8 data anyway. Don't bother trying I would say.
Chris
2009/10/22 Stéfan van der Walt <stefan@sun.ac.za>:
A question that pertains to the scikit as a whole: what do we assume the limits of images to be? I think a common convention is 0-255 for type uint8 and 0-1 for type float. These need to be handled in all functions, and we may soon see patterns emerging that can be captured in standard utility functions.
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? uint8: 0-255, the only choice. but again, why assume anything? Cheers, Ralf
Regards Stéfan
2009/10/23 Ralf Gommers <ralf.gommers@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. Cheers Stéfan
2009/10/23 Stéfan van der Walt <stefan@sun.ac.za>
2009/10/23 Ralf Gommers <ralf.gommers@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
participants (3)
-
Chris Colbert -
Ralf Gommers -
Stéfan van der Walt