Magick Image File Format (MIFF) is a platform-independent format for storing bitmap images. MIFF was originally invented by John Cristy for ImageMagick, but is also a native format of GraphicsMagick. It is useful as an efficient lossless working file format which assures that all of the image attributes used by GraphicsMagick are preserved. Several lossless compression algorithms are available in order to save space.
|
A MIFF image file consist of two sections. The first section is a header composed of keywords describing the image in text form. The next section is the binary image data. The header is separated from the image data by a : character immediately followed by a ctrl-Z.
The MIFF header is composed entirely of LATIN-1 characters. The fields in the header are keyword and value combination in the keyword=value format, with each keyword and value separated by an equal sign (=). Each keyword=value combination is delimited by at least one control or whitespace character. Comments may appear in the header section and are always delimited by braces. The MIFF header always ends with a colon (:) character, followed by a ctrl-Z character. It is also common to precede the colon with a formfeed and a newline character. The formfeed prevents the listing of binary data when using more(1) under Unix where the ctrl-Z has the same effect with the type command on the Win32 command line.
The following is a list of keyword=value combinations that may be found in a MIFF file:
Disposal |
Description |
---|---|
0 |
No disposal specified. |
1 |
Do not dispose between frames. |
2 |
Overwrite frame with background color from header. |
3 |
Overwrite with previous frame. |
Other key value pairs are permitted. If a value contains whitespace it must be enclosed with braces as illustrated here:
id=GraphicsMagick class=PseudoClass colors=256 compression=RLE columns=1280 rows=1024 scene=1 signature=d79e1c308aa5bbcdeea8ed63df412da9 copyright={Copyright (c) 2000 ImageMagick Studio} <FF> :
Note that keyword=value combinations may be separated by newlines or spaces and may occur in any order within the header. Comments (within braces) may appear anywhere before the colon.
The elements shown in the following table may appear after the header and before the image data. These elements appear in the order described in the following table if the keyword indicates that they exist.
Element |
Keyword |
Description |
---|---|---|
Image directory |
montage |
The directory consists of a name for each tile of the composite image separated by a newline character. The list is terminated with a NULL character. |
ICC Profile |
profile-icc |
Binary color profile. |
IPTC Profile |
profile-iptc |
Binary IPTC Newsphoto profile. |
Generic Profiles |
profile-<name> |
Binary generic profile. Multiple named generic profiles may exist. |
Next comes the binary image data itself. How the image data is formatted depends upon the class of the image as specified (or not specified) by the value of the class keyword in the header. All numeric values in the binary section are written with the most significant bytes occuring first (big-endian ordering).
DirectClass images (class=DirectClass) are continuous-tone, images stored as RGB (red, green, blue), RGBA (red, green, blue, alpha), CMYK (cyan, yellow, magenta, black), and CMYKA (cyan, yellow, magenta, black, alpha) intensity values as defined by the colorspace and matte keywords. The size of each intensity value depends on the depth of the image. The depth, number of bytes, and numeric range of each value are shown in the following table:
Depth |
Bytes Per Value |
Value Range |
---|---|---|
8 |
1 |
0..255 |
16 |
2 |
0..65535 |
32 |
4 |
0..4294967295 |
The alpha value (if it occurs) represents the degree of pixel opacity (zero is totally transparent).
PseudoClass images (class=PseudoClass) are colormapped RGB images. The colormap is stored as a series of red, green, and blue pixel values. The size of each colormap value depends on the image depth, as shown in the following table:
Depth |
Bytes Per Value |
Value Range |
Bytes Per Colormap Entry |
---|---|---|---|
8 |
1 |
0..255 |
3 |
16 |
2 |
0..65535 |
6 |
32 |
4 |
0..4294967295 |
12 |
The number of colormap entries is defined by the colors keyword. The colormap data occurs immediately following the header (or image directory if the montage keyword is in the header). Immediately following the colormap data is the PseudoClass image data. PseudoClass image data is an array of index values into the color map. The number of bytes comprising the index value depends on the number of colors in the image. The following table shows the number of bytes in each colormap index as determined by the colors keyword:
Colors |
Bytes Per Index |
Index Range |
---|---|---|
<=256 |
1 |
0..255 |
<=65535 |
2 |
0..65535 |
<=4294967295 |
4 |
0..4294967295 |
If matte is true, each colormap index is immediately followed by an equally-sized alpha value. The alpha value represents the degree of pixel opacity (zero is totally transparent).
The image data in a MIFF file may be uncompressed, runlength encoded, Zip compressed, or BZip compressed. The compression keyword in the header defines how the image data is compressed. Uncompressed pixels are stored one scanline at a time in row order. Runlength encoded compression counts runs of identical adjacent pixels and stores the pixels followed by a length byte (the number of identical pixels minus 1). Zip and BZip compression compresses each row of an image and precedes the compressed row with the length of compressed pixel bytes as a word in most significant byte first order.
MIFF files may contain more than one image. Simply concatenate each individual image (composed of a header and image data) into one file.
|
John Cristy, magick-users@imagemagick.org ImageMagick Studio LLC.
Copyright © GraphicsMagick Group 2002, 2003, 2004