Design change for the colorspace manipulation functions (for Krita 2.0)

[Casper Boemann]

On Saturday 03 June 2006 13:03, Cyrille Berger wrote:
> Hello,
>
> ** problems
> I have allways been annoyed by the ever growing list of manipulation
> functions in KisColorspace (currently mathToolboxID, intensity8, darken,
> invertColor, applyAdjustment, createDesaturateAdjustment,
> applyInverseAlphaU8Mask createBrightnessContrastAdjustment)
Ok. It hasn't really grown for the last year, but in general I agree that it 
is something we should address (which is why on IRC we agreed that you wrote 
this mail). Oh and applyInverseAlphaU8Mask and applyAdjustment hardly qualify 
as belonging in the list as they are actually well thought out functions that 
save us from a lot. So the list isn't that long right now. Still it _could_ 
and that we need to take of so that 2.0 can become API stable

> It raises two problems:
> - one, you have to write the functions for each colorspace, or have some
> sort of fallback to LAB (which isn't necesserelly the best choice and might
> cause degradation)
> - two, it's not flexible enought, a plugin might require a new operation
> (if it's an official plugin it is easy to augment the API), impose the use
> of LAB in such operation is a bad idea, because converting to/fromLAB is
> slow (and our filter are allready slow enought) and should only be used as
> either a fallback or if the operation only exist in LAB, and operation are
> not allways even defined for LAB, but might only exist in other
> colorspaces.
As I see it we have N colorspaces and M operations.

What we want to avoid is to have NxM implementations of the operations, but 
instead N+M.

Furthermore since both colorspaces and operations is an extensible list it is 
not feasible to have either every operation in the colorspace (because then 
we can't add operations) nor is it feasible to let the operations know about 
each colorspace(because then we can't add more colorspaces)

So we need decoupling. My intention was a small toolkit of basic operations 
(like applyInverseAlphaU8Mask which you were so fast to condemn before).
That was the idea, but in reality such a toolkit is hard to make. 
Difference,alpha manipulation, mixColors are successes (and why the 
colorspaces haven't grown in a long time) but we need to extend the useful 
toolkit, and not just add every operation we need. The adjustments are less 
than perfect in this regard.

The alternative is that an operation first converts to say Lab, do the 
operation there, and convert back.

> ** requirements
> So what I think, would be the requirements of a replacement solution:
> flexible, have a fallback system (with inheritence, it might be only that
> you inherit from XYZ or LAB), be able to warn the user if the fallback
> operation will require a transformation with a lost of information.
well if we allow fallback like that then plugin writers will stop supporting 
the lesser colorspaces. I dont' like that.

>
> ** proposition
> I think we should do like every other single bit of krita, and have a
> registry (maybe two, one for adjustement operation, and one for generic
> operation).
>
> so will would have:
> KisColorAdjustment* createAdjustement(KisID adjustementID,
> parametersforadjustement) (currently parametersforadjustement = {Q_UINT16
> **transferValues }, you might object that this isn't flexible enought, I
> ponder if it's worth to instead use QValues in parameters, would
> adjustement require or be usuable with other parameters ?)
>
> And will would have:
> KisGenericOperationFactory* createGenericOperation(KisID
> genericOperationID);
>
> To use this operations, the user would need the header files corresponding
> to that operation and to cast it.
But your suggestion doesn't really address how it should work, as in do the 
job of providing colorspace independence. I still see this as NxM 
implementations. You have at best given a syntax for some fuctions, but I 
fail to see how this should be implemented.

-- 
best regards / venlig hilsen
Casper Boemann