Re: [Gimp-developer] Fwd: [CREATE] Suggested dates for LGM 2009 Montreal
Hi, On Fri, 2008-11-07 at 20:31 -0200, Joao S. O. Bueno wrote: May 6-7-8-9, 2009. LGM would start on Wednesday morning and end on Saturday, end of the day! That would mean taking at least four days off to participate in the conference. That makes it very hard for anyone who has a regular job. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fwd: [CREATE] Suggested dates for LGM 2009 Montreal
On Sunday 09 November 2008, Sven Neumann wrote: Hi, On Fri, 2008-11-07 at 20:31 -0200, Joao S. O. Bueno wrote: May 6-7-8-9, 2009. LGM would start on Wednesday morning and end on Saturday, end of the day! That would mean taking at least four days off to participate in the conference. That makes it very hard for anyone who has a regular job. The format is under discussion, as are the dates. What do you think about proposing something like having teo core days on the weekend, and one or two days before that for end usre talks and workshops? Something like: thee mroe technical oriented, and inter-software operation talks for subjects like GEGL, the Create Raster format, etc..all would be scheduled on Saturday, and on Sunday we schedule inter-team BOFs and other thing, like the in the first LGM), and thurday and friday would have using the GIMP, doing great art with Inskcape, maybe a plug-in creation workshop, and such? (btw, at my regular job, if I am going to an itnernational conference, I can have the extra days off) Sven ___ 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] Suggested dates for LGM 2009 Montreal
Hello all: I am a very peripheral gimp and gegl player, but if you are having trouble sending someone to Montreal, I almost certainly can go and deliver whatever talk you want me to. (I have family there.) Nicolas Robidoux Laurentian University/Universite Laurentienne (8 1/2 hours driving from Montreal) ___ 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 drawable-source_node; ___
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
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
