Video drivers incorporating the DIB format extensions let you specify negative values for the biHeight field. If the field contains a negative value, then the origin of the bitmap is the upper left corner and the height is the absolute value of biHeight.

The biHeight field is useful with BI_RGB and BI_BITFIELDS formats. In these two formats, the origin of a bitmap is defined to be the lower left corner when the biHeight value is positive. Therefore, to display a bitmap with either the BI_RGB or BI_BITFIELDS format on a window system that defines the origin of the image to be the upper left corner (such as the X Window System), specify a negative biHeight value. This negative value will tell the video driver to change the origin of the bitmap to the upper left corner. (If you specify a positive biHeight value for either the BI_RGB or BI_BITFIELDS format and display the bitmap from the video driver on a window system that defines the origin of an image to be the upper left corner, then the image will appear upside down.)

7.6 Extended BITMAPINFOHEADER Data Structure

The current members of the BITMAPINFOHEADER data structure are intended to serve as the primary members of any redefinition of the BITMAPINFOHEADER. All of the fields in the data structure should maintain their basic meanings but may have slightly different interpretations or restrictions on values.

If the biSize field of the BITMAPINFOHEADER data structure is greater than the value of sizeof(BITMAPINFOHEADER) , then the BITMAPINFOHEADER data structure is an extended BITMAPINFOHEADER data structure. The BITMAPINFOHEADER pointer can be recast as an extended BITMAPINFOHEADER as shown in Example 7-4.

Example 7-4 Extended BITMAPINFOHEADER Data Structure Definition

typedef struct tagEXBMINFOHEADER { BITMAPINFOHEADER bmi; /* extended BITMAPINFOHEADER fields */ DWORD biExtDataOffset; /* Other stuff will go here */ /* Format-specific information */ /* biExtDataOffset points here */ } EXBMINFOHEADER;

In Example 7-4, the BITMAPINFOHEADER bmi field will always match the standard BITMAPINFOHEADER structure. The biExtDataOffset field specifies the byte offset to the start of the extended format specific data. The offset is relative to the beginning of the EXBMINFOHEADER data structure. The format-specific data is located at:

EXBMINFOHEADER * exbi; (unsigned long)exbi + exbi->biExtDataOffset

The format-specific structure and member definition correlates uniquely to the value of the BITMAPINFOHEADER member biCompression. Additions to the format-specific structure definition will not break any previous definitions. This means that any application or system function given a pointer to a BITMAPINFOHEADER data structure (or derivative thereof) will be capable of determining the appropriate recast typedef by examination of biCompression alone, with biSize serving only as a validity cross-check.

Each redefinition of BITMAPINFOHEADER for any value of the biCompression field contains the identical initial members as are defined for BITMAPINFOHEADER. This applies equally to future redefinition of BITMAPINFOHEADER for those biCompression values already incorporated (for example, BI_RGB, BI_RLE8, and BI_RLE4).

7.7 JPEG and MJPG Format Extensions

For additional information on the JPEG and MJPG format extensions discussed in this section, see the technical notes referred to in the Preface under Related Documents.

7.7.1 JPEG and MJPG Extensions

These extensions have the following features:

• Provide immediate support for partial implementation of the full scope of JPEG Baseline Sequential DCT process as defined in ISO 10918 for SOF0 (marker code 0xFFC0). The implemented subset of the full scope shall maximize cross-platform interchange between the known universe of existing JPEG compressors and decompressors.
• Provide for transparent (or nearly so) implementation of the full scope of JPEG Baseline Sequential DCT process as defined in ISO 10918 for SOF0 (marker code 0xFFC0).
• Provide for subsequent inclusion of additional nonhierarchical JPEG processes on a singular and individual basis. The additional JPEG processes identified by JPEG markers SOF1, SOF2, SOF3, SOF9, SOF10, and SOF11 shall be capable of being implemented in whole or in part by compressors or decompressors with no constraint on the number or combination of processes implemented. Provision for hierarchical processes is deemed inappropriate to the DIB context.

For additional information on JPEG, see the technical notes referred to in the Preface under Related Documents.

This extension defines two standards:

• JPEG still-image format
• JPEG motion format (also known as motion JPEG)

