On 12.08.2010 13:09, Rupert Weber wrote:
> On 08/11/2010 11:20 PM, yahvuu wrote:
>> Me, too, thinks that sRGB is a reasonable assumption. If you want to Do It
>> you will have to take the image's color profile into account. Since most, if
>> not all
>> 8-bit implementations of color operations are agnostic of the current color
>> however, i think it's valid to postpone full color space support until
>> processing takes over.
> I agree. But I considered adding a reserved parameter to the functions,
> so we have the option to later add color management support without
> breaking binary compatibility of 3rd party plug-ins.
>> As far as layer modes are concerned, you are actually free to choose.
>> If i understand correctly, you're on a chase for the 'best' 'color' layer
>> anyway (where 'best' refers to some subjective quality).
> Well, yes for now. But the conversion routines go into the colorspace
> lib and may be used by plug-ins for who knows what. (like the
> Decompose/Compose plug-in.) Then it might become relevant.
> (Then again, nobody complained so far and probably nobody would ever
> notice if we did it Right(tm)...)
only the brave ones who do 8-bit processing with non-sRGB images would notice
that the four 'color' layer modes try the behave the same regardless of working
it's mostly a matter of proper documentation, i think.
For the library: if you add a whitepoint parameter for the conversion routine,
that's fine, i think (left alone side-effects like
performance penalty etc).
If a fixed value gets used, document it, so plug-ins know
what they use.
For the layer-modes: The myriads of possiblities should not clutter the UI, so
i think there
was consensus that you are free to choose the 'best'
formula for the
new 4 layer modes. On the surface these are simply
labelled 'Color' etc,
nitty-gritty details are to be looked up in the
PS: For the future, to make things complicated:
- the scientific users mentioned in the product vision probably want to
choose exactly one of the myriad of possible conversions. This is more
a problem of a suitable user interface than of code bloat.
- A typical operation like sharpening luminance should not involve
creating a new layer.
One way to solve this could be to offer 'virtual color component
channels', so one
can work on a luminance channel -- analogous to working on the red
Gimp-developer mailing list