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)

graphics/bmp.gif

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)

graphics/tif.gif

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)

graphics/png.gif

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)

graphics/jpg.gif

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)



Image Processing with LabVIEW and IMAQ Vision
Image Processing with LabVIEW and IMAQ Vision
ISBN: 0130474150
EAN: 2147483647
Year: 2005
Pages: 55

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net