Image Standards

This section discusses the most important image standards, most of them using the previously mentioned compression techniques. Most of them are also file types LabVIEW and IMAQ Vision can handle.

Windows Bitmap Format (BMP)

This device-independent format is primarily used by Windows operating systems. In particular, programs like Paintbrush or Microsoft Paint generate BMP files. The main parts of the BMP format are:

• BITMAP file header;
• BITMAP- INFO
  • BITMAP-INFO header
  • RGB-QUAD;
• BITMAP image data.

The BITMAP file header is structured according to Table 3.6. It is important that the first word of the header contains "BM" in order to indicate a valid BMP file.

Table 3.6. Structure of the BMP File Header

Offset	Bytes	Name	Description
00H	2	bfType	file ID ( BM )
02H	4	bfSize	file length (byte)
06H	2		reserved (must be 0)
08H	2		reserved (must be 0)
0AH	4	bfOffs	offset to data area

Following the BITMAP file header, which describes only the file itself, the BITMAP info header gives information about the image data (Table 3.7). Here, the field biBitCnt is of extra importance; it defines the number of colors in the image, using the following values:

1:	defines 1 bit per pixel (binary image);
4:	defines an image with 16 colors;
8:	defines an image with 256 colors;
24:	defines an image with 16 million colors. The colors are coded directly in the image data area.

Table 3.7. Structure of the BMP Info Header

Offset	Bytes	Name	Description
0EH	4	biSize	length of header (byte)
12H	4	biWidth	width of bitmap in pixels
16H	4	biHeight	height of bitmap in pixels
1AH	2	biPlanes	color planes
1CH	2	biBitCnt	number of bits per pixel
1EH	4	biCompr	compression type
22H	4	biSizeIm	image size (byte)
26H	4	biXPels	horizontal resolution (pixels/m)
2AH	4	biYPels	vertical resolution (pixels/m)
2EH	4	biClrUsed	number of used colors
32H	4	biClrImp	number of important colors

The field biCompr defines the type of compression used:

0:	no compression;
1:	RLE coding for 8 bit per pixel;
2:	RLE coding for 4 bit per pixel.

Table 3.8 shows the RGB-QUAD block, which gives additional information about the image color.

Windows NT uses only the three fields from 36H to 3EH . Starting with Windows 95, a new format called BMP4 was introduced; it uses additional fields (second part of Table 3.8).

