'Magick Image File Format,
!

Magick Image File Format



@Magick Image File Format (MIFF) is a platform-independent?format for storing bitmap images. MIFF is a part of theBImageMagick toolkit of image manipulation utilities for theIX Window System. ImageMagick is capable of converting manyJdifferent image file formats to and from MIFF (e.g. JPEG,XPM, TIFF, etc.).

<A MIFF image file consist of two sections. The first7section is a header composed of keywords describing the9image in text form. The next section is the binary image@data. The header is separated from the image data by a :3character immediately followed by a newline.

@The MIFF header is composed entirely of ASCII characters.:The fields in the header are keyword and value combinationJin the keyword=value format, with each keyword and valueEseparated by an equal sign (=). Each keyword=value3combination is delimited by at least one control or8whitespace character. Comments may appear in the headerCsection and are always delimited by braces. The MIFF header5always ends with a colon (:) character, followed by a2newline character. It is also common for aformfeed and aAnewline character to appear before the colon. You can thenClist the image keywords with more(1), without printing the.binary image that follows the colon separator.

LThe following is a list of keyword=value combinations that#may be found in a MIFF file:


#
class=DirectClass#
class=PseudoClass&
indicates the type of binary imageB data stored in the MIFF file. If this keyword is not8 present, DirectClass image data is assumed.



colors=valueB
specifies the number of colors in a DirectClass image.:For a PseudoClass image, this keyword specifies the5size of the colormap. If this keyword is not present<in the header, and the image is PseudoClass, a linear3256 color grayscale colormap is used with the imagedata.



columns=value:
indicates the width of the image in pixels. This is a$required keyword and has no default.

.

compression=RunlengthEncoded!
compression=Zip#
indicates the type of algorithm6 used to compress the image data. If this keyword is. not present, the image data is assumed to be uncompressed.



depth=8
depth=16L
This is the depth of a single color value representing values from 0 toO 255 (depth 8) or 65535 (depth 16). If this keyword is absent, a depth of 8 isassumed.



gamma=value
GThis is the gamma of the image. If it is not specified, a gamma of 1.0((linear brightness response) is assumed,

id=ImageMagick>
The id keyword identifies the file as a MIFF-format0image file. This keyword is required and has no6default. Although this keyword can appear anywhere in7the header, it should start as the first keyword of the2header in column 1. This will allow programs like:file(1) to easily identify the file as MIFF.



matte=True
matte=False4
specifies whether a DirectClass image has7 matte data. Matte data is generally useful for imageC compositing. This keyword has no meaning for pseudocolor images.

?

montage=<width>x<height>{+-}<x5offset>{+-}<y offset>2
size and location of the individual tiles of a7composite image. See X(1) for details about thegeometry specification.

>

Use this keyword when the image is a composite of a number4of different tiles. A tile consists of an image andGoptionally a border and a label. <width> is the size in:pixels of each individual tile in the horizontal directionHand <height> is the size in the vertical direction. Each;tile must have an equal number of pixels in width and equal:in height. However, the width can differ from the height.K<x offset> is the offset in number of pixels from the<vertical edge of the composite image where the first tile ofHa row begins and <y offset> is the offset from the8horizontal edge where the first tile of a column begins.

@

If this keyword is specified, a directory of tile names must8follow the image header. The format of the directory isexplained below.



packets=value;
specifies the number of compressed color packets in the1image data section. This keyword is optional for@RunlengthEncoded images, mandatory for Zip images,$and not used for uncompressed image.



rows=value;
indicates the height of the image in pixels. This is a$required keyword and has no default.



scene=valueD
indicates the sequence number for this MIFF image file.@ This optional keyword is used when a MIFF image file is2 one in a sequence of files used in an animation.

!

signature=value9
this optional keyword contains a string that uniquely1 identifies the image colormap. Unique colormap9 identifiers are normally used when animating a sequence of PseudoClass images.

?The following is a sample MIFF header. In this example,#<FF> is a formfeed character:
      id=ImageMagick#      class=PseudoClass  colors=2560      signature=d79e1c308aa5bbcdeea8ed63df412da91      compression=RunlengthEncoded  packets=27601      columns=1280  rows=1024
      scene=1      {-         Rendered via Dore by Sandi Tennyson.      }      <FF>      :
JNote that keyword=value combinations may be separated by8newlines or spaces and may occur in any order within the<header. Comments (within braces) may appear anywhere before the colon.

CIf you specify the montage keyword in the header, follow the7header with a directory of image tiles. This directory7consists of a name for each tile of the composite image@separated by a newline character. The list is terminatedwith a NULL character.

>Following the header (or image directory if the montage:keyword is in the header) is the binary image data itself.9How the image data is formatted depends upon the class of9the image as specified (or not specified) by the value of'the class keyword in the header.

PDirectClass images (class=DirectClass) are continuous-tone,>RGB images stored as intensity values in red-green-blue9order. Each color value is one byte in size [0..255] and<there are three bytes per pixel (four with an optional matteAvalue). The total number of pixels in a DirectClass image9is calculates by multiplying the rows value by the columnvalue in the header.

LPseudoClass images (class=PseudoClass) are colormapped IRGB images. The colormap is stored as a series of red-green-blue 3pixel values, each value being a byte in size. The5number of colormap entries is indicated by the colors5keyword in the header, with a maximum of 65,535 total6entries allowed. The colormap data occurs immediately>following the header (or image directory if the montagekeyword is in the header).

BPseudoClass image data is an array of index values into the:color map. If these are 256 or fewer colors in the image,8each byte of image data contains an index value. If the<image contains more than 256 colors, then the index value is8stored as two contiguous bytes with the most significant2byte being first. The total number of pixels in a>PseudoClass image is calculated by multiplying the rows)value by the columns value in the header.