Still-Image JPEG
All JPEG DIB still-image formats (for example, an AVI file) shall embed a complete Interchange Format JPEG data stream as a contiguous whole. This provision shall eliminate inadvertent introduction of platform-, system-, or application-specific conditions that may cause some JPEG-compliant compressors and decompressors to be incapable of processing the embedded JPEG data of a DIB. Provision for indexed access to tables and other data within the JPEG portion of a DIB shall be accommodated solely by the introduction of new offset and length members in the body of the revised BITMAPINFOHEADER data structure (none are yet defined). This provision permits any application, compressor, or decompressor to construct a JPEG DIB file simply by prepending the defined structures to JPEG data, then performing a single pass through the JPEG data to calculate and set the associated offset and length members that correlate to JPEG data items.

Motion JPEG
Motion JPEG DIBs shall accommodate interchange formats that satisfy the General sequential and progressive syntax (ISO 10918 Part 1, Annex B, Paragraph B.2). A set of images of this type with compatible parameters can be placed in an AVI file to describe a motion sequence. Frame headers for these DIBs shall be limited to those specified in Paragraph B.2.2 of the cited Annex B. These types are SOF0, SOF1, SOF2, SOF3, SOF9, SOF10 and SOF11. Of the types accommodated, this specification provides implementation only for the Baseline Sequential DCT (SOF0).

7.7.2 Extended BITMAPINFOHEADER for JPEG and MJPG

When using the extended BITMAPINFOHEADER for JPEG, the following applies to the BITMAPINFOHEADER fields:

Field	Usage
biSize	Is sizeof(EXBMINFOHEADER) + sizeof(JPEGINFOHEADER).
biBitCount	Is 24 for RGB or YCbCr. Is 8 for Y-only images (8-bit mono).
biCompression	JPEG_DIB for still-image JPEG DIB---FOURCC is "JPEG". MJPG_DIB for motion JPEG DIB---FOURCC is "MJPG".
biSizeImage	For JPEG data (JPEG_DIB or MJPG_DIB), this is the length of the data including the EOI marker.
biXPelsPerMeter	Should be set to 0.
biYPelsPerMeter	Should be set to 0.

Example 7-5 and Figure 7-7 show the format specific structure for JPEG and MJPG extended BITMAPINFOHEADER data structures.

Example 7-5 JPEG and MJPG Extended BITMAPINFOHEADER Data Structure Definition

typedef struct tagJPEGINFOHEADER { /* compress-specific fields */ DWORD JPEGSize; DWORD JPEGProcess; /* Process specific fields */ DWORD JPEGColorSpaceID; DWORD JPEGBitsPerSample; DWORD JPEGHSubSampling; DWORD JPEGVSubSampling; } JPEGINFOHEADER;

Figure 7-7 Extended BITMAPINFOHEADER for JPEG and MJPG

The JPEGINFOHEADER data structure has the following fields:

JPEG DIB Specific Fields
These fields start at the offset specified by biExtDataOffset:

JPEGSize
Specifies the size of the JPEG DIB specific fields. This field allows for expanding the JPEG DIB specific fields. The size should be set to sizeof(JPEGINFOHEADER) .

JPEGProcess
Specifies the various format types. Currently, only JPEG_PROCESS_BASELINE (Baseline DCT sequential) is allowed.

Process-Specific Fields:

JPEGColorSpaceID
Specifies the color space used for the compressed JPEG data.

JPEG_Y
The Y-only component of YCbCr as described below. Implies 1 component.

JPEG_YCbCr
YCbCr as defined by CCIR 601 (256 levels). The RGB components calculated by linear conversion from YCbCr shall not be gamma corrected (gamma = 1.0). Implies 3 components. This is the only option defined for motion JPEG images.

JPEG_RGB
24-bit RGB (3 components).

JPEGBitsPerSample
Specifies the number of bits per sample per component for the defined color space. For this extension, this value will be 8. The subsequent frame header shall have its sample precision parameter set to 8.

JPEGHSubSampling
Specifies the horizontal sampling factors used for the chrominance components of a YCbCr image. Applicable only to images with JPEGColorSpaceID = 2 (YCbCr). Specifies the horizontal sampling factor for the chrominance components (jointly) with respect to the luminance component. Nonzero values must correlate to the Hi values for both chrominance components in the JPEG frame header (see ISO 10918).

