Garry, that’s beautiful. I couldn’t resist sharing your post on Twitter 
Glad to see you back with new stuffs!
1 Like
It’s an outgrowth of the warp field eventually spanning the entire image, pulling all pixels, and these subject to rapidly changing gradient directions. That seemed in keeping with the feline abuse theme, but — while aesthetically consistent — I myself don’t find it pleasing; I’ve put it in the kit for whenever I need a cheap earthquake effect.
I have another idea for a tutorial, generating Aegean Number as images. To see what it looks like:
Base Symbol:
1234 in Aegean:
You could explore this so many ways.
1 Like
As in the single number: one thousand, two hundred and thirty four, I trust. On my first read, the glyphs came off the screen for me as ‘1,2,3,4’ (𐄇,𐄈,𐄉,𐄊). The mind is a funny place.
What do you have in mind? an exercise in structured drawing using math expression plotters, polygon() and ellipse()?
Perhaps a rough cheat sheet article can state the generality of putting plot point coordinates that fit in an origin-centered unit square in a math vector, an archetype entry in some sort of ‘glyph library’, then, in the specific plotting event, affine-transform the generic coordinates of a glyph library entry to serve the particular positioning of the glyph, the results of that being fed to polygon(). That cheat sheet may draw most of its content from ‘fun with affine transforms,’ to wit: scale, rotate, flip, shear, mirror and the like. However, your: ‘You could explore this so many ways’ suggests an interest in the Minoan/Mycenaean numbering system itself. That could be a fun off-topic jaunt, which I do from time to time in tutorials, but in the main, I don’t see that mapping into an expository on G’MIC technique.
Alas, but I have to throw that on the pile of TODOs. It has been 𐄛𐄗𐄇days since I’ve pushed to gmic-community, and the Arabesque article perpetually seems but 𐄇𐄋days to completion: it is a bit like nuclear fusion — the tutorial of the future! Always has been; always will be.
“I write to discover what I think.”
— Daniel J. Boorstin
There is @David_Tschumperle’s How to write clean G’MIC code ? thread. I went on at length on the topic of code clarity in Post #61: Voynich Manuscript, and will spare you all an encore.
I’ve no quibble with this. G’MIC doodling is a kind of image-processing solitaire with the personal, private aim of seeing what might crop up, and sometimes something good does. I’ve misplaced the link, but I remember a post that @David_Tschumperle made in his personal blog about one of the motivations of designing G’MIC in a particular way: to have a playpen where one can concentrate on the game at hand, with a minimum distraction from the language’s execution requirements: no code-compile iterations, for example. G’MIC has been designed for play.
For me, these private playpen activities spawn tutorials, but whilst there, I do not worry too much about wielding the appurtenances of clarity — careful variable naming, commenting, clean coding; it is not time for that. But I do have clarity in mind, because, for me, G’MIC doodling is very much an exercise in the Boorstin sense: I am trying to clarify what I am thinking. Out of that clarification a tutorial may spring forth, and should that happen, then the game changes: I have come into possession of some discovery that I wish to share. From there on, along that line of an express intent to communicate, the rules of clarity come into play.
2 Likes
Personally, I disagree with this assessment if one goes to math parser approach often like I often do, or if one does $_persistent things which can get really complicated and often involves rewrite of the original code with _persistent taken into account.
Things like P5js are a bit more popular because it meets this requirement better. Where these languages IMO fails is that they’re not as extensible as G’MIC or Python.
I view G’MIC as the only solution to have multiple filters in multiple programs, and the most flexible in content of raster graphics processing as if nothing comes close in flexibility. However, there are things I can’t do in G’MIC like things that requires user-defined functions (I written a bug report wishing for a way to math parser to force evaluation of macro only once or a function), and it has no bigint or ways to have multiple types output. So, sometimes, clever things has to be done to get around these problems.
If you wanted to change that, solutions are possible, but that would mean delving into and extending CImg (and whatever) that powers G’MIC from the background. 
1 Like
“If you can’t explain it to a six year old, you don’t understand it yourself.” — Albert Einstein
@David_Tschumperle provided this assessment in Image processing made easier with a powerful math expression evaluator.
Alas! David’s personal blog, opensource.graphics, dropped off the Internet sometime between 01-December-2021 and 23-February-2022, when it was first spied in the claws of some shiny-pants domain-name flippers. Thanks be to Brewster Kahle and friends for being on the planet, because the Internet Archive’s Wayback Machine grabbed David’s pages before opensource.graphics slid forever beneath the (digital) ocean waves.
Since a Wayback recall can be dreadfully slow, I’ve excerpted the quotes that, I think, conveys David’s original G’MIC motivations (but don’t trust my interpretations — read the entire post if you can suffer through the download):
To be more precise, an important part of my work is even to design (and hopefully publish) my own image processing methods. Most of the time of course, my trials end up with clunky, ineffective and slow operators which give nothing interesting else than knowing the approach is not good enough to be followed. Someone who says everything he tries works right the first time is a liar. Step by step, I try to refine/optimize my prototypes or sometimes even take a completely different direction. Quickly, you realize that it is crucial in this job not to waste time when doing algorithm prototyping because the rate of success is in fact very low.
That’s actually one of the reason[s] why I’ve started the G’MIC project. It was primarily designed as a helper to create and run custom image processing pipelines quickly (from the shell, basically). It saves me time, everyday.
So whilst you’re in the discovery playpen, a tool that gets you quickly past the junk-thinking is very important indeed.
David further writes that this motivation not to waste time with tool mechanics extends down to the pixel processing scale, the math expression evaluator’s operational level, and that if he wished to have a playpen of ready-to-use pixel processors on par with the utility of macro-level G’MIC commands, then he needed to teach the math expression evaluator how to do looping constructs, thus transporting the math expression evaluator from the realm of elementary expression parsing (a calculator) to something resembling a programming language. But the necessary modifications to CImg.h, where the math expression evaluator lives, seemed technically in reach and the goal was a good one:
Until now, when I was trying to implement this kind of algorithms, I was resigned to go back coding them in C++: It is one language I feel comfortable with, and I’m sure it will run fast enough most of the time. Indeed, computation time is often a bottleneck in image processing. Some of my colleagues are using scripting languages as Matlab or Python for algorithm prototyping. But they often need some tricks to avoid writing explicit code loops, or need to write at least some fast C/C++ modules that will be compiled and run from those higher-level interfaces, to ensure they get something fast enough (even for prototyping, I’m definitely not talking about optimized production code here!)
But, I’m not really satisfied with my C++ solution: Generally, I end up with several small pieces of C++ sources I need to compile and maintain. I can hardly re-use them in a bigger pipeline, or redistribute them as clean packages without a lot of extra work. Because they are just intended to be prototypes: They often have only basic command-line interfaces and thus cannot be directly integrated into bigger and user-friendly image processing frameworks. Making a prototype algorithm really usable by others requires at least to wrap it as a plug-in/module for [ …copy the name of your favorite image processing tool or language here… ]. This generally represents a lot of boring coding work, that may even require more time and efforts than writing the algorithm itself!… I’d definitely prefer a simpler solution that let me spend more time on writing the algorithm itself than packaging it or making it usable. After all, the primary purpose of my work is to create cool algorithms, not really coding user interfaces for them.… [So], how to make those prototyped algorithms finally usable without spending too much time on making them usable?
So, methinks, “to have a playpen where one can concentrate on the game at hand, with a minimum distraction from the language’s execution requirements” is not a far-off assessment of @David_Tschumperle’s gmic motivations. And if you allow me to voice an impression or two on your own oeuvre, I think I can make the case that your choice of the word ‘disagree’ is not entirely apt, considering the words that follow: your game runs orthogonally to that of the ‘G’MIC-as-playpen’ model I advanced. Not at loggerheads, but at right angles, thereby increasing the span of the discussion space. In ways far beyond my game, you canvass where image-processing and -generator artists water and assess the closed-source or undocumented tools they’re (trying) to use, and reverse-engineer these as filters for the gmic_qt plug-in, making functional work-alikes available wherever gmic_qt lives. That is good work, but offers up its frustrations in the realm of how well interpretive languages like gmic map to the computational resources of hardware: so your words following divulge — not disagreement! — but a keen interest in the operational innards of gmic and the math expression evaluator, this with the aim of finding optimal coding technique. That is not entirely athwart with @David_Tschumperle’s ‘G’MIC-as-playpen’ aims, nor is it entirely aligned. David, methinks, is willing to forego some performance in gmic so long as the environmental housekeeping chores remain slight. On the other hand, your appetite for performance remains whetted.
Fortunately, before he fell into the research scientist rabbit-hole, he plied the software engineering trade, and like most worthies of that profession, takes a particular pride in his work, and is not disinclined to better that effort — so long as it does not distract too much from the siren song of research. Be gentle with him, for whatever else there might be in his lot, there is that militant, radical, bomb-throwing-whilst-Einstein-quoting Technical Writer, who has herded onto the Discourse server with all the rest of the maverick cats, and wants people to just be able to read the stuff. Or so he claims. But, should there be a frisson of apprehension coursing through the place, it may be that the Technical Writer could fall over — any minute now! — and start shilling All The Rules of The Software Development Life Cycle, this louder than a NYFD hook-and-ladder caught in the 5 PM rush. ‘David: comment your code!’ ‘DAVID! What the h-e-double-tooth-picks is $=a supposed to mean???’ ‘Daaaa-vid! Your math expressions look like the noise of a dropping comm line!!!’ ‘DAAAVID — *!*’
Fear not. The Technical Writer has mellowed in his age. Somewhat. A little. Perhaps. But don’t nudge him; he may yet fall over and then have Words with you too.
2 Likes
Hah, now this makes me smile (laugh even)
Interesting stuff in there too, a relief to not lose the pages from that old domain - it had good descriptions of algorithms on it.
Those of you who follow the GitHub commit logs will note an upload of tutorial material, the first in many a
On tap, I have a Math Expression article that is to be rooted from the tutorial main page, as mathematical expressions are one of those core areas on par with pipelines and image structure. I am making no predictions about when I might post, but it is rather further along than Arabesques and epicycles were when I first undertook that. Hopefully, the COVID related distractions may be mostly behind me. Fingers crossed.
3 Likes
This is really good news!
So glad to see you back with us @grosgood !
Moreover, your new tutorial pages made me discover a new bug in the G’MIC interpreter, always a good thing to discover some before making a new release
Tutorial Upgrades for May 7, 2023. Significant changes:
- A new index page, with an emphasis on doing finger exercises. The former content has been moved to a new file: Introduction.gmd, which branches off of the index. Still a pleasant read, but it doesn’t get off the dime for new people who just want to start.
- A new primary-subject page, Math.gmd, to serve as the root of math tutorials. The specific topics branching from this root will come in future tutorial updates. This is a Whitman Sampler introduction to the topic.
- A new cheat: exec_cheat.gmd, executing subprocesses from G’MIC; indirectly supports the Arabesques Cookbook article.
- A new cheat: subs_cheat.gmd, G’MIC substitution basics.
On tap: Additions to the Math tutorial sections. Bringing up to current spec a number of 1.6x tutorials. Be nice if I could upload that in that rarest of months, June. Take care!
2 Likes
Hello Garry.
I have new issues when generating the tutorial pages here, because of the Python svghelper.py script that doesn’t want to run.
G’MIC -run reports this error:
[gmic]-0./gmd2html/*foreach#5816/*expr#5823/(...)/*local#6112/run/__run/svgtoimg/ Execute external command 'python scripts/svghelper.py --densit(...)c8214260319 images/ampersand_circ.svg' in verbose mode.
File "scripts/svghelper.py", line 12
SyntaxError: Non-ASCII character '\xc2' in file scripts/svghelper.py on line 13, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
Any idea on how to fix this? I’m not a Python guy
1 Like
That is curious. Probably a replacement will be pushed shortly. I think I can fix this before the press of the day begins.
Ah. Did not properly handle internationalization of character encoding. Methinks this will address my tendency to regard Caen as just another borough of New York City.
So lets try Commit 8df222c0
diff --git a/tutorial/cheats/scripts/svghelper.py b/tutorial/cheats/scripts/svghelper.py
index a40ecf9e..51e1601c 100755
--- a/tutorial/cheats/scripts/svghelper.py
+++ b/tutorial/cheats/scripts/svghelper.py
@@ -1,4 +1,5 @@
#! /usr/bin/python
+#-*- coding: utf-8 -*-
import argparse
import svgpathtools
@@ -9,8 +10,8 @@ DESC = """
Plot points from SVG Path.
"""
DENHLP = """
-Plot point quantity as powers of two; 4 → 2⁴ → 16.\n
-Larger → denser. Defaults to 10 (1024)
+Plot point quantity as powers of two; 4 -> 2^4 -> 16.\n
+Larger -> denser. Defaults to 10 (1024)
"""
OUTHLP = """
Text file for output plots.
Runs nicely here. Hopefully there as well.
gosgood@bertha ~/git_repositories/gmic-community/tutorial/cheats $ gmic it exec_cheat.gmd gmd2html. 2 ot exec_cheat.html
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input text-data file 'exec_cheat.gmd'.
[gmic]-1./ Output image [0] as text-data file 'exec_cheat.html'.
[gmic]-1./ End G'MIC interpreter.
Also patched exec_cheat.gmd help display to be consistent with the python script. Fingers crossed.
1 Like
Looks good, this issue seems to be solved.
I get another one anyway:
[gmic]-0./gmd2html/*foreach#5816/*expr#5823/(...)/*local#6112/run/__run/svgtoimg/ Execute external command 'python scripts/svghelper.py --densit(...)c6102473865 images/ampersand_circ.svg' in verbose mode.
Traceback (most recent call last):
File "scripts/svghelper.py", line 5, in <module>
import svgpathtools
ImportError: No module named svgpathtools
Probably some Python package to install with pip ?
OK, I’ve done this:
$ pip install svgpathtools
and it started downloading billions of data 
1 Like
Yes. pip will install svgpathtools.
Sorry to have put you to so much trouble…