Review Request: KColorSpace::KHCY::KHCY(const & QColor) constructor floating point precision error

[Matthew Woehlke]

Michael Kreitzer wrote:
> I considered that as well. The only thing that worries me is IEEE 754 on x86 
> seems woefully unreliable for direct comparisons if you're not trying to do 
> something very simple (e.g. prevent a divide by zero).

True, but I think it will be okay in this case. If the values aren't 
identical, the chroma calculation should hopefully be meaningful.

And this should only happen for black or white, yes? (Although you could 
get some pretty tiny-but-non-zero values of c for grays, before.) Maybe 
it would be better to always calculate c, and check after for infinity 
or NaN.

Do you think this would be better?

     // chroma component
     c = qMax( (y - n) / y, (p - y) / (1 - y) );
     if (!(c >= 0.0 || c <= 1.0))
         c = 0.0;

> The method you commited is probably fine, but I'd love to see an algorithmic 
> method to avoid the problem altogether. I'm just not familiar enough with this 
> subject to be able to propose one.

Well, it's an RGB -> HCY colorspace conversion, so there is always 
http://en.wikipedia.org/wiki/HSL_and_HSV :-).

Basically, your corner cases are going to be when y==0 || y==1 (black or 
white). Strictly speaking, c==NaN is really a more "correct" answer (you 
are at one of the points of the bicone/sphere), but practically speaking 
c==0 (treat black/white as fully-gray) is most useful.

Let me know if you think of something you like better :-).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Have you tried that new mixed drink, 'GDR'"?
"What is it?"
"Gin, Duck and Rum. It tastes fowl."