A nice new feature comes in the next version of G’MIC (2.5.0): the way a filter can dynamically build its graphical interface is improving, which will make the parameter setting interfaces clearer and more concise (possibility to hide or grey elements for example).
You can see here what the next Colors / Simulate Film filter will look like. It will completely replace the “Film Emulation/” section. Another filter “Colors / Color Grading” is also in preparation on the same principle.
In the end, G’MIC will offer more than 550 3D color CLUTs to apply to your images!
I will post pre-release binaries for 2.5.0 with this feature included later today. Version 2.5.0 will be really cool!
Dynamic setting? That’s exciting as we no longer would have to see useless settings in theory. @Joan_Rake1 has asked for that for her glitches IIRC. Not sure what I"m going to do with that.
The latest gmic_gimp_qt works very well.
I did have to back up the old gmic profile and let gmic_gimp create a new one to get everything working. Easy enough to swap back if I want to use the previous 2.4.2 version
I wonder if it is worthwhile to consolidate all of the CLUT related filters into one or at least one sub-category. This would make them easier to discover. Also, I feel like I am missing the fun. I know nothing about Simulate Film, Color Grading and Color Presets because I am a CLI user.
It would be great if 1) all CLUT related filters were in a (sub)category in the plugin and 2) were presented in a clearer manner in the actual documentation. While I appreciate https://gmic.eu/color_grading/index.shtml, as described in the documentation thread, there is room for improvement. I generally don’t know a whole lot about what is available because there are too many CLUTs and I don’t know where and how to preview and compare them.
@David_Tschumperle How exactly does the dynamic gui will work? You can hide element if there’s a condition right? And if so, does the number of input change? It’s probably too early to be asking this question, but as soon as it happen, I’ll probably finish my 8-bit Color Transfer which will make my older version of it obsoleted.
I looked using #@gui as search parameter, and I’m not seeing anything where if value is set, then hide this element. That’s what I’m assuming what will be featured. Also, I learned that it seems that G’MIC support language-dependent GUI. So, in that case, I would need to translate my filter then.
Well, I did install the pre-release and so far, all the custom presets that I’ve tested work fine. Some even seem a bit spiffier but that could just be subjective.
This is still an alpha feature, subject to changes.
But if you are interested in how it currently works, please have a look to the first lines of comment in the gmic_stdlib.gmic file.
More particularly :
# After the closing separator, you may specify a 'visibility state' suffix for the parameter, which can be
# { _0: Hidden | _1: Grayed-out | _2: Visible (default) }.
and
# A G'MIC command can return new values for each parameter of the filter, into the status (see command 'status').
# To do so, the returned status must follow the syntax : {params1}{params2}{..}{paramsN} where N must be exactly
# equal to the number of parameters for the current filter. Optionnally, you can append to each {param}
# its visibility state suffix ( e.g: {param}_1 ).
So, basically you have the possibility to hide/show widgets corresponding to the filter parameters, according to whatever condition you want (basically tested in the code for the filter _preview command). Code of filter #@gui Colormap : fx_colormap,fx_colormap_preview may be a good starting point to understand how this actually works (the code is short enough).
After a long period of nope, bugs, I finally figured it out. I went by this approach though
u “{$1}”
“{$2}"{$1==1?0:2}
"{$3}”{$1==1?2:0}
Actually, nvm. I’m gonna need more time to explore this, but I find it a bit difficult to develop it straight away. Like, I have to assign the correct amount of variables, and then change the u section. That’s what I’m finding.
EDIT: Why do one have to create “{$n}” for all by default visible? That’s the only thing that should be changed if possible as that would fix the productivity issue here.
Clarification EDIT: By the time, I gotten to EDIT, I did figured it out, but however I just don’t find having to put into “{$a}…{$z}”\ often and especially in the end.
). 
