Re: [Gimp-developer] Layer modes ported to GEGL, explanation of new compositing model
Hello, On Mon, Nov 10, 2008 at 12:50 PM, David Gowers <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer modes ported to GEGL, explanation of new compositing model
Hi, On Mon, Nov 10, 2008 at 9:18 AM, David Gowers <[EMAIL PROTECTED]> 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 #ff 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 -- Reticience and self-censorship is a farce. The deceiver does not himself know the truth, anything that he holds back he holds back not only from others but from himself. Fuck censorship. "I yam what I yam." Index: app/core/gimpimagemap.c === --- app/core/gimpimagemap.c (revision 27590) +++ app/core/gimpimagemap.c (working copy) @@ -536,7 +536,7 @@ gegl_node_set (image_map->input, "tile-manager", image_map->undo_tiles, - "linear", TRUE, + "linear", FALSE, NULL); gegl_node_set (image_map->shift, @@ -544,9 +544,12 @@ "y", (gdouble) rect.y, NULL); + + /* XXX it's not clear to me whether linear should be FALSE or TRUE here. + I just went with the nicer-looking output */ gegl_node_set (image_map->output, "tile-manager", gimp_drawable_get_shadow_tiles (image_map->drawable), - "linear", TRUE, + "linear", FALSE, NULL); image_map->processor = gegl_node_new_processor (image_map->output, Index: app/core/gimpdrawable-operation.c === --- app/core/gimpdrawable-operation.c (revision 27590) +++ app/core/gimpdrawable-operation.c (working copy) @@ -76,12 +76,13 @@ input = gegl_node_new_child (gegl, "operation","gimp:tilemanager-source", "tile-manager", gimp_drawable_get_tiles (drawable), -"linear", linear, +"linear", !linear, NULL); + /* XXX is above correct? input and output are nonlin, op is lin */ output = gegl_node_new_child (gegl, "operation","gimp:tilemanager-sink", "tile-manager", gimp_drawable_get_shadow_tiles (drawable), -"linear", linear, +"linear", !linear, NULL); gegl_node_add_child (gegl, operation); Index: app/core/gimpprojection.c === --- app/core/gimpprojection.c (revision 27590) +++ app/core/gimpprojection.c (working copy) @@ -388,7 +388,7 @@ gegl_node_new_child (proj->graph, "operation","gimp:tilemanager-sink", "tile-manager", gimp_projection_get_tiles (GIMP_PICKABLE (proj)), - "linear", TRUE, + "linear", FALSE, NULL); gegl_node_connect_to (graph, "output", Index: app/core/gimpdrawable.c === --- app/core/gimpdrawable.c (revision 27590) +++ app/core/gimpdrawable.c (working copy) @@ -1227,7 +1227,7 @@ NULL); gegl_node_set (drawable->source_node, "tile-manager", drawable->tiles, - "linear", TRUE, + "linear", FALSE, NULL); return d
Re: [Gimp-developer] Layer modes ported to GEGL, explanation of new compositing model
David Gowers wrote: > 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 Exactly where in the pipeline to insert color profile conversions is an open question. Some kind of integration with babl sounds sane to me as well. We probably want to make use of caching in GEGL somehow too, to avoid doing color space conversions all the time. - Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer modes ported to GEGL, explanation of new compositing model
Hello Martin, On Mon, Nov 10, 2008 at 8:18 AM, Martin Nordholts <[EMAIL PROTECTED]> 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 -- Reticience and self-censorship is a farce. The deceiver does not himself know the truth, anything that he holds back he holds back not only from others but from himself. Fuck censorship. "I yam what I yam." ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer modes ported to GEGL, explanation of new compositing model
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. > 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. 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. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer modes ported to GEGL, explanation of new compositing model
Hello Martin, On Sun, Nov 9, 2008 at 4:36 AM, Martin Nordholts <[EMAIL PROTECTED]> 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 <><>___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Layer modes ported to GEGL, explanation of new compositing model
Hi The layer modes have now been ported to GEGL. As layer mode compositing with GEGL uses a different model than legacy layer mode compositing it deserves some elaboration. If you want to try out the new layer mode compositing you can do View -> Use GEGL in GIMP trunk. The new model is based on the one in the SVG 1.2 draft: http://www.w3.org/TR/2004/WD-SVG12-20041027/rendering.html The model used is Dca' = f(Sc, Dc) * Sa * Da + Sca * (1 - Da) + Dca * (1 - Sa) Da' = Sa * Da + Sa * (1 - Da) + Da * (1 - Sa) where Sc is the layer color (channels) Dc is the composite of the layers below Dc' is the result composite Xa means alpha channel Xca means pre-multiplied data f(Sc, Dc) is a blending formula Things to note about this model: The contribution to the end pixel that comes from the layer mode specific blending is proportial to Sa * Da, i.e. the subpixel area that contains both the layer and below composite in the Porter-Duff alpha compositing model. The rest of the contribution to the end pixel comes from the unblended (since there is nothing sensible to blend with) layer and below composite pixels: Sca * (1 - Da) + Dca * (1 - Sa). All layers independent of layer mode are treated as having an opacity and thus affect the alpha of the final composite. This new model creates a more consistent and predictable layer mode blending experience. Examples of differences compared to legacy layer mode compositing: 1. With a 50% opaque Addition mode layer put on top a 50% opaque Normal mode layer, the resulting composite has an opacity of 0.5 + 0.5 - 0.5 * 0.5 = 75% with GEGL layer mode compositing, but 50% with legacy layer mode compositing. 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. 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. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
