G'MIC exercises

I don’t understand this part of rotate

u,v,w,angle,interpolation,boundary_conditions,_center_x[%],_center_y[%],
        _center_z[%]

I know this is a 3D rotation, but this doesn’t seem to work:

$ 150,100,200,1,a=min(asin(x/(w/2)),pi/2);b=sin(a)*cos(y/(h/2));atan(b+z/(d/2))^5 rotate 1,0,0,90,1,3,50%,50%,50%
1 Like

You are right. This is a bug.
Fixed with : Fix when argument has a '%' suffix. · dtschump/gmic@60cbfd8 · GitHub

Will be OK in next release.
Workaround : don’t use a % suffix in your center_z argument, and it will work with current version 3.1.2.

Is there like a easier way to remove pixels at point x without using eval/dynamic array? Is this the only solution? Basically, how split -,{‘unicode’} work, but removes and keep image appended.

$ tic +pal 10 s x repeat 190 rm[{int(u($!))}] done a x toc

I usually use discard for things like that, since it’s a native command:
gmic +pal 10 100%,100%,100%,1,"u>0.5" rv a c discard x,1 channels 1,3

I was thinking of recreating this:

I’m not sure you can see that.

Basically what I want is discard color of each palette independent of axis in a loop. Is discard is the only way to do it? Seems so.

There’s also the problem of creating bezier curves (both finding the length and generating one while plotting each pixel at pixel length.).

Slightly simpler way with discard, assuming you don’t need negatives in your palette:
gmic +pal 10 sh 0 f. "u>0.5?i:-1" rm. discard x,-1

Edit: you could also do something similar to what discard does inside a fill, just copy from I[P] and increment P by more than 1 when you want to skip a pixel/vector.

Is it possible to insert argument after execution of a command in the cmd? I want to make brainfuck esolang interpreter on G’MIC. I guess one could use pre-user input and use $=argpos instead.

Provide an example. Why “esolang”?

where Hello World! is:

++++++++++[>+++++++>++++++++++>+++<<<-]>++.>+.+++++++
 ..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.

Ok, I want the equilavent to std::cin for G’MIC, but there isn’t a way. Also, I’m doing the esolang interpreter just for fun as I wanted to do something a bit different.

Ooh, I’m so close to making the Brainfuck interpretor on G’MIC.

It certainly has an attractive name. :joy_cat:

1 Like

It has been a long time since I touched G’MIC for non-LOLs. I am trying to calculate entropy. What am I doing wrong here?

Octave (last line - I believe everything matches before this)

-sum (P .* log2 (P))
ans = 6.7506

G’MIC

gmic v - sp tiger channels 1 histogram 256 s x repeat $! { if ia#$^<==0 rm[$^<] fi } a x normalize_sum eval -sum(i*log2(i)) rm v + e[] ans\ =\ ${} v -

ans = 0.061134182091894584

What exactly is .*? Knowing that may solve your problem.

.* is element-wise multiply, which is the default behaviour in G’MIC.


Never mind, I forgot to use crop().

gmic v - sp tiger channels 1 histogram 256 s x repeat $! { if ia#$^<==0 rm[$^<] fi } a x normalize_sum eval N=crop();-sum(N*log2(N)) rm e[] entropy\ =\ ${}

entropy = 6.7505967368741926

Now, I need to figure out the most efficient method in G’MIC to compute entropy.

1 Like

There’s the use of is#index, this is the sum of values in image.

Next task is to make a local entropy filter. That would mean I would have to write math interpreter code. Will have to figure out how to do histogram and removing 0 elements (finally have to learn to use dar_*? :stuck_out_tongue:).

It’s da_* now. And if this is your first time writing a math interpreter code, you’re stepping up your game. It’s a bit like writing in C#/C++, but not exactly. You can also use strings made as part of math evaluator code. See some of my code for examples as I use a lot of math interpreter code.

Not my first time but in a way I am stepping up my game: I will try to write as much as I can without pestering you all as I did before. :crossed_fingers:

I forgot about the discard command. Might be useful here.

I have to add a return here just to make a command work:

# snipped code
rm. return
#@cli rep_ordered_dithering: bit_depth>0,0<=dithering<=1,threshold_map_iteration>0 | bit_depth_a>0:...:bit_depth_z>0,0<=dithering<=1,threshold_map_iteration>0 | [palette],0<=dithering<=1,threshold_map_iteration>0 |
bit_depth<0,0<=dithering<=1,threshold_map_iteration>0,spread
#@cli : Apply ordered dithering effect onto image.
#@cli : Note : bit_depth_a:...:bit_depth_z implies that the first argument is a set of arguments joined by the ':' char. This is used for separating bit depth channels.
rep_ordered_dithering:

Without it, it gives me this:

C:\Windows\System32>gmic sp waterfall +pal 20 rep_index_by_window_and_color_restriction[0] [-1],.5,0,0,0,0,1
[gmic]-0./ Start G'MIC interpreter.
[gmic]-1./ Input sample image 'waterfall' (1 image 750x500x1x3).
[gmic]-1./+pal/+_pal/ Create palette 'aap12'.
[gmic] *** Error in ./rep_index_by_window_and_color_restriction/ (file 'C:\Users\User\AppData\Roaming\user.gmic', line #482) *** Command 'input': File 'bit_depth<0', format does not take any input options (options '0<=dithering<=1,threshold_map_iteration>0,spread' specified).

What gives?

I believe it has something to do with:

bit_depth>0,0<=dithering<=1,threshold_map_iteration>0 | bit_depth_a>0:...:bit_depth_z>0,0<=dithering<=1,threshold_map_iteration>0 | [palette],0<=dithering<=1,threshold_map_iteration>0 |
bit_depth<0,0<=dithering<=1,threshold_map_iteration>0,spread

Removing that confirms it though. So, I have to change it a bit. Somehow.

This works though:

#@cli rep_ordered_dithering: bit_depth>0,0<=dithering<=1,threshold_map_iteration>0 : 
#@cli : bit_depth_a>0:...:bit_depth_z>0,0<=dithering<=1,threshold_map_iteration>0 :
#@cli : [palette],0<=dithering<=1,threshold_map_iteration>0 :
#@cli : bit_depth<0,0<=dithering<=1,threshold_map_iteration>0,spread
#@cli : Apply ordered dithering effect onto image.
#@cli : Note: bit_depth_a:...:bit_depth_z implies that the first argument is a set of arguments joined by the ':' char. This is used for separating bit depth channels.

Why?

The colon denotes the separation between parts of command information. Use it instead of the vertical bar. My uneducated guess is the logic is wrong:

threshold_map_iteration>0 | bit_depth_a>0

the interpreter isn’t expecting a parameter to have two different names with an OR in between. In contrast, there is no problem here:

#@cli : bit_depth_a>0:...:bit_depth_z>0,0<=dithering<=1,threshold_map_iteration>0 :

bit_depth_a and ... are on their own, separated from the rest of the line.