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

List:       kde-kimageshop
Subject:    Re: How to achive colorspace independence
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2005-10-22 18:47:23
Message-ID: 200510222047.23944.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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 
colorspaces.

> 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

Yes.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


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