GIMP Version: 2.8.10
Operating System: Windows
GIMP Experience: Beginner Level

---

Sorry to put here a question that's probably very silly, but:

how can I send messages from a (user) gmic filter to gimp error console, in a similar way that is common in a gimp script i.e. (gimp-message "blablabla")?

I read that gmic messages can be send to stdout or stderr (and there are many gmic command to "send" messages), but how can one say inside the (user)filter "use gimp console as stderr" for instance? so that a command like -echo "blablabla" writes to gimp error console?
So far, I only succeeded in using -echo_file myfile,"blablabla", and obtained a file named "myfile" under C:\Program Files\GIMP 2\bin, but I would prefer using the gimp error console

Thanks

edit: another little info: in the manual it is written that -echo_file appends the message in the specified file; so far, in my experiments, if I write two different -echo_file commands with two different messages, in the file I see only the last one; is it correct?

Hello dinasset:

Ages since we've gimp-chatted; I have not visited here as frequently as I should.

Stripped to the essence, perhaps this is what you are trying to do:

#@gimp Hi world: hiworld
#@gimp : hiworld = text("Hello, world!")
#@gimp : sep = separator()
hiworld :
-v -
# Beam me up to the error console, Scotty.
-echo "$1"
-v +

But what you see on the error console ("Output messages = verbose(console)") is:
[gmic]-1./ Start G'MIC interpreter.
[gmic]-1./ End G'MIC interpreter.

which annoys, particularly when -echo seems to be advertised as just the command you need:

-echo (+):
message

Output specified message, on the error output.
(eq. to '-e').
Command selection (if any) stands for displayed scope indices instead of image indices.

This hello world filter is a bit of nefarious artifice, I confess, but fabricated to illustrate the interaction between -verbose (abbreviated -v) and -echo (abbreviated -e).

-verbose is designed to supress ("shut up") -echo commands situated too far from the calling scope. That is, when a G'MIC command -blah invokes command -foo which invokes -hahaha, the last being a command three levels removed from the calling scope of -blah, an -echo command situated within -hahaha may not print to the error console if the last -verbose command designates a scope depth shallower than 3. That is, complaints originating from -hahaha are too far removed from the interest of the (human) invoking -blah.

Now, it so happens that nearly every one of the nearly four hundred gmic-gimp scripts use the verbose command in its canonical form: -v - <script> -v + which usually shuts up -echo commands from the current scope on down. That is, to echo commands in the current scope, as well as all the deeper scopes: just shut up. -verbose supports a relative notation; "-v -" means: 'take the current scope level (whatever it is) and reduce it by one.' "-v +" takes the opposite tack. In a typical run, the scope level begins at 0, so "-v -" sets the scope to -1 and silences everything.

It is quite easy to copy those funny little marks over to your own test script because they seem important and are probably necessary for something. They are: noise suppression, but when you're testing a script you want to hear a little noise. My wont is to leave them out until I need them. You may also set the verbosity level to an absolute number -v 1000 <script> -v 0, meaning that you are interested in hearing echos, even if they're 1000 levels from your calling scope. It's not a good idea to set absolute verbosity levels when releasing a script to the world, noise supression is based on the protocol of scripts relatively dropping the scope level by one on entry and increasing it by one, relatively on exit. When testing, however, it is quite legitimate (and useful) to set the level to a particular value.

