ImageMagick 5.2.0, June 1, 2000

 User Visible Changes

  • Under Unix, format "coder" modules may be built and installed (by default) to /usr/local/lib/ImageMagick/modules/coders when configure option '--with-modules' is specified. Coder modules are detected and loaded at run-time. Use of coder modules removes knowledge of specific image formats from the ImageMagick library, decreases installation dependencies, and allows users to add support for new formats without re-compiling ImageMagick. ImageMagick currently has a total of 72 coder modules. ImageMagick looks for modules in its installation directory, in the sub-directory ".magick" in the user's home directory, and in the list of directories specified by the environment variable MAGICK_MODULE_PATH.
  • Module loading is also fully supported under Microsoft Windows.
  • Image file identification based on the file header (magic) is now programmed via a text file (magic.mgk) rather than embedded in the C code. This allows extending ImageMagick's knowledge of file types without modifying ImageMagick itself.
  • XML files conforming to the W3C SVG DTD are now rendered directly by ImageMagick. Support is exploratory at this time, and will likely be re-implemented later.
  • The drawing primitives have been extended to support drawing bezier curves, rounded rectangles, and arcs. There is now support for drawing compound objects (a sequence of objects) using drawing paths. The concept of a drawing "pen" has been split into "stroke" (for the outline) and "fill" for the objects internal color. If fill is not defined, then only the object outline is drawn. This substantial change results in the existing drawing commands for filled objects (fillEllipse, fillRectangle, fillCircle, and fillPolygon) being deprecated.
  • ImageMagick now supports writing a "cache" format which is a snapshot of ImageMagick's disk-backed pixel cache (disk usage is approximately  rows x columns x 4 x sizeof(Quantum)). Use of the native cache format avoids the image decode step entirely (image pixels are memory-mapped, and accessed as required) and can be used to  accelerate repeated accesses to a large image.
  • The build environment for Windows NT is entirely re-done.  There is now a "configure" program which generates a set of Visual C++ project files which satisfy a set of reqirements (e.g. DLL, multi-thread, X11). These project files are then used to build ImageMagick.
  •  C API Changes

    There have been substantial C API changes in order to support thread-safety through API reentrancy, improvements to the interface, and support for multiple pixel views.

    API changes include:

    Implementation Changes


     


    Home Page Image manipulation software that works like magic.