Value	Meaning
0	Subsampling is not applicable (JPEGColorSpaceID != 2). Defined as JPEG_SUBSAMPLING_NA.
1	For every luminance sample in the horizontal dimension, the chrominance components are sampled in a 1:1 ratio. Defined as JPEG_SUBSAMPLING_1.
2	For every luminance sample in the horizontal dimension, the chrominance components are sampled in a 1:2 ratio, with chrominance samples (Cb and Cr separately) sampled at half the horizontal spatial resolution as for luminance. Defined as JPEG_SUBSAMPLING_2.
4	For every luminance sample in the horizontal dimension, the chrominance components are sampled in a 1:4 ratio, with chrominance samples (Cb and Cr separately) sampled at one-fourth the horizontal spatial resolution as for luminance. Defined as JPEG_SUBSAMPLING_4.

JPEGVSubSampling
Specifies the vertical sampling factors used for the chrominance components of a YCbCr image. Applicable only to images with JPEGColorSpaceID == 2 (YCbCr). Specifies the vertical sampling factor for the chrominance components (jointly) with respect to the luminance component. Nonzero values must correlate to the Vi values for both chrominance components in the JPEG frame header (see ISO 10918).

Value	Meaning
0	Subsampling is not applicable (JPEGColorSpaceID != 2). Defined as JPEG_SUBSAMPLING_NA.
1	For every luminance sample in the vertical dimension, the chrominance components are sampled in a 1:1 ratio. Defined as JPEG_SUBSAMPLING_1.
2	For every luminance sample in the vertical dimension, the chrominance components are sampled in a 1:2 ratio, with chrominance samples (Cb and Cr separately) sampled at half the vertical spatial resolution as for luminance. Defined as JPEG_SUBSAMPLING_2.
4	For every luminance sample in the vertical dimension, the chrominance components are sampled in a 1:4 ratio, with chrominance samples (Cb and Cr separately) sampled at one-fourth the vertical spatial resolution as for luminance. Defined as JPEG_SUBSAMPLING_4.

Example 7-6 shows an example of setting up the headers:

Example 7-6 Header Setup Example

BITMAPINFOHEADER * lpbi; /* basic header */ EXBMINFOHEADER * exbi; /* extended header */ JPEGINFOHEADER * jpegbi; /* JPEG specific header */ /* Allocate enough memory for the extended JPEG bitmap ** info header */ lpbi = (BITMAPINFOHEADER *)mmeAllocMem( sizeof(EXBMINFOHEADER) + sizeof(JPEGINFOHEADER)); if ( lpbi == (BITMAPINFOHEADER *)NULL ) { mmeFreeMem(icinfo); fprintf(stderr,"Cannot allocate memory\n"); return; } /* size is always set to reflect the entire structure size */ lpbi->biSize = sizeof(EXBMINFOHEADER) + sizeof(JPEGINFOHEADER); /* Set the compression for Still JPEG */ lpbi->biCompression = JPEG_DIB; /* bit count for JPEG or MJPG is 24 */ lpbi->biBitCount = 24; /* Set up the extended bitmap info header properly. ** The ExtDataOffset should point to the location in memory ** just beyond the extended bitmap info header where we will ** place the JPEG bitmap info header */ exbi = (EXBMINFOHEADER *)lpbi; exbi->biExtDataOffset = sizeof(EXBMINFOHEADER); /* set up the JPEG bitmap info header. ** We'll specify baseline DCT as the process, ** YCbCr colorspace, ** bits per sample is always 8 for baseline DCT, ** vertical subsampling at 1:1 and ** horizontal subsampling at 1:2 ** The JPEGSize should match the size of the JPEG bitmap ** info header we are using. */ jpegbi = (JPEGINFOHEADER *) ((unsigned long)exbi + exbi->biExtDataOffset); jpegbi->JPEGSize = sizeof(JPEGINFOHEADER); jpegbi->JPEGProcess = JPEG_PROCESS_BASELINE; jpegbi->JPEGColorSpaceID = JPEG_YCbCr; jpegbi->JPEGBitsPerSample = 8; jpegbi->JPEGHSubSampling = JPEG_SUBSAMPLING_2; jpegbi->JPEGVSubSampling = JPEG_SUBSAMPLING_1;

