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 
>> Right(tm),
>> 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 
>> space,
>> however, i think it's valid to postpone full color space support until 
>> GEGLized
>> 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 
>> mode
>> 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
color space...

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 
'physical color
       component channel'.
Gimp-developer mailing list

Reply via email to