Release of G'MIC 3.2

@David_Tschumperle I think I can attempt to make a new mathematical expression called 'vector_sort()' which sort a vector using values from another vector. It’s enables a way to build my 4x8 window thing with closest n color in palette within one fill/eval, and might be useful for other things too. I’ll have to wait for your approval before attempting.

  • 2022/05/11: Release of version 3.1.2.
3 Likes

Typo (commas):

#@cli name : "name1","name2",... : (+)
#@cli : Set names of selected images.
#@cli : - If selection is empty or not explicitely specified, it represents the last 'N' images of the list, where\
# 'N' is the number of specified arguments to the command `name`.
#@cli : - If the selection contains a single image, then it is assumed the command has a single name \
# argument (possibly containing multiple comas).

Anyone having difficulty with parse_cli in v3.1.2? I have a simple command like this:

find : parse_cli print,$1

It doesn’t seem to work for me now… do I need to change something?

what is that intended to do?

parse_cli_print is defined as a command but

parse_cli seems to take the command’s name after output mode

#@cli parse_cli : output_mode,{ * | command_name }
parse_cli : skip “{1=print},{2=*}”

Sorry, there was a typo in the stdlib.
See fix here : https://github.com/dtschump/gmic/commit/7555881710fce998b2cf5ea35632cc47a14e30a1

I’m updating the stdlib, will be ready in 5-6 minutes.

1 Like

oooh nice I never knew that existed!

gmic parse_cli print,gcd_
gmic parse_gui print,Gara

: ) thanks both

1 Like

Here’s another you probably know, but I find it convenient as a command:

#@cli define : _command
#@cli : Display the definition of the specified command.
#@cli : $ define define
define : e $${$1}

and then:
gmic define define
produces

[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./define/ e $${$1}
[gmic]-0./ End G'MIC interpreter.

Good to see that you’re still “lurking” here too :slight_smile:

1 Like

define is quite nice to use as an aid for developing filter. That actually might make it easier for me to create a python script to add more palettes to +pal.

loving that introspection feature - so many things I don’t know, thank you.

yes I do still skulk in the corner and admire this creative community from a distance

Bug Report:

# Run the Below
$ t=5 t<<=2 echo $t

# Result: Strange thing happens
# Expected: 20

Indeed, thanks! :+1:
Fixed with:

I’ll release a new 3.1.3_pre package later today.

I have a idea, I would like to be able to modify multiple array at once.

This won’t work:

$ echo {v=vector(#5,2);v[3,2]=2;v;}

See what copy() can do for you, it’s a very versatile function that can be used to set multiple values of an array.

foo :
  eval "
    A = [ 0,1,2,3,4,6,7,8,9 ];
    copy(A[3],-1,3,1,0);
    print(A);
  "

gives:

[gmic_math_parser] A = [ 0,1,2,-1,-1,-1,7,8,9 ] (size: 9)
1 Like

I have an error building gmic-qt for Gimp on my Mac. “make -C translations” seemingly throws it:
??

make -C translations
make[2]: Entering directory ‘/Volumes/mbkaroSD2/Users/karo/sw/gmic-qt/translations’
No lrelease(-qt5) command available.
make[2]: Leaving directory ‘/Volumes/mbkaroSD2/Users/karo/sw/gmic-qt/translations’
make[1]: Leaving directory ‘/Volumes/mbkaroSD2/Users/karo/sw/gmic-qt’
make[2]: *** [Makefile:9: cs.qm] Error 1
make[1]: *** [Makefile:921: qm_files] Error 2
make: *** [Makefile:565: gimp] Error 2
+ exit

SOLVED: I have added handish qt5/bin to PATH solved the problem. Seemingly this way to generate translations is not fully (qt5) standard!

I got the same error today, but it has been fixed with the very latest version in the git repository.

Is it normal for commands which insert a new image to take longer (“plus” commands) than manually adding a new image then applying it?

I was a bit surprised that running +sqr[0] takes over 20ms with a 1920x1080 image, but running [0] sqr. takes 0ms. This is with v3.1.2.

Edit: the same seems to apply for the [0]x2 shortcut as well, doing [0] [0] takes less time

Update: looks like the console messages. If I run a loop with with no output using v - there’s no difference in speed!

Interesting thanks!
Even if that is related to console message, It’s a bit weird though, as +sqr[0] outputs a single line of log, while [0] sqr. outputs two lines.
Will check that.

Here’s what I last tested, which disproves the console output theory:
gmic sp r 1920,1080,1,3 tic v - repeat 50 { +sqr[0] rm. } v + toc rm
Elapsed time: 1.356 s.

And then this:
gmic sp r 1920,1080,1,3 tic v - repeat 50 { [0] sqr. rm. } v + toc rm
Elapsed time: 0.18 s.

I have no idea what the reason is now…

1 Like