There’s always c++ for creating your own box filter and it will be faster than gmic, and yes that’s gonna take a while.
boxfilter is already a native G’MIC command, done in C++, and with OpenMP parallelization.
(good luck to make it faster 
)
He said he wanted to make his own version which is why I suggested c++.
Changed the wording. Didn’t mean to imply that cimg / gmic’s boxfilter wasn’t fast or doing box filter things.
I recall my only experience learning programming fell flat in grade school when I was introduced to Turing. Maybe I wasn’t all that interested back then, or I was distracted by the teacher’s weirdness (he kept on talking about his failed projects and fanboy-ing Larry Ellison). Perhaps it is time to learn… Apparently, @anon41087856 learned C / C++ in a short time. Any advice would be appreciated.
None of my filters acknowledge alpha. Could you remind me how Krita handles images? Are layers always RGBA or CMYKA?
Krita G’MIC-QT always convert images to RGBA32F scaled by 255 regardless of color space in Krita. It convert it back after gmic processing.
I could always use blend, which has all the conditionals. Wanted to go my own way. 
There is also sh. 0,2 command rm.. That is what I use to limit processing to color channel.
Unrelated to G’MIC, for the first time, I have lost the Regular trust level on the forum. I guess I got into the habit of reading without logging in. I am logging in less and less since I joined but I still read most posts. And I like less or am liked less. It is kind of annoying because I regularly help people add tags, change categories or titles (where needed only). I enjoy being useful in that way.
I am also 
regular. 
I had to work hard to avoid that double-entendre… 
That said, I’ve just had my raisin bran, so I’m good to go!
Things that become important at age 63… 
Why not just log in?
This version of your code fixes Contrast FFT though I prefer to leave it to you how to address this change.
#@cli afre_contrastfft : 1<=strength<=100,0<=_amount<=100,1<=_iterations<=10
#@cli : Enhance contrast for selected images with Fourier transform.
#@cli : Default values: 'strength=75', 'amount=50' and 'iterations=1'.
afre_contrastfft : check "${1=75}>=1 && ${2=50}>=0 && ${3=1}>=1 &&
$1<=100 && $2<=100 && $3<=10"
m "process_image: +fftpolar ^.. {($1-0.5)/100} ifftpolar[^0] afre_softlight $2"
e[] "[afre]^_^) contrastfft: Enhance contrast for image$? with Fourier transform using strength=$1, amount=$2 and iterations=$3."
repeat $! l[$>] repeat $3
if s==2||s>3 sh 0,{s-2} process_image. rm.
else process_image
fi
done endl done
um process_image
To explain what I did.
- I simply moved the main processing code into a internal command code for rapid editing purpose. I don’t really want to poke too much with your code.
- sh 0,{s-2} would take out the “alpha channel” and put it as a shared image, then you can process the shared image and then remove it when the “color channels” no longer needs to be edited.
@paperdigits Thanks for the bump. I only log in when I intend to write posts. It is easy to log in from my laptop but not so using mobile since my touch screen is broken and Firefox crashes often. I don’t care about stats or likes but it does affect the Regular grant (which I hide because it isn’t about the status but how I can help people).
@Reptorian While the idea is good, I wonder why David doesn’t do this anywhere. Could it be that this doesn’t always work? In certain circumstances shared doesn’t, right?
It’s a bit harder to write with shared than it is with split channels. I use shared primarily because it is faster to process images with shared when the output dimension is the same as the old dimension than to use s c a c. I avoid the easier approach because of speed whenever possible.
I started a bunch of threads and have been busy with others. No work on any of the commands. I should debug the code for real; however, I am more interested in ideas than the programming and mathematics. 
In the meantime, fun elsewhere— okay, I will throw you a bone.
Half-sized preview
Full-sized raw
Update
Depracated afre_gui*_alt and replaced it with afre_gui*_fast based on the new afre_box_fast. Commands have adopted _fast where appropriate. The “faster” box depends on afre_box and boxfilter, and behaves a little differently. It is still relatively slow but definitely faster than the non fast version. Will be available in few hours.
1 Like
@afre I had checked out your latest commit. However, I must point you this. It seem like the loop should be $<. What I see is split channel and then it will modify one of the split channel after the endl.
I could be wrong, but that is how I’m reading it.
I don’t think there is a problem. afre_norm behaves as it should. This is the IO.
Input (s channels) -> Output (1 channel, or s channels of the 1 channel)
That said, changes are in store, mostly cosmetic.