Just a personal request, whenever you’re done with the gf filter, can you leave commentary on how it works next to each line? I believe the gmic code would finally provide a way to code in guided filter for Krita.
I have already been labelling the image stack to keep track of things. If you have the paper handy, you should be able to follow along. Still prepping for release. Kind of annoying but me knowing how to use it doesn’t mean the public will. 
PS Sticking with existing code has proved to be difficult. Full rewrite in progress, retracing my steps. Tried store and restore but won’t be using them as they would slow down the command.
If you are using G’MIC 2.7.2, with store and restore hard-coded as native commands, I doubt they will slow down the command. Native versions of these commands are actually quite fast.
For instance, with:
foo :
v -
sp lena,4096 # <- 4096x4096 image
store lena
repeat 10
tic
restore lena
v + toc v -
rm
done
q
I get:
$ gmic foo
[gmic]-0./ Start G'MIC interpreter.
[gmic]-1./foo/*repeat/ Elapsed time: 0.147 s.
[gmic]-1./foo/*repeat/ Elapsed time: 0.145 s.
[gmic]-1./foo/*repeat/ Elapsed time: 0.144 s.
[gmic]-1./foo/*repeat/ Elapsed time: 0.145 s.
[gmic]-1./foo/*repeat/ Elapsed time: 0.144 s.
[gmic]-1./foo/*repeat/ Elapsed time: 0.144 s.
[gmic]-1./foo/*repeat/ Elapsed time: 0.178 s.
[gmic]-1./foo/*repeat/ Elapsed time: 0.166 s.
[gmic]-1./foo/*repeat/ Elapsed time: 0.144 s.
[gmic]-1./foo/*repeat/ Elapsed time: 0.145 s
Quite but not quite. Since they can make images disappear and reappear, they are useful for building complex commands. However, they are slower than holding on to the original in the image stack, esp. when the command is iterative like rolling_guidance. I.e., if you place tic toc outside of the repeat loop, all of the elapsed times would add up quickly.
Speaking of which, remember my comment about tic toc? Say if I wanted to time the command at various junctions. I would want to use one tic at the beginning and multiple tocs following; but that is not the current behaviour. Take this extreme but short example
gmic repeat 51 tic done repeat 50 sp tiger toc done toc q
I would have to prepopulate the tics ahead of time.
Made some progress on the guided filter. Rewrote from scratch the self-guided and custom guided variants. Kept them simple this time. If you are keen on the stats, so far the code is 946 characters long including the formatting and comprises of 3 sub-commands. In the future I might break them into even smaller commands, as they have other applications.
A Before writing the one command to rule them all, I will go through steps 3-5 for each sub-command to make them user-friendly on their own.
1 Like
Took a detour from the guided filter again. This time I have been working on making afre_gnorm and afre_hnorm ready for release. I may extend those commands later. In particular, a year ago, I discussed how the edge is uneven, being too bright or thick in some parts. There is also the amazing phase congruency (and its many applications) but I might never get to it. Currently, I have simpler ideas that I may explore soon.
On other news, afre_y50 is being extra fussy right now about there being exactly 3 channels, which gets in the way of general use; i.e., if RGB, then do command, else norm, or something like that. I will make the appropriate changes soon.
1 Like
Update Barely made any progress. Been busy and exhausted. Incoming discussion.
Guided filter Besides getting it ready, I have realized that it is slow for normal use, a limitation of G’MIC scripting, among other factors. Radius 1-2 are very fast but larger radii are much slower. Without optimizing or compromising the code (or writing and compiling C++ code), I might decide to extend the core filter with an iterative (edge-preserving1) version.
1 Long term work in progress. Edge detection gradient_norm is surprisingly elegant, compared to other methods, but as I have noted in other posts, strong edges aren’t only brighter but also thicker. A map with lines with even brightness and thickness would be ideal for pixel weighting. There are other approaches to edge-preservation but they are difficult to understand and implement properly.
Local contrast This would depend on the guided filter, as do many filters on my to do list. Research on this isn’t done. I have much to learn. What I do have is a working filter that is conservative to the point where it behaves like a sharpener.
Sharpen Speaking of which, instead of including my LoG (Laplacian of Gaussian) filter, I have decided to make a new one using FFT.
Dehaze Sorry about hyping it up. The haze removal I want to do requires lots of elements to work individually and in tandem, a robust guided filter being one of them. Currently, it is last on my list of priorities. Original thread: Developing afre_dehaze.
Update updated afre_vigrect and added afre_vigcirc. Edit both in a PR.
These are my vignette filters, one rectangular and the other circular. They add a vignette that either brightens or darkens the periphery, controlling its size, strength and position. afre_vigrect has an additional blur feature to give it more flexibility that I don’t think afre_vigcirc requires: let me know how that goes.
1 Like
Hmm, adding shape vignette seem doable. I’ll attempt that.
@David_Tschumperle By the way, I’m gonna make a pull request. Requesting manual pull request insertion.
Reason - Pull request get lost like in the case of my changes in a pull request on @Joan_Rake1 gmic file. You can see that in a pull request I have made, and that includes a link to the lost pull request. So, since there’s going to be 2 pull request…
Both vignetting filters are in a PR available now. Clarification: Both filters have GUI and CLI.
Will do that in the future but currently I am more interested in upping practical filters. The fun versions will come after I am done with the core commands and filters (which are many).
What shapes would interest you?
Personally, I would be interested in real vignetting examples of lenses and camera + lens + hood (mis)matches.
PS I finally used a bit of git and learnt to do
git push -f origin last_known_good_commit:branch_name
No more clumsily deleting the repository and re-forking it after a mistake. 
Potential afre_vig* features
1 afre_vigrect and afre_vigcirc could go into a GUI multi-filter.
2 Could add other transformations such as rotation and sheering.
3 Could generalize rectangle and circle with polygon and ellipse, respectively.
4 Could give user the option to submit their own shape for manipulation.
Looking at the pull request, what with the ^_^ face? I’m confused about that.
Update
Been working on improving the gradient_norm for my edge detection purposes. afre_edge CLI GUI will do a fairly good job in thinning the edges and evenly brightening them. afre_box CLI has been added to my core set of commands. afre_edge depends on it and so will the guided filter.
Introduced a smiley face in the output. As with the error face, I want to insert some charm into an otherwise boring CLI. If Ed could do it I could do it too. (Not that I wanted to make the reference, but it fits. Speaking of which, a live-action version of Cowboy Bebop is in development. I wonder if it would be any good. Redoing or renewing classics is controversial at best.)
These changes are in a PR right now and will be available soon. Edit Just increased the input range. Bonus Try turning up details and see what happens. With the right combination, you get a web-like appearance.
1 Like
I think I might just use it for another pdn filter replica. Thank you.
That is a compliment. It would be great if you could link to my user page, as shown in the image above and post here so that I could keep track. Thanks.
Another person (@Iain) expressed interest in afre_edge. Since this is a diary, I have some personal (and vulnerable) thoughts on the matter.
Reflection
The code is already up and running. It should be self-explanatory but let me know if you have any specific questions.
The real test of a command, filter or, more abstractly, an idea is that people use it, hopefully with proper attribution. I would encourage you to use the command itself and not simply replicate it because I came up with it myself, expending time, energy and imagination into it. If it is not satisfactory for your uses, I would prefer that we brainstorm or collaborate to make it better together. That way we can learn from one another.
I am brimming with ideas but don’t usually have the tools or resources to realize them. Thanks to this community and those behind it (in particular, @patdavid and @David_Tschumperle), I have gone from knowing nothing to knowing something and being able to actively help our forum members and visitors. If you answer my questions, give feedback or use my commands, that would help me be much more productive.
A deeper and darker reason for this line of thinking is that, for almost all of my life, people have taken advantage and taken credit for my work. So much so that it is as if I didn’t exist or I were a hindrance. I get nothing in return, or worse: lost time, wages or straight up abuse. It is very painful living like that, impoverished and without anyone to have my back (for real).
Which is why I try to be of good cheer in this forum and in the code with these (^_^) (>_<). And so some attribution, encouragement and / or collaboration would help keep me going.
6 Likes
Thanks @afre for all your efforts.
I know that developing G’MIC scripts is not always an easy task, and you have always held on to it, thank you, on behalf of the entire user community!
6 Likes
Thanks. Was feeling a way low yesterday.
1 Like
Hello @afre
I do think you are an extremely talented person.
For sure, your help on this forum is quite appreciated!
If I may crack a joke, just only for being able to code proficiently with the “G’MIC programming language” makes you a super star! 
4 Likes
I really appreciate you letting us know what you’ve been thinking. I look up to people like you when it comes to GMIC filters. You certainly know a lot about the stuff I don’t know much about. 
I would encourage you to use the command itself and not simply replicate it because I came up with it myself, expending time, energy and imagination into it. If it is not satisfactory for your uses, I would prefer that we brainstorm or collaborate to make it better together. That way we can learn from one another.
I like this approach a lot.
3 Likes
Au contraire, mes ami: here, you are valued. From my perch, you and @Morgan_Hardwood do more than any other members to keep us on track in these threads. I personally sit up and listen carefully to what you have to say; I haven’t much pitched in to some of the conversations due to multitasking, but that’s changing as I put the day job on the back burner.
One thing on my to-do list is to more completely understand G’MIC programming. Programming languages were my academic focus, but I have to admit G’MIC vexes me. Your proficiency in it is well-regarded, at my desk…
Open-Source thinking is a bit of a glitch in our market economy: exchange of ideas doesn’t necessarily put food on the table, or as you point out, directly instill a sense of accomplishment in the contributor. Even with all the ‘conversation’ taking place here, you can bet we’re all reticent to spill our guts here when we don’t know who will respond mis-understandingly.
@afre, I most definitely value your contributions here.
5 Likes
It took me a year on G’MIC programming, and I still have a lot of questions about doing it. And then there’s unsolved one like this one - Anything to autoconnect points within G'MIC? . I don’t get that much praises on what I do, but I still do it because I definitely want to offer fun filters found on Paint.NET forums and obscure sources to G’MIC. @afre did helped me significantly as well as @David_Tschumperle, but the only way to learn G’MIC programming is to just do it. You’re never going to learn programming/scripting otherwise.
1 Like