KColor is coming this Monday...
mw_triad at users.sourceforge.net
Fri May 25 21:53:51 BST 2007
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.
> 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.)
"Still the prettiest." -- Legolas
(as quoted in The Very Secret Diaries by Cassandra Claire)
More information about the kde-core-devel