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 documentation/src.
regards,
yahvuu
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
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
