Also Known As: JFIF, JFI, JPG, JPEG
| Type | Bitmap |
| Colors | Up to 24-bit |
| Compression | JPEG |
| Maximum Image Size | 64Kx64K pixels |
| Numerical Format | Big-endian |
| Multiple Images Per File | No |
| Originator | C-Cube Microsystems |
| Platform | All |
| Supporting Applications | Too numerous to list |
| See Also | Chapter 9, Data Compression (JPEG section) |
Usage
Used primarily in graphics and image manipulation programs
Comments
One of the few formats incorporating JPEG compression and as
such offers superior compression for deep-pixel images.
Vendor specifications are available for this format.
Code fragments are available for this format.
Sample images are available for this format.
JPEG (Joint Photographic Experts Group) refers to a standards organization, a method of file compression, and sometimes a file format. In fact, the JPEG specification itself, which we describe in terms of compression in Chapter 9, does not itself define a common file interchange format to store and transport JPEG data between computer platforms and operating systems. The JPEG File Interchange Format (JFIF) is a development of C-Cube Microsystems for the purpose of storing JPEG-encoded data. JFIF is designed to allow files containing JPEG-encoded data streams to be exchanged between otherwise incompatible systems and applications.
Contents:
File Organization
File Details
For Further Information
A JFIF file is basically a JPEG data stream with a few restrictions and an identfying marker. In order to understand the JFIF format, you'll need to understand JPEG; in addition to Chapter 9, see the JPEG FAQ (Frequently Asked Questions) document included on the CD-ROM and available on the Internet.
Both JPEG and JFIF data are byte streams, always storing 16-bit word values in big-endian format. JPEG data in general is stored as a stream of blocks, and each block is identified by a marker value.
The first two bytes of every JPEG stream are the Start Of Image (SOI) marker values FFh D8h. In a JFIF-compliant file there is a JFIF APP0 (Application) marker, immediately following the SOI, which consists of the marker code values FFh E0h and the characters JFIF in the marker data, as described in the next section. In addition to the JFIF marker segment, there may be one or more optional JFIF extension marker segments, followed by the actual image data.
Although JFIF files do not possess a formally-defined header, the SOI and JFIF APP0 markers taken together act as a header in the following marker segment structure:
typedef struct _JFIFHeader
{
BYTE SOI[2]; /* 00h Start of Image Marker */
BYTE APP0[2]; /* 02h Application Use Marker */
BYTE Length[2]; /* 04h Length of APP0 Field */
BYTE Identifier[5]; /* 06h "JFIF" (zero terminated) Id String */
BYTE Version[2]; /* 07h JFIF Format Revision */
BYTE Units; /* 09h Units used for Resolution */
BYTE Xdensity[2]; /* 0Ah Horizontal Resolution */
BYTE Ydensity[2]; /* 0Ch Vertical Resolution */
BYTE XThumbnail; /* 0Eh Horizontal Pixel Count */
BYTE YThumbnail; /* 0Fh Vertical Pixel Count */
} JFIFHEAD;
SOI is the start of image marker and always contains the marker code values FFh D8h.
APP0 is the Application marker and always contains the marker code values FFh E0h.
Length is the size of the JFIF (APP0) marker segment, including the size of the Length field itself and any thumbnail data contained in the APP0 segment. Because of this, the value of Length equals 16 + 3 * XThumbnail * YThumbnail.
Identifier contains the values 4Ah 46h 49h 46h 00h (JFIF) and is used to identify the code stream as conforming to the JFIF specification.
Version identifies the version of the JFIF specification, with the first byte containing the major revision number and the second byte containing the minor revision number. For version 1.02, the values of the Version field are 01h 02h; older files contain 01h 00h or 01h 01h.
Units, Xdensity, and Ydensity identify the unit of measurement used to describe the image resolution. Units may be 01h for dots per inch, 02h for dots per centimeter, or 00h for none (use measurement as pixel aspect ratio). Xdensity and Ydensity are the horizontal and vertical resolution of the image data, respectively. If the Units field value is 00h, the Xdensity and Ydensity fields will contain the pixel aspect ratio (Xdensity : Ydensity) rather than the image resolution. Because non-square pixels are discouraged for portability reasons, the Xdensity and Ydensity values normally equal 1 when the Units value is 0.
XThumbnail and YThumbnail give the dimensions of the thumbnail image included in the JFIF APP0 marker. If no thumbnail image is included in the marker, then these fields contain 0. A thumbnail image is a smaller representation of the image stored in the main JPEG data stream (some people call it an icon or preview image). The thumbnail data itself consists of an array of XThumbnail * YThumbnail pixel values, where each pixel value occupies three bytes and contains a 24-bit RGB value (stored in the order R,G,B). No compression is performed on the thumbnail image.
Storing a thumbnail image in the JFIF APP0 marker is now discouraged, though it is still supported for backward compatibility. Version 1.02 of JFIF defines extension markers that allow thumbnail images to be stored separately from the identification marker. This method is more flexible, because multiple thumbnail formats are permitted and because multiple thumbnail images of different sizes could be included in a file. Version 1.02 allows color-mapped thumbnails (one byte per pixel plus a 256-entry colormap) and JPEG-compressed thumbnails, in addition to the 24-bit RGB thumbnail format. In any case, a thumbnail image is limited to less than 64K bytes because it must fit in an APP0 marker.
Following the JFIF marker segment, there may be one or more optional JFIF extension marker segments. Extension segments are used to store additional information and are found only in JFIF version 1.02 and later. The structure of these extension segments is shown below:
typedef struct _JFIFExtension
{
BYTE APP0[2]; /* 00h Application Use Marker */
BYTE Length[2]; /* 02h Length of APP0 Field */
BYTE Identifier[5]; /* 04h "JFXX" (zero terminated) Id String */
BYTE ExtensionCode; /* 09h Extension ID Code */
} JFIFEXTENSION;
APP0 contains the values FFh E0h.
Length stores the length in bytes of the extension segment.
Identifier contains the values 4Ah 46h 58h 58h 00h (JFXX).
ExtensionCode indicates the type of information this extension marker stores. For version 1.02, the only extension codes defined are 10h (thumbnail encoded using JPEG), 11h (thumbnail stored using 1-byte pixels and a palette) and 13h (thumbnail stored using 3-byte RGB pixels).
The extension data follows the extension segment information and varies in size and content depending upon the ExtensionCode value. (Refer to the current JFIF specification for the possible formats of the extension marker segment.)
JFIF decoders must be prepared to ignore unrecognized extension markers and APPn segments. Application-specific APPn markers not recognized by a JPEG decoder can be simply skipped over by using the data length field of the marker.
The JFIF marker is essentially a guarantee that the file conforms to the JFIF conventions. Most JFIF decoders therefore regard the JFIF marker segment as optional, and are quite capable of reading a raw JPEG data stream that complies with the JFIF conventions regarding color space and sample alignment. (There are many such files out there, because JFIF merely formalized common practice in these areas.) A robust decoder will treat a JFIF file as a stream of blocks, with no assumptions about block order beyond those mandated by the JPEG standard. This makes it possible to read many non-standard and incorrect JFIF file variations, such as a COM marker inserted between the SOI and JFIF APP0 markers (there are a fair number of these in existence too). We also recommend that a decoder should accept any JFIF file with a known major version number, even if the minor version number is newer than those known to the decoder.
The actual JPEG data in a JFIF file follows all APP0 markers and adheres to the format defined in the JPEG documentation. The baseline JPEG process is the recommended type of image data encoding to be used in JFIF files. This is to ensure maximum compatibility of JFIF files for data interchange.
To identify a JFIF file or data stream, scan for the values FFh D8h FFh. This will identify the SOI marker, followed by another marker. In a proper JFIF file, the next byte will be E0h, indicating a JFIF APP0 marker segment. However, it is possible that one or more other marker segments may be erroneously written between the SOI and JFIF APP0 markers (a violation of the JFIF specification). As previously mentioned, a decoder should still attempt to read the file.
The next two bytes (the APP0 segment length) vary in value, but are typically 00h 10h, and these are followed by the five byte values 4Ah 46h 49h 46h 00h (JFIF). If these values are found, the SOI marker (FFh D8h) marks the beginning of a JFIF data stream. If only the FFh D8h FFh values are found, but not the remaining data, then a "raw" JPEG data stream has been found. All JFIF and JPEG data streams end with the End Of Image (EOI) marker values FFh D9h.
There are many proprietary image file formats which contain JPEG data. Many simply encapsulate a JPEG or JFIF data stream within their own file format wrapper. Scanning for the JPEG SOI marker and reading until the EOI marker is encountered will usually allow you to extract the JPEG/JFIF data stream. At least one proprietary image file format, the .HSI format by Handmade Software, contains JPEG data, but cannot be successfully read or uncompressed without using special software, due to proprietary modifications of the JPEG encoding process. (All .HSI files begin with the values 68h 73h 69h 31h and should not be considered normal JPEG files.)
Only two non-proprietary formats, other than JFIF, currently support JPEG-encoded data. The latest version of the Macintosh PICT format prepends a PICT header to a JFIF file stream. Strip off the PICT header (everything before the SOI marker) and any trailing data (everything after the EOI marker) and you have the equivalent of a JFIF file. The other format, TIFF 6.0, also supports JPEG and is discussed in depth in the article on TIFF.
For further information about the JFIF file format, see the specification included on the CD-ROM. You may also contact C-Cube Microsystems at:
C-Cube Microsystems
Attn: Scott St. Clair
Corporate Communications
1778 McCarthy Blvd.
Milpitas, CA 95035
Voice: 408-944-6300
FAX: 408-944-6314
See also Chapter 9 for information about JPEG compression. The JPEG FAQ and the compression FAQ, also included on the CD-ROM, contain background information about JPEG.
The JPEG standard itself is not available electronically; you must order a paper copy through ISO. In the United States, copies of the standard may be ordered from:
American National Standards Institute, Inc.
Attn: Sales
1430 Broadway
New York, NY 10018
Voice: 212-642-4900
The standard is divided into two parts; Part 1 is the actual specification, and Part 2 covers compliance-testing methods. Part 1 of the draft has now reached International Standard status. See this document:
Digital Compression and Coding of Continuous-tone Still Images, Part 1: Requirements and Guidelines. Document number ISO/IEC IS 10918-1.
Part 2 is still at Committee Draft status. See this document:
Digital Compression and Coding of Continuous-tone Still Images, Part 2: Compliance Testing. Document number ISO/IEC CD 10918-2.
See the discussion of JPEG in Chapter 9 for a list of additional references, including commercially available books that contain the JPEG specification and the JPEG FAQ (Frequently Asked Questions). The CD-ROM contains several JPEG programs and libraries.
Copyright © 1996, 1994 O'Reilly & Associates, Inc. All Rights Reserved.