Legacy ImageMagick Discussions Archive

The issue was raised that it is time to start thinking about ImageMagick version 7.

NOTHING presented here has been finalized, or programmed. This is just to see what other developers and major users of IM think, and to allow them input into the decision process, and where what they consider to be important directions for the future for ImageMagick.

This presents an opportunity to make some major non-backward compatible changes (not to major) that may have been needed for a long time.

During the last Major Revision IM v5 to IM v6 resulted "convert" and most other IM commands switching to a 'do options in order given' type change. See Why did the command line style change! for details. This in turn allowed for the introduction of things like parenthesis, and image sequence re-ordering operators, as well as the addition of -composite into the convert command.

With IM version 7 development now a possibility, other similar changes can also now be looked at and thought about. The following list is what I consider the most important changes that need to be made.

• Data structures modified to handle transparency as ALPHA rather than MATTE.
  
  I consider this vital, as just about ever complex function in IM has to 'negate' matte for correct math color processing. Almost all input and output handling of transparency is also generally given in terms of alpha values rather than matte values.
  
  Currently the only operators that deal with 'matte' data in that form is -separate, -combine, -threshold, and -level. All other operators I know about use 'alpha' values, those operators include -fx and -evaluate.
• Rewrite of "convert" so as to, remove the old 'legacy' handling (giving errors), and to allow 'single pass' parsing of the options.
  
  This in turn allows for the use of "convert" scripts, and the possible development 'operation loops' to say loop N times, or even over the current image list, one image at a time.
  
  This may also involve a rename of "convert" to a more generic name such as "magick" which will not have conflicts on the window system. "convert" could be just a symbolic link to "magick".
• A fully-defined system of argument processing to allow extraction and use of information from previously read or modified in-memory images, as arguments to settings and operations. For example the use of '@' to read string arguments from files. or to 'include' a list of options for further processing options from other external files and sources.
• If "convert" is modified as described in the previous point, the reason for the two pass option handling will break "mogify". However "mogrify" could be replaced by a "script" to using "convert" to do the in place modification of images.
• Re-structure of image sequence and use of 'global' settings within the core library. That is all library functions has some method of accessing the whole current image sequence, and global settings (image_info) structure, to allow better interaction.
  
  Examples of existing problems include...
  • Allowing the use of escaped sequences, so as to create a new image the same size or color as some existing image.
  • -compose is not regarded as 'global' which means it gets reset on open parenthesis, but will not be cleared on close parenthesis with a the -respect-parenthesis flag set.
  • when "-tile image" is used, a -size setting given set AFTER the -tile setting could effect the outcome of -tile, in illogical ways.

These I see as the major change requirements for a IM v7 development. Other minor interface changes should also be made at this time including...

• Variable number of arguments for options (only posible in a one pass system option handling system), to allow for optional arguments to different operation 'methods'.
• Complete removal of many old obsolete options, like -pen, -flatten (now -layers flatten) -mosaic (now -layers mosaic)
• addition of -displace, -blend, and -dissolve into "convert"/"magick", and a tiled variation for -composite, allowing for all "composite" to be directly available in "convert".
• A -montage option which provides all the montage image framing methods, though shadow can remain separate. As well as a -array method to layout those 'montage framed' images. As a result the "montage" command itself could be simply a "script" wrapper around "convert"/"magick"
• Consolidation of 'auto-level' type options such as -normalize, -contrast-stretch, -linear-stretch, -equalize into a single option with various methods, to allow for easier expansion with many other automatic image leveling and image enhancement techniques and methods. Many of these have been 'proven' in scripts developed by Fred Weinhaus
• and probably many more small items that would not be compatible with the current system.

Thoughts and discussions on the above is of course welcome and why this has been place in this public forum.

For consideration and discussion (although these are more specific suggestions than Anthony's more architecturally suggested changes):

1 ) compiled fx expressions (or whatever it takes to speed up fx dramatically)
2 ) more than one constant allowed in -evaluate so that slightly more complex expression can be added
3 ) allow more than two images with -blend (multi-image weighted average)
4 ) a proper functioning -displace using both x and y displacement images
5 ) least square-fit control point, spline interpolated option to -distort
6 ) Improvements to -display to allow interactive drawing (lines, circles etc), measuring and/or reporting (distances of lines and radius/diameter of circle, etc) and control point picking
7 ) Implementation of some of my scripts (whatever people think are useful)
8 ) Functions like -level, -normalize, -equalize, -contrast-stretch, etc should have 3 options: a) process each channel separately, b) process all channels in concert based upon the images global stats or the graylevel version of the image, c) convert to hsl, process based upon the lightness channel, then convert back to rgb


As I think of more, I will edit this message.

I have added this to a new (plain text) page on ImageMgaick version 7 recomendations

Give it a day or so to appear.

Does asking to ImageMagick be more "dynamic" fit here?
For example, can't HDRI be used as an option (or as a loadable module) instead needing to be defined at compile time?

HDRI will never be dynamic. It would require a complete rewrite of ImageMagick to support dynamic depths and types.

We have seen some high-end image-processing applications that support dynamic types and depth. However, when we designed ImageMagick we decided on the compile-time option for performance reasons.

anthony wrote:This may also involve a rename of "convert" to a more generic name such as "magick" which will not have conflicts on the window system. "convert" could be just a symbolic link to "magick".

I would humbly suggest doing away with the command name `convert' altogether. If there are historical reasons for keeping it, I completely understand, but here are a few reasons to abandon it.

• convert is a basic english verb, rather than a name specific to the problem-domain of image manipulation.
• convert conflicts with a built-in command in MS Windows.
• "convert" is not a representative name of what the program does---only one of its many capabilities.

"magick" seems like an obvious and appropriate name.

anthony wrote:Variable number of arguments for options (only posible in a one pass system option handling system), to allow for optional arguments to different operation 'methods'.

I respectfully disagree on this point. I feel that operators which take more than one positional argument introduce unnecessary complexity to the user interface, and make command lines harder to read. To me, the ideal design would be as follows:

• operators may require a single positional argument.
• additional values may be passed to an operator via settings preceding the operator. This is parallel to what most programming languages call named arguments.

Existing operators that take multiple positional arguments could be broken up into separate operators. For example, instead of -evaluate add 1 you would simply have -add 1.

Optional positional arguments to operators introduces an ambiguity between operator arguments and image-loaders (such as filenames).