afre's G'MIC diary

The purpose of this thread is to keep people up to date on my progress and process, similar to @David_Tschumperle’s change log and diary threads. Hope you like it. Feedback is welcome; just keep it short (or start a new thread).

If you have been following my posts in the Play Raw and G’MIC categories, among others, I have been keeping a growing number of commands. It is time for me to clean up the mess and start pull requesting them.

The first command to be going up is afre_y50. Its objective is to generate a luminance Y (D50) channel from a linear RGB image using either Rec.2020 or Rec.709.

afre_y50 also introduces quirky error messages * (>_<) *.

* (>_<) * afre_y50: Parameter must be '0' (Rec.709) or '1' (Rec.2020).

Can’t wait to see your coding samples here.

I hope to share my guided filter next because it has many applications. The hard part is making it presentable and useful to the general public. To do:

1 Among ~10 versions, choose which ones to share.

2 Proofread to make sure they work as expected.

3 Add CLI tags for help.

4 Nake sure there is an appropriate amount of parameters.

5 Set reasonable value ranges and checks.

6 Do the final checks and letting it sit in my fork.

7 Make a pull request.

PS Lesson Since I made so many versions, it has been hard to determine which commands I issued bug fixes. I will have to comb through them and also decide on the command and image naming scheme. Guess this is the reason that people use version control like Git.

Raises hand

Mr.Afre, is that new guided filter basically a inside implementation of it as in it doesn’t use guided() from the builtin code at all? Step by step?

It is an implementation with personal touches. It will be a core command in afre.gmic. Process:

@garagecoder helped me with G’MIC specific questions.

– The original papers by He helped me understand the idea and components.

– Other papers helped me understand its limitations.

– Step-by-step, I replicated algorithms I thought were interesting yet simple.

– After gaining insight, I went on to experiment and write my own code.

In that sense, I am an unemployed researcher doing it for the sake of FLOSS and fun. This upload won’t be the end. (Still making it ready for public release, which is another task all together.) In time, I might share my other variations or implement them into what I have decided to integrate into afre.gmic.

1 Like

@David_Tschumperle up is still not adding afre_y50 to the interpreter. Did I do something wrong?

PS As well, the merge is supposed to lower the verbosity of afre_cleantext; but when I up, it still has the same verbosity as before. Does this have to do with the G’MIC version being a pre-release? I have Version 2.7.2 (pre-release #190916).

No, that was my fault : a bug in the filter update command. Basically the update didn’t work since a few days. It should be fixed now.

Why should it do that ?


The PR included that commit.

1 Like

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. :hedgehog:

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
    restore lena
    v + toc v -

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