Hi,

1) ...

Agreed.

2) A bunch of GIMP filters have become GEGL operations, but names of settings need revisiting, defaults need a reality check. Also, value range is not necessarily the same thing as the range that should be visible in UI, and some variables need a non-linear ("gamma") property that can be set.

Some times ago, I tried to keep http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL up-to-date. It mixes GIMP plugin's with GEGL' operations, but still contains a lot of comments about current states of some GEGL operations.

It's not complete at all and not 100% accurate, but I think this really helps to keep track of things that have to be done or at least that have to be reviewed. A "WIP" tag without comment means that the operation was never reviewed.

It would be great if all remarks that are not directly fixed in GEGL, are written in that page, so they don't get forgotten. There or in Bugzilla (but there are so many things that the wiki seams easier for now I think).

While 1) needs some knowledge of the problem, 2) is really accessible for everybody: pick one operation, try it in GIMP, see if there is anything wrong with it, fix some parameters values/names (like in commit 1a0e01e9dd3d7f), add a "gamma-correction" toggle if needed (like the "srgb" boolean in over.c), send a patch in bugzilla and "done". Possibly add comments about bugs or other wider improvement, but that's all.

I hope this will help people willing to get involved and do not hesitate to call for help on irc if needed.

Kind regards,

Téo

On Thu, Sep 4, 2014 at 9:48 PM, Teo Mazars wrote:
...

add a "gamma-correction" toggle if needed (like the "srgb" boolean in over.

In this particular instance I would offer the opposite advice :). Remove the "gamma-correction" toggle / "srgb" boolean, and create a separate "gegl:over-perceptual" or "gegl:over-gamma" operation.

I consider what was done in GIMP with such sRGB booleans a hack; that accidentally spread to the GEGL code base. From a GEGL color-management perspective; over in linear light space; and over in perceptual light space are two different (compositing) operations; and from the perspective of applications using GEGL - it is easier to deal with property/parameter-free compositors/layer-modes.

/pippin

I am not convinced. The way it's done is fine in my opinion, mainly because it doesn't duplicate the implementation. What you suggest would be to create specialized meta operations foo-linear and foo-perceptual on top of foo with fixed "srgb" parameters and to hide foo... Right? I am not sure why this would help for anything, but I don't see anything wrong. And then it would be just a complement of what was suggested, still really easy to do :)

Kind regards,

Téo

2014-09-05 13:02 GMT+02:00 Øyvind Kolås :

On Thu, Sep 4, 2014 at 9:48 PM, Teo Mazars wrote:
...

add a "gamma-correction" toggle if needed (like the "srgb" boolean in

over.

In this particular instance I would offer the opposite advice :). Remove the "gamma-correction" toggle / "srgb" boolean, and create a separate "gegl:over-perceptual" or "gegl:over-gamma" operation.

I consider what was done in GIMP with such sRGB booleans a hack; that accidentally spread to the GEGL code base. From a GEGL color-management perspective; over in linear light space; and over in perceptual light space are two different (compositing) operations; and from the perspective of applications using GEGL - it is easier to deal with property/parameter-free compositors/layer-modes.

/pippin _______________________________________________ gegl-developer-list mailing list
List address: gegl-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gegl-developer-list

On Fri, Sep 5, 2014 at 2:24 PM, Téo Mazars wrote:

I am not convinced. The way it's done is fine in my opinion, mainly because it doesn't duplicate the implementation. What you suggest would be to create specialized meta operations foo-linear and foo-perceptual on top of foo with fixed "srgb" parameters and to hide foo... Right? I am not sure why this would help for anything, but I don't see anything wrong.

Do note that compositors/layer modes being parameter-less permits doing things like more easily using them as properties of other/meta-nodes using these ops internally, if the behavior changes based on an additional boolean we do not get that. It also means that for a directly generated UI based on GEGL data-structures; this boolean toggle would is exposed.

The desire to do any (compositing) ops in arbitrary color spaces is what should be dealt with by wrapping things in meta-ops; permitting to cast data to CIE Lab, sRGB or even HSV. In the case of over and other standard layer-mode ops, I would rather duplicate the implementation - considering them to be actually different compositing ops. The amount of actual code duplication should amount to _one_ additional line in the ruby code that generates most of GEGLs compositing operations.

/pippin