On 09/06/2010 09:17 PM, Sven Neumann wrote:

I am not so happy about the choice of the term "obsolete". The old layer modes are not obsolete. I'd suggest to use the term "legacy" instead.

I'm ok with either.
The obsoleteness is what I tried to find out earlier. Right now GEGL doesn't support the old HSV/HSL modes. Is it supposed to?

A reminder of Martin's suggestions: > I think the names needs to suggest that new files should avoid using > those layer modes.
>
> Other alternatives:
>
> "(compat.)"
> "(legacy)"
> "(obsolete)"
> "(broken")
> "(old)"

I'd consider legacy/obsolete/old defendable. 'old' is nice for its shortness, 'legacy' doesn't sound as negative. The old modes aren't broken (just different and maybe less useful) and 'compat.' is, well, somehow ugly.

But I'll let you guys bang each others' heads over that. ;)

Rupert

About bablizing the layer modes: I spent a little time with babl and all I can say right now is that it will definitely take a while to get that done.
So far it's been like a set of Russian puppets, and I don't think I've even reached the innermost yet.
I wouldn't dare to give an estimate, but given that there are so many questions not even asked yet, let alone answered, I'm pretty sure that it won't be in 2010.

Regards

Rupert

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.)

The problem is that I have to clip twice in integer mode: once from Lab to XYZ, then again from XYZ to RGB.

Widening the lab-to-xyz LUT solved the problem for red, but created strange color bandings for blue, so it probably leads to integer overflow somewhere.

In other words: I'll have to work on the lab-to-rgb conversions...

Rupert

On 09/12/2010 11:37 AM, Rupert Weber wrote:

Just discovered that the clipping in the new layer modes needs more work.

Problem solved.
Not reposting the patch for now to keep the noise down, as I'm sure there will be other small issues.

Rupert

On 09/13/2010 01:05 PM, yahvuu wrote:

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. [...]

hopefully i'm not needlessly complicating things, yahvuu

The way I understand it is that GEGL intentionally uses the non-gamma-corrected pixels in order to render like the current modes. (As Øyvind had explained somewhere earlier on the list).

But for the LCH layer modes that is just wrong without being necessary, as there are no legacy LCH modes, and Lab/LCH is whole different thing from doing RGB arithmetic anyway.

I am proposing the attached tiny patch to correct that (Actually I believe someone else described that solution here on the list somewhere, but I maybe confusing it with Øyvind's post).

Handling other modes is an opp and thus completely invisible to me ;o)

There is a very interesting article about operations on non-linear RGB which I think I found linked on bugzilla: http://www.4p8.com/eric.brasseur/gamma.html

Rupert

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

On 10/04/2010 04:17 AM, David Gowers (kampu) wrote:

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.
[...]
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.

Unfortunately, that's not fixable but a result of the too small gamut of the sRGB working space.
Combining the lightness of #2a7e23 with hue/saturation of #11e500 results in (linear) sRGB values which are negative for red and blue. Clipping those to 0-255 yields the result you observed (the color becomes lighter than it should be).

Whenever you observe this misbehavior, at least one of the resulting RGB components should be at 0 or 255 -- otherwise it really would be a bug.

The only fix is to use a larger working space, like scRGB.

Regards

Rupert

On 10/05/2010 01:20 AM, David Gowers (kampu) wrote:

In that case it really is a bug. Neither the input colors or output colors contain 255.

The output color series is: 008700 008d00 009300 009800 009d00 00a200 00a700 00ab00 00af00 00b300 00b600 ...

But the outputs contain 0's. And that's not because they happened to come out to exactly 0, but actually they should be t found a way to get perfect round-trips without being much slower.

I currently have a floating point version which is at least 4 times slower. It gives perfect Lab roundtrips, and almost-perfect for LCH (off by one for 0.00006% of RGB values). It still needs quite a bit of work, but I am hoping to turn that into a viable babl candidate.

Regards

Rupert