Reptorian G'MIC Filters

I don’t think I could find a short code that demonstrate my issue as I don’t know where is the issue. It should work.

A short command that reveals you can’t create new image with apo would be apo “.” . That is not related to my issue.

All I know is that if I change the current rep_form_pixel to rep_form_pixel: apply_parallel “_rep_form_pixel $*” , typing in rep_form_pixel -1,20,20, nothing gets changed. But yet, _rep_form_pixel -1,20,20 works.

The rep_pixel_code works like this

1 Setting up to using shape as reference image or using the [0] as reference by using a copy of it to avoid editing the original [0].

2 Then, it sets up basic transformation changes into the [$isnis]. [$isnis] layer is used as shape reference per tile.

3 Then, you can see that the shape reference [$isnis] are resized to fit specified tile size from tw, and th. Cut 0,1 and n 0,1 is used to ensure that $isnis stay in the 0,1 range.

4 Apply shape per every tiles per images. That’s the repeat $ti_l-$isnis l[$isnis,{$>+1$isnis}] block is about.

4a The deepest repeat block is an algorithm that use 0,1 image to transfer the average color per tone. Average sampling duo tone block.

4b After the repeat block, the tiles are reattached

5 Remove the shape layer reference

Also, I found out that separating the big repeat block as a new command and using apply_parallel just does not work.


Edit: Does the fact that it doesn’t work with -1 has anything to do differing image size?

Obvious but important questions to ask and then verify.
1 Are you escaping properly?

2 Are the parameters corresponding to the correct variables?
– Don’t assume they are.

3 Are there commands or conditions that apply_parallel cannot do or handle?
– I find shared for instance can sometimes cause things to fail.

1 What do you mean by that? No error throws up with _rep_form_pixels. Do I have to add something somewhere?

2 I checked, they work and are correct. You can check for yourself. -1 use [0] as shape layer while circle or 2 use circle, then change pixels to tiles of shapes, and all the other parameters correspond.

3 I guess that might be the problem, but it doesn’t explain how the apply_parallel works for defined shape without fail.

4 I don’t think this is getting anywhere to solving the issue. @Joan_Rake1 and David is a bit busy.

Sorry for not being helpful in tangible ways. Too over-exhausted.

1 The fact that you are quoting in apply_parallel means that you cannot just plop _rep_form_pixel $* next to it and assume it would work. Maybe double quoting isn’t enough.

2 As long as you double checked… I had lots of trouble with some of my own code; then I checked at every juncture and found that I made a mistake or misunderstood how G’MIC inherited the variable values.

3 Sure, it might work in the defined shape case but the rest of the code is different and that part may be why it doesn’t work or at least work as expected.

I think now I have a idea. I’ll have to change code to always use [0] as reference within _rep_form_pixels. But, within rep_form_pixels. I’ll make a copy of [0] and make the command apply to [1,{$!-1}]

That should do it.

I agree and that sounds roughly how I handled the matter in my case. (Just had trouble expressing myself yesterday.) I am wondering why you did [1,{$!-1}] instead of [1,-1]. Would like to know for my education.

I’ll use [1,-1] instead. You wouldn’t happen to know how to send a image as variable? I’d like to do this.

Image0=[0]
l[1]$Image0 rm… endl

What I should see is Image0 on [1]. It would solve my issue and keep the fast processing speed offered by apply_parallel.

As far as I can tell, a variable cannot store an image in this manner. Perhaps in (…) form but I don’t think that is what you want. Other than that, I guess

Image0=[0]
l[1]$Image0 rm… endl

would become

l[1][0] rm… endl

Yeah, I guess my filter would have to be on hold until I can find a solution to this. $[] did not work for me, and it seem to be on the manual. I would love to be able to create [0] within l[1] or apply_parallel “” for that matter.

I don’t quite know how to use your commands. Both commands yield the same thing: a copy of tiger.

gmic sp tiger +rep_form_pixel -1,20,20  # psnr = inf
gmic sp tiger +_rep_form_pixel -1,20,20 # psnr = inf

You need to have at least two images to work with -1 or any other negative number. Otherwise, named shapes or 0-23 would create shaped tiles using the corresponding shape.

The results for both commands are identical.
gmic sp tiger,flower,50 +rep_form_pixel -1,20,20 +_rep_form_pixel[0,1] -1,20,20 rm[0,1] a[2,3] x a[0,1] x

