No worry I don’t think I’m that kind of guy…
Your list is very informative.
What I understand here is that IM 's main target is 2D color images (managing of color profiles, color spaces and so on, is made transparent to the user). As you know, G’MIC has a completely different approach : the input/output data can be anything (just considered as an array of values), it just assumes the user knows exactly what kind of data he manipulatess (particularly what the values of the “image(s)” mean). So, definitely not targeted on color images only.
I think G’MIC is indeed less convenient for the user interested in color image conversion. Besides, it’s true that G’MIC only deals with quite basic image formats.
But on the contrary, I feel G’MIC allows more flexibility when it comes to write custom scripts to process various image data (multi-spectral, volumetric, …). That’s why for instance, it is even possible to write things like “a parser that converts markdown files in HTML” as a G’MIC script
I’ve never been a fan of such approaches in software or programming languages. Often, the proposed user API ends up with a mixing that force to use both settings and arguments, which is sometimes hard to follow and seems unnatural (at least to me).
Indeed.
Indeed.
Something that has always scared me in ImageMagick is the syntax of the language which seems to follow quite different rules depending on the type of command you want to use.
My own biased opinion : The rules of the G’MIC language may look a bit esoteric at first glance, but once you get them, you feel like you can do whatever you want
Actually, I’m so biased that I’d be curious to know why some people would prefer to use G’MIC rather than IM to write image processing pipelines. @afre @Reptorian @garagecoder @grosgood and others.
Is that only because scripts can be easily converted as filters for the GIMP plug-in ?
If so, why not creating a similar GIMP plug-in that embeds IM features ?
@snibgo, has it be considered by the IM development team ?
Just curious!