Design change for the colorspace manipulation functions (for Krita 2.0)
Cyrille Berger
cberger at cberger.net
Sat Jun 3 13:03:33 CEST 2006
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)
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.
** 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.
** 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.
--
--- Cyrille Berger ---
More information about the kimageshop
mailing list