![[ImageMagick]](../images/script.png)
![[sponsor]](../images/sponsor.jpg)
|
|
|
|
|
[
About ImageMagick
Command-line Tools
Processing
Options
Program Interfaces
MagickWand
MagickCore
PerlMagick
Architecture
] [ Install from Source Unix Windows Binary Releases Unix Windows Resources ] [ Download ] [ Links ] [ Sponsors Trips to Argentina ] |
The citizens of Oz were quite content with their benefactor, the all-powerful Wizard. They accepted his wisdom and benevolence without ever questioning the who, why, and where of his power. Like the citizens of Oz, if you feel comfortable that ImageMagick can help you convert, edit, and compose your images without knowing the the nitty-gritty details on hows its done, feel free to skip this section. However, if you want to know more about the software and algorithms behind ImageMagick, read on. To fully benefit from this discussion, you should be comfortable with image nomenclature and be familiar with computer programming. An image typically consists of a rectangular region of pixels and metadata. To convert, edit, or compose an image in an efficient manner we need convenient access to any pixel anywhere within the region. And in the case of an image sequence, we need access to any pixel of any region of any image in the sequence. However, there are hundreds of image formats such JPEG, TIFF, PNG, GIF, etc., that makes it difficult to access pixels on demand. Within these formats we find differences in:
In addition, some image pixels may require attenuation, some formats permit more than one image, and some formats contain vectors that must be first rasterized (converted from vector to pixels). An efficient implementation of an image processing algorithm may require we get or put:
In addition, some images include a clip mask that define which pixels are eligible to be updated. Pixels outside the area defined by the clip mask remain untouched. Given the varied image formats and image processing requirements, we implemented the ImageMagick pixel cache to provide convenient access to any pixel on demand anywhere in the image region and from any image in a sequence. In addition, the pixel cache permits access to pixels outside the boundaries defined by the image (we call these virtual pixels). In addition to pixels, images have a plethora of image attributes and profiles. Attributes include the well known items like width, height, depth, and colorspace. An image may have optional attributes which might include the image author, a comment, a create date, and others. Some images also include profiles for color management, or EXIF, IPTC, 8BIM, or XMP informational profiles. ImageMagick provides command line options and programming methods to get, set, or view image attributes or profiles or apply profiles. ImageMagick has more than 275,000 lines of C code and optionally depends on over a million lines of code in dependent libraries (e.g. JPEG, PNG, TIFF libraries). Given that, one might expect a huge architecture document. However, a great majority of image processing is simply accessing pixels and its metadata and our simple and elegant implementation makes this easy for the ImageMagick user. We discuss the implementation of the pixel cache and getting and setting image attributes and profiles in the next few sections. Next, we discuss image coders to read or write a particular image format followed by a few words on creating your own image filters. In the final section, we discuss using ImageMagick within a thread of execution. The ImageMagick pixel cache is a repository for image pixels with up to 5 channels. The first 4 channels are stored first and an optional second area follows with 1 channel. The channels are at the depth specified when ImageMagick was built. The channel depths are 8 bits-per-pixel for the Q8 version of ImageMagick, 16 bits-per-pixel for the the Q16 version, and 32 bits-per-pixel for the Q32 version. The primary 4 channels can hold any value but typically contain red, green, blue, and alpha intensities or cyan, magenta, yellow, and alpha intensities. The optional fifth channel contains the colormap indexes for colormapped images or the black channel for CMYK images. The pixel cache storage may be anonymous memory mapped memory, heap memory, disk-backed memory mapped, or on disk. The pixel cache is referenced counted. Only the cache properties are copied when the cache is cloned. The cache pixels are only copied when you signal your intentions to update any of the pixels. Create the Pixel CacheThe pixel cache is created when an image is created and you try to get or put pixels. Here are three methods to create a pixel cache associated with an image:
In our discussion of the pixel cache we use the MagickCore API to illustrate our points but the principals are the same for other program interfaces to ImageMagick. When the pixel cache is created, the pixels are scaled from the whatever bit depth they originated from to that of the pixel cache. For example, a 1-channel 1-bit monochrome PBM image is scaled to a 4 channel 8-bit RGBA image assuming we are using the Q8 version of ImageMagick. You can determine which version you have with this command: -> identify -version Version: ImageMagick 6.2.7 04/30/06 Q16 http://www.imagemagick.org As you can see, the convenience of the pixel cache sometimes comes with a tradeoff in storage and speed. Access the Pixel CacheOnce the pixel cache is created you will want to get, update, or put pixels to it. Use these methods to get at the pixels in the cache:
Here is some typical MagickCore code for manipulating pixels in the pixel cache. In our example we copy pixels from the input image to the output image and decrease the intensity by 10%: When we first create the destination image by cloning the source image, the pixel cache pixels are not copied. They are only copied when we signal our intentions of updating the pixel cache by calling GetImagePixels() or SetImagePixels(). The SyncImagePixels() method does the actual pixel updates to the cache. Recall we mentioned that the indexes of a colormapped image or the black channel of a CMYK image are stored separately. We use GetIndexes() to gain access to this channel. For example, to print the colormap indexes, use:
IndexPacket
*indexes;
for (y=0; y < (long) source->rows; y++)
{
p=AcquireImagePixels(source,0,y,source->columns,1);
if (p == (const PixelPacket *) NULL)
break;
indexes=GetIndexes(source);
for (x=0; x < (long) source->columns; x++)
(void) printf("%d\n",indexes[x];
}
if (y < (long) source->rows)
/* an exception was thrown */
The pixel cache decides whether to give you direct access to the image pixels. In most cases the pixels are staged to an intermediate buffer-- and that is why you must call SyncImagePixels() to ensure this buffer is pushed out to the pixel cache to guarantee the corresponding pixels in the cache are updated. For this reason we recommend that you only acquire, get, or set a scanline or a few scanlines of pixels at a time. However, you can get any rectangular region of pixels you want. For GetImagePixels(), you must get a region within the bounds of the image area. For a 640 by 480 image, you can get a scanline of 640 pixels but if you ask for 641 pixels an error is returned. AcquireImagePixels() does not have this constraint. For example, p=AcquireImagePixels(source,-3,3,source->columns+7,7); gives you the pixels you asked for without complaint. Virtual PixelsWe call any pixels outside the image region virtual pixels. Their value is defined by the SetImageVirtualPixelMethod() from the MagickCore API or -virtual-method option from the command line. The methods include: background: The area surrounding the image is the background color. edge: Extend the edge pixel toward infinity (default). mirror: Mirror the image. tile: Tile the image. transparent: The area surrounding the image is transparent blackness. A fair number of image processing algorithms require a neighborhood of pixels about the pixel of interest. There is typically a caveat concerning how to handle pixels around the image boundaries, known as edge pixels. With virtual pixels, you do not need to concern yourself about special edge processing other than choosing which virtual pixel method is most appropriate for your algorithm. Cache Storage and Resource RequirementsWe mentioned previously that this simple and elegant design of the ImageMagick pixel cache comes at a price in terms of storage and processing speed. The pixel cache storage requirements scales with the area of the image and the bit depth of the pixel components. For example, if we have a 640 by 480 image and we're using the Q16 version of ImageMagick, the pixel cache consumes image width times height times bit depth divided by 8 times the number of channels bytes or approximately 2.3 megabytes (i.e. 640 * 480 * 2 * 4). Not too bad, but what if your image is 25000 by 25000 pixels. We now need approximately 4.7 gigabytes of storage. Ouch. ImageMagick accounts for possible huge storage requirements by caching large images to disk rather than memory. By default, the pixel cache is stored in memory using anonymous memory mapping, if that fails we try heap memory, if that fails we create the pixel cache on disk and attempt to memory-map it, if that fails we simply use standard disk I/O. Disk is cheap but its also very slow, upwards of 1000 times slower than memory. We can get some speed improvements, up to 5 times, if we use memory mapping to the disk-based cache. These decisions about storage are made automatically by ImageMagick negotiating with the operating system. However, you can influence how ImageMagick allocates the pixel cache with cache resource limits. The limits include:
To determine the current setting of these limits, use this command: -> identify -list resource File Area Memory Map Disk ------------------------------------------------ 960 5.8711gb 7.8281gb 15.656gb 16eb You can set these limits either with environment variables or with the SetMagickResourceLimit() MagickCore API method. As an example, our online web interface to ImageMagick, ImageMagick Studio, has a memory limit of 32 megabytes and a map limit of 64 megabytes and a disk limit of 1 gigabytes. Since we process multiple users at once we don't want any one user consuming all the available memory on our system. Instead large images are cached to disk which stops these users from consuming too much process time as well (instead they consume I/O time). If the image they upload is too large, the pixel cache disk limit is exceeded and the program exits. Note, the cache limits are global, meaning if you create several images, the combined resource requirements are compared to the limit to determine the pixel cache storage disposition. Cache ViewsAcquireImagePixels(), GetImagePixels(), SetImagePixels(), and SyncImagePixels() can only deal with one pixel cache area at a time. Suppose you want to access the first and last scanline from the same image at the same time? The solution is to use a cache view. A cache view permits you to access as many areas simultaneously in the pixel cache as you require. The cache view methods behave like the previous methods except you must first open a view and close it when you are finished with it. Here is a snippet of MagickCore that gives us two areas of an image:
ViewInfo
*view_1,
*view_2;
view_1=OpenCacheView(source);
view_2=OpenCacheView(source);
for (y=0; y < (long) source->rows; y++)
{
u=AcquireCacheView(source,0,y,source->columns,1);
v=AcquireCacheView(source,0,source->rows-y,source->columns,1);
if ((u == (const PixelPacket *) NULL) || (v == (const PixelPacket *) NULL))
break;
for (x=0; x < (long) source->columns; x++)
{
/* do something with u & v here */
}
}
view_1=CloseCacheView(view_1);
view_2=CloseCacheView(view_2);
if (y < (long) source->rows)
{ /* an exception was thrown */ }
Magick Persistent Cache FormatRecall that each image format is decoded by ImageMagick and the pixels are placed in the pixel cache. If you write an image, the pixels are read from the pixel cache and encoded as required by the format you are writing (e.g. GIF, PNG, etc.). The Magick Persistent Cache (MPC) format is designed to eliminate the overhead of decoding and encoding pixels to and from an image format. MPC writes two files. One, with the extension .mpc, retains all the attributes associated with the image or image sequence (e.g. width, height, colorspace, etc.) and the second, with the extension .cache, is the pixel cache in the native format. When reading an MPC image file, ImageMagick reads the image attributes and memory maps the pixel cache on disk eliminating the need for decoding the image pixels. The tradeoff is in disk space. MPC is generally larger in file size than most other image formats. Best PracticesAlthough you can request any pixel from the pixel cache, any block of pixels, any scanline, multiple scanlines, any row, or multiple rows with the AcquireImagePixels(), GetImagePixels(), SetImagePixels, AcquireCacheView(), GetCacheView(), and SetCacheView() methods, ImageMagick is optimized to return a few pixels or a few pixels rows at at time. There is additional optimizations if you request a single scanline or a few scanlines at a time. These methods also permit random access to the pixel cache, however, ImageMagick is optimized for sequential access. If you are updating pixels obtained with GetImagePixels() or GetCacheView() don't forget to call SyncImageCache() or SyncCacheView() after you update the pixels to ensure any updates get pushed to the pixel cache. Use SetImagePixels() or SetCacheView() if you setting an initial pixel value. The GetImagePixels() or GetCacheView() method reads pixels from the cache and if you are setting an initial pixel value this read is unnecessary. Don't forget to call SyncImagePixels() to push your updates to the pixel cache. You can request pixels outside the bounds of the image with AcquireImagePixels() or AcquireCacheView(), however, it is more efficient to request pixels inside the image region. Although you can force the pixel cache to disk using appropriate resource limits, disk access can be upwards of 1000 times slower than memory access. For fast, efficient, access to the pixel cache, try to keep the pixel cache in anonymous memory mapped or heap memory. The ImageMagick Q16 version of ImageMagick permits you to read and write 16 bit images without scaling but the pixel cache consumes twice as much memory as the Q8 version. If your system has constrained memory resources, you might want to use the Q8 version of ImageMagick If you are dealing with large images, make sure the pixel cache is written to a disk area with plenty of free space. Under Unix, this is typically /tmp and for Windows, c:/temp. You can tell ImageMagick to write the pixel cache to an alternate location with the MAGICK_TMPDIR environment variable. For example, export MAGICK_TMPDIR=/data/magick If you plan on processing the same image many times, consider the MPC format. Reading a MPC image has near-zero overhead because its in the native pixel cache format eliminating the need for decoding the image pixels. Here is an example:
convert bigassimage.tif bigassimage.mpc convert bigassimage.mpc -crop 100x100+0+0 1.png convert bigassimage.mpc -crop 100x100+100+0 1.png convert bigassimage.mpc -crop 100x100+200+0 1.png ... MPC is ideal for web sites. It reduces the overhead of reading and writing an image. We use it exclusively at our online image studio. Images have metadata associated with them in the form of attributes (e.g. width, height, description, etc.) and profiles (e.g. EXIF, IPTC, color management). ImageMagick provides convenient methods to get, set, or update image attributes and get, set, update, or apply profiles. Some of the more popular image attributes are associated with the Image structure in the MagickCore API. For example:
(void) printf("image width: %lu, height: %lu\n",image->columns,image->rows);
For a great majority of image attributes, such as an image comment or description, we use the GetImageAttribute() and SetImageAttribute() methods. Here we set an attribute and fetch it right back:
const ImageAttribute
*attribute;
(void) SetImageAttribute(image,"comment","This space for rent");
attribute=GetImageAttribute(image,"comment");
if ((attribute == (const ImageAttribute *) NULL) &&
(attribute->value != (const char *) NULL))
(void) printf("Image comment: %s\n",attribute->value);
Image profiles are handled with GetImageProfile(), SetImageProfile(), and ProfileImage() methods. Here we set a profile and fetch it right back:
StringInfo
*profile;
profile=AcquireStringInfo(length);
SetStringInfoDatum(profile,my_exif_profile);
(void) SetImageProfile(image,"EXIF,profile);
DestroyStringInfo(profile);
profile=GetImageProfile(image,"EXIF");
if (profile != (StringInfo *) NULL)
(void) PrintStringInfo(stdout,"EXIF",profile);
An image coder is responsible for registering, optionally classifying, optionally reading, optionally writing, and unregistering one image format (e.g. PNG, GIF, JPEG, etc.). Registering alerts ImageMagick a particular format is available to read or write. While unregistering tells ImageMagick the format is no longer available. The classifying method looks at the first few bytes of an image and decides if the image is in the expected format. The reader sets the image size, colorspace, and other attributes and loads the pixel cache with the pixels. The reader returns a null image and an exception if an error occurs or returns a single image or an image sequence if the format supports multiple images per file. The writer does the reverse. It takes the image attributes and unloads the pixel cache and writes them as required by the image format. The modular design of the image coder makes it relatively easy to support new formats. Here is a complete image coder with the exception of the classification method: ImageMagick provides a convenient mechanism for adding your own custom image processing algorithms. They are invoked from the command line with the –process option or from the MagickCore API method ExecuteModuleProcess(). ImageMagick includes a sample custom filter listed here. It computes a few statistics such as the brightness and saturation mean and standard-deviation. To invoke the custom filter from the command line, use this command:
-> convert logo: -process Analyze -verbose info:
Image: logo:
Format: LOGO (ImageMagick Logo)
Class: PseudoClass
Geometry: 640x480
...
BrightnessMean: 59192
BrightnessStddev: 15209
SaturationMean: 6156
SaturationStddev: 16952
ImageMagick is thread safe with the exception of the MagickCore AcquireImagePixels(), GetImagePixels(), SetImagePixels(), and SyncImagePixels() pixel cache methods. If a thread wants to access the pixel cache, simply use a cache view. We do this for the CompositeImage() method, for example. Suppose we want to composite a single image over a different image in each thread of execution. If we use AcquireImagePixels(), the results could be corrupt since multiple threads might be asking for different areas of the pixel cache simultaneously. Instead we use AcquireCacheView() which creates a unique view for each thread of execution ensuring our program behaves properly regardless of how many threads are invoked. The other program interfaces, such as the MagickWand API, are thread safe so there are no special precautions for threads of execution. |