7.7.3 Image Data for JPEG and MJPG

The information in this section is for those developers who want to understand the details of the JPEG data format. For most developers, the applications need only query the compressor or capture device for the extended BITMAPINFOHEADER for the default format and store that structure and the data images to a file. When reading JPEG data, applications need only pass the extended BITMAPINFOHEADER to the decompressor followed by the JPEG image data. The application should not have to interpret the contents of the data. Only applications seeking to convert data from one file format to another must be concerned with these details.

Image data should not contain any thumbnail or other optional data because this will greatly increase the size of the image data. If thumbnail, copyright, or creator information is desired, the appropriate RIFF chunks should be used to store this data. (See the JPEG definitions in the RIFF references in Chapter 8.)

The inclusion of optional data (for example, comments, application-specific data, and so on) is strongly discouraged because this will greatly increase the size of the image data.

Still-Image JPEG

Complete JPEG interchange format stream from SOI-EOI including all tables and compressed data IAW ISO 10918 Paragraph 3.9.1 Interchange Format (see Example 7-7). The size of the data shall be defined by the biSizeImage field in the BITMAPINFOHEADER for JPEG structure.

Motion JPEG

This DIB type contains incomplete JPEG data (Abbreviated Format per ISO 10918) and is not intended for standalone single image frame disk files. It may be used within RIFF files and other contexts where it is appropriate to:

• Decode an image without supplying the associated JPEG Huffman tables. This presumes the compressor or decompressor has been properly preinitialized prior to image decode.
• Request encoder output of compressed image data absent embedded Huffman Tables.

All motion JPEG data will use YCrCb encoding.

In an AVI sequence, all motion JPEG frames will be key frames because this ensures that within the AVI and Multimedia Services for OpenVMS architecture, all frames will be directly and independently addressable.

For optimal size and speed during playback of an AVI file, the Huffman data used by motion JPEG will be fixed. This will make the individual frames of every motion sequence smaller and more efficient to play back. Also, as all sequences of motion images use the same Huffman data and color space, it is much more likely that motion data can be directly exchanged without recompression. A definition of the Huffman data will be provided in mme/mmsystem.h as a byte string that can be concatenated onto the start of a motion JPEG image to form a valid still JPEG image:

MJPGDHTSeg = { X'FF', DHT, length, JPEG huffman table parameters }

Q-table data is present and may vary in every frame of a motion sequence to permit control over the bandwidth of sequences that contain bursts of frames of varying levels of complexity. The restart interval used during the compression process may also vary for every frame.

Following the Tables segment is the compressed image data. The data is in JPEG stream syntax and includes the SOI, DRI, DQT, SOF0, SOS, and EOI markers. For JPEG_YCbCr, JPEG_RGB, and JPEG_Y color space IDs, these markers are shown in the typical order with typical values.

As with all DIB files and functions that take packed DIBs, regardless of compression, the offset to the image data can be calculated as follows:

LPBITMAPINFOHEADER lpbi; ... ImageOffset = lpbi->biSize + lpbi->biClrUsed*sizeof (RGBQUAD);

Example 7-7 Sample Table Segment for Baseline Process

X'FF', SOI X'FF', DHT, length, Huffman table parameters (only in still JPEG) X'FF', DRI, length, restart interval X'FF', DQT, length Lq = 67 for JPEG_Y or Lq = 132 for JPEG_RGB or JPEG_YCbCr Precision, Table ID, Pq =0, Tq = 0 DQT data [64] [If 3 Components Precision, Table ID, Pq =0, Tq = 1 DQT data [64] ] X'FF', SOF0, length, Sample Precision P = 8 Number of lines Y = biHeight Sample per line X = biWidth Number of components Nc = 1 or 3 (must match information from JPEGColorSpaceID) YCbCr RGB 1st Component parameters C1= 1 =Y 4 =R 2nd Component parameters C2= 2 =Cb 5 =G 3rd Component parameters C3= 3 =Cr 6 =B * *] X'FF', SOS, length, Number of components Ns = 1 or 3 (must match information from JPEGColorSpaceID) YCbCr RGB 1st Component parameters C1= 1 =Y 4 =R 2nd Component parameters C2= 2 =Cb 5 =G 3rd Component parameters C3= 3 =Cr 6 =B * * * X'FF', EOI