9MIFF is capable of storing a digital signature for9colormapped images. This signature was developed for use6when animating a sequence of images on a colormapped XAserver. All of the signatures in a sequence of MIFF files6are checked, and if they all match, you do not need tocompute a global colormap.

6The default colormap identifier is a digital signature8computed using RSA's Data Security MD5 Digest Algorithm.7(See a description of this algorithm in Internet draft,<[MD5], July 1992. The colormap signature is computed if theBMIFF file is part of a scene (i.e. the scene value does not equal 0).

BThe image data in a MIFF file may be uncompressed or may be8compressed using one of two algorithms. The compression5keyword in the header indicates how the image data is:compressed. The run-length encoding (RLE) algorithm may be:used to encode image data into packets of compressed data.CFor DirectClass images, runs of identical pixels values (not;BYTE values) are encoded into a series of four-byte packets;(five bytes if a matte value is included). The first three;bytes of the packet contain the red, green, and blue values6of the pixel in the run. The fourth byte contains the;number of pixels in the run. This value is in the range of<0 to 255 and is one less than the actual number of pixels in:the run. For example, a value of 127 indicates that thereare 128 pixels in the run.

>For PseudoClass images, the same RLE algorithm is used.8Runs of identical index values are encoded into packets.9Each packet contains the colormap index value followed by;the number of index values in the run. The number of bytes>n a PseudoClass RLE packet will be either two or three,;depending upon the size of the index values. The number of:RLE packets stored in the file is specified by the packets+keyword in the header, but is not required.

DA more complex algorithm, the Zip compression scheme, may be used toEto achieve a greater compression ratio than run-length encoding. TheCnumber of compressed packets stored in the file is specified by thepackets keyword in the header.

:MIFF files may contain more than one image. Simply;concatenate each individual image (composed of a header andimage data) into one file.




Copyright

3Copyright 1995 E. I. du Pont de Nemours and Company:Permission to use, copy, modify, distribute, and sell this8software and its documentation for any purpose is hereby6granted without fee, provided that the above copyright8notice appear in all copies and that both that copyright6notice and this permission notice appear in supporting4documentation, and that the name of E. I. du Pont de1Nemours and Company not be used in advertising or4publicity pertaining to distribution of the software:without specific, written prior permission. E. I. du Pont9de Nemours and Company makes no representations about the4suitability of this software for any purpose. It is5provided "as is" without express or implied warranty.

2E. I. du Pont de Nemours and Company disclaims all6warranties with regard to this software, including all8implied warranties of merchantability and fitness, in no:event shall E. I. du Pont de Nemours and Company be liable9for any special, indirect or consequential damages or any6damages whatsoever resulting from loss of use, data or8profits, whether in an action of contract, negligence or6other tortuous action, arising out of or in connection-with the use or performance of this software.




Authors

7John Cristy, E cristy@dupont.com, E.I. du Pont de Nemours and CompanyIncorporated.






1[home page]