What kind of parameters are supported, and which are not ? For instance, I suppose point() must be split into two float() ? Does GEGL supports a color selector (parameter color() )?
I assume that having GEGL nodes make G’MIC effect non-destructive inside GIMP. For effects like Drop Water, how does it feel ? Non-destructive means effects are recomputed from time to time and I’m a bit afraid that it could be not fast enough (G’MIC has not been primarily designed with real-time effects in mind).
Do you plan to “release” these nodes officially one day or another ? I would be very interested in promoting you (well deserved!) and your work, and sharing this great news on the G’MIC social accounts.
Most of the parameters I think are supported Color works out of the box as it maps nearly directly to Gegl.Color type, I’m not sure about the point() tho - can I ask you to point any g’mic command that uses point() as a paremeter?
I need to say it’s quite fast Gegl caches the results so as long as you dont change any parameter value it should not re-render anything
Absolutely I just need to spend some time and verify some of the generated commands and finish implementing support for Aux pad (it could be handy in some blending operations)
For sure I will keep you posted, many thanks for your kind words again
Regarding the “non destructive nature” of GEGL operations: as soon as you apply the operation result it is no longer non-destructive, I mean the effect is then applied on your image/layer in gimp as any other filter does.
This kind of parameters shows as moveable points on the preview widget.
Technically speaking, they can be replaced by two successive float() parameters that corresponds to percentages along the X and Y dimensions of the previewed image.
You can never have too many of them. https://gmic.eu/gui_filters.txt
List of filters in the G’MIC plugin (1280 filters, 01/12/2025, 15:21:50)
Indeed (without the “About” and “Bush” tags), there are 1226 filters, so 850 is only ~70%.
Regarding the use of point() parameters.
It’s probably not possible (or too complicated) to implement, but Gegl also supports control points (aspect ratio).
And some aren’t even meant for filter. Well, that makes up a irrelevant minority. I have a demo filter which is named “Tupper’s Self-Referential Formula” or something like that, and it shows you can definitely process large integers in G’MIC through “trickery”, and it’s just a demo. So, something like 820 filters are actually applicable. Reduce that by some with dynamic gui and _persistent, maybe a little less than 800.
What could be cool is to have a way (a script?) to automatically update/recompile/re-install the GEGL nodes automatically from the filter update file (that is, e.g. https://gmic.eu/plain_update364.gmic).
This file hosted on the G’MIC server is updated from time to time, when an existing filter gets a new feature, or when a new filter is added, as I did a few days ago:
My ultimate goal is to have a GitHub pipeline that will build all the plugins against latest G’MIC stdllib and package them in some way that users could fetch it without thinking much about it.
@activey , I’ve seen your thread has been shared on Mastodon by @darix:
And reshared by the GIMP account (@patdavid probably ? ):
I’m indeed pretty sure your work on these GEGL nodes for G’MIC could raise a lot of interest in the community (having finally a wide variety of filters in GEGL would be really cool ).
I can only suggest that you keep going!
The post from GIMP made me think a bit about the fact that the G’MIC-Qt plug-in could become useless (at least for GIMP users), and at this point, there are some limitations of GEGL nodes I’m thinking of, and I’d like to discuss with you (it may be that these limitations are technically impossible to solve due to the architecture of GEGL, but I’m not sure).
So, do you think these points could find a solution somehow in the future ?
I must admit I don’t know the details of GEGL very well. TBH, I always thought that GEGL was, from the outset, a library with a somewhat limited scope (for someone like me who often works professionnally with multispectral 2D/3D images, and not “just” color images), so I never took much interest in it. That’s why I’m counting on your opinion!
G’MIC filters that takes multiple inputs or output multiple layers have to be simplified to 1→1 filters. What mechanism could be used to handle multiple input/output layers in GEGL nodes ?
GEGL on-canvas preview could be possibly annoying for complex G’MIC filters that take a lot of time to render (e.g. denoising). For those, a smaller preview widget like in our plug-in seems to be more suitable (renders faster). What’s your opinion about this?
Not sure how GEGL on-canvas preview works for filters that modify the layer resolution (e.g. upscaling). How does it handle this ? Does the “Before/After” preview work as expected?
It seems it won’t be as easy to update GEGL nodes when G’MIC filters are updated, as in the plug-in (one button click ). GEGL nodes are generated in a “static” way. Do you think this could be changed in the future (so having a dynamic interface that is reconstructed each time the GEGL node is launched). I’m not sure about that because I fear the interface of a GEGL node (filter parameters) must be all known before it starts.
Let me know what you think about all this.
And thanks again for your hard work!
In regards of animation support - not sure yet, will have to eventually check. But I some feeling GStreamer would be a better fit for that [well, I have some plans for that hue hue].
ad 1: Im afraid there is no simple way to do it now in GEGL, as it always produces just a single output Have to be investigated…
ad 2: yeah, I’m still considering how to do it best, for now im just using geg:save-pixbuf operation which makes it simple to integrate with GTK4
ad 3: good question I had some hard time with dimension changes, need to have a closer look while I will be validating operation by operation,
ad 4: yes, this wont be as straightforward as it is with gmic-qt plugin, my solution requires static code generation as this is how GEGL introspects the possible properties of a given operation, dynamic properties adding is probably not supported yet… but I think I can ask @Pipping some day [author of GEGL itself]
Color works out of the box as it maps nearly directly to Gegl.Color type, I’m not sure about the point() tho - can I ask you to point any g’mic command that uses point() as a paremeter?
):
Have to be investigated…