Recently deleted post.
Here on Linux, it seems to work as expected.
Not sure what changed from the old version (besides the points size, and the coords box missing), but it works 
Also tried the CLI version :
Looks pretty useful for color amputees like me 
The result shouldn’t change.
However, the behind the scenes changes:
- Usage of subcommands. I think it is easier to read.
- More interactive points. The old one has only one interactive point. There’s a plus icon next to point, so I hidden all the coordinates.
When I figure out value(), maybe less variables too.
Just one bug, there’s a occasional spasm out problem with moving interactive points. I don’t know why it happens. EDIT: My changes seems to reduce the spasm issue. And this besides, I updated the Color Harmonies filter.
There seems to be a bug exporting though. I’ll look into that. Oh all of my file export script seems to delete the original images. I fixed it by adding a + next to it, but not sure if that is what I was suppose to be doing with export scripts.
@grosgood After a conversion with the person that made the Python code we were discussing on discord, I finally have my own solution:
#@cli rep_scale_upscaled_pixelart_into_original:
#@cli : Automatically scale pixel art work that has been upscaled into its original dimension.
rep_scale_upscaled_pixelart_into_original:
foreach {
ss={s}
+compose_channels + /. $ss
+fft[-1]
a[-2,-1] c 100%,100%,100%,1,cabs(I#-1) => fft_amplitude
keep[0,-1]
crop[fft_amplitude] 0,0,{([w,h]-1)>>1}
+resize[fft_amplitude] {w#$fft_amplitude},1,100%,100%,2
+resize[fft_amplitude] 1,{h#$fft_amplitude},100%,100%,2
new_dimensions={[xm#-2,ym#-1]}
keep[0]
resize $new_dimensions,100%,100%,2
}
The sad thing is that FFT is faster on numpy than on G’MIC. Significantly faster, but the rest is fine. Anyways, here’s the result with a test:
Alternative code that works on harsher compression:
#@cli rep_scale_upscaled_pixelart_into_original:
#@cli : Automatically scale pixel art work that has been upscaled into its original dimension.
rep_scale_upscaled_pixelart_into_original_2:
foreach {
ss={s}
+compose_channels + /. $ss
+fft[-1]
a[-2,-1] c 100%,100%,100%,1,cabs(I#-1) => fft_amplitude
keep[0,-1]
s[-1] x,2 mirror[-1] x
s[-2,-1] y,2 mirror[-3,-1] y
add[-4--1] crop. 0,0,66%,66%
+resize[fft_amplitude] {w#$fft_amplitude},1,100%,100%,2
+resize[fft_amplitude] 1,{h#$fft_amplitude},100%,100%,2
new_dimensions={[xm#-2,ym#-1]}
keep[0]
resize $new_dimensions,100%,100%,2
}
New CLI Filter rep_blend_by_statistical_mode_8bit_layers though it serves a purpose with one other filter, it’s much faster for 8-bit images.
Basically, it calculates statistical modes of colors.
See example here:
Note the last image does not have track outline.
I don’t understand that sentence, but looking at the images i suppose it calculates the similitudes between all images, so it can recover the background beneath the tracks? ( Or maybe i really just don’t get it, since i can see a few black spots on the last image where there is no track line on at least one of the track images, so it should be also clean.)
Close enough. It calculates the most common color of all the layers. If there is two colors with the same number of frequency or if all the colors are unique, then it return nan, which explains the black dots. I will add a optional parameter to handle 2 or more colors with same frequency cases, but cases with all unique color will remain nan.
alright, should this work?
gmic sp tiger,david,fruits b 50 rep_blend_by_statistical_mode_8bit_layers
i got this:
*** Error in ./ *** inv_dim_det@[$img_checked]
OH, maybe it’s the difference in dimensions?
No, it shouldn’t work when dimensions are different. I’m not even sure how to address that, yet. So, all dimensions have to be the same for now. Also, now updated the error output.
This works rather nicely :
gmic run 'sp tiger . . r 500,500 foreach { repeat 4 { circle. {u(100)}%,{u(100)}%,{u(4)}%,{u(.7,1)},${-rgb} } } +rep_blend_by_statistical_mode_8bit_layers'
1 Like
New filter released, Statistical Mode.
Basically returns the most common color either across layers or per layers.
This is something I did before, but it was too slow, and I tried keeping that as generic as possible. But, decided to restrict to 0-255 and 0-65535 for speed.
I’m going to take a break from improving my old filters. I have something new:
For now, until I finish this (which is easy), you can have this test code which is based off the one-liner! @prawnsushi @grosgood
#@cli +rep_menger_sponge: number_of_iterations>0,_shading_method={ 0=default | 1=by-level | 2=negate-after | 3=negate_by_level }, _9-digits_octal_number_a,9-digits_octal_number_b... : number_of_iterations>0,_shading_method={ 0=default | 1=by-level | 2=negate-after | 3=negate_by_level }, _3-digits_octal_number_a,3-digits_octal_number_b...
#@cli : Create image based on Karl's Menger Sponge. Octal numbers are integer number ranging from 0-7 inclusive, and there must be 3 or 9 digits.
#@cli : If you want the default 3D version of the Menger Sponge, use octal number: 757505757.
#@cli : Default arguments: '_shading_method=0','_3-digits_octal_number_a=757'
#@cli : $ +rep_menger_sponge 4,0,757505757,564437751 *. 255 surfels3d
+rep_menger_sponge:
skip ${2=0},${3=757}
check "octal_digits_counts=size('$3');set('octal_digits_counts',octal_digits_counts);$#>2&&isint($1,1,7)&&isint($2,0,3)&&(size('${3--1}')==(octal_digits_counts*($#-2)+($#-3)))&&(octal_digits_counts==3||octal_digits_counts==9)"
imgs,number_of_iterations,number_of_octals=$!,{[$1-1,$#-2]}
if $number_of_iterations
2,2,2,3,1-[z,y,x];
else
2,2,2,3,[z,y,x];
('$3') -. {_'0'}
if im<0||iM>7 error inv_char_det
elif !iv error var_zero_det
fi
map. ..
resize. {w==9?[3,3,3,1]:[3,3,1,1]},-1 rm..
if $2 negate. fi
return
fi
{[$#-2,1,1,3*$octal_digits_counts]},>"begin(
const octal_digits_counts=$octal_digits_counts;
const _0=_'0';
octal_digits_vector=shift([${3--1}],-1,2);
);
binaries=vectors();
if(!octal_digits_vector[x],run('error all_zeros_det'););
digits=v2s(octal_digits_vector[x],octal_digits_counts,octal_digits_counts);
digits-=map(bool(digits),[0,_0]);
for(pos=[0,0],pos[0]<s,pos+=[3,1],
if(!inrange(digits[pos[1]],0,7,1,1),run('error inv_char_det'););
binary=I[#-1,digits[pos[1]]];
copy(binaries[pos[0]],binary,3,1,1);
);
binaries;
"
if !iv error var_zero_det fi
rm..
if $octal_digits_counts==9
mode_3d=1
new_dimensions=3,3,3,1,-1
new_iteration_scale=300%,300%,300%,1,0,2
else
mode_3d=0
new_dimensions=3,3,1,1,-1
new_iteration_scale=300%,300%,1,1,0,2
fi
+crop. 100%,100% resize. $new_dimensions
if $2!=1 negate. fi
resize.. $number_of_iterations,100%,100%,100%,0,2
s.. x
resize[$imgs--2] $new_dimensions
extract[$imgs--2] i==1,1
MULT=3
foreach[$imgs--2] {
* $MULT
MULT*=3
}
ref=$imgs
repeat $number_of_iterations {
w,h,d:=w,h,d
resize[-1] $new_iteration_scale
if $mode_3d
if $2==3
$w,$h,$d,1,{$>&1}
elif $2==1
$w,$h,$d,1,{$>+2}
else
$w,$h,$d
fi
else
if $2==3
$w,$h,1,1,{$>&1}
elif $2==1
$w,$h,1,1,{$>+2}
else
$w,$h
fi
fi
repeat h#$ref {
j[-2] [-1],{I[#$ref,$>]}
}
rm.
ref+=1
}
rm[$imgs--2]
if $2>=2 negate. fi
4 Likes
I like the 3d version, reminds me of lego bricks.
I’d be pleased to explore this, FPS style.
I wonder how far you can go with modeling in G’mic?
Still on a hiatus as I went to focus on other things.
This seems interesting to explore: Turning into Turing •__• JK
1 Like
Like removing a stubborn smudge or stain: the more one tries, the worse or the more elaborate it becomes. Wow, is that JK box is annoying! And some shapes are rude!
1 Like
Reminds me of how i made this with small (1° max) random rotations :
This last one looks like some kind of game level…?
1 Like
Hoping for a new Worms worthy of Armageddon.
Somehow i feel like everyone here is taking a break at the same moment. So, let’s go 
…?
You better start coding now