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. * Handling of image 'channels'. o Greyscale only has one channel. o General create/delete/swap of channels. o User defined channels (say holding masks, labels, distance) o Use of 'sync' flag to 'syncronize' alpha weighting, and color handling. That is 'sync' means treat all channels as a single color unit, and not as separate entities. See -auto-level, -morphology convolve, and alpha blending in mathematical compositions. o Use of a channel for the 'write-mask' (clip mask) for various operations. This includes fixing bugs and other usage problems in many operators. See my notes (developers only) in http://wraith.rcs.griffith.edu.au/~anthony/im/STORE/ write_masking_operations.txt o Make expensive operations avoid calculating results pixels with a 'write mask' set. o Combine 'write mask' with a virtual-pixel Ignore/Disable so as to generate a 'read mask' or 'ignore pixel contribution' mask. OR a completely separate 'read mask' channel posibility. Specific example: allow the compilation of statistics from just a masked area of the using -identify, and histogram generation. Also: Perform blurs, distortions, morphology with specific areas, and especially virtual pixels, able to be completely ignored, just as -resize does normally. * Rewrite of "convert" so as to, remove the old 'legacy' handling (giving errors if no images are present), and to allow 'single pass', or file stream parsing of the image processing operations. That means image processing operations could be read from a file, or even from a pipeline. That is no more command line length limits. It may even be posible to have a daemon process to which the calling program (such as PHP) submits image processing operations 'on the fly'. Imagine for example a shell script that reads images, does calculations the feeds operations to a background running imagemagick command! That would completely remove the need for IM to o A 'reset' option will be needed that will completely reset the command. That is remove all images, MPC buffers, and return settings to defaults. o close/exit/quit options to: close the input stream completely, stop reading current stream (at least for the moment), have image command quite completely (perhaps do final image write) o Replace the current 3 sets of CASE statements with better function handling method that will speed up the library calls. o Use of a 'wand' for passing of image 'attributes', per-image 'properities', and global 'artifacts' into operators. The command will probbaly not be called "convert" perhaps "imagick"? * A fully-defined system of argument handling to allow the use of image information. EG: the update to the current system of 'attributes', 'properities', and 'artifacts' o allow use of escapes in geometry arguments. o FX access to image information, including user defined numerical 'properities' and 'artifacts', posibly even evaluate expressions. For example precalculate and save statistic information and constants into pre-image properties or global artifacts, then call FX which uses that pre-calculated numbers so as to avoid recalculating them all the time. Also saving FX constants in properities, allowing you to do your own 'tally' of image information as to go. o Formatting of "fx" number, and other strings (That is some method of formating percent escapes) * Consolidation of color space and color profile handling? These are after all really the same thing. o Input images are to be 'thought' to be using a "sRGB" profile on both read and write, unless the default color profile is specified. (-linear flag?) o We will need a "sGray" (non-linear) vs a "gray" (linear) colorspace for saves to MIFF and to handle conversions between them. o ALL linear processing commands such as resize, blur, distort, level, draw, morphology, dither etc., should either: automatically convert images to a linear RGB colorspace, or produce a warning (image is not linear). WARNING: automatic conversion may not be a good idea for IM Q8 versions popular amongst window, and large image, users. o all color settings (-fill, -background, etc) should have a colorspace associated (RGB, sRGB, undefined). Note that '#...' colors has no defined colorspace and could be any colorspace. For more details of all the known colorspace problems to be fixed see http://www.imagemagick.org/Usage/bugs/future/#colorpace Minor Changes and handling (may also 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, Flag many others as depreciated! * Text/Image Justification, as separate to Gravity Positioning. But undefined justification uses the gravity setting. Perhaps Justification can be like gravity, or a specific 'handle' point within the image. EG: +X+Y pin-point inside the image! * 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 the pipe-lined imagemagick processor. * 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. * Consolidation of specialised blurs such as "-radial-blur" and "-motion-blur" with correct naming of the blur, and directional effect selection. EG: -blur-special method args * Draw by default turns fill on and stroke off, but this is no good for drawing lines! This may be why 'fill' is 1/2 pixel too big! the fill size should be fixed so it it only fills to actual boundary, but may need 'stroke' to draw rectanges to whole pixel boundaries. * FX parsing to execution tree. * Make histogram: comments 'off' by default, unless specifically enabled. Better still remove histogram: and replace with a -histogram (image to single row of 'value bins') and -profile (graph a row or column of pixels) options instead! Probably a separate function to return color counts (as per "identify" output. * Defining of the 'intensity' method to use for things requiring a greyscale value from color values. Specifically -compose LightenIntensity, -compose CopyOpacity -clut (color to A index color) and so on. * Fine control of settings (context) using \[...\] For example \( -font arial label:unbold \[ -font arialb \) label:bold \] label:unbold That would then imply that -respect-parenthesis is either not needed, or simply means that \( ...\) also does a \[ ... \] as part of its handling. * ensure -region geometry ... +region is working internally replace with a \( +clone -crop geometry ... \) -compose NOTE: any image sequence operator can also terminate -region * Limit simple image operations to specific images (reduces clone needs) -image-list list ... +image-indexes NOTE: a image list operator also terminates -region * -fx-image expression process/replace all images using the expression not just the first image (a simple -fx version) * Replace -rotate with a call to distort images (VP background, bestfit) Merge old Rotation method into -shear with '@' flag, or as -shear-rotate * expert option to change '%' escape to some other character (same rules) There will probably be many items that would not be compatible with the current system. Posibilities and thoughts from the above (IM v8 posibility hooks). * 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 go 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. ------------------------------------------------------------------------------- IM 7 Suggestions/Thoughts -- from Fred Weinhaus 1) Implement a skip factor for selecting frames 1a) Anthony: Read one image from a stream of images, without EOF or closing stream. Not just ALL images in a stream to EOF. That is allow for loop processing of an image stream! 2) Implement some mechanism to permit compiled-like fx expressions, i.e. a way to speed them up. By this I mean allow sequencing through the output and indexing into the input image(s) according to the expression. A simple means of doing this would be a new -process filter template. That way, someone like me can code the fx expression operation without having to know all the details of IM core programming. 3) Modularize the histogram functions so that operations could be performed on/using the cumulative as well as regular and normalized histograms. For example, many of my automatic thresholding scripts need to perform some math operation such as log on the normalized histogram (probability distribution) cumulating arrays from both ends. 4) Perhaps modularize the code in such a way that one can piece together new functions without having to know all the internal details of IM core operations. Anthony has mentioned macro-like programming with loops, etc. This may well be what I am after. Seems like many more people might be able to contribute to IM functions if modules or functions could simply be pieced together. This may not be practical as I know little about programming. Alternately, more -process templates like I mentioned above could be provided so that users could more actively contribute back new functions. 5) Improvements to display to allow control point pair picking and storing in a file 6) Improvements to display to allow interactive drawing (lines, circles etc), measuring and/or reporting (distances and angles of lines and radius/diameter of circles, etc) 7) Ability to generate new images such as contants and gradients from the sizes of earlier images in the command line. This would include fx-like computations from the width and height in specifying the constant or gradient image size. I think this may already be in Anthony's list. 8) Functions using the histogram, such as -normalize, -equalize, -contrast-stretch, (level?) etc should permit at least the first 2, if not up to the following 4 ways to operate as relevant: a) process each (rgb) channel separately, b) process all (rgb) channels in concert based upon the images global stats or, c) access some other user-specified colorspace to compute the histogram (or min/max) from the appropriate intensity-like channel and apply to the rgb image and d) similar to the latter c) option, but convert to the other colorspace, process the intensity like channel only, then convert back to rgb. 9) Layer positioning with some sort of gravity control. 9a) Anthony: And Justification relative to the gravity defined position! -------------------------------------------------------------------------------