ImageMagick 5.1.1, January 1, 2000
-
Image sizes are limited by physical memory plus available disk space on
the machine, or the file addressing limits of the operating system, whichever
comes first. This means that if you can figure out how to build a big enough
machine (and have plenty of time) terabyte images can be processed.
-
An image cache subsystem and API are provided to map portions (as small
as one pixel or as large as the entire image) of images into memory and
to save any updates.
-
Memory mapping is used to access files. This is the most efficient access
mechanism available.
-
DirectColor pixels are now stored in an efficient 32-bit structure (or
64-bit when QuantumLeap is enabled).
-
PseudoColor indices are now stored separately from the DirectColor pixels
(PseudoColor and DirectColor representations are still available simultaneously).
-
In-memory run-length encoding is eliminated.
-
Compressed images are decompressed and compressed incrementally in order
to limit memory consumption.
-
Lots of minor C API fixes and improvements.
-
Cache threshold setting for setting the boundary between use of RAM or
RAM + disk when processing an image:
- Use the --enable-cache option (e.g. --enable-cache=160) to set
the compiled-in default when running the configure script.
- Use -cache for ImageMagick utilities
- Set the cache_threshold attribute in PerlMagick
- Set the cacheThreshold attribute in Magick++
-
The identify utility now displays precise read-time values.
-
The Win32 build environment (now called "VisualMagick") is completely re-done
and supports building both multi-thread DLL as well as static libraries.
Image manipulation software that works like magic.