Figured out how to do weighed color average, and added a few more features to Picture Mosaic which has yet to be finished.
EDIT:
Improved indexing approach.
Improved indexing approach.
1 Like
The above was a example of weighed color average and all channels indexing. I have further improved the Picture Mosaic with regards to multiplication of alpha over the previous one by considering weighed multiplication, so that the tile will be appropriately multiplied by the correct value.
New Formula:
alpha_tile*=mini_tile_alpha>=palette_alpha?1:mini_tile_alpha/palette_alpha;
Old Formula:
alpha_tile*=mini_tile_alpha_relative_value;
The old formula is the alpha value of mini tile used to map into larger image. And it’s relative, so it’s alpha_value/maximum_alpha_value.
See how the new formula is a massive improvement to old formula? The outline of the blurred cupid is a lot more clear, and less faded out. You can still see that it fade alpha on the new formula which is intended for the parameter used for this test.
After someone created a thread, I will push a new filter which automatically simplifies images to regions of color.
However, I have a issue though. onfail doesn’t seem to work. @David_Tschumperle
#@cli rep_color_region: _threshold[%]>0
#@cli : For use in images with large color blobs, this simplifies a image.
rep_color_region:
skip ${1=25%}
threshold={cut($1,0,1)}
onfail threshold={25%} done
foreach {
round
+colormap 0,,0
+index[-2] [-1],0,0
+area. 0,0
gt. {ia*$threshold}
*.. .
negate.
-.. .
rm.
colormap. 0,,1
crop. 1,100%
map. ..
rm..
index.. .,0,1
rm.
}
onfail must be located within a local...endlocal block.
I did that, and it didn’t work out because when I did command blur 10, it creates a image of 10x1x1x1. Anyway, I don’t think it matters that much.
New Filter! Color Region
@makkkraid - You can update, and then check if this filter works out for you. Also, there’s some limitations which I mentioned on the other thread.
1 Like
Wow, THAT’S WHAT I NEED! Thank you!
The below image is one of actual texture example.
Those complex tribal design egdes were need to be binarised.
(If I need to fix this manually, it will be nightmare.
Unfortunately, the filter burned my poor laptop in 4K, but work in 1k. )
(shrinked 1K)
(example threshold 1%)
Thank you, I’m glad it worked out. I added a new feature which should help remove the pesky stray pixels. Wait for update, then update.
1 Like
News for filter developers. I made rep_cubic_map behave similarly to map. So, they’re almost completely identical now. Only missing palette names, but I don’t care about that. You can use string like neumann,periodic,continuous as argument for $2. map is still faster than rep_cubic_map though lacks the benefit of cubic interpolation.
Other news, I fixed some of my filter after I realized my hindsight after changing rep_cubic_map a long time ago. Now that is fixed though by changing multiple channels images into 1 channel images.
Ok, I’m trying to do this again - GitHub - weightan/SchrodingerWellPython: 2D 3D Time independent FDM Schrodinger equation solver for arbitrary shape of well
So far, I got something interesting here and yes, I know it’s awful:
I’m so close to replicating it.
$ shape_circle 30 rep_hamiltonian_solver
foreach {
if w!=h
{vector(#2,max(w,h))}
image[-1] [0],.5~,.5~
remove[-1]
fi
n,number_of_points={[w,wh]}
increment={sqr(1/($n-1))}
increment_value={-1/$increment}
zeroV={4/$increment}
unroll x +store image *. $increment_value crop. 0,{w-2} +crop. 0,{w+1-$n}
$number_of_points,1,1,1,$zeroV
diagonal
image[2] [0],1,0,0,0,-1
image[2] [0],0,1,0,0,-1
image[2] [1],$n,0,0,0,-1
image[2] [1],0,$n,0,0,-1
keep[2]
eigen +colormap[0] 0 +index[0] [-1],,0 rm.. +map[-1] [0] mirror.. y
abs[1]
permute[1] yczx
map[-2] [1]
keep[-2]
split c
keep[10-30]
resize $n,$n,1,1,-1
resize $number_of_points,$number_of_points,100%,100%,5
}
@grosgood : As you know Python more than I do, I’d really like to know where’s my error lies in.
Could it be a bug? I don’t know. But, you do see the Hamiltonian thing over there though warped pretty badly.
Even worse, is there precision issues?
1 Like
Got your ping. Take a look at it this evening (EDT) +9 from now.
Ok, I got something here that may point to what’s wrong.
In G’MIC: eigen returns all of the values while in Python, eigs does not.
To compare:
Python:
[1547.66545256+0.j 1517.62132561+0.j 1516.12250555+0.j 1478.06129581+0.j
1477.57237834+0.j 1463.76775931+0.j 1431.57916675+0.j 1430.78182734+0.j
1405.92683802+0.j 1401.17307414+0.j 1382.09798342+0.j 1376.556618 +0.j
1341.82494445+0.j 1336.85706001+0.j 1324.39149193+0.j 1321.7803852 +0.j
1322.59761669+0.j 1271.40908278+0.j 1269.70397701+0.j 1269.16912034+0.j
1257.00825326+0.j 1248.58571388+0.j 1239.29681191+0.j 1207.59996283+0.j
1203.61897929+0.j 1198.23439211+0.j 1195.38574275+0.j 1177.302681 +0.j
1164.00312276+0.j 1157.02243459+0.j 1143.11971337+0.j 1135.34716796+0.j
1128.51695344+0.j 1122.82541233+0.j 1095.6001975 +0.j 1093.44935625+0.j
1090.06408006+0.j 1084.36234437+0.j 1069.6374306 +0.j 1067.7698526 +0.j
1057.10323808+0.j 1053.05410242+0.j 1041.90248464+0.j 1034.60908779+0.j
1020.6903318 +0.j 1017.11011815+0.j 1013.25788554+0.j 1005.78036904+0.j
993.26218789+0.j 987.8677187 +0.j]
G'MIC:
1547.6651611328125
1517.62353515625
1516.1331787109375
1478.0655517578125
1477.5809326171875
1463.7799072265625
1431.58984375
1430.792236328125
1405.9400634765625
1401.1859130859375
1382.107666015625
1376.56591796875
1341.830322265625
1336.8651123046875
1324.39990234375
1322.6060791015625
1321.7891845703125
1271.4134521484375
1269.7103271484375
1269.1767578125
1257.01708984375
1248.593017578125
1239.303955078125
1207.6051025390625
1203.6260986328125
1198.24072265625
1195.392822265625
1177.309326171875
1164.0076904296875
1157.0294189453125
1143.12939453125
1135.35205078125
1128.5230712890625
1122.830322265625
1095.6036376953125
1093.455322265625
1090.068359375
1084.365234375
1069.64111328125
1067.773193359375
1057.1060791015625
1053.05712890625
1041.90625
1034.6107177734375
1020.6900024414062
1017.111328125
1013.2581176757812
1005.7803955078125
993.2601318359375
987.86773681640625
977.6895751953125
975.50494384765625
970.9161376953125
954.3734130859375
952.8443603515625
946.28466796875
942.17669677734375
938.19940185546875
928.97772216796875
926.95709228515625
926.2930908203125
919.509521484375
911.813232421875
909.3084716796875
890.194580078125
885.49945068359375
877.151123046875
866.640869140625
865.1080322265625
863.273681640625
858.83734130859375
858.0335693359375
851.953125
846.6942138671875
839.8017578125
837.04931640625
829.38299560546875
822.556396484375
819.5535888671875
815.85369873046875
810.25787353515625
797.93218994140625
784.00103759765625
784.00091552734375
784.000732421875
784.00067138671875
784.00048828125
784.00048828125
784.0003662109375
784.0003662109375
784.0003662109375
784.0003662109375
784.0003662109375
784.0003662109375
784.00030517578125
784.00030517578125
784.00030517578125
784.00030517578125
784.00030517578125
784.00030517578125
784.00030517578125
784.00018310546875
784.00018310546875
784.0001220703125
784
784
784
784
784
784
784
784
784
784
784
784
784
783.99993896484375
783.9998779296875
783.9998779296875
783.9998779296875
783.9998779296875
783.9998779296875
783.9998779296875
783.9998779296875
783.99981689453125
783.99981689453125
783.999755859375
783.999755859375
783.999755859375
783.999755859375
783.999755859375
783.99969482421875
783.99969482421875
783.99969482421875
783.9996337890625
783.99951171875
783.99951171875
783.99951171875
783.99932861328125
783.99932861328125
783.99932861328125
783.99920654296875
770.06787109375
757.74273681640625
752.14630126953125
748.44635009765625
745.4439697265625
738.61688232421875
730.95123291015625
728.19818115234375
721.30657958984375
716.048095703125
709.967041015625
709.1634521484375
704.72784423828125
702.892578125
701.3604736328125
690.8492431640625
682.50006103515625
677.80718994140625
658.69342041015625
656.1876220703125
648.48992919921875
641.70703125
641.04327392578125
639.0228271484375
629.8011474609375
625.823486328125
621.71588134765625
615.15594482421875
613.62725830078125
597.08575439453125
592.49493408203125
590.31072998046875
580.13201904296875
574.7374267578125
562.2193603515625
554.7420654296875
550.889404296875
547.3092041015625
533.39111328125
526.0975341796875
514.94561767578125
510.89678955078125
500.2301025390625
498.36233520507812
483.6376953125
477.93606567382812
474.55062866210938
472.40020751953125
445.17477416992188
439.48263549804688
432.65298461914062
424.88055419921875
410.97842407226562
403.99676513671875
390.69747924804688
372.61428833007812
369.76617431640625
364.3807373046875
360.39996337890625
328.70346069335938
319.414306640625
310.99172973632812
298.83123779296875
298.29632568359375
296.59078979492188
246.21989440917969
245.40277099609375
243.60873413085938
231.14285278320312
226.17506408691406
191.443359375
185.90216064453125
166.82701110839844
162.07321166992188
137.21826171875
136.4208984375
104.23233032226562
90.427597045898438
89.938774108886719
51.877582550048828
50.378730773925781
20.334630966186523
As you can see, the Python version is essentially trimmed G’MIC eigen. And Python returns eigen vector from trimmed eigen values.
The values on eigen vector in G’MIC does not correspond with Python eigen vector. This is likely the source of my problem.
Still doesn’t rule out the possibility of bad decoding after the eigen step, but I checked and find that hypothesis pretty unlikely.
Ok, I got closer, but I think it’s a issue with eigen command. There’s simply too many non-unique eigen values for pixelsort to succeed at unscrambling.
Second one is my best attempt at fixing the scramble bug.
Current code (without the scrambling rectifying):
rep_hamiltonian_solver:
foreach {
if w!=h
{vector(#2,max(w,h))}
image[-1] [0],.5~,.5~
remove[-2]
fi
n,number_of_points={[w,wh]}
increment={sqr(1/($n-1))}
increment_value={-1/$increment}
zeroV={4/$increment}
unroll x +store image *. $increment_value crop. 0,{w-2} +crop. 0,{w+1-$n}
$number_of_points,1,1,1,$zeroV
diagonal
image[2] [0],1,0,0,0,-1
image[2] [0],0,1,0,0,-1
image[2] [1],$n,0,0,0,-1
image[2] [1],0,$n,0,0,-1
keep[2]
eigen abs[1]
1,{h#0},1,1,y
pixelsort[-1] +,y,[0]
permute[1] yczx
map[-1] [-2]
keep[-1]
split c
resize $n,$n,100%,100%,-1
}
EDIT:
Also have potential for shapes like heart.
2 Likes
Finally the bug has been fixed thanks to @weightt_an who pointed out that argsort() shouldn’t be in the Python code, and so I responded by removing pixelsort line.
Beautiful figures 
1 Like
Dancing cupid?!
1 Like
Maybe. I prefer “Quantum Cupid”. Now, for me to make a new filter using this filter I made.
You know what would be cool is making an animation where the above circular pattern coalesces into the cupid pattern and then having it dance.
Who needs flash animation when we have G’MIC!
1 Like
I think that could be feasible provided I could calculate eigenvector at point x using eigen and skip the rest. Not sure if that part is feasible. If it is, then it’s just a matter of doing it, and then morphing them together.
It is possible based on what @David_Tschumperle (migration of blobs) and @grosgood (other interesting examples) demonstrated. I know you like a good exercise/challenge. 
Hmm, is there a way to blur using a mask? Like less opacity means it’ll be factored less in blurring.
1 Like
Remember my discussion on summed area tables for blurring? @garagecoder made one that expects an input mask. Not optimized though. Could be faster.