GNOME Bugzilla – Bug 161449
programming GEGL operations through node properties
Last modified: 2018-05-22 12:01:55 UTC
I had initially thought of this for the GIMP - a way to have a custom compositing mode that would have,as one of it's parameters, a bytecode stack allowing almost programaticaly operations between two pixel values. I had built a patch for it, back in GIMP 1.3.15 - the code won't apply to anything existing today. Either, I did not find at the time a way to pass down the opcode string to function, so it is sort of hardcoded in the compositing code. Anyway, the part that parses the bytecode and composites 8 bit RGBA pixels using intermediary 16.16 fixed point values for the channels used to work. I will attach the patch here, so that people can have an idea of how it worked, and make use of any concept in there that could be used in GEGL.
Created attachment 34895 [details] [review] 'prrof of concept' patch for GIMP 1.3.15 There it is. The fun is in the "custom_pixels" function.
The idea of GEGL is that everything is custom so the summary of this bug report isn't very well choosen. We can of course keep it open as a way to store your code but you would have to rewrite all this as GEGL ops anyway.
Sven... I cannot think of a name other than a Custom combine op for somthing that is a custom combine op. Feel free to change the summary as you like.
Creating a "custom compose op", might as well be done in terms of a graph. GEGL already provides arithmetic operations as "compose ops" by combining multiple of these within a composer node containing a graph. You would be able to acheive the same results. Being able to express it directly as a formula might be convenient in some cases, this could be achieved by writing a parser that generates an abstract syntax tree, which incidentally would be the GEGL graph needed to evaluate the custom compositing mode. (there is no reason this should be limited to compositing modes though, filters have exactly the same needs and the same possibilities exist there.)
Changed the topic to "Programming operations through node properties". This should be done by having the behavior as a string parameter to an operation, that does "something" behind the scenes. It might be compiling C code, running lua code or other forms of manipulation that are considered useful. At the moment, porter duff operations as well as the SVG compositing modes are implemented with a ruby generator at the moment, GIL is meant to be the unified way of specifying such things in GEGL, and thus that would probably be the desired language. I do not know how well GIL works at the moment though as it is dormant code. a = [ ['normal', '(1.0 - qa) * cb + ca'], ['svg_multiply', '(1-qa)*cb + (1-qb)*ca + ca*cb'], ['screen', 'cb + ca - ca * cb'], ['darken', 'MIN ((1 - qa) * cb + ca, (1 - qb) * ca + cb)'], ['lighten', 'MAX ((1 - qa) * cb + ca, (1 - qb) * ca + cb)'] ]
Lowering priority, creating a mathmap or gluas like compositing like shader operation based on this code is still an option, not one with a high priority though.
Seems reasonable to set patch state as 'obsolete'
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gegl/issues/1.