Gives me a idea: Apply filter, boost lighter area, apply filter again.
Fixes — As usual, update your G’MICs and their filters in a couple of hours after the diary entry.
1 afre_brightness Copy-pasted the wrong curve.
2 Improved afre_brightness and afre_contrast.
1 Like
3 Deprecated afre_jabz afre_ijabz (in stdlib now); afre_jchz afre_ijchz still available.
4 Improved afre_localcontrast. Tweaked weights and uses Jzazbz now. Edit 3 Smooth before enhancement, which slows the command but yields better results. Sorry, took 3 commits!
Update your G’MICs and their filters in a couple of hours after the diary entry. Again
1 Like
5 Rewrote afre_softlight. It is ready to graduate from “Testing”: instead of “Layers”, I may put it in “Colors” because it belongs with afre_brightness afre_contrast afre_localcontrast afre_darksky Thoughts?
Edit The range is a little off compared to the builtin version. That minuscule difference is enough to make afre_darksky go 
. Investigating…
Edit Apparently, the code works when in user.gmic but not in update***.gmic. Any idea why that is? Is insomnia getting in the way again?
1 Like
That seems to work here. What kind of errors do you get ?
Resolved
The plugin wasn’t updating or reading the *.gmic files properly. After a few reboots and relaunches, the problem disappeared.
Changes
1 Since afre_darksky works with the rewritten afre_softlight now, I replaced the builtin with mine.
2 I moved the rewritten afre_softlight out of Testing and into the Colors category. It is an implementation of @DGM’s code, which in turn is based on a defunct company’s. I found myself using this soft light blend the most, so it would be appropriate for me to make a command for it. See I'm generating new blending modes for Krita - #51 by DGM. My old implementation, while trying to be helpful, was too complicated and would not be easy to use as a stepping stone for more complex commands.
As usual, update your G’MICs and their filters in a couple of hours after the diary entry.
Re: denoising. Better at preserving the structure. As for texture, well…
1 Like
That was a different method. Now a refinement of the Method 2 in post #155. However, it takes time due to all the looping. Basically, it uses the result from Method 2 as a guide for the noisy image. Since it is so slow, this would be untenable for larger images. With these small images, it takes 2-3 minutes!
Weakness – Areas with more blur in the original noise-free image are destroyed here, as can be seen by the lighted areas of the pencils and the fading text on the left. The fade is more extreme than the original image’s. Some sort of normalization of texture and / or noise is probably needed. My brain still turns to jelly when talking to @Iain or @rawfiner, so any denoise attempts will usually end in defeat. Maybe it is a matter of defeating my timid self. That said, at my own pace, I am getting a nano step better.
Advancement – The main improvement is that these images don’t exhibit the splotching and the edges are preserved albeit filled with holes where I am guessing the high frequency noise used to be.
Major update
Made some final touches to the denoise command. I removed unnecessary code that contributed to the problem identified in my previous post. It is a more presentable form of the custom self-guided filter that I worked on for a long time.
I am calling it afre_denoisesmooth (CLI GUI) because it can denoise noisy images and smooth low-noise images (while preserving structure and textures). As I am using my own custom guided filter, it will be much slower than the native one, since I am only scripting it and it is more nuanced. Also, it is because of the amount of looping ( loop_n = radius + amount ). At the moment, I prefer not to add fast versions, which would compromise the performance and stability.
2 Likes
I attempted to use Smooth Denoise, I wish it was faster. I’m not sure if stability is a problem, but performance boost is fine if the sacrifice in details is not too bad.
Working on it at my own pace. I would rather share an imperfect command than not at all.
PS afre_gui* call afre_box twice. I have ideas to make afre_box faster.
1 Like
To dos
I haven’t had time to deal with the previous to dos. I have kept a list but it might not match those mentioned on the forum. I have added a handful more here: Spaniel, king of tree stumps! - #11 by afre Placing it here, in this thread, so I can remember.
Minor Update
Been working on the alt versions of afre_gui0 afre_gui1 afre_denoisesmooth . Renamed their suffixes from _fast to _alt because they are barely any faster and are more experimental in nature.
My alt custom guided filters have taken on using the builtin blur (Gaussian) instead of boxfilter (which yielded bad results) as a replacement for afre_box . It is a natural choice because box filters approximate the Gaussian blur anyway. The speed gain wasn’t all that much however.
I turned down the structure weight in afre_gui1_alt for afre_denoisesmooth_alt . It seems to fade the edges rather than preserve them when I iterate the command. I wonder if this applies whenever iteration occurs. If it does, I may consider changing the defaults to structure=0 . Since it is unique to my code, it should probably be dialed back anyway.
As usual, update your G’MICs and their filters in a couple of hours after the diary entry.
More experimentation using Iain’s test image.
“Denoised” Preview 1.5MP
“Denoised” Minimal Raw 6MP
Processing time is ~0.75MP/min. Faster than before…
If I clip and stretch the image, “Denoised” Preview looks nicer.
Another method (not guided filter driven) preserves more detail in some areas (snack graphics) but is block-y in others (lens).
Still far from what others can do but that isn’t exactly my focus. I am investigating new ideas and exploring strange new worlds. 
1 Like
Strange new world? Does this mean you’re going to make some fun filters like the filters I did which don’t do anything for photo-editing?
What I mean is that I am moving faster than I am realizing ideas. I am playing instead of achieving.
E.g. I have had the components to make a guided filter that matches or exceeds the very recent dt release for a very long time but I am not interested in putting one together. Frankly, the ones I have made are already fun to play with. No wonder Davids tend to put my commands into the fun category. They are more like gag toys that work if you know them intimately but are utterly unreasonable if you don’t. The same with the other commands. If I were about being practical, I would have mended them already, which I have for some of them; e.g. soft light used to be a little too unreasonable, so I made it useful and as a result boring.
I am more interested in exploring uncharted territory and doing idle nonsense because it is fun. Let’s just say I am writing G’MIC poetry in the way @chroma_ghost honed his creativity. I guess that this is what I have always done. I am simply declaring it now. Don’t you worry, I am still playing with “denoising”. Whatever that means with my buckets of sand.
Looking good.
I think this would be a good candidate for my frequency domain detail recovery. You could test this using my noise reduction filter. You can test this by using two layers. Noisy one on top, clean one on the bottom, and in the filter select ‘guide recovery’. This means the filter is extracting the details from the difference between the layers.
Simpler and “faster” “denoising”.
1 Like
A long quest to find a satisfactory noise reduction filter. Let us hope you find it.
