[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Design change for the colorspace manipulation functions (for Krita
From:       Cyrille Berger <cberger () cberger ! net>
Date:       2006-06-03 11:03:33
Message-ID: 200606031303.34082.cberger () cberger ! net
[Download RAW message or body]

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 ---
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop

[prev in list] [next in list] [prev in thread] [next in thread]