You may have Been Here, Done This, already, because in your Post #8 you are invoking -inpaint directly on a command line, so I hazard to guess that you are already aware that the parameters gathered by the pretty Inpaint [Patch-Based] GUI are not quite those that become arguments to -inpaint itself, that -fx_inpaint_patch is the first G’MIC command that runs to process the settings provided by the pretty GUI and some argument transformations take place.
That said, it may not be abundantly clear what happens to the GUI settings as they go on their merry way to -inpaint arguments, by way of -fx_inpaint_patch. For that, you need to know where the definition of -fx_inpaint_patch resides and what set-up it does for -inpaint. There are a few ways to do that:
- @KaRo has introduced you to the double-dollar (
$$) substitution rule, quite new, which expands gmic custom commands so that -echo can print their implementation in the command shell.
a. The $$ substitution typically references the *.gmic download file. You could peruse that source yourself. It arrives at your system when you click on the update button in the gmic-qt dialog box or execute gmic -update command in a shell. For Windows 10, G’MIC puts this file in %AppData%\Roaming\gmic and is named updatexxx.gmic, where xxx may be 297 - current production - or 298 current development. You can determine which is which by looking at the window banner of the gmic-qt dialog box; that cites which gmic version the plug-in runs with. %AppData% is a Windows system environmental variable. Type %AppData% in your Windows 10 search bar to find the specific folder location on your system.
b. Those with Unix-like systems may find updatexxx.gmic at ${HOME}/.config/gmic/updatexxx.gmic
- This download file may be perused with any text editor but it is not an easy read, as the file is generated from a number of primary sources, white space and comments have been filtered out and there is little in the way of indentation. Still, use your favorite text editor to search for
fx_inpaint_patch and mark well its location for later study.
- Those of us who build from sources or are otherwise terminally curious about
gmic obscurities fork the gmic git repository. There, fx_inpaint_patch may be found in gmic/src/gmic_stdlib.gmic around line 45198, as of commit 727952fef08a, (Fri Jul 2 13:16:51 2021 +0200), master development branch. This is one of the primary source files that is comment- and white-space stripped, then incorporated into updatexxx.gmic.
I’ve gone on at length on locating G’MIC commands, and -fx_inpaint_patch in particular, because through Adding Custom Commands, any command can be studied in detail and modified to observe effects. The Bouncing Ball Tutorial walks through the process of extending G’MIC with a new command; you start from a blank slate, as it were. That technique broadly points the way toward taking any existing G’MIC custom command and rewriting it as if it was new. It becomes your own personal version of the command.
There are two ways to go about doing this.
- You may add commands to your local G’MIC extensions, These are contained in the file
%AppData%\user.gmic (Windows) or ${HOME}/.gmic (Unix-like).
- Create any text file with a
.gmic extension — myradioactivecommands.gmic perhaps — and extend your command set on-the-fly by way of -command (m for short):
gmic -m myradioactivecommands.gmic ...
In either environment, the local extensions file is a text file composed by the rules at Adding Custom Commands.
To illustrate, here is one way to make a local, personal version of -fx_inpaint_patch for purposes of understanding how it sets up -inpaint
I copied the current definitions of fx_inpaint_patch and its helper -_fx_inpaint_patch to another command file, gtutor_ipaintpatch.gmic, expanded
command names to their full spellings, re-indented to clarify program structure and added comments.
gtutor_inpaint_patch
# Implementation. Don't call this.
_gtutor_inpaint_patch :
-repeat $!
-local[$>]
R=$9
G=$10
B=$11
A=$12 -d
-if !$A" && "(s==2" || "s==4)
-split_opacity -d
+neq. 0 -d
-mul[0,-1] -d
-append c -d
R=0
G=0
B=0
-fi # Purely transparent color.
+round -d
-select_color. 0,{round([$R,$G,$B,$A])} -d
-if $13
-dilate. {1+2*$13} -d
-fi -d
-inpaint.. [1],$1,{$1*$2},$3,1,{$4*$1},${5-8}
-remove. -d
-endl
-done
# Work-alike of fx_inpaint_patch. Call this like:
#
# gtutor_inpaint_patch 12,16,1.0,2.0,0.0,0.05,10.0,1,255,0,0,255,0,0
#
# $1: Patch Size = _int(7,1,64)
# $2: Lookup Size = _float(16,1,32)
# $3: Lookup Factor = _float(0.1,0,1)
# $4: Blend Size = _float(1.2,0,5)
# $5: Blend Threshold = _float(0,0,1)
# $6: Blend Decay = _float(0.05,0,0.5)
# $7: Blend Scales = _int(10,1,20)
# $8: Allow Outer Blending = _bool(1)
# $9: Mask Color = R - 255
# $10: Mask Color = G - 0
# $11: Mask Color = B - 0
# $12: Mask Color = A - 255
# $13: Mask Dilation = _int(0,0,32)
# $14: Process by Blocs of Size 100%,75%,50%,25%,10%,5%,2%,1%
gtutor_inpaint_patch :
-repeat $!
-local[$>]
-if $14
bs={max(16,min(w,h)*arg(1+$14,100,75,50,25,10,5,2,1)%)}
-apply_tiles "_fx_inpaint_patch $*",$bs,$bs,1,25%,25%,0,2
-else
_gtutor_inpaint_patch $*
-fi
-endl
-done
This suffices in your shell to run the modified command:
gmic -v 3 -m gtutor_ipaintpatch.gmic -input im_damaged.png -gtutor_inpaint_patch. 12,16,1.0,2.0,0.0,0.05,10.0,1,255,0,0,255,0,0
This pipeline up-ticks verbosity, (-v 3), introduces the modified commands (-m), puts a red-splotched image on the command line (-input im_damaged.png) and then runs the modified command (-gtutor_inpaint_patch. 12,16,1.0,2.0,0.0,0.05,10.0,1,255,0,0,255,0,0).
You may notice sprinked throughout this modified command: -d. This is the shorthand form of -display, which can be repurposed as a fair dinkum breakpoint for stepping through G’MIC scripts. When G’MIC hits -d, it dumps details about the images on the list to the shell standard output as well as displaying the image list, somewhat inaccurately, but to be as illustrative as possible. You may add and remove -d as you like, as well as modify parameters and what the script actually does. I think anyone here who spelunks through G’MIC commands uses one or another version of this technique and are welcome to chime in with their own tips.
You may observe at some point that, as @KaRo points out, the GUI parameters are altered on their way to -ipaint. No surprise there, but now you have the means to precisely see how those alterations take place.
- The
Patch Size and Lookup Size from the GUI are multiplied together to become -inpaint’s lookup_size parameter.
- The GUI’s
Patch Size, unmultiplied, serves directly as -inpaint's patch_size
inpaint's lookup_factor receives unaltered the GUI’s Lookup Factorinpaint's lookup_increment is not available in the GUI: it has been fixed at 1.- The GUI’s Blend Size and Patch Size multiply together to provide
inpaint's blend_size.
- The next four parameters fall into a one-to-one correspondence:
a. GUI: Blend Threshold → inpaint: blend_threshold
b. GUI: Blend Decay → inpaint: blend_decay
c. GUI: Blend Scales → inpaint: blend_scales
d. GUI: Allow Outer Blending → inpaint: is_blend_outer
Other GUI parameters are not meant for in_paint directly, but establish characteristics of the selection mask that it is given and the wrapper command uses the parameters instead. Thus, the GUI’s color swatch becomes an argument to -select_color, responsible for generating the block-out mask, ipaint's initial parameter, and GUI’s Mask Dilation parameter dilates that mask.
With these connections, you can project the GUI’s settings onto what ipaint expects, and, by extension, take @David_Tschumperle 's-ipaint-centric notes in Post 4 and project them back to the GUI.
For many reasons, there are plug-in authors whose G’MIC coding skills are orders of magnitude beyond their English documentation abilities — let it be. English is not their native language. My course in G’MIC documentation resolutely remains with the core, because upon that ground is where all gmic-qt plug-ins ultimately sit. Except for an ocasional one I might develop, I don’t do plug-in documentation. I fear that means for many gmic-qt plug-ins there will be no orchestrated documentation effort for some time — perhaps never.
Alas, @ChameleonScales, you and people like you will have to embark on these spelunking expeditions from time to time to see how gmic-qt plug-ins connect to the core, which is rarely in a 1:1 fashion. If this seems a dauntingly long post, I apologize; perhaps it will be the basis of a Cookbook article at some point and become rather less like raw notes. In the mean time, I hope it gives you enough pointers in where to look for things in the code base and how to recover the connections between gmic-qt GUI’s and the core G’MIC language.
)? And what does the value really mean anyway?
interesting and good to know. Thanks again
