On 12.09.2010 11:37, Rupert Weber wrote:
> Just discovered that the clipping in the new layer modes needs more work.
>
> It's not a problem with colors that originated in sRGB, but the layer
> modes can easily construct colors outside sRGB, or even
> invisible/virtual colors.
> The current behavior is different from floating point/GEGL implementation.
>
> Especially when composing e.g. in Color mode onto a white layer, results
> differ. A red onto white will become yellow (which isn't necessarily
> worse than the red from floating point, as it seems to be closer to
> correct lightness -- but it's different.)
btw, the red returned from the current GEGL implementation is too dark:
the projection eventually converts to linear light "RGB u8" [1] and
these values get fed directly to the screen, which in contrast expects
gamma-corrected values -- that is, at least when color management is turned off.
By numbers:
sRGB 1 0 0 red (color mode) over
sRGB 1 1 1 white
gives LCH(ab) (D65):
LCH 53.24 104.55 40 red
LCH 100 0 % white
the result color is certainly out of gamut:
LCH 100 104.55 40 super-bright red
= RGB 3.11 0.45 0.21 linear light [2]
= R'G'B' 1.64 0.70 0.50 gamma-encoded [2]
with the GEGL projection enabled, GIMP currently delivers
(1.0 0.45 0.21) * 255 = 255 115 55
using proper gamma handling the result, truncated to sRGB, will be:
(1.0 0.70 0.50) * 255 = 255 179 128
hopefully i'm not needlessly complicating things,
yahvuu
[1] to quick'n'dirty test the gamma-correct conversion,
gegl/gimp-gegl-utils.c:61 can be modified to:
case 3:
return babl_format ("R'G'B' u8"); /* former ("RGB u8") */
case 4:
return babl_format ("R'G'B'A u8"); /* former ("RGBA u8") */
[2] babl clamps the results of LCH->RGB conversions to the [0 ..1] interval:
extensions/CIE.c:1286
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
