Hello Martin,

On Sun, Nov 9, 2008 at 4:36 AM, Martin Nordholts wrote:

2. With a 100% opaque Addition mode layer put on top a completely transparent layer, the resulting composite becomes 100% opaque containing the unblended Addition mode layer pixels when using GEGL, but completely transparent when using legacy compositing.

Ah, so if I want to make the result preserve the alpha of the underlying layer, I'll need to do that via layer mask?

FWIW, since you changed the meaning of the layer modes, is this a good time to make compositing gamma-correct? Currently, GIMP blends pixels as if they had gamma == 1.0, whereas the typical is sRGB (approximation of gamma 2.2). I thought GIMP would do this as it was switched over to GEGL; it doesn't currently. Evidence:
1. Create a new square image (with sRGB profile or no color profile) 2. Fill with black
3. Add another layer
4. Draw a radial gradient white->transparent 5. Set layer mode to Addition
6. Toggle 'View->Use gegl' on and off. The result is identical; rather than showing a linear blend white -> black, an exponential blend (ie sRGB) white->black is shown.

Small example images attached, 'wrongblend.png' and 'rightblend.png'. IMO it is correct for GIMP to produce results similar to 'rightblend.png' when GEGL use is enabled.

The current plan is to have add kind of compatibility rendering mode so that old .xcfs will render the same as in old versions of GIMP also when using GEGL.

In this case, we should definitely aim to have gamma-correct blending. Legacy compatibility for gamma can be done by binding our current behaviour (pretend the data is gamma 1.0 while it really isn't) to the 'legacy rendering' option (presumably auto-triggered on detection of legacy XCFs)

David

Hello Martin,

On Mon, Nov 10, 2008 at 8:18 AM, Martin Nordholts wrote:

Hi David

David Gowers wrote:

Ah, so if I want to make the result preserve the alpha of the underlying layer, I'll need to do that via layer mask?

Exactly, masking should generally be performed *after* blending with the new layer mode compositing model.

Cool, I like this, it certainly is more consistent :)

FWIW, since you changed the meaning of the layer modes, is this a good time to make compositing gamma-correct?

Yes definitely. In fact, layer mode compositing with GEGL _does_ work on data with gamma = 1.0. That is, the layer mode blending occurs on color data in the babl format "RaGaBaA float", i.e pre-multiplied, linear light 32 bit per channel RGBA.

The reason you don't see a difference when toggling Use GEGL is that now during development the source data, namely the data from the tiles of the TileManagers of the GimpDrawables, are treated as if containing color data in the babl format "RGBA u8", i.e. linear light 8 bit per channel RGBA. A more correct assumption would be "R'G'B'A u8", i.e.

Thank you for explaining that, it was just what I suspected :)

I'll see what happens when I make that change :) (apparently just one line, app/core/gimpprojection.c:391, is needed to be changed to implement this now :D)

gamma corrected RGBA.

The long term goal is of course to make sure color space conversions are correct throughout the whole image processing pipeline, taking into account the current color profile of the image etc.

So eventually we need to be able to construct on-demand babl_formats which utilize arbitrary profiles, and have babl depend on lcms to get a acceptably quick transform between those and the standard spaces? And recognize the use of standard colorspace profiles (eg sRGB, linear-light RGB) so we can get faster processing for them?

David

Hi,

On Mon, Nov 10, 2008 at 9:18 AM, David Gowers wrote:

I'll see what happens when I make that change :) (apparently just one line, app/core/gimpprojection.c:391, is needed to be changed to implement this now :D)

This was slightly more complex than I said. Somewhat hackish diff attached.

It effects color tools as well as compositing. (that may be controversial, since it changes the meaning of existing Levels, etc.. tool settings. It does mean you can do a proper linear inversion, and recoloring with the Curves tool is a good deal more intuitive than before. (recoloring with 'colorize' is VASTLY better than before -- the output actually is good quality :))

Easiest way to see the color-tool difference is to make a greyscale gradient and use the Levels tool (set output minimum to 255 and output maximum to 0, then toggle 'Colors->Use Gegl')

It exposes a bug in either the 'threshold' op, or babl. Try it with default settings, on a greyscale B->W gradient, and notice #ffffff becomes black rather than white

Of course, this does not fix the various places where we refer to values in range 0...255 (eg Threshold dialog) where really, we should use 0..1 or 0...100. IMO adjustment step-size needs to be carefully thought out -- 1/255.
(0.0039215686274509803)
is actually wrong (because the adjustment is done in linear space; the correct minimum step size is
0.00030352698354883752)

Lastly! I don't know whether this merges shadow-tiles in linear-light RGB or not. It appears that it does, but I haven't run proper tests yet :)

I am amazed and excited how easy this was :D

David

Hello,

On Mon, Nov 10, 2008 at 12:50 PM, David Gowers wrote:

Lastly! I don't know whether this merges shadow-tiles in linear-light RGB or not. It appears that it does, but I haven't run proper tests yet :)

No, it doesn't.

David