Release of G'MIC 3.4

About this: I’m actually a bit to blame for agreeing to implement this feature.
in practice, if you want to have a random value in an open range ]a,b[, it’s better (and faster) to write for instance u(a+eps,b-eps) with eps=1e-5 rather than u(a,b,0,0).
At the end, what the algo does is indeed add/subtract an epsilon to the specified bounds, but it does this every time you call the function, while the bounds can often be precalculated as constant values.
So in practice it’s not that interesting to use.
I prefer not to add these options to the new functions rand() then.

Concerning the srand() problem. I will see what I can do, but in any case, remind that for large vectors, the filling with random values will be done in parallel, and in this case, there are no ways to ensure the ordering of the filling is always the same.
So, in the multi-threaded case, srand() is practically useless.

1 Like

Ah, I understand.

Regarding epsilon value. Wouldn’t it be nice to implement C++ nextafter, and the backward version of that? There’s also use in case of modulo operation here, so you can preserve the value to modulo by.

OK so I confirm what I’ve said.
I’ve done a patch to force the rand() function to be sensible to srand() .
And I get this:

foo : check "isint(${1=10}) && $1>0"
  eval "
    srand(10);
    U = round(rand(#$1,0,100));
    srand(10);
    V = round(rand(#$1,0,100));
    print(U,V);
  "

And for small N, I indeed get similar vectors:

$ ./gmic foo 10
[gmic]./ Start G'MIC interpreter (v.3.3.3).
[gmic_math_parser] U = (uninitialized) (mem[36]: vector10)
[gmic_math_parser] V = (uninitialized) (mem[48]: vector10)
[gmic_math_parser] U = [ 24,47,31,92,31,3,26,14,67,43 ] (size: 10)
[gmic_math_parser] V = [ 24,47,31,92,31,3,26,14,67,43 ] (size: 10)
[gmic]./ End G'MIC interpreter.

But for large vectors, the multi-threading evaluation starts and you can’t get equivalent vectors:

$ ./gmic foo 1e6
[gmic]./ Start G'MIC interpreter (v.3.3.3).
[gmic_math_parser] U = (uninitialized) (mem[1000038]: vector1000000)
[gmic_math_parser] V = (uninitialized) (mem[3000041]: vector1000000)
[gmic_math_parser] U = [ 2,1,31,52,28,86,3,93,32,53,88,14,39,83,88,36,59,79,9,25,62,86,31,33,11,52,27,18,45,88,68,12,6,29,39,88,63,82,63,59,69,41,96,0,47,88,41,86,18,15,13,78,77,34,28,0,20,54,3,98,50,69,15,63,...,44,98,99,94,99,28,79,81,71,98,25,9,62,43,26,22,76,64,0,85,85,72,14,43,81,62,12,81,38,2,95,86,23,68,49,13,41,69,18,15,83,59,65,70,32,9,61,33,35,96,13,80,48,25,13,38,12,2,50,11,23,24,47,31 ] (size: 1000000)
[gmic_math_parser] V = [ 54,53,24,6,47,78,79,90,62,76,79,22,39,27,21,55,40,55,16,50,78,19,18,44,29,31,50,63,63,50,56,49,84,41,51,41,76,10,59,37,85,35,43,33,75,68,83,0,59,71,47,54,78,18,60,35,84,69,72,88,46,99,78,28,...,28,79,81,71,98,25,9,62,43,26,22,76,64,0,85,85,72,14,43,81,62,12,81,38,2,95,86,23,68,49,13,41,69,18,15,83,59,65,70,32,9,61,33,35,96,13,80,48,25,13,38,12,2,50,11,23,24,47,31,92,31,3,26,14 ] (size: 1000000)
[gmic]./ End G'MIC interpreter.

Note that you have the same kind of behavior “outside” the math evaluator, when you use the commands rand or noise:

$ gmic 1e6 srand 0 rand 0,255 srand 0 +rand. 0,255

So, my advice here is not to apply a patch that will make srand() works only for small vectors but not for large ones. There is clearly an undefined behavior here, and it’s the kind of nightmare a developer don’t want to have to deal with.

Searching for ‘0x’ yields no result on Math Expression documentation. It would be nice if there was some points about hexadecimal literal, and binary literal there.

2024/02/19: Release of G’MIC 3.3.4.

Hi, do you think this is a bug?

Got this error when using dilate/erode_threshold with boundary condition set to 0:

 gmic sp , dilate_threshold 2,2,1,255,0
[gmic]./ Start G'MIC interpreter (v.3.3.4).
[gmic]./ Input sample image 'portrait2' (1 image 800x800x1x3).
[gmic] *** Error in ./dilate_threshold/*substitute/arg/ *** Command 'arg': Invalid argument '0,dirichlet,neumann'.
[gmic] Command 'arg' has the following description: 

  arg:
      n>=1,_arg1,...,_argN

    Return the n-th argument of the specified argument list.

Hm.

gosgood@lydia ~ $ gmic -run 'sp cat,800 dilate_threshold 2,2,1,255,0'
[gmic]./ Start G'MIC interpreter (v.3.3.4).
[gmic]./run/__run/ Input sample image 'cat' (1 image 800x733x1x3).
[gmic] *** Error in ./run/__run/dilate_threshold/*substitute/arg/ *** Command 'arg': Invalid argument '0,dirichlet,neumann'.
[gmic] Command 'arg' has the following description: 

  arg:
      n>=1,_arg1,...,_argN

    Return the n-th argument of the specified argument list.

gosgood@lydia ~ $ gmic -version

  gmic: GREYC's Magic for Image Computing: command-line interface
        Version 3.3.4 (pre-release #24020310)
        (https://gmic.eu)

        Copyright (c) Since 2008, David Tschumperlé / GREYC / CNRS.
        (https://www.greyc.fr)

debug_dilate_threshold.txt (113.7 KB)

This looks sort of janky. From lines 1315-1324 of the dump:

<gmic>./dilate_threshold/*substitute/ Enter scope '*substitute/'.
<gmic>./dilate_threshold/*substitute/ Item[0]: 'arg', selection [0].
<gmic>./dilate_threshold/*substitute/ Found custom command 'arg: check "isint($1) && ($1)>0" $=arg u ${arg{1+($1)}}' (takes arguments).
<gmic>./dilate_threshold/*substitute/ Command 'arg': arguments = '0,dirichlet,neumann'. # Huh?
<gmic>./dilate_threshold/*substitute/ Found 3 given arguments for command 'arg':
<gmic>./dilate_threshold/*substitute/   $1 = '0'
<gmic>./dilate_threshold/*substitute/   $2 = 'dirichlet'
<gmic>./dilate_threshold/*substitute/   $3 = 'neumann'
<gmic>./dilate_threshold/*substitute/ Expand command line for command 'arg' to: 'check "isint(0) && (0)>0"  arg0,arg1,arg2,arg3="arg","0","dirichlet","neumann"  u ${arg{1+(0)}}'.

Alas, no further time to run the rabbit into the hutch…

1 Like

Thanks, but i didn’t say it very well (my bad) in my previous post: actually erode_threshold suffers from the same symptoms.

1 Like

Hello,

would it be possible to add a “show alpha” option to the window command?

Thanks

You can do that with +drgba[img] w. rm.

1 Like

Thanks, i have to remember this :slight_smile:

The https://gmic.eu/gmic_stdlib334.h download is missing.

Hello @PDN_GMIC ,

Yes, now the file to use is : http://gmic.eu/gmic_stdlib_community334.h
It natively includes all the “community” filters directly inside G’MIC.

1 Like

Does Gmic 3.3.4 work with 2.99.16 ?

GNU Image Manipulation Program version 2.99.16
git-describe: GIMP_2_99_16
Build: org.gimp.GIMP_official rev 0 for windows
# C compiler #
Using built-in specs.
COLLECT_GCC=C:/msys64/mingw64/bin/cc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-13.1.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/include --libexecdir=/mingw64/lib --enable-bootstrap --enable-checking=release --with-arch=nocona --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time --disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-libssp --disable-multilib --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev7, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --disable-libstdcxx-debug --with-boot-ldflags=-static-libstdc++ --with-stage1-ldflags=-static-libstdc++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (Rev7, Built by MSYS2 project) 

# Libraries #
using babl version 0.1.107 (compiled against version 0.1.107)
using GEGL version 0.4.47 (compiled against version 0.4.47)
using GLib version 2.76.3 (compiled against version 2.76.3)
using GdkPixbuf version 2.42.10 (compiled against version 2.42.10)
using GTK+ version 3.24.38 (compiled against version 3.24.38)
using Pango version 1.50.14 (compiled against version 1.50.14)
using Fontconfig version 2.14.2 (compiled against version 2.14.2)
using Cairo version 1.17.8 (compiled against version 1.17.8)

GIMP-WARNING: gimp-2.99.exe: gimp_wire_read(): error

I use the latest G’MIC plugin in GIMP 2.10.36 , windows 64. Is there a way to make G’MIC use more memory?

Hi @iarga,

Correct me if I’m wrong, but I think G’mic will only use what is needed by the filter you are currently using. Why would it use more ram than needed?
And I think filter devs will preferably try to use the less ram posssible so it can run on most computers.

But using higher resolution images and many layers will obviously use more ram.

1 Like

There are a-priori no limit on the amount of RAM that G’MIC can use, unless you have some system settings that enable such constraints.

1 Like

That’s not necessarily true. Optimizations comes after. Readable and maintainable code comes first, then optimizations. Sometimes, I will optimize my work after new findings or is time.

My first time coding Fragment Blur, it took a day just to work on a decently-sized image with 64 GB Ram, but I got it down to near compiled speed with C# and multi-threaded at that. Another one is Stitch Distort, I work on readable code, but as soon as I have new findings, I was able to optimize it. And so on.

1 Like

That’s why I said preferably :wink:
I might not be the 1st goal though.
I know I have to keep everything low since I only have 8gb of RAM… Got enough crashes because of that heh.

1 Like