Hello G’MIC scripters,
I propose to open this thread to discuss about the design of the G’MIC script language, in the most general sense.
For instance, I’d be really interested to get feedback from script developers, and thoughts on:
- What you think about the language : what’s good, what’s wrong, what needs to be improved?
- How do the language compare with other similar tool/language (e.g. ImageMagick, bash, …).
- Propositions of possible evolutions of the language ?
- Discussions about the best way to write “classical” programming patterns in G’MIC.
As a reminder, I developed the G’MIC language with the following ideas in mind:
It had to be a scripting language, for quick prototyping of image processing algorithms. The idea was to optimize my developing pipeline, which is basically : write some code, test code, correct code, test code, write some code, test code, … I didn’t want to wait anymore for a compilation process before I can test my code (as I did for years, using C++).
G’MIC is then an interpreted language and it will probably remain so
It had to be a concise language, again, to allow quick prototyping. I think this goal has been achieved (maybe even too much ?). Most of the time, IP algorithms written in G’MIC will be shorter than those written in other languages, to the detriment of the overall readability of the code (comments are sometimes essential to understand what a code does).
Now, my personal pro/cons list:
What I like in the language:
- it is defined only by a few “simple” rules (but not necessarily obvious to handle).
- It allow to test some new ideas from scratch very quickly.
- It allows to create new image processing filters and distribute them easily, now for a wide variety of digital illustration/image retouching applications : GIMP, Krita, Paint.NET, Photoshop, PaintShop Pro, Photoline, …
- The embedded math evaluator is wonderful and allows to write custom “per-pixel” code that runs reasonnably fast most of the time (particularly when using parallelization tricks).
- Adding new commands make them automatically available to be used in other pipelines.
What I don’t like so much:
- The documentation : we miss some clear tutorials to teach the language. @grosgood has made a fantastic job a few years ago with these pages, but unfortunately the language has evolved a bit since then, and some things do not work exactly as described in these pages now.
- I miss the speed of C++. That was expected of course, but it’s sometimes really embarrassing to think that a filter could run 5-10x faster if it was coded in C++.
Idea of possible evolutions:
- At the moment, my main goal is actually optimizing the performance of the interpreter (memory footprint and execution speed). The current number of commands written in G’MIC is already large, and any useful optimization could benefit to all these commands.
- Concerning the syntax of the language itself, I don’t have any ideas to improve it right now. Maybe you could help ?
Do not hesitate to share your thoughts about all this.