Design issues (opengl, hdr, channels, pigment(?))

[Boudewijn Rempt]

(My answer is a bit late, I was too sick this weekend to do much, and even now 
I'm not really up and running.)

On Saturday 27 January 2007, Cyrille Berger wrote:

> Write an implementation of KoColorTransformation (or the relevant
> Transformation like KoConvolutionTransformation for convolution). And then
> we need to create a mechanism to determine which transformation to select.

That mechanism is another issue. For asm routines, we should use kcpuinfo.h to 
switch, I think, but for opengl we may need either a priority scheme or a 
configuration option. Or let the calling code determine whether it wants to 
use opengl.

> > I think we should go the getTexture() and writeTexture() route.
>
> what is this route ?

For getting the paint device data in a form that shader programs can use. It's 
not much use passing only up to a maximum 4096 pixels worth of data to a 
shader, that way the gpu hardly gets to flex its muscles. So I was thinking 
of having a toTexture/fromTexture pair similar to to/fromQImage and 
read/writeBytes that would copy image data into a texture object and from a 
texture object. I

NVidia's GPUFilter framework for Photoshop filters is interesting, too. I'm 
reading through that at the moment.

I'm trying to come up with an experimental viewplugin that does this (initally 
through the read/writeBytes methods) to test whether the cost is prohibitive. 
(Just for fun & kicks, and because I want to do something new for a change, 
but maybe this plugin will be our equivalent of the nvidia filter framework.)

> I am affraid that you are confusing two different problems:
>  - apply filter on only one channel
>  - signal based processing for filters (which is for what KisMathToolbox is
> for), it only works for colorspace with continuous data (so not for the
> index colorspace) and it doesn't work for colorspace with an "angle" as
> channel, but one would need to provide a KisMathToolbox implementation for
> those.

Okay, I think I understand now. In any case, I think it's useful to have a 
general method to extract one channel into a single-channel colorspace paint 
device and to put it back. KisPainter::bitBlt should be able to do that, but 
that interferes with colorspace conversions.

> see below (at the end of my comment on pigment), I think the QBitArray
> solution, after all, we didn't even choose the solution to enforce
> KisSelection...

I think there's something missing in this sentence :-). But if I fill in the 
gaps correctly, you prefer the bit array solution? Do we need to make it 
automatic to have a filter configuration per channel for all filters?

> Not much has change you know ;) It's just that instead of calling a virtual
> function of the colorspace, you call a virtual function of a transformation
> object that you did created with a call to a function of the colorspace.
> This allow us to dynamically creates operations and choose the best one for
> the CPU or the task at hand (I am thinking that this might be a possibility
> to keep fast implementation for the previous point, I need to think a
> little bit more about it).

We could have the factory function make the choice using kcpuinfo and a 
configuration parameter for opengl (because opengl is fast but inaccurate we 
cannot mandate it); that way the object returned always is the fastest 
version.

> Now, we need to think if we need or if we want to have extensibility of
> those operations.

You mean make it possible to add functionality to colorspaces using plugins? 
Then we'd need to have a kind of per-colorspace registry of ops that the 
colorspace can query to get the asm, plain-software or opengl variant of an 
op.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20070130/b04ee7d6/attachment.pgp