I mentioned alfim in Anyone can read 1977 codes here? - #46 by David_Tschumperle . Rather than drag that thread off-topic, I will expand here.
Background
I recently re-wrote the ImageMagick “-fx” pixel expression evaluator to improve performance. It is now one, two or (rarely) three orders of magnitude faster. “-fx” already contained if-then, while-do etc for pixel expressions, and I have kept “-fx” language changes to a minimum.
The general ImageMagick language does not contain features we might expect such as if-then and while-do and functions for image expressions. For example, if we want to build, process and collapse image pyramids we need to use a shell script, or an API such as C or C++ or Python or one of many others. Hence image processing libraries are scattered across multiple platforms such as bash or Windows BAT or C or Python or …
There are good historical reasons for this. IM was born over 30 years ago, when personal computers had about 1 MB of memory. Adding high-level facilities to IM would enlarge it, so the general IM language, and the “-fx” interpreter, had to be quite simple. These days, we have computers that “understand” spoken commands, so the IM language now seems unnecessarily primitive. In addition, performance benefits can be had from keeping all image operations within a single command.
The IM language could use a total re-design, so there is for example an unambiguous parseable definition of “image_expression”. That would be technically simple, but would create roll-out issues for the thousands (millions? billions?) of IM implementations. (It could be said that G’MIC is that re-design, and there is no simple migration path from IM to G’MIC.)
So my question to myself was: can we augment the IM language to increase its power? What is the minimum useful augmentation?
Goals
Alfim (“Augmented Language For ImageMagick”) is a first attempt. It adds just:
-
conditional processing (if-then-elseif-else-endif and while-do-endwhile with break and continue), to any depth;
-
functions (with parameters and returned-values and local variables), to any depth;
-
include filename, typically containing function definitions, to any depth;
-
a few convenience commands to aid debugging of alfim scripts and of alfim itself.
Ideally, alfim will accept any valid IM command unchanged. Currently, this works except for the final implied write at the end of a typical IM command.
Language design
Fairly simple. In my experiments so far, conditionals and functions add great power at fairly low cost.
Interpreter design
Also fairly simple. The alfim program translates the command (with any “included” files) to binary format, and executes that. It doesn’t fully parse commands. It assumes that anything it can’t understand is “heritage” ImageMagick, and it passes those elements to IM for processing. So alfim doesn’t need to know that “-blur” will replace each individual image in the list, while “-append” will replace the entire list by a single image.
Future
Alfim currently works, but I have only had it for about a week. There is loads of work to do before anything is publishable.
Alfim uses the IM library, but is a separate program. Will alfim features ever find their way into IM proper? I don’t know.
