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

[Boudewijn Rempt]

I'm going to try an summarize a couple of design issues that have been 
discussed here and on irc for the past months. I hope we can get to a 
resolution and then, hopefully, even an implementation.

* OpenGL

Adrian Page already started thinking about using opengl for more than just 
fast zooming. Michael recently posted his experiments with an opengl based 
image manipulation program. I would really like to make good use of opengl 
(if available). 

These are the places I would like to use opengl:

- display (fast zooming, rotated canvas, hdr exposure, wetness, canvas, paint 
thickness visualisation. Optionally also fast but inaccurate projection 
composition?).
- filters (convolution, for instance)
- cursor visualization (perhaps with opengl overlays, so we can have 3-d 
stylus?)
- brushop implementations (which are a kind of filters)
- paint device composition

For display we need to make the projection and the current masks (selection, 
height, wetness) available as textures & allow shaders to work on them. 

For cursor visualisation we simply need to check whether the opengl overlay 
extension is available and use it on the widget.

For composition, filters and brushops we need to make the paint device data 
available as textures. That's the same, in a sense, as for display, except 
that for display we need the projection data converted to rgb (the masks can 
stay single-channel).

I can see two approaches:

- store the tiles themselves as textures if opengl is available and make the 
tiles available through the datamanager (eek!)

- add a getTexture(), writeTexture() to KisPaintDevice (and the tile backend). 
There is no reason why glsl shaders need rgb data. You can put anything in a 
texture and work on it as if it were just another multi-dimensioned array. 
The glsl operations should come from the colorspaces. Cyrille: you need to 
remind me of how we were going to do glsl, mmx and software operations in 
pigment.

I think we should go the getTexture() and writeTexture() route. This can 
always be optimized later with caching the textures; making the tile backend 
have textures as another level of caching (texture, memory, compressed 
memory, swapfile) sounds too complicated for me.

* OpenEXR multi-layer files

I'm not sure whether this is just an import/export filter thing or whether we 
need to review our projection composition or layer stack design. But it's an 
interesting area our most-favoured user (Basse) is very interested in.

* Channels

We discussed this briefly yesterday. Basically, the question is: is there a 
need to view in-band pixel data as separate bands? Or a set of separate 
bands? Or is the math toolbox solution sufficient? 

Possible uses of subset-of-channel views on paint devices are:

- filtering on one or a subset of the channels (like we do for color 
adjustment, but without separate settings for each channel, so you can do 
things like sharpen the L channel of a Lab image).

- compositing one or a subset of channels of two paint devices.

- drawing on one or a subset of channels (same as above, but for the user it 
feels different)

- copying one or a subset of channels (ditto)

The implementation in trunk I started for this (but didn't finish) was to add 
a const QBitArray & channelFlags parameter to KisFilter::process() and 
KoColorSpace::bitBlt() that has a 1/0 flag for all channels in the pixels of 
the current colorspace and force the implementation to check that before 
working with the given channels. 

That's a bit fragile. If we can come up with either a KisChannel class that 
returns iterators that point to the chosen channel instead of the beginning 
of the pixel and have a pixelSize the size of the chosen channel, then we 
don't need to do much work on the composite ops or the filters: they should 
work out of the box. to/fromQImage and to/fromTexture would return a 
grayscale QImage or a texture with only the right pixel.

But there's a performance hit: I cannot image how we could work on a subset of 
the channels except by iterating over all the selected channels individually 
and calling the filter or composite op for all the selected channels 
individually. 

* Pigment

As I said, I've lost track of pigment a little, what's done, what needs to be 
done and what the design is... I wouldn't mind a little summary :-).


-- 
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/20070126/4c522b82/attachment.pgp