ImageMagick - 5.1.1

ImageMagick has a new logo (contributed by Ofer Tenenbaum). Requests for all or part of a pixel row, or multiple complete pixel rows, are mapped directly to the underlying image in memory, or memory mapped from a disk file, avoiding performance-robbing pixel copying. Requested rectangular regions which are narrower than the image width must still be copied to a scratch space. Support for WBMP, Wireless Bitmap (level 0) images (contributed by Milan Votava) 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. 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.