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