For -echo, the right hand selection set, if used, establishes if, and how many, scope levels are displayed to the left of the echo text. So if -blah calls -foo, and foo calls -hahaha, and -hahaha has -echo[0--1] "Hello world." within, then the error console will display /blah/foo/hahaha/ Hello world. (assuming the verbosity setting doesn't suppress the echo command). Similarly -echo[-1] simply places the immediate scope containing the echo command: *hahaha/ Hello world. (note the '*' indicating supressed scope levels). -echo[^-1] "Hello world." supresses the immediate scope, but admits the others: /blah/foo/ Hello world. -echo[] "Hello world." will be printed without any scope indicia: Hello world. If you're familiar with how the notation selects images, then mentally substitute 'scope' for 'image position' you won't go far wrong.

I've been bandying the word 'scope' about without saying what it is, but that is just my attempt at dramatic suspense, so as to keep you reading to the end of this rather longish post. Scope is a count of (1) the number of times commands invoke other commands, plus (2) the number of times the script enters block-oriented commands such as -if ... -endif, -repeat ... -done, -local ... -endlocal. Should ever you require the count of the scope to where a particular command executes, insert an adjacent echo command selecting scopes [0--1] and the entire scope will print out. You can also put the console into verbose (console) mode, which echoes every script line as if invoked with -echo[0--1].

Just as one might select an image that is not there, one can select a scope that is not there, an error. Thus -echo[100] "I'm a hundred decks down in the engine room and there's water coming in here!" will probably launch another torpedo if the -echo command is only 16 levels from the calling scope. Note that -verbose does not set the scope; it indicates at what scope levels from the calling scope -echo commands will be allowed to echo. Scope is an environmental condition indicating how many blocks and commands have been "entered" since the script began execution. It just happens; script writers can't change it.

I hope all this verbiage doesn't make everything entirely murky for you. For me, it is the raw stuff of another command tutorial, so thanks for asking. In the meantime, always keep !

Garry

Hi Garry,
yes quite a lot of time!
Thanks for your detailed answer.
From my side let me explain in a very few words my need (my ideal Roman is Caesar: do you remember the famous 3 words? veni, vidi, vici)
At the moment I can get what I need using -echo_file, (with just that problem I see on the file only the last output, the command doesn't seem to "append" really the new message to the file...):
- assuming I want to trace the modification applied to an image with a command
- only as an example, the average value (ia)
- I (now) enter: -echo_file myfile,{ia}
- on myfile I see approx 151.xxxxxxx
- then I perform modifications to the image, only as an example: -mul 1.2
- I enter again: -echo_file myfile,{ia}
- on myfile I see approx 182.xxxxxxx
Thus, I see the effect of my command (in this case, it was obvious, but assume the modification commands inserted into the filter are more complex, and the value(s) I want to check are also various).
What I would like to have is a way to get those messages on the gimp console.
Is it possible?
Thanks

Hello dinasset,

I won't have time to write a detailed answer as Garry did
Just a few remarks :
- The 'Output messages' combobox located on the left of the plug-in interface is your friend : choose 'Very verbose (console)' to output all messages from the G'MIC interpreter on the console window (it actually sets the verbosity level to 99 before calling the G'MIC script). Choose 'Very verbose (logfile)' to output the same messages in a log file (usually located in a file named $TEMP/gmic_log, where $TEMP=/tmp/ on Linux, and %TEMP% on Windows).
- You shouldn't try to specifically echo messages in a specific text file, unless you really need so. I'd suggest to use the 'regular' G'MIC logfile option instead, and you won't have to manage the fact that this file can be overwritten by something else. New messages that coming are always appended to the logfile.
- As for the '-output_file' issue, you are perfectly right, this is a problem in the documentation. This commands re-create the file each-time instead of appending a new message on it. This is something I need to improve (probably with letting the user the choice to append/overwrite the file when the command is invoked).

Thanks David,
the problem of standard gmic_log file is that it's full of (often insignificant at the moment) messages, not only of those written by a user request, while the file defined in the "-echo_file" command only contains what I asked to write in there.
If you could:
1 - either tell me how to get a std log file which only contains my requests for a message (and which are the best commands to use -echo? or something else? there are many...)
2 - or solve the problem in -echo_file (like -echo_file file,msg,append) that would be nice
Still it would be better -for a gimp user- the possibility to assign the stderr of gmic (maybe temporarily) to the gimp console

Hello dinasset,

Yes. And departed this world with an equal economy of words: "Et tu, Brute?"

Echoing to gimp console. Not impossible, but a bit of a reach. Might call for some inter-project coordination and wishlist submissions.
extending -file_echo, perhaps is closer at hand. The effort sits entirely within G'MIC. There are a lot of toys in the 1.6.0.1 beta -- interesting toys! -- with the extension to -display a direct help in filter debugging. Maybe after the 1.6.0.1 dust settles. It's not for me to promise, though. I just write about the stuff.

In the meantime, there's Blather.

Blather is another G'MIC filter more illustrative than useful, but what it illustrates is useful. You want to echo messages out to the G'MIC console without all the other blather, which you will get if you set output messages to verbose or very verbose or debug mode. So don't touch that dial. Leave it in Quiet mode. You'll manage the verbosity level in your script; the main theory is in my previous post.

Here's Blather (For illustrative purposes, copy it to your .gmic file and then relaunch your G'MIC plug-in. Then you'll swipe from it and adapt as you need to.)

#@gimp Blather: blather
#@gimp : msg = note("Welcome to image blather.")
#@gimp : sep = separator()
blather :
-verbose -
-repeat @#
-local[$>]
verb={@^}
-verbose 0
-echo[] "Statistics for image: "{$>}"."
-echo[] "Minimum intensity: "{im}"."
-echo[] "Average intensity: "{ia}"."
-echo[] "Maximum intensity: "{iM}"."
-echo[] "Range: "{iM-im}"."
-verbose {$verb}
-echo[] "Bah! Nobody ever reads me!!!"
-endlocal
-done
-verbose +

That's it. Walks down the image list and echoes vital statistics on each image.

You'll never use Blather as a piece; you'll just copy various useful bits from it.
The first useful bit is: verb={@^}, which sets the variable verb with the current verbosity level. Set verb just before the point you want to write your echo statements. And then, before the first -echo command, set verbosity absolutely to zero: -verbose 0

The next useful bits are the various -echo commands, which mainly illustrate how to cocatenate legend strings with variable content. That's how you write little reminders of what numbers mean. Waltz through gmic_def.gmic or an .updateXXXX.gmic which are treasure troves of echo technique.

Once you've done writing what you want to echo, set the verbosity level back to whatever it was before with the cached value: -verbose {$verb}. That's how you play nicely with the prevailing message echoing system.

You probably grasp what's going on here. The game is to bump verbosity temporarily to zero, echo out to the console what you want to echo, then set the verbosity back to whatever it was before.

This stunt should be pulled all within the same scope. Be careful not to straddle blocks, as in: -local verb={@^} -verbose 0 <script with echoes> -endlocal -verbose {$verb}. That will probably break things.

Note that the last -echo usually gets suppressed unless something external to this illustration raises the ambient verbosity level to some high number.

Here's a sample run of Blather on a Gimp layer stack with two items. I set "Input layers" to 'all' so that all of the Gimp layer stack was copied into the G'MIC image list. Output was set to the default "Quiet level"

Statistics for image: 0.
Minimum intensity: 0.
Average intensity: 145.9756526947021.
Maximum intensity: 255.
Range: 255.
Statistics for image: 1.
Minimum intensity: 0.
Average intensity: 107.516788482666.
Maximum intensity: 255.
Range: 255.

This is appropriate, I think, for developing scripts, when you are trying to keep track of what's going on. Once you have a grasp of that, and are confident about a production release, I would pull out all of the echoes and verbosity level setting stuff out and leave the script less obscured and the standard echo reporting mechanism undisturbed.

Hope this helps.

Garry

Many many thanks, Garry, for the "Blather" filter !!! Great Help.
I will play with it, adjust it to my needs (in the list of gmic variables displayed), and use it when developing a G'MIC filter which wants to modify image characteristics.
(btw: thanks also for entering in the Latin game...."Ave, Caesar! Filter-Developers te salutant")

Hello dinasset,

Glad that you find this useful. I'm quite sure, however, that when 1.6.0.1 is officially released, that you'll find "Blather" almost wholly superceded, and perhaps entirely superceded if your main interest is obtaining values of image metrics.

From the draft 1.6.0.1 release notes:
"- The GIMP plug-in is now compiled by default with the ability of opening display windows. Filter can now use G'MIC display windows and events to propose better interactions with the user."

This is the same display window that has long been available to command line coders, described here in the G'MIC tutorials.. When the interpreter encounters a -display command it stops and maps a display window depicting the items on the image list. It also prints a comprehensive set of metrics for each image on the list to the G'MIC console or log file (which should be set to verbose, and not quiet). As noted in the tutorial, you can select particular images from the list for closer inspection, zoom into a smaller subsets, pan the subsets around with the arrow keys, inspect the intensity of individual pixels, determine whether the dynamic range of the image fits the 0-255 unsigned integer restriction, and so on.

So wherever you might presently echo image metrics using Blather techniques, insert instead a -display command. This command supports selections, of course, so if you only want to inspect the last item on the image list, you could write -display[-1]. You can write any other selection as well.. I've been using this facility in the beta for a couple of weeks now and it seems quite rock solid and stable.

I don't see much use for Blather techniques after 1.6.0.1 - perhaps, from time to time, echoing out the results of a computation which display doesn't show, values of non-image related variables and such. Take it to be a short term fix. But there are much better facilities on the way.

Take care,
Garry

I see.
At the moment, your Blather will provide everything I need.
Thus, thanks again!

Hi Garry,
sorry to bother you, but this evening I wanted to start "blathering", hence I did the following:
- cleared the existing content of "C\Users\User\AppData\Local\Temp\gmic_log"
- copied into my gmic file ("My Directory") your Blather filter (with no changes for now)
- started gimp
- loaded one image as a base layer
- then loaded as layers many others images
- open the gmic interface
- under My Directory I saw your Blather
- selected it
- "apply"
- I see the filter is working
- but..
- gmic_log file is empty

What's wrong in my process? Maybe the clearing of the file

(tried also "run" instead of "apply" but same result)
_____________________________________________
edit: I forgot to set initially to "very verbose (console"
done
now I see the info !
thanks
_____________________________________________
edit2: added another gmic variable, OK
got also that one!
nice "filter"!

Hello dinasset
Home from a client. Still mid afternoon here in Brooklyn NY; I think I'm about eight hours behind you in Italy.
This is just what I got now in /tmp/gmic log with output messages set to Verbose (logfile)

So for logging to the plug-in's temporary logging file, you need not put up with very verbose or debug levels, unless you'd like something to read Glad to be of some help.
Garry