Considerations for changes in ImageMagick Version 7 Expanded from IM discussion forum topic... ImageMagick version 7 wish list http://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=11502 NOTHING presented here has been finalized, or programmed. 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 IM Examples, "Basics", 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 the "-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, to make IM even better for everyone. ---------------------- Major Changes.... * 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 if no images are present), and to allow 'single pass' parsing of the options. That means image processing operations could be read from a file ("convert" script), or even from a pipeline. That is no more command line length limits. It may even be posible to have a "convert" daemon process to which the calling program (such as PHP) submits image processing operations 'on the fly'. Further work may allow image operations to be 'stored' as a execution sequence in memory, which in turn would allows the use of functions, loops and conditional processing of operations. The storage may even be simple the option string input, though that would mean re-parsing of the operations for loops. If strings are used, the conditional and looped functionality could actually be done using an external 'macro expandsion' language. Which is how ray-tracers handle such methods. If functions, loops and conditionals are provided then the use of 'includes' to read functions or other very complex image processing operation sequences from other files or sources, also becomes posible. Again this could simply be part of the string-macro language. * A fully-defined system of argument handling to allow extraction and use of information from previously read or modified in-memory images, as arguments to settings and operations. As this is not in the core library, the internal image processing functions do not need access to the image sequence, which has been the current 'stopping point'. For example if a argument starts with '=' then any percent escapes are *immediatally* processed. before being passed to the normalimage process handling. This is different to things like -label '...' which delays its escape handling until after the image has been read in. * If "convert" is modified to allow reading of image processing options from a file, the current handling of "mogrify" will break. However "mogrify" could be replaced by a "script" to using "convert" to do the in place modification of images. Especially if 'stored' operation sequences are also provided. This may require some form of separation of the input options and the list of images to loop over, to make it work. That is a syntax change. * Re-structure of image sequence and the addition of a 'global' settings structure within the core library. That is all library functions has some method of accessing the whole current image sequence, and the attached global settings (image_info) structure, if needed to allow better interaction. Examples of existing problems that is involved include... o Allowing the use of escaped sequences, during the creation/reading of new images. This allows canvas to be made which is the same size or color as some existing image. o The "-compose" setting is not being 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. o When "-tile image" is used, a -size setting given set AFTER the -tile setting could effect the outcome of -tile, in illogical ways. Posibilities and thoughts from the above (IM v8 posibility hooks). * As part of the reimplementation replace the current huge CASE statement handling with a tokenized function handling method that will speed up the library calls. * As part of this consider the parsing of each option (setting/operation) into a data structure to allow for the future addition of repeatable options for creating loops, functions and if-then-else control structures. * We could even do so far as to allow for the automatic generation of an equivelent C program source from convert arguments. This however depends on how the above is implemented. ---------------- Minor Changes and handling (may be added in IM v6) * Ability to handle a variable number of arguments for some options (only posible in a one pass system option handling system), to allow for optional arguments to different operation 'methods'. For example -noise random does not need an argument, but other noise methods do. * Complete removal of many old obsolete options, like -pen, -flatten (now -layers flatten) -mosaic (now -layers mosaic) * A -montage option which provides access to the montage image framing methods in "convert-mogrify". However shadowing can remain separate. * Image Layout methods such as the paged array provided in "montage" 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. Specifically formalization of 'linked' and 'un-linked' RGB/CMYK channels and leveling by convting to HSL and applying it to just the lightness channel, before converting back. * Formalization of all 'global' vs 'image meta-data' type settings. EG: compose, background, fill, bordercolor, dispose, delay, loop EG "-compose" defines a global setting used by composition operators. But if not set composition otherators will use image meta-data settings. For example: "-compose" should never modify image meta-data. But "-set compose" should set image meta-data for when writing out image. This will provide the best of BOTH worlds. simple user control of 'compose' while still allowing, per image, compose controls if people require it. As part of this -delay -dispose -loop will be discontinued as a 'global' usage of these setting has no real meaning in animations, instead -set delay etc will be used with parenthesis for control. * Add a "-set-image 'index_list' meta-data setting" operator varient to make it easier to set the meta-data of specific images without needing to clone those images. EG: -set-image 1--2 delay 10 will set the meta-data 'delay' time of the second to second last image to 10 centi-seconds. There will probably be many more small items that would not be compatible with the current system.