KColor is coming this Monday...

[Matthew Woehlke]

Dominik Haumann wrote:
> On Friday 25 May 2007, Matthew Woehlke wrote:
>> Zack Rusin wrote:
>>> Now all those mentioned H* colorspaces are by definition non-linear
>>> transformations of the RGB colorspace. So they, again by definition,
>>> lose precision on conversions.
>> But in 64-bit floating point math (which KColor uses exclusively), the
>> loss is negligible. In fact the test suite *requires* that KColor(
>> someQColor ).convert( KColor::Hs? ) gives back the original color (at
>> least in 8-bpp) when cast back to a QColor. That is the result must
>> QColor::operator== the input. So I fail to see why this is a concern.
> [snip]
> 
> Just in case there is really 'data loss': this should go into the api dox, 
> maybe along with an image ;)

I don't think an image is possible, to do so many lossy conversions that 
you have lost 41+ bits (what it would take to be able to see something 
in an image) is IMO really, *really* extreme :-). I'm fine writing a 
note along the lines of "there /is/ math involved in performing a color 
space conversion, so if you happen to need 40-plus bit precision, keep 
this in mind" if you think it's necessary? My thinking is that once you 
start doing /any/ operations other than copy, you're going to get a 
comparable level of fuzz.

A note in the QColor cast operator is probably more relevant, also 
because I am pretty sure QColor doesn't support HDR (and I'm kind-of 
leaving normalization in KColor alone, so you get "implicit" HDR).

(Ack, and I was using "bpp" before which is not right, should be bits 
per /channel/, not per pixel.)

-- 
Matthew
"Still the prettiest." -- Legolas
(as quoted in The Very Secret Diaries by Cassandra Claire)
http://www.ealasaid.com/misc/vsd/