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

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:

Table 3.7. Structure of the BMP Info Header

The field biCompr defines the type of compression used:

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

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

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

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

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

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

Table 3.16. Tag Data Types

Table 3.17. Image Organization Tags

Table 3.18. Image Pointer Tags

Table 3.19. Pixel Description Tags

Table 3.20. Data Orientation Tags

Table 3.21. Data Compression Tags

Table 3.22. Document and Scanner Description Tags

Table 3.23. Storage Management Tags

Table 3.24. Ink Management Tags

Table 3.25. JPEG Management Tags

Table 3.26. YC b C r Management Tags

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

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

Table 3.29. Palette (PLTE) CHUNK

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

Table 3.31. Physical Pixel Dimension (pHYs) CHUNK

Table 3.32. Textual Data (tEXt) CHUNK

Table 3.33. Image Last Modification Time (tIME) CHUNK

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

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

Table 3.36. JFIF EOI Segment

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

Table 3.38. JFIF Extension APP0 Segment

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

Table 3.40. Define Arithmetic Coding (DAC) Segment

Table 3.41. Define Quantization Table (DQT) Segment

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