With BMP4 color spaces other than RGB can be used. One of them is the CIE model (Commission Internationale de l'Eclairage), which is the basis for all of the color models we discussed in Chapter 2.

The following data area contains the image data itself. Usually, the data is not compressed and is stored line by line. The compression options described above are seldom used.

Table 3.8. Structure of the BMP RGB-QUAD Block

Offset	Bytes	Name	Description
36H	4	redMask	mask of red color part
3AH	4	greenMask	mask of green color part
3EH	4	blueMask	mask of blue color part
42H	4	only BMP4	mask of alpha channel
46H	4	only BMP4	color space type
4AH	4	only BMP4	x coordinate red CIE end point
4EH	4	only BMP4	y coordinate red CIE end point
52H	4	only BMP4	z coordinate red CIE end point
56H	4	only BMP4	x coordinate green CIE end point
5AH	4	only BMP4	y coordinate green CIE end point
5EH	4	only BMP4	z coordinate green CIE end point
62H	4	only BMP4	x coordinate blue CIE end point
66H	4	only BMP4	y coordinate blue CIE end point
5EH	4	only BMP4	z coordinate blue CIE end point
62H	4	only BMP4	gamma red coordinate
66H	4	only BMP4	gamma green coordinate
6AH	4	only BMP4	gamma blue coordinate

Graphics Interchange Format (GIF)

This format was developed by CompuServe and first released under the standard GIF87a in 1987 and two years later extended to GIF89a. Interesting features of the GIF format are the capabilities for animations (using multiple images) and for transparency. The typical structure of a GIF file is as follows :

• GIF header block;
• logical screen descriptor block;
• global color map (optional);
• extension blocks (optional);
• image area (repeated for each image):
  • image descriptor block,
  • local color map (optional),
  • extension block (optional),
  • raster data blocks;
• GIF terminator.

A GIF file always starts with the header, using the simple structure shown in Table 3.9. Table 3.10 shows the structure of the subsequent logical screen descriptor block.

Table 3.9. Structure of the GIF Header

Offset	Bytes	Description
00H	3	signature "GIF"
03H	3	version "87a" or "89a"

Table 3.10. Structure of the GIF Logical Screen Descriptor

The content of the logical screen descriptor block is valid for the entire GIF file. Starting from offset 04H , a bit field, called resolution flag , describes some definitions: Bit 7 indicates whether a global color map is present. If this bit is true, a global color map follows the logical screen descriptor block.

Bits 4 to 6 define how many bits are used for the color resolution. Bit 3 indicates whether the global color map is sorted (only GIF89a), and bits 0 to 2 define the number of bits per pixel.

The (optional) global color map contains the fundamental color table for all of the subsequent images. It is used if the image itself does not have its own color table. The maximum color resolution for each pixel is 8 bits (256 values).

Table 3.11. Structure of the GIF Image Descriptor Block

Each image of the GIF file starts with an image descriptor block (Table 3.11) that contains the most important image properties. The last byte again contains some flags; one of them is the local color map flag, which specifies whether a local color map block is present and follows the image descriptor block.

The optional extension block, which may follow the local color map, contains some data blocks starting with a byte that defines its length. The entire block starts with a header byte (ASCII 21H = '!') and ends with a terminator byte (ASCII 00H ).

The image data itself is structured in one or more raster data blocks (Table 3.12). The first byte defines the minimal code length for the used LZW coding (usually the number of color bits per pixel); the second byte gives the number of bytes in the following data block n .

Table 3.12. Structure of a GIF Raster Data Block

Bytes	Description
1	code size
1	bytes in data block
n	data bytes

The end of a GIF file is defined by a terminator block containing a single byte (ASCII 3BH = ';' ).

Tag Image File Format (TIFF 6.0)

The Tag Image File Format (TIFF; currently available in version 6.0) was defined by a few companies (among them Aldus, Hewlett-Packard, and Microsoft). The fundamental structure of a TIFF file is built by a header (Table 3.13) and a variable number of data blocks, which are addressed by pointers.

Table 3.13. Structure of the TIFF Header

Offset	Bytes	Description
00H	2	byte order ('II' = Intel, 'MM' = Motorola)
02H	2	version number
04H	4	pointer to first image file directory (IFD)

Another important part of a TIFF file is built by the image file directory (IFD) blocks (Table 3.14). Their main function is to work as a directory and as a header for the specific data areas. The data block belonging to IFDs is addressed with a pointer.

Table 3.14. TIFF IFD Block Structure

Offset	Bytes	Description
00H	2	number of entries
02H	12	tag 0 (12 bytes)
0EH	12	tag 1 (12 bytes)
	...
...	12	tag n (12 bytes)
...	4	pointer to next IFD (0 if last)

The next unit of a TIFF file is a tag , which is a 12-byte data structure containing information about the image data. The content of a tag is shown in Table 3.15; it ends with a pointer to the respective image data area. Table 3.16 defines the different data types.

Finally, Tables 3.17 “3.26 show the different tag groups. The definition of the tags is beyond the scope of this book; for more details, please read [30].

Table 3.15. TIFF Tag Structure

Offset	Bytes	Description
00H	2	tag type
02H	2	data type
04H	4	length of data area
08H	4	pointer to data area

Table 3.16. Tag Data Types

Code	Type	Remarks
01H	Byte	8-bit byte
02H	ASCII	8-bit ASCII code
03H	SHORT	16-bit (unsigned) integer
04H	LONG	32-bit (unsigned) integer
05H	RATIONAL	2 LONGs: 1: Fraction, 2: Denominator
06H	SBYTE	8-bit (signed) integer
07H	UNDEFINED	8-bit anything
08H	SSHORT	16-bit (signed) integer
09H	SLONG	32-bit (signed) integer
0AH	SRATIONAL	2 SLONGS: 1: Fraction, 2: Denominator
0BH	FLOAT	4-byte single precision IEEE floating point
0CH	DOUBLET	8-byte double precision IEEE floating point

Table 3.17. Image Organization Tags

Code	Tag Group	Data Type	Values
0FEH	New subfile	LONG	1
0FFH	SubfileType	SHORT	1
100H	ImageWidth	SHORT/LONG	1
101H	ImageLength	SHORT/LONG	1
112H	Orientation	SHORT	1
11AH	XResolution	RATIONAL	1
11BH	YResolution	RATIONAL	1
11CH	PlanarConfiguration	SHORT	1
128H	ResolutionUnit	SHORT	1

Table 3.18. Image Pointer Tags

Code	Tag Group	Data Type	Values
111H	StripOffsets	SHORT/LONG	StripPerImage
117H	StripByteCounts	SHORT/LONG	StripPerImage
116H	RowsPerStrip	SHORT/LONG	1
142H	TileWidth	SHORT/LONG	1
143H	TileLength	SHORT/LONG	1
144H	TileOffsets	SHORT/LONG	TilesPerImage
145H	TileByteCounts	SHORT/LONG	TilesPerImage

Table 3.19. Pixel Description Tags

Code	Tag Group	Data Type	Values
102H	BitsPerSample	SHORT	SamplesPerPixel
106H	PhotometricInterpretation	SHORT	1
107H	Thresholding	SHORT	1
108H	CellWidth	SHORT	1
109H	CellLength	SHORT	1
115H	SamplesPerPixel	SHORT	1
118H	MinSampleValue	SHORT	SamplesPerPixel
119H	MaxSampleValue	SHORT	SamplesPerPixel
122H	GrayResponseUnit	SHORT	1
123H	GrayResponseCurve	SHORT	2 BitsPerSample
12CH	ColorResponseUnit	SHORT	1
12DH	ColorResponseCurves	SHORT	1 or N
131H	Software	ASCII
132H	DateTime	ASCII
13BH	Artist	ASCII
13CH	HostComputer	ASCII
13DH	Predictor	SHORT	1
13EH	WhitePoint	RATIONAL	2
13FH	PrimaryChromatics	LONG	2 x SamplesPerPixel
140H	ColorMap	SHORT	3 x 2 BitsPerSample

Table 3.20. Data Orientation Tags

Code	Tag Group	Data Type	Values
10AH	FillOrder	SHORT	1

Table 3.21. Data Compression Tags

Code	Tag Group	Data Type	Values
103H	Compression	SHORT	1
124H	T4Options	SHORT	1
125H	T6Options	SHORT	1
152H	ExtraSamples	BYTE	n
153H	SampleFormat	SHORT	SamplesPerPixel
154H	SMinSampleValue	ANY	SamplesPerPixel
155H	SMaxSampleValue	ANY	SamplesPerPixel
156H	TransferRange	SHORT	6

Table 3.22. Document and Scanner Description Tags

Code	Tag Group	Data Type	Values
10DH	DocumentName	ASCII
10EH	ImageDescription	ASCII
10FH	ScannerMake	ASCII
110H	ScannerModel	ASCII
11DH	PageName	ASCII
11EH	XPosition	RATIONAL
11FH	YPosition	RATIONAL
129H	PageNumber	SHORT	2
298H	Copyright	ASCII

Table 3.23. Storage Management Tags

Code	Tag Group	Data Type	Values
120H	FreeOffsets	LONG
121H	FreeByteCounts	LONG

Table 3.24. Ink Management Tags

Code	Tag Group	Data Type	Values
14CH	InkSet	SHORT	1
14DH	InkNames	ASCII
14EH	NumberOfInks	SHORT	1
150H	DotRange	BYTE/SHORT	n
151H	TargetPrinter	ASCII

Table 3.25. JPEG Management Tags

Code	Tag Group	Data Type	Values
200H	JPEGProc	SHORT	1
201H	JPEGInterchangeFormat	LONG	1
203H	JPEGInterchangeFormatLength	LONG	1
204H	JPEGRestartInterval	SHORT	1
205H	JPEGLossLessPredictors	SHORT	SamplesPerPixel
206H	JPEGPointTransforms	SHORT	SamplesPerPixel
207H	JPEGQTables	LONG	SamplesPerPixel
208H	JPEGDCTables	LONG	SamplesPerPixel
209H	JPEGACTables	LONG	SamplesPerPixel

Table 3.26. YC b C r Management Tags

Code	Tag Group	Data Type	Values
211H	YCbCrCoefficients	RATIONAL	3
212H	YCbCrSubSampling	SHORT	2
213H	YCbCrPositioning	SHORT	1

The image data of a TIFF file can be uncompressed or compressed with one of the following algorithms:

• PackBit compression, which is a proprietary coding technique;
• Modified Huffman (MH) coding;
• LZW coding by dividing the data into " strips ," with a maximum of 8 kbytes and a maximum buffer length of 12 bits;
• JPEG coding (since TIFF 6.0). Usually, the TIFF file format is known for its lossless compression techniques; therefore, JPEG does not seem to fit in here. Also, JPEG compression is not used very often in TIFF files.

Portable Network Graphics Format (PNG)

The PNG file format was originally defined to replace the GIF format because of the patented LZW coding used in GIF. PNG supports images with up to 16 bits per pixel for gray-scale values and up to 48 bits for color values.

The main elements of a PNG file (and also of some other formats) are CHUNKs, which are data blocks of variable length, thus quite similar to tags, with a structure according to Table 3.27.

Table 3.27. CHUNK Structure

Offset	Bytes	Description
00H	4	length of data area (bytes)
04H	4	CHUNK type
08H	n	CHUNK data area
...H	4	CRC value of data area

In general, a PNG file consists of a signature (8 bytes long) and at least three CHUNKs (IDHR, IDAT, and IEND). If the first letter of a CHUNK type is a capital letter, the CHUNK is a critical CHUNK, which must be supported by every program able to read PNG files. [11] All others are ancillary CHUNKs.

[11] The capitalizations of the other letters have specific meanings, but there is no need to discuss them here.

Four critical CHUNKs are possible:

• The Header CHUNK (IHDR) (Table 3.28) contains information about the data stored in the PNG file and immediately follows the PNG signature.
• The Palette CHUNK (PLTE) (Table 3.29) is only used in color images and defines palette values (one for red, green, blue each).
• The Image Data CHUNK (IDAT) contains the compressed image data. If the image is large, it is split into more than one IDAT CHUNKs.
• The Trailer CHUNK (IEND) is located at the end of the PNG file and does not contain a data area.

Table 3.28. Header (IHDR) CHUNK

Offset	Bytes	Description
00H	4	image width (pixels)
04H	4	image height (pixels)
08H	1	bits per pixel (per sample)
09H	1	color type
0AH	1	compression type
0BH	1	filter type
0CH	1	interlace flag

Table 3.29. Palette (PLTE) CHUNK

Offset	Bytes	Description
00H	3	palette value (1 byte each for red, green, blue)

Tables 3.30 “3.33 show examples for ancillary CHUNKs. For more information about them and other possible CHUNKs, please read [30].

Table 3.30. Primary Chromacities and White Point (cHRM) CHUNK

Offset	Bytes	Description
00H	4	x value white point
04H	4	y value white point
08H	4	x value red
0CH	4	y value red
10H	4	x value green
14H	4	y value green
18H	4	x value blue
1CH	4	y value blue

Table 3.31. Physical Pixel Dimension (pHYs) CHUNK

Offset	Bytes	Description
00H	4	pixels per unit ( x direction)
04H	4	pixels per unit ( y direction)
08H	1	flag: 0 = unit unknown, 1 = unit meter

Table 3.32. Textual Data (tEXt) CHUNK

Offset	Bytes	Description
00H	n	string with key word
...H	1	00H as separator
...H	n	text

Table 3.33. Image Last Modification Time (tIME) CHUNK

Offset	Bytes	Description
00H	2	year
02H	1	month (1 “ 12)
03H	1	day (1 “ 31)
04H	1	hour (0 “ 23)
05H	1	minute (0 “ 59)
06H	1	second (0 “ 60)

The image data compression is a deflate/inflate compression, based on the LZ77 algorithm using a 32-kbyte sliding window. This algorithm is a license-free technique.

ZSoft Paintbrush File Format (PCX)

This image format is quite old; it was developed by ZSoft and usually used by the imaging software Paintbrush. Because of its great (former) popularity, it is still supported by almost all imaging programs. Table 3.34 shows the structure of a PCX header.

PCX uses the color definition by color planes as shown in Figure 1.5 on page 11. Older PCX versions use only 8 colors (16 with an intensity bit); this use corresponds to the color capabilites of CGA or EGA cards. Starting with version 3.0, PCX supports 256 colors (VGA support).

Table 3.34. PCX File Header

Offset	Bytes	Description
00H	1	identification: 0AH = PCX
01H	1	PCX Version: 0: 2.5, 2: 2.8, 3: 2.8 (w/o palette), 5: 3.0
02H	1	compression flag: 0: no compression, 1: RLE
03H	1	bits per pixel (per plane)
04H	8	coordinates of original image: XMIN , YMIN , XMAX , YMAX
0CH	2	horizontal resolution of a point in dpi (dots per inch)
0EH	2	vertical resolution of a point in dpi (dots per inch)
10H	48	color map with color palette (16 x 3 byte field)
40H	1	reserved
41H	1	number of color planes (max. 4)
42H	2	bytes per image line (even number)
44H	2	palette data: 1: color, 2: gray
46H	58	empty

The image data area itself is either RLE-compressed or uncompressed. The image is divided into its color and intensity information and processed line by line; that means that first the red value of line 1 is compressed and stored, followed by the green value, the blue value, and the intensity value. After that, the processing of line 2 starts.

JPEG/JFIF and JPEG2000 (JPG, J2K)

The JPEG and JPEG2000 standards were already discussed as compression methods . JPEG uses DCT (discrete cosine transform), quantization, and Huffman encoding of the coefficients; JPEG2000 uses DWT (discrete wavelet transform), quantization, and arithmetic coding of the coefficients.

The file format used for JPEG coded files is called JPEG File Interchange Format (JFIF); a JFIF file contains the following:

• SOI segment (start of image)
• APP0 segment (application marker)
• Extension APP0 segments (optional)
• SOF segment (start of frame)
• EOI segment (end of image)

The entire image data is located in the SOF segments.

A JFIF file may also contain smaller images (called thumbnails ) for preview use. In this case, additional (extension) APP0 segments follow the first APP0 segment. A JFIF file always starts with an SOI segment and ends with an EOI segment.

Tables 3.35, 3.36, and 3.37 show the structures of SOI, EOI, and APP0 segments, respectively.

Table 3.35. JFIF SOI Segment

Offset	Bytes	Description
00H	2	SOI signature ( FFD8H )

Table 3.36. JFIF EOI Segment

Offset	Bytes	Description
00H	2	EOI signature ( FFD9H )

The (optional) extension APP0 segment (Table 3.38) contains an extension code that defines the structure of the thumbnail image:

• 10H : thumbnail JPEG coded;
• 11H : thumbnail with 1 byte per pixel;
• 13H : thumbnail with 3 bytes per pixel.

Table 3.37. JFIF APP0 Segment

Offset	Bytes	Description
00H	2	APP0 signature ( FFE0H )
02H	2	segment length
04H	5	ID "JFIF"
09H	2	version ( 0102H )
0BH	1	units
0CH	2	x density
0EH	2	y density
10H	1	x thumbnail
11H	1	y thumbnail
12H	3 x n	RGB thumbnail values

Table 3.38. JFIF Extension APP0 Segment

Offset	Bytes	Description
00H	2	APP0 signature ( FFE0H )
02H	2	segment length
04H	5	ID "JFXX"
09H	1	extension code
0AH	n	data area

The next tables show some details about the encoding: Table 3.39 describes the DHT segment, which specifies the Huffman table; Table 3.40 shows the DAC segment used for the coding of the color components . Finally, Table 3.41 shows the DQT segment that defines the JPEG quantization table.

Table 3.39. Define Huffman Table (DHT) Segment

Offset	Bytes	Description
00H	2	DHT signature ( FFC4H )
02H	2	segment length
04H	1	color component index
05H	16	Huffman table length
15H	n	Huffman table

Table 3.40. Define Arithmetic Coding (DAC) Segment

Offset	Bytes	Description
00H	2	DAC signature ( FFCCH )
02H	2	segment length
04H	1	color component index
05H	1	value

Table 3.41. Define Quantization Table (DQT) Segment

Offset	Bytes	Description
00H	2	DQT signature ( FFDBH )
02H	2	segment length
04H	1	index
05H	64	quantization table

As mentioned above, the entire data is stored in SOF segments. JFIF allows a number of different SOF segments, each of them specifying a coding algorithm. Until now, only baseline DCT coding has been used.

Comparison of Image Standards

If we compare some of the discussed image standards, we may find file sizes as shown in Table 3.42. All of the files are enclosed on the CD; they were generated with the standard settings of Corel Photo Paint version 8.

Table 3.42. Comparison of Image Standards

	BMP	GIF	TIF	PNG	PCX	JPG	J2K
Compression:	none	none/LZW	none	LZ77	none	DCT	DWT
Monochrome size (kbytes):	76	76	75	67	77	23	2
Color size (kbytes):	223	34	223	207	229	28	6

Digital Imaging and Communication in Medicine (DICOM)