On Thu, Sep 16, 2010 at 2:15 AM, Rupert Weber <g...@leguanease.org> wrote:
> On 09/14/2010 09:23 PM, yahvuu wrote:
>> yep, that yields the desired RGB triple 255, 179, 128 for the example under
>> discussion (i.e. blending red over white using 'color mode').
>> However, after reading some more code, i'm less than shure it does so for
>> the right reasons. Same goes with my previous explanation of gamma 
>> mismatch...
> But if GIMP is feeding non-linear sRGB to GEGL, isn't that the right
> reason for GEGL to treat it as what it is?
> The discussion in the link you sent seems to support that.
> Of course, for all the RGB layer modes (i.e. everything but
> Hue/Sat/Color/Value) backwards compatibility makes it a different story.
> Rupert

Hi, I have a bug report.
Saturation handling seems to effect brightness.
In Saturation or Color draw/layer modes, this shows up as repeated or
overlaid paint making the result distinctly brighter.

Try making a flat region of color #2a7e23, selecting Pencil tool,
choosing Color mode and a large brush, and painting #11e500 repeatedly
over the same area.
This is using the latest patch, and independant of whether the
0001-app-gegl-Let-GEGL-assume-sRGB-for-layer-modes.patch is applied.

In general, you can manifest this bug by picking a dark color,
making a region of it, and painting over with a HSV value-increased
version of same color.
Ideally, this would possibly change Hue or Chromaticity, but shouldn't
change Lightness significantly. Looking at the LCH color selector, L
rises ~2 points for each paint application in my example.

This mainly appears when applying a brighter color which has a
significantly increased C value, but not always, IMO -- for example
#4eda3c on #004500 (avg 3-4 L diff / application)

I'll happily test any further patches for this. IMO if this issue is
fixed, then it should be ready for integration into git master.
Gimp-developer mailing list

Reply via email to