Review Request: KColorSpace::KHCY::KHCY(const & QColor) constructor floating point precision error
mw_triad at users.sourceforge.net
Mon Jun 22 23:44:39 BST 2009
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
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
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 :-).
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."
More information about the kde-core-devel