How to achive colorspace independence
boud at valdyas.org
Sat Oct 22 20:47:23 CEST 2005
On Friday 21 October 2005 21:58, Casper Boemann wrote:
> 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.
This sounds like a generic way of doing things, but this also demands that the
colorspace has a function that knows how to create the basic adjustment and
knows what to do with the adjustment, and the filter must know how to fill
the adjustment with parameters -- i.e, all of the filter except for the
iterator is in the colorspace -- right?
> 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.
I never thought of scaling as a filter, but it's true, of course. Is mixColors
natively implemented in all cs's -- or do we have fallback to 16 bit lab or
xyz? Should check...
No, we're still falling back on QColor here. This is one thing we will need
to fix before the release, since it means that a simple scaling will transform
a 16 bit image to essentially an 8 bit image.
> 3) Drawing kind. Simply copying the pixels or using the composite ops to
> merge them
Yes, that works very nicely, and uses Adrian's scheme to tell the outside
world which kinds of compositing the cs supports; we may want to copy this
for the other type functions that may not be completely implemented in all
> 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.
Note that it should be 16 bit XYZ: that colorspace is easily accessible from
the colorspacefactory registry.
> 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.
Another no-no (except for very decorative filters, like dropshadow or
oilpaint) is silently converting the pixels to rgb, applying the algorithm
and then converting back.
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20051022/94fc87b7/attachment.pgp
More information about the kimageshop