I 'm working on a custom GEGL plugin that uses G’MIC processing inside. I spent some time on analyzing code of gmic-qt and gimp host and made a first version working with basic filters like “negate”, “wind” or similar but not all the G’MIC operations are functional
for my learning/understanding. there is already a gmic plugin for gimp IIRC.
do you use gegl outside of gimp or what would be the advantage of hooking up gmic in gegl?
I’d like to tell you a few random things (I’ve already discussed a bit on Discord with you, but Discord is not really user-friendly):
Having a GEGL operator that integrates G’MIC is an awesome thing. It’s something I’ve been thinking about for a long time but never had the time to look into in detail. There’s definitely potential there!
I think that GEGL automates the creation of graphical interfaces for its operators, whose parameters are well defined in advance. Since G’MIC works in much the same way (the G’MIC-Qt plug-in creates dynamic interfaces from the written definition of filter parameters), do you think it would be possible to somehow “automate” the creation of GEGL operators (maybe a single .c file) for each of the G’MIC-Qt filters independently? So, at the end, you would get a (huge) collection of .c files with the right parameters, that could be compiled and added as new independent G’MIC nodes in any GEGL-based interface (GIMP included) ?
I’m not sure how much work this would involve, but it doesn’t seem that easy to me, and may not even be feasible as it stands (for example, do the GEGL parameters cover all possible G’MIC parameters?). So, I am interested in any information on this subject!
One of the hard-to-convert features of G’MIC is that a G’MIC filter can take any number of images M as input and generate any number of images N as output. This can typically be M=N for filters that work independently on each image, but it can be anything else (this is the case for the “Drop Water” filter, which generates additional layers for each image passed in as input, so N>M). But the fact is, there is absolutely no way, when parsing the filter definition, to know by advance how many layers a particular filter will output. It’s actually not a limitation it’s a feature Because some filters may generate additional layers or not, depending on the value of the parameters they are called with (e.g “Drop Water” has a parameter “Output As Separate Layers”.
As you find out, you can still “force” the output of a filter to be a single layer by adding command gui_merge_layers at the end of the G’MIC command line.
But you can also force a G’MIC filter to have a 1→1 behavior (one output image for each input image), by doing something as:
Doing this kind of construct ensures that a G’MIC filter will consider only a single input image at a time, and will output a single image, whatever the number of input images you gave.
Beware, some filters requires at least two layers though, to work properly, or at least to support some of its feature (e.g. “Stylize” with custom style selected).
That’s all I can say for now. I’m really excited about your project!
I appreciate your kind words I need to say I spent some time on this hehe.
As it comes to generating C code for each G’MIC operation - yeah, I was considering it to be honest But as you said it may be not possible because of different data types used for operation arguments, but - I need to check
For the first version I would probably go with just regular command input and then refine it in next release.
@David_Tschumperle I have one question tho, there are some g’mic operations that are just generating stuff instead of operating on the input image, for instance:
fx_image_sample 0,0,0
when I use it in my GEGL plugin with the effect is funny hehe
In GEGL world this kind of operation would have just a source and no sink, but in order to do that I will need to recognize if given g’mic command expects input or is just an image generator - then I could include it in the code generator.
Do you think it would be possible to get this info by reading output of gmic_decompress_stdlib()? I already created a parser for it but I’m not sure how to make this distinction.
No way. Sorry to say this in such a way, but…
A G’MIC command takes a list of M images (M possibly 0) as input and outputs a list N images (N possibly 0 or whatever). There is absolutely no way to know how many images a G’MIC filter will output. (you may imagine to implement your own filter that produce an arbitrary number of output images for instance).
I understand this is a problem if you deal with “static” nodes that require to know these numbers M or N.
What could be done anyway is to “estimate” (without guarantees), for each command the number of output image, just by calling it with default params, and an input like, a 1x1 image, and count the number of output images.
For instance:
1 fx_drop_water 0,20,2,80,0,3,35,10,1,0.5,0.25,0.5,0.75,0.05,0.15,1 u $! rm
will return (in the status value), the number of ouput images.
Of course, it works only for filters that produces a fixed number of outputs (so, where no parameters of the filter can change that number, and if this number is not random, of course).
I think I’ve found some kind of workaround “GEGL way”, for instance when somebody would like to use just fx_image_sample in order to just generate an example image it would possible to use an empty GEGL buffer as an empty input and crop it to a specified size and just use the exact same size inside fx_image_sample
That’s really incredible. Is the GEGL interface generated automatically by parsing the filter parameters?
If so, that’s fabulous, and you’re fulfilling a dream I’ve had for a long time!
Up to some extent - yes What gmic-qt does and the gegl plugin cannot is that it can generate a separate layer for each gmic image output while in GEGL there is just a single output for each node, always
So as long as somebody dont need some fancy multi-layer split and can live with a flattened outputs then yes