image

They’re identical, but for defined shapes case, rep_form_pixel is at least 3-8 times faster. If I could send image to variable, the image as shape reference case would be faster for rep_form_pixel than _rep_form_pixel.

If I am getting you right, you mean to say that defined shapes currently run faster using the apply_parallel command, and you want the same to be the case for an arbitrary image pair.

Yes, that is what I want to solve.

Have you tried changing the format of the image? E.g., (…) form as I guess-suggested? I don’t quite know which format the defined shapes are in… You probably know enough C(++) code to dig into CImg and G’MIC.

The issue been solved. Now I have finished and made a pull request on gmic-community.

Here’s a picture to go with it -

Process with polygon as shape tile on HSL colour space.

1 Like

Another filter is in work. Here’s the code for playing around with this filter.

offset_x=0
offset_y=-0*-1
mode=0; #HARD;MEDIUM;SOFT;DESTROY#
{w},{h},100%,4,0
#Formula creates the basic donut#
f. "
ang=110;
ang=pi*(ang/180);
r=max(w,h)/min(w,h);
xx=((x/w-.5)*2)*(w>h?r:1);
yy=((y/h-.5)*2)*(h>w?r:1);
sph=sqrt(xx^2+yy^2);
mv1_sph=1;
mv2_sph=.4;
max_val_sph=max(mv1_sph,mv2_sph);
min_val_sph=min(mv1_sph,mv2_sph);
sph_bnd=sph>max_val_sph||sph<min_val_sph?0:1;
nv_sph=((1/((max_val_sph-min_val_sph)/1))*(sph-max_val_sph)+max_val_sph);
nv_sph-=.5;
nv_sph=cos(nv_sph*pi)*sph_bnd;
XX=xx*cos(ang)-yy*sin(ang);
YY=xx*sin(ang)+yy*cos(ang);
xx=XX;
yy=YY;
xx/=2*(w>h?r:1);
yy/=2*(h>w?r:1);
xx+=.5;
yy+=.5;
[nv_sph,sph_bnd,xx,yy];
"
shift. {($offset_x*100)/2}%,{($offset_y*100)/2}%
f.. "
donut_x=i2#-1+"$offset_x"/2;
donut_y=i3#-1+"$offset_y"/2;
donut_opacity=i1#-1;
donut_depth=i0#-1;
xx=(x/w);
yy=(y/h);
donut_xx=donut_opacity>0?donut_x:xx;
donut_yy=donut_opacity>0?donut_y:yy;
xx=donut_xx*donut_depth+xx*(1-donut_depth);
yy=donut_yy*donut_depth+yy*(1-donut_depth);
i(xx*w,yy*h,z,c,2,3);
"
k..

@afre I’m wondering something. Is it possible to generate non-existent color noises based on absolute integer value? I could do a script to test values and if passed, then color doesn’t exist and proceed to make it. This idea comes from pdn forum in which a member wanted to see if it is possible to automatically create non-existent color noises.

I’m thinking of using store and restore command to do this, but my idea with eq and compose_channels, I’d imagine it would be super slow.

Here’s a slow command that separates all the pixels, and then convert them to color.

s y s x remove_duplicates a x

Extended version

if w>1 s x fi if h>1 s y fi remove_duplicates a x
ww=w
repeat=15
rn=0
equality=0
alpha=0
if !$alpha to_rgb fi
do
do
chan_v1={round(u(0,255))}
chan_v2={round(u(0,255))}
chan_v3={round(u(0,255))}
chan_v4={round(u(0,255))}
{w},{h},100%,100%,$alpha?[$chan_v1,$chan_v2,$chan_v3,$chan_v4]:[$chan_v1,$chan_v2,$chan_v3]
+eq
equality={iM#-1} rm. r. 1,1
if !$equality a x else rm. fi
while $equality
rn+=1
while $rn<$repeat

I found some time to reply. Hope it helps.

By non-existent, do you mean for the entire image or for a given region (e.g., 1 or more pixels)? Depending on your criterion, you would need to approach it differently.

It would be more efficient if you could use builtin commands. colormap 0 would help you index all of the colours in an image. Then generate noise that contains colours that don’t belong to this index.

1 Like