No, it’s not correct to set on first pixel. That’s the only thing that needs to be changed asides from using a theoretical faster way.
Yeah, there is probably a faster way to do it. I asked @David_Tschumperle about this. I wanted a guassian blur version as well. And yes, this is box filter based on pixel luminosity.
In that case I’ll have a think. Per pixel convolution kernel would be nice too but probably slow (and a memory hog) 
Edit: tomorrow at the earliest, got to sleep now!
Some random ideas that could work (no code):
use a constant size kernel and discard e.g. use crop()
iterate boxfilter per kernel size
trade off by using ram and just product vectors
I suggest you do idea #1 to show @Reptorian how to use crop(). 
BTW, what does the asterisk of off* mean?
Crop only allows positive integer. The asterisk is multiply by.
LOL, I was reading too much into it as some programming thing.
Seems like looping a boxfilter is fast enough most times (just keep the loop instructions minimal):
#@cli gcd_boxfilter_local : [image]
#@cli : gcd_boxfilter_local all selected images with the specified image argument.
gcd_boxfilter_local : check ${"is_image_arg $1"}
pass$1 0 r. {0,[w,h,d]},100%,0 round. 1 abs. store. arg_img
repeat $! l[$>]
{[w,h,d,s]} i $arg_img
repeat iM+1
+eq[2] $> +boxfilter[0] $>
j[1] .,0,0,0,0,1,.. rm[-2,-1]
done k[1]
endl done
gmic sp +mirror. x div. 4 gcd_boxfilter_local.. .
Edit: also works fine changing boxfilter for blur:
I have tested it. My result is more accurate, however, yours is much faster. Here’s the XOR test.
I don’t know how to get the result nearly exactly the same, but I can only get it close enough to look similar, but obviously different. So, I can’t say for sure.
However, yours is more flexible, I think I’ll stick with gcd_boxfilter_local.
For reference, this was my latest version of my code.
repeat $! l[$>]
+to_gray
f.. "
val=0;
off=abs(round(i(#-1,x,y,z,0)/2));
if(off,
for(xx=off*-1,xx<=off,xx++,
for(yy=off*-1,yy<=off,yy++,
val+=j(xx,yy,0,0,0,1);
);
);
val/=sqr(off*2+1);,i
);
"
rm.
endl done
Curious: How do you know? Because the math interpreter uses more sigfigs?
I’m assuming that, yes as well as the fact that my code copy values per every pixels one-by-one, and return the result. If I had to make changes to my own code. I would probably create a multithreaded version, but that would be difficult. Not impossible though.
Another curiosity is why you aren’t programming at a lower level. Clearly, you know enough to do that. I mean code that compiles, which would be much faster.
Well, three reasons.
Yup that makes sense, because I think boxfilter itself is approximate. If you switch it for blur in true gaussian mode it probably gets as accurate (assuming you make a gaussian version), but possibly quite slow too.
Edit: forgot to mention, the loop version will handle multi channel kernel masks (which is how I was testing it). You need to ensure single channel for a true comparison (I guess you noticed that).
Yes, I noticed. By the way, I just realized that there could be variable per-pixel convolution. If you assign an arbitrary function to determine the convolution kernel, in theory, you could make variations of per-pixel convolution.
I’ve been thinking about the very same thing! One more difference I just realised… yours only uses odd sized kernels. That probably explains majority of the change.
That could another contributing factor to the difference. My intention with odd-sized kernel is that it’s always right on target i.e center on center.
EDIT: Have tested it with single channel. The difference is minimal.
EDIT as of 12/26/2019:
@hover I just had made Thorn Fractal by far more maintainable.
I might be adding one more feature which would be allowing users to input their own chaotic formula when I feel like getting around that.
Reptorian,
can you create organic- spider web like patterns with holes? Hole is something which web is wrapping around itself like this :
https://www.nhm.ac.uk/content/dam/nhmwww/discover/spider-webs/radial-web-landscape.jpg.thumb.768.768.png
Which filter is this? https://pixls-discuss.s3.dualstack.us-east-1.amazonaws.com/original/3X/c/a/cae3728a0834087a7c3af7fb375863f35a5a65b6.png
I have added the option to allow custom alternating formulas for rep_thorn_fractal. Now that cli command is completed even if there’s the performance issue associated with inserting vectors of ${14–1} per pixels, and moving on to complete the gui version. It’s fast, but I believe it’ll be faster if I had a choice to get around that.
rep_thorn_fractal -2,50000,255,4,2.544,-5.2424,1,1,1/2,1,0,0,30,a/cos(b),b/sin(a),a/sin(b),b/tan(a) n 0,255
Any integer number less than -1 for first option implies you are going to insert custom alternating formula. The larger the absolute of the negative number, the more inputs you are going to have to insert for command to work. For negative two, that means 17 inputs where last 4 is your formulas. For negative 3, that means 19 inputs where last 6 is your formulas.
Picture result of this command
EDIT: Now, GUI version has been upgraded. Now you can insert custom alternating formulas.
I just wanted to share another result with custom alternating formula. This is with the default GUI setting on Custom Alternative Formula 1 with the only difference is cx=-9.6 and cy=39.400002. cx/cy is distortion x/y.
EDIT: I have just made rep_major cli. It’s a extended version of this filter - Majority Color Effect (ymd:100726) - Plugins - Publishing ONLY! - paint.net Forum
Should arrive by the time you read this, and if not, wait at least 4 hours to a day.
GUI version soon.
Something like this ?
