API change proposal for pigment's KoColorSpace

[Boudewijn Rempt]

On Friday 01 December 2006 12:30, Cyrille Berger wrote:

> > If we're serious about opengl, (...)
>
> Well we are :) at least the architecture should be open for it.

Still, it needs a serious bit of design to make it possible, because we've got two ends that don't know anything about each other: the tile backend and the colorspace functions that manipulate the data.

I'm not sure how we can make clear to the colorspace functions that the data we pass are handles to textures, instead of pointers to arrays of bytes. I'm afraid that in order to allow shader programs to replace lcms functionality (or simpler functionality like convolution, we'll have to have a much closer connection between data backend and functionality. 

It's definitely true that using opengl makes wondrous things possible: Corel Painter uses it, as does Art Rage and Impasto. For one thing, bumpmapping and lighting according to paint and canvas structure or highlighting according to wetness becomes a snap. But whether it's possible to implement that AND still also have all functionality available for non-opengl AND keep a clean design is beyond me at the moment.

Maybe bluescada has an idea (but he isn't on the ml, is he?, maybe Adrian has an idea? I suspect that to do this well, an application has to concentrate on doing primarily opengl.

> > > Yes exactly, but I think 'conversion' is a bit too narrow a term for
> > > this, since afaik it also is a problem with transformations.
> > > Personally, I think I like the idea of having a per-thread cache, if
> > > that can be done efficiently with the threadweaver thing. Using a mutex
> > > on this kind of thing defeats the primary purpose of multithreading
> > > this anyway, since most of the time will be spent in these routines (I
> > > think, empirical verification could be needed ;)).
> >
> > Yes, indeed. Mutexes make the whole thing serialized anyway.
>
> Here is what I propose :
>
> class KoColorTransformationOperation {
>
> virtual void transform(const quint8 *src, quint8 *dst, qint32 nPixels) const = 0;
> 
> };
>
> virtual KoColorTransformationOperation *createBrightnessContrastAdjustment(quint16 *transferValues) const = 0;
> virtual KoColorTransformationOperation *createDesaturateAdjustment() const = 0;
> virtual KoColorTransformationOperation *createPerChannelAdjustment(quint16 **transferValues) const = 0;
> virtual KoColorTransformationOperation *createConvertOperation(const KoColorSpace * dstColorSpace,  qint32 renderingIntent = INTENT_PERCEPTUAL) const = 0;
>
> Then it's up to the thread to keep a cache of the operations he wants/needs
> to keep.


Eh? Maube it's just the layout or something... What's the connection 
to threading? How is this to be used? How are we making sure we don't 
recreate the transforms more often and don't new memory more often than 
necessary?

And in any case: createConvertOperation would better be createConversionOperation.
-- 
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/20061201/e8b5d36d/attachment.pgp