afre_softlight GUI and afre_sharpenfft CLI are in a PR ready to be accepted.
afre_sharpenfft uses FFT to compute a high pass which is then used to sharpen the image. It has two parameters: strength controls how much and size controls the granularity. GUI will come later.
Updates
– afre_reorder has been accepted. Context: Feature request 'Reorder List'.
– afre_log2 transforms images into or back from log2 space.
Custom guided filters
I am tired of holding them back from public use. afre_gui0 and afre_gui1 will be available once the PR has been accepted and code propagated into the update files. I call them “custom” because I made some improvements. For the traditional guided filter, use G’MIC’s core filter guided.
Description
They are base filters meaning that they won’t have all of the features and safeguards that my private experimental filters have. They are also not optimized; they will be incredibly slow. Guided filtering works best with small radii anyway (because haloing is undesireable), so slowness for larger radii isn’t a problem to me personally.
afre_gui0 is the self-guided filter and afre_gui1 requires the user to specify a guided. I will combine them into one command later, extended them and use them in more sophisticated filters with additional features and considerations.
In terms of input for afre_gui1, I have followed the same conditions as the G’MIC’s default guided; i.e., the width, height and depth (the 3rd dimension) of the base and guide images must be the same. As with afre_softlight, it will be adaptable to any input range. As for output, if the range expands, I will leave it as is, including negative values. (The simplest way to deal with outliers is to cut (clip) them to range.)
Small update
Have been busy dealing with real life challenges. As usual, many of them are serious and draining, so progress in G’MIC development has been slow.
1 Scripts don’t age well as G’MIC evolves. E.g., fx_darken_sky, fx_gamify, fx_hnorm and afre_cleantext are old and, to begin with, were rushed to fulfill a need in the forum. I will have to update and make them robust later.
2 I am always in search of a minimalist way to generate an acceptable image from a near-raw image. I have been playing with adaptive gamma algorithms that could be used to brighten an image while maintaining natural contrast. Might lead to a command.
Need to compare it with my current brighten-contrast methods. In terms of speed, it is fast. Also, there is no need to compete with “filmic”: plenty of folks are doing that already and I have never been that interested in it. Here is an example of my current implementation in action:
The lightest part doesn’t have as much contrast as other people’s entries – I have to work on that –, but overall I am quite satisfied with this preliminary test.
afre_reorder bug fix: before, it reversed the order of the latter images if the input list is shorter than the total number of images.
afre_gnorm improvement: no more gradient reversal on thin lines. This will improve the performance of afre_edge. It may as a side effect cause lines to be too thin. Increasing the recovery parameter will help thicken them. Edit Not as thin anymore; I have tweaked the range of afre_gnorm to be the same as gradient_norm.
– Added afre_contrastfft GUI CLI. Part of the FFT series. Seems to perform better locally than a contrast curve in regular spatial space. Also updated afre_sharpenfft CLI to behave similarly. Edit Behaviour reverted: I would rather clip the extremities than introduce halos. afre_sharpenfft now has GUI.
– I am uncertain how much more afre_cleantext can do for Working with afre_cleantext filter and G'MIC plugin. There is still room for improvement; however, the requests being made appear more relevant to scanning and post-processing technique rather than the filter specifically.
My commands are meant to be minimalist and definitely won’t address sophisticated subjects as detection and machine learning. As noted, I have a hard life and so won’t have the wherewithal to deal with the thread beside the long posts I have already written there.
@Reptorian has some ideas, which I hope to collab with him once we both have more time. Edit Looks like I may not need the collaboration after all: afre_contrastfft might just serve in its place.
In theory that is possible. We’d just have to figure out how to extract some bit of letter information by using saturation or chroma and lightness info to determine where’s the supposed letter are, and normalize then cut from that information. But, we’ll see what happens in the end since the initial plan of ours is to collaborate on the filter, and we’ll get back to you on that.
Please continue the discussion on the appropriate thread. No need to cross-post.
Update afre_sharpenfft and afre_contrastfft are complete with CLI and GUI accessible to the public. Another set that I can remove from my private *.gmic files.
Warning and discussion about afre_sharpenfft I jumped the gun and changed its behaviour without checking to see how it performed. The new behaviour was more in line with typical sharpening where haloing begins to emerge as the kernel size and amount increase, which to me is unacceptable! I have reverted it to the previous version where it clips the darks and lights and flattens the contrast to a certain extent, nothing that followup processing can’t ameliorate. Please verify that you have the correct parameters; otherwise, update your filters! Should have the following:
afre_sharpenfft:
0<=strength<=10,0<=_size<=10
Sharpen selected images with Fourier transform.
Default values: 'strength=10' and 'size=1'.
Corrections2 hrs of sleep a day does that to me: 2 commit mistakes now.
– *sharpenfft*contrastfft have previews now.
– *softlight combine GUI CLI, update instructions. Will give it more attention later.
Not insomnia but the call of life and duty. Been like this for more than a month now. discuss and G'MIC helps me decompress, so I drop by in the in-between times.
Thanks! That said, sharpenfft, contrastfft and other afre_* commands are immature and not robust enough for general use. Typically, they aren’t very happy when you push them but excellent when you use milder settings. In that sense, they have inherited their author’s meekness and minimalism.
sharpenfft still suffers from haloing when using a larger size than 1. Perhaps, I need to revisit the variant that I reverted from again, or come up with another method. (There is still a non-FFT method sitting around but I want to focus on getting this right first.) Another issue that can arise from fft commands is they can generate image edge artifacts. contrastfft seems okay but sharpenfft's artifacts grow as size increases.
afre_y50 hasn’t changed since I made it available and works as expected. I am not aware that @Joan_Rake1 has been using it. I would appreciate that people let me know when they use my commands so that I know which ones are in circulation. @David_Tschumperle is there a way to keep track of whether a command is a dependency? Would be a great feature to have actually!
Last time I checked @Joan_Rake1 used afre_gnorm and / or afre_hnorm. One command was broken to begin with and the other was based on code I posted but with apply_color or something like that. Don’t remember if there was proper attribution, as described earlier in this thread. I am guessing the issue she might be having is using them under their old names.
in circulation. being used. That way I can see what people are doing downstream and whether my changes will be affecting other commands positively (new features) or negatively.
Another set that I can remove from my private 
2 hrs of sleep a day does that to me: 2 commit mistakes now.