I’ve built the binary packages for version 2.8.0_pre and uploaded to the G’MIC website, you can get it there, to continue getting filter updates :
Any feedback appreciated!
1 Like
Updating and compatibility
update (Version 2.8.0 (pre-release #191030)) doesn’t give me the newly committed afre_orien. Are there still issues?
Also I am uncomfortable having the filters be only available for people who upgrade regularly. Not everyone will have the latest version or know how to upgrade. Is there a way to ensure backwards compatibility or at least define compatibility so that the update command may determine what to update for which version?
Licensing
update280.gmic is dual licensed but afre.gmic only uses CeCILL v2.0. Some filter writers may add additional clauses. I think it might be a good idea to delineate which filters have which licences to make it clearer. Right now update*.gmic is simply dual licensed as far as anyone who reads it is concerned.
About afre_orien : I’ll check. Apparently, the command is indeed compiled in the update280.gmic file, but was not send to the server, which I don’t understand.
About Licensing:
Basically, the file update280.gmic is a concatenation of the stdlib file and the gmic-community files. Theoretically, I’m not allowed to generate update280.gmic if all licenses of the gmic-community files are not compatible together.
From what I understand, I think we can currently choose a copyleft license (with a contamination clause, like CeCILL v.2) for applying to the update280.gmic file, and it will be OK.
If a contributor’s file in gmic-community has a more permissive license (e.g. LGPL or CeCILL-C), then I’m still authorized to generate the update file, and license it with a less permissive license, and people interested by a filter code in those files can still get it with the more permissive license as well.
Anyway, in the future, we have to take care of the license compatibility when a new file is added to gmic-community.
About filter updates:
IMHO, there are no simple answers to this problem. We have two possible approaches:
- Either we force ourselves to keep a strong backward compatibility of the G’MIC syntax and API when new versions are out, so at least, people of older versions can still update and use some of the new filters (those that do not require the use of new introduced features).
- Or, we have some breakpoints sometimes, and freeze the filter updates for a set of older versions.
I am more in favour of the second solution. As the G’MIC-Qt plug-in knows its version number, it can still get the latest filter updates that have been done for this particular version.
So, users of older versions can still use some of the filters from gmic-community.
And, from a developer viewpoint, having all filters use a common syntax makes things really easier to maintain (actually, I would be already dead if I had to maintain the filter codes for each possible released G’MIC versions…).
Another point to consider : The GIMP team is working on a resource manager directly integrated into GIMP. This means that in the future, plug-ins would be updated automatically for the users (just as it does on Linux, if you install it via the packages).
This will solve the problem of the updates of the plug-in binary.
1 Like
There is a problem with move. Moving down works but moving up or moving in reverse isn’t behaving as expected. E.g.,
gmic sp tiger,flower,chick mv[1] 0 # flower,tiger,chick
gmic sp tiger,flower,chick mv[1] 2 # tiger,flower,chick
gmic sp tiger,flower,chick mv[1] -1 # tiger,flower,chick
That’s expected.
move[img] pos actually inserts the image img between the positions pos and pos+1, and then every image that was before in position [pos...-1] is ‘shifted’ to the right.
For instance, if you have a list with 3 images, you want positions 2 and -1 to represent the same position, so mv[0] 2 and mv[0] -1 should be equivalent (and they are).
It is not really possible for move to act differently if you move an image forward or backward in the list. I mean, for a single image, it could be possible, but what about moving a selection of several images at a position that is located in the middle ? Headache guaranteed 
If you want to move an image at the end of the list, then mv[img] $! is the solution.
Basically, it is unusable in this state. The window goes to the top left corner of the screen. The top bar is off-screen and I cannot interact with it. If I try to resize the window or forcibly move it using Windows shortcuts, it redraws itself to its default state. If I click on the main window after the array window shows up, not only do both windows redraw themselves, but the main window covers the array window, preventing me from querying the values.
I noticed two issues with the plugin. If there are solutions for both that I am unaware of, please let us know.
1 Notes cannot take parentheses. I tried escaping them.
2 In a filter where resizing and alignment is present, preview may be cropped and blending layers misaligned. This happens when accepting multiple input layers. The workaround is to reset zoom.
PS If the outcome is smaller than the largest input image, you get a misalignment (the blending is misaligned: see where grass touches the lip) and a crop in the preview. E.g.,
Correct alignment looks like this
Just thought a bit about that later, and mv[img] 100% is also working (and is often more user-friendly on the command line, because ! is a reserved character, at least on bash)
@David_Tschumperle I was updating to see if Fibonacci filter arrived to g’mic. It did not, so I’m guessing there is going to be a stable release of 2.8 soon.
There is one minor syntax change in the G’MIC language that probably makes future versions of the G’MIC stdlib not compatible with current version 2.8.0_pre, so I suggest you update your binaries for 2.8.0_pre as soon as possible.
Basically, the selection shortcuts ., .. and ... (resp. for [-1], [-2] and [-3]), will be accepted also between brackets []. That way, it’s now valid to write something as a[0,.] c (rather than a[0,-1] c).
… very good extension to write scripts!
If I am reading this correctly, I always run into this problem when I take in user input. I have to code around this in awkward ways, including changing the way the command behaves. One more request: would it be possible to have a way to convert dot shortcut strings to the long form? That would help make console output text clearer.
BTW,
is that an extra not?
It’s now valid, sorry.
Is it possible to do this?
f "a=[0,1,2,3];b[4,5,6,7];merge(a,b) #[0,1,2,3,4,5,6,7]#"
For context, I am rewriting rep_stitch. That means I would need to get n channels value based on values found in a combined set of channel values inside a vector that contains a size of values multiplied by channel numbers.
No, but :
f "a=[0,1,2,3];b[4,5,6,7]; c = [ a,b ]; #[0,1,2,3,4,5,6,7]#"
Hi David.
Question and request - can you expand the information contained in:
List of filters in the G’MIC plug-in
https://gmic.eu/gui_filters.txt
I will give an example:
Artistic / Anguish (command 'samj_Angoisse_en')
Information from gmic_qt_log:
- [gmic_gimp_qt]./preview/ v 0 samj_Angoisse_en 1,5,0,5,100,2,4,1,250
- [gmic]-1./ Start G’MIC interpreter.
- [gmic]-1./samj_Angoisse_en/samj_Angoisse/ Set local variable ‘iterations=1’.
- [gmic]-1./samj_Angoisse_en/samj_Angoisse/ Set local variable ‘dog_sigma1=5’.
- [gmic]-1./samj_Angoisse_en/samj_Angoisse/ Set local variable ‘dog_sigma2=0’.
- [gmic]-1./samj_Angoisse_en/samj_Angoisse/ Set local variable ‘sw_threshold=5’.
- [gmic]-1./samj_Angoisse_en/samj_Angoisse/ Set local variable ‘smooth_amplitude=100’.
- [gmic]-1./samj_Angoisse_en/samj_Angoisse/ Set local variable ‘noise_amplitude=2’.
- [gmic]-1./samj_Angoisse_en/samj_Angoisse/ Set local variable ‘noise_type=4’.
- [gmic]-1./samj_Angoisse_en/samj_Angoisse/ Set local variable ‘opacite=1’.
- [gmic]-1./samj_Angoisse_en/samj_Angoisse/ Set local variable ‘sharpen_amplitude=250’.
Information from updatexxx.gmic:
…
#@gui Artistic
#@gui Anguish : samj_Angoisse_en, samj_Angoisse_en(1)
#@gui : note = note(“Iterations”)
#@gui : Iterations = int(1,1,3)
#@gui : note = note(“Dog”)
#@gui : Sigma 1 = float(5,0,10)
#@gui : Sigma 2 = float(0,0,10)
#@gui : note = note(“Segment Watershed”)
#@gui : Threshold = float(5,0,10)
#@gui : note = note(“Smooth”)
#@gui : Amplitude = float(100,0,200)
#@gui : note = note(“Noise”)
#@gui : Amplitude = float(2,0,10)
#@gui : Type = choice(4,“Gaussian”,“Uniform”,“Salt and pepper”,“Poisson”,“Rice”)
#@gui : note = note(“Blend”)
#@gui : Opacity = float(1,0,1)
#@gui : note = note(“Sharpen”)
#@gui : Amplitude = int(250,0,500)
#@gui : sep = separator(), note = note(“Author: Samj. Latest Update: 2015/03/27.”)
samj_Angoisse_en :
…
New List of filters in the G’MIC plug-in (something like a PDB database):
Artistic / Anguish (command 'samj_Angoisse_en iterations(1,1,3),dog_sigma1(5,0,10),dog_sigma2(0,0,10),sw_threshold(5,0,10),smooth_amplitude(100,0,200),noise_amplitude(2,0,10),noise_type(4,“Gaussian”,“Uniform”,“Salt and pepper”,“Poisson”,“Rice”),opacite(1,0,1),sharpen_amplitude(250,0,500)
A big “Thank you !” to the 49 sponsors who donated to support our project, in October and November !
I’m currently working on improving the way the verbosity of the messages is managed in G’MIC.
Big changes on the way.
Basically, the use of the commands verbose will be very reduced in the future, most of the commands just won’t need to deal with that, as things will be done automatically.
Still a lot of things to fix right now, but I’m on the right way
3 Likes
Bug? I probably ran out of memory, a usual occurrence.
gmic a0.gmz afre_y50 1 colormap 0
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input file 'a0.gmz' at position 0 (1 image 6016x4010x1x3).
[afre]^_^) y50: Compute luminance (D50 Rec.2020) of image [0].
[gmic]-1./ Estimate full colormap for image [0].terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc