How to achive colorspace independence

Casper Boemann cbr at boemann.dk
Fri Oct 21 21:58:15 CEST 2005


Over the last year or so our colorspace independence have come a long way.

I have almost completed the color adjustments. Convolution has been handled, 
and we use mixColors in more and more places.

Still the filters will always be a problem, because with each new filter comes 
new challenges. I think there is several different cases and no single 
solution fit them all. Here is what I have learned so far and what we might 
want to put down in /doc somewhere:

1) Single pixel adjustments, like changing brightness. Each pixel can be 
modified on each own. The best way here is to let the cs do the work. I have 
made a framework wher you allocate an KisAdjustment from the colorspace, and 
the method that applies that adjustment to a range of pixels. Plain and 
simple and by allocating first we reuse some data avoiding overhead.

2) Scaling and other things where each resulting pixel is the weigthed mixture 
of a number of pixels. The mixColors function in the cs does this rather 
well.

3) Drawing kind. Simply copying the pixels or using the composite ops to merge 
them

4) Complex filter. If the filter needs to modify the channels and need access 
to more than one pixel at a time, then it's best to convert to XYZ since it's 
the biggest gamut cs we have and most algos that work on rgb would work on 
xyz too. There is however a large overhead in converting to and from so 
please make sure it is needed.

NO-NOs are using the data like it is a color component (say like red). Apart 
from the fact that you don't know if it is 8bit, 16bit or float or whatever, 
you also don't know if it is a color component or a polar coord like hue, or 
something even weirder.

In short : don't do anything to the data: let the colorspace do it - OR 
transform to XYZ or Lab and do the work there

-- 
best regards / venlig hilsen
Casper Boemann


More information about the kimageshop mailing list