[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KColor is coming this Monday...
From:       Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date:       2007-05-25 20:53:51
Message-ID: f37icv$1om$1 () sea ! gmane ! org
[Download RAW message or body]

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/

[prev in list] [next in list] [prev in thread] [next in thread]