![[Graphic: Figure SPIFF-1]](../../figures/en/gspiff01.gif)
Also Known As: Still Picture Interchange File Format, JPG, SPF
| Type | Bitmap |
| Colors | Bitonal to 32-bit |
| Compression | Modified Huffman, MR, MMR, JBIG, JPEG, uncompressed |
| Maximum Image Size | 4Gx4G pixels, 64Kx64K pixels for non-tiled baseline JPEG |
| Multiple Images Per File | No |
| Numerical Format | Big-endian |
| Originator | ISO/IEC |
| Platform | All |
| Supporting Applications | All that support the JFIF format |
| See Also | JFIF and the discussion of JPEG and JBIG compression in Chapter 9, Data Compression |
Usage
SPIFF is the official
replacement for the JFIF file format for
storing JPEG data. It is also the format to
use for storing JBIG data, and it offers an
alternative to CCITT Group 3, Group 4, and
CALS for storing MR and
MMR data.
Comments
SPIFF is a new international
standard and is currently supported by very few applications.
Most JFIF readers, however, will have no
problem interpreting
SPIFF-JPEG
files.
SPIFF is a generic bitmap file format defined by ITU (International Telecommunication Union) and ISO/IEC (International Standards Organization/International Electrotechnical Commission) for the storage, compression, and interchange of color or gray-scale, continuous-tone images, and bitonal image data.
Contents:
File Organization
File Details
For Further Information
SPIFF may be best described as the "official" JPEG file format. When the Joint Photographic Experts Group (ISO/IEC JTC1/SC29/WG1) established the JPEG compression standard in 1990, they didn't create a corresponding standard file format for the storage and interchange of JPEG data. Some five years later, SPIFF has been ratified by the JPEG committee to fill this omission.
Why was an official JPEG file format not created by the original JPEG committee? The official reason is that the JPEG Convener at that time realized that numerous other standards groups were defining file formats for various application environments, such as SC18 for the Office Document Architecture (ODA) and SC24 for image processing applications. Each of these groups was planning on storing JPEG-compressed data within file formats of its own design.
The Convener reasoned that a single file format covering the needs of all applications could not be adequately defined and concluded that the other standards bodies should be left to create their own formats to encapsulate JPEG data. The Convener also indicated that any file format work undertaken by the JPEG committee could be perceived as infringing upon the scope of work of other standards bodies.
One unofficial reason for the decision was that the JPEG committee was under pressure to release its standard and, with quite a bit of work left to do, could not see taking on another major task, such as that of defining a file format.
But raw JPEG data stored in a file does require some ancillary information to make it useful (such as the color space of the image), so creating a file format for JPEG data was something that someone needed to do, even if the format wasn't going to be officially sanctioned by the JPEG committee.
The format that emerged was the JPEG File Interchange Format ( JFIF) created in 1992 by Eric Hamilton of C-Cube Microsystems and other developers as well. JFIF is the format typically used when software reads and writes what is more commonly referred to as a JPEG file. Although JFIF was a very simple format--containing little more than a header followed by a JPEG data stream--it was very portable across all operating systems, and it quickly became the de facto standard file format for storing JPEG image data.
When Eric Hamilton took over as WG1 Convener ( JPEG and JBIG committees), he started to work on a completely defined file format for JPEG data. His rationale was that everybody else was working on large and complicated formats with lots of features, while the great majority of users only need something simple that allowed image interchange. The interchange of compressed pictures definitely falls within the scope of the ISO project JTC 1.29.04 ( JPEG), and, therefore, Hamilton reasoned that the committee could start work on SPIFF without going through the red tape of balloting a new work item proposal.
Why use SPIFF rather than JFIF? JFIF is small, simple, and widespread, and practically every JPEG image display program reads it. Why give it up?
One reason is that SPIFF is much more carefully designed, specified, and thought-out than JFIF. SPIFF is an official standard rather than an ad hoc one, and it has been through a more thorough review process.
SPIFF is also more flexible than JFIF. Extended features include support for more color spaces and a provision for specifying image gamma. JFIF took a shortcut by attempting to require that all JFIF images have a gamma of 1.0. That requirement has been widely ignored because many pre-existing images have other gamma values, and, as it turns out, a gamma of around 0.4 to 0.5 is technically superior.
The variation in gamma values means that JFIF images frequently come out too dark or too light, depending on their origins and the viewing system. SPIFF offers the opportunity to improve the situation by marking files with their image gamma. Viewers can then correct image brightness as needed for their display hardware.
SPIFF is part of the JPEG standard and therefore is very well-defined in format, application, and compliance testing. It is fully expected that SPIFF will eventually replace JFIF as the file format of choice for continuous-tone color and gray-scale compressed image data.
SPIFF will also be supported by the Independent JPEG Group's (IJG) JPEG library (included on the CD-ROM). What this means is that you can integrate SPIFF support into your image and graphics applications using a well-known, well-written, widely distributed, and freely available source code library that hundreds of applications already use.
The SPIFF specification does not define a standard file extension or type indicator for SPIFF files. IJG recommends that the extension ".JPG", and "JPEG" type indicator, be used for SPIFF files containing lossy (DCT) JPEG-compressed data, and that ".SPF" be used for all other variants of SPIFF. (Of course, the JBIG community might prefer a ".JBG" extension for SPIFF-JBIG files.)
The file extension .JPG is already commonly used for JFIF-format JPEG files. However, properly written JFIF-compatible software should read SPIFF-JPEG files without difficulty. The SPIFF format has been carefully designed to make this possible by defining the magic numbers and length fields to make the SPIFF header look like a series of JPEG APPn markers, which old JPEG decoders will just ignore.
It is also reasonable to expect that SPIFF-JPEG software will also read JFIF files for backwards compatibility. Because JFIF and SPIFF-JPEG are interoperable, there is no need to confuse the average user by introducing a new file extension for SPIFF files containing JPEG data.
The non-JPEG variants of SPIFF, however, are not interoperable with any existing software and, in fact, will confuse JFIF-only software considerably, so those variants need a different extension. Using the extensions ".JPG" and ".SPF" also offers the advantage of maintaining a clear distinction between lossy and lossless SPIFF image formats, which should help to minimize user confusion and unintentional degradation of data.
SPIFF files are composed of four major sections: the header, the information directory, the image data, and an optional section containing indirect data (that is, information too large to fit in the information directory).
Header |
Directory |
Image Data |
Indirect Data |
The header is typical of most bitmap file headers and contains information necessary to properly decode the image data. The directory may be thought of as a secondary header that contains optional fields of information called directory entries. The image data is stored immediately after the directory and is followed by any directory data that was too large to fit in a single directory entry.
This section describes the contents of the SPIFF header and directory and provides other details of the format.
The header is 36 bytes in length and has the following format:
typedef struct _SpiffHeader
{
DWORD MagicNumber; /* Primary identification value
(FFD8FFE8h) */
WORD HeaderLength; /* Header length (not including
MagicNumber) */
CHAR Identifier[6]; /* Secondary ID value ("SPIFF\0") */
WORD Version; /* SPIFF version */
BYTE ProfileId; /* Application profile */
BYTE NumberComponents; /* Number of color components */
DWORD ImageHeight /* Number of lines in image */
DWORD ImageWidth; /* Number of samples per line */
BYTE ColorSpace; /* Color space used by image data */
BYTE BitsPerSample; /* Number of bits per sample */
BYTE CompressionType; /* Type of data compression used */
BYTE ResolutionUnits; /* Type of resolution units */
DWORD VerticalResolution; /* Vertical resolution */
DWORD HorizontalResolution; /* Horizontal resolution */
} SPIFFHEADER;
MagicNumber is the identification value for SPIFF files. This 4-byte field always contains the value FFD8FFE8h.
HeaderLength contains the length of the header excluding the MagicNumber field. In v1.0 of SPIFF, this value is always 32.
Identifier contains additional identification values. These values are 53h 50h 49h 46h 46h 00h (the NULL-terminated string "SPIFF").
Version contains the major and minor revision of SPIFF that the file conforms to. The most significant byte contains the value 01h and the least significant byte contains the value 00h. These values correspond to v1.0.
Differing minor version numbers represent backward-compatible changes in the SPIFF format. Differing major version numbers represent backward-incompatible changes in SPIFF. File readers should attempt to read SPIFF files even if the minor revision number is not recognized, but should give up if the major version is not recognized.
ProfileId specifies the features that the file reader must support to read the file. The possible values for this field are 0 (no profile specified), 1 (continuous-tone base profile), 2 (continuous-tone progressive profile), 3 (bi-level facsimile profile), and 4 (continuous-tone facsimile profile).
NumberComponents indicates the number of color components (channels) in the primary image. This value is 1 for a typical gray-scale image and 3 for an RGB or CMY image.
ImageHeight and ImageWidth store the size of the image. ImageHeight is the number of scan lines in the primary image. ImageWidth is the number of samples per line.
ColorSpace specifies the color space coordinate system used to define the samples. Allowed values for this field are:
| 0 | Bi-level |
| l | YCbCr, ITU-R BT 709, video |
| 2 | No color space specified |
| 3 | YCbCr, ITU-R BT 601-1, RGB |
| 4 | YCbCr, ITU-R BT 601-1, video |
| 5 | Reserved |
| 6 | Reserved |
| 7 | Reserved |
| 8 | Gray-scale |
| 9 | PhotoYCC |
| 10 | RGB |
| 11 | CMY |
| 12 | CMYK |
| 13 | YCCK |
| 14 | CIELab |
BitsPerSample specifies the number of bits per sample.
CompressionType indicates the type of compression algorithm used to encode the image data. The possible values for this field are:
| 0 | Uncompressed, interleaved, 8 bits per sample |
| 1 | Modified Huffman |
| 2 | Modified READ |
| 3 | Modified Modified READ |
| 4 | JBIG |
| 5 | JPEG |
ResolutionUnits indicates the type of units used to express the resolution of the image. Possible values for this field are 0 (aspect ratio defined by VerticalResolution and HorizontalResolution), 1 (dots or samples per inch), or 2 (dots or samples per centimeter).
VerticalResolution and HorizontalResolution contain the resolution of the image. If ResolutionUnits is 0, the values of these fields contain, respectively, the numerator and denominator of the aspect ratio of the samples. Otherwise, these fields contain the image resolution as fixed-point numbers.
Following the header is a directory of references to information stored within the SPIFF file. This directory may be thought of as a second header that contains one or more optional fields of information about the image data. See Figure SPIFF-1 for a diagram of the directory entry structure.
The directory will contain at least one directory entry; the End Of Directory is mandatory; all other entries are optional. Data associated with the directory entry may be stored "directly" within the directory entry or be stored "indirectly" outside of the directory and following the image data. The maximum size of a block of data that may be stored within a directory entry is 65,527 bytes.
The header of each directory entry is 12 bytes in length and has the following format:
typedef struct _SpiffDirectoryEntry
{
WORD EntryMagic; /* Directory entry magic number (FFE8h) */
WORD EntryLength; /* Length of entry */
DWORD EntryTag; /* Identification value of the entry */
} SPIFFDIRECTORYENTRY;
EntryMagic identifies the start of each directory entry. This value is always FFE8h.
EntryLength is the length of the entry, not including the EntryMagic field. The value of this field may be in the range 6 to 65534.
EntryTag is a bit field identifying the format and type of data stored or referenced by the directory entry. Each directory entry will always have a unique EntryTag value and a specific format of entry data.
The eight most significant bits (31:24) of EntryTag are always zero. The value of the next three bits (23:21) define the originating standards body to which the file data conforms. The possible values are:
| 0 | SPIFF specification definition |
| 1-3 | ISO/IEC and common text generic standards |
| 4 | ISO application standards |
| 5 | ITU-T recommendations |
| 6 | National standards bodies |
| 7 | Application-specific |
The remaining bits (20:0) are defined by the standards organization defining the particular tag. The SPIFF specification defines the possible values of these remaining 20 bits when the three identifier bits are set to zero. See the section below called "Entry Tags" for more detailed information.
Each directory entry must be a multiple of four bytes in length. An entry with no associated data is eight bytes in length. An entry containing an offset to indirect data is 12 bytes in length. And an entry containing direct data must have its data padded to end on the nearest 4-byte boundary.
Directory entries are not linked together by offset values in the way that TIFF image file directories are. Instead, entries occur in contiguous order after the header and before the image data.
The last entry in a directory is the EOD (End Of Directory) entry and marks the end of the directory. In an EOD entry, EntryMagic is FFE8h, EntryLength is always 8, and EntryTag is always 1.
Note that the EntryLength value of the EOD entry is two bytes larger than it seems it should be. This is because the length of the EntryMagic field is also added into this value, but only for the EOD entry. As we noted, the EntryMagic, EntryLength, and EntryTag fields are defined to appear as a JPEG SOI marker followed by a series of JPEG APP8 markers, so the SPIFF header and directory entries are ignored by JFIF readers. The EOD EntryLength value is two greater than it should be so that old JFIF decoders will also skip over the SOI marker that appears at the beginning of the SPIFF data area. Otherwise, older decoders would see two SOI markers and complain.
Header |
Directory Entry 1 |
Directory Entry 2 |
Directory Entry N |
EOD Entry |
Image Data |
Indirect Data |
SPIFF v1.0 defines the format of 15 directory entries and EntryTag entries. All of these entries (except the End of Directory entry) are optional, and many may appear only once in a SPIFF file if used. The exact format of each entry is documented in the SPIFF specification and summarized in Table SPIFF-1:
Name | Use | EntryTag | Multiple Entries |
|---|---|---|---|
End Of Directory |
End of directory marker |
1 |
No |
Transfer Characteristics |
Gamma correction |
2 |
No |
Component Registration |
Location of components |
3 |
No |
Image Orientation |
Rotated, flipped |
4 |
No |
Thumbnail Image |
Thumbnail header |
5 |
Yes |
Image Title |
Text |
6 |
Yes |
Image Description |
Text |
7 |
Yes |
Time Stamp |
Time and date |
8 |
No |
Version Number |
Image version number |
9 |
Yes |
Creator Identification |
Text |
10 |
Yes |
Protection Indicator |
Level of authenticity |
11 |
No |
Copyright Information |
Text |
12 |
Yes |
Contact Information |
Text |
13 |
Yes |
Tile Index |
Pointer to tiles |
14 |
No |
Scan Index |
Pointers to scans |
15 |
No |
Set Reference |
Relationship to other files |
16 |
Yes |
End of Directory indicates the end of the directory. This entry contains no associated data and is immediately followed by image data.
Transfer Characteristics describes the gamma correction value of the image.
Component Registration describes the positioning of samples within components (that is, color elements within a sample) relative to the samples within other components.
Image Orientation specifies which edge of the image is the top and whether the image is flipped.
Thumbnail Image is a lower resolution version of the primary image.
Image Title is a textual description for the image.
Image Description is an additional textual description of the image data.
Time Stamp is an ISO 8601 standard date and time string in the format YYYY-MM-DD and HH:MM:SS.mmmZ.
Version Number is the number of revisions of the image.
Creator Identification is textual information that describes the creator of the image data and file.
Protection Indicator specifies the usage rights of the image data.
Copyright Information contains the copyright text for the image data.
Contact Information is a textual description of how to contact the creator and/or owner of the image data.
Tile Index contains a listing of all the offset values for the tiles in the image data.
Scan Index contains a listing of all the offset values for the scans in the image data.
Set Reference is a reference number typically used to identify the file as related to other groups of files.
Indirect storage is only allowed for the Thumbnail Image, Scan Index, Tile Index, and all textual directory entries (Image Name, Image Description, and so forth). Each of these entries contains a field specifying the offset of the data from the beginning of the file. If this value is 0, then the data is stored directly within the entry. It is recommended that direct storage be used whenever possible (that is, when the entry data is less than 64K in size).
SPIFF requires that the Scan Index and Tile Index entries only be stored as indirect data. These indexes are only useful to decoders that can perform random access on a file and are likely to be built on the fly by encoders, so requiring them to be stored at the end of a SPIFF file is a reasonable thing to do.
The SPIFF format also provides for application-specific directory entries that would store any information not supported by the standard directory entries defined in the SPIFF specification. These directory entries are identified by setting the bits 23:21 in the EntryTag to all ones.
There is currently no process for registering or reserving application-specific directory tags, so it is recommended that additional identifying information be present in the entry data. This will help prevent data interpretation problems caused by duplicate application-specific directory tags defined by different organizations. SPIFF readers should, of course, ignore any directory entries with an unrecognized tag value.
Although thought of as a file format for JPEG data, SPIFF is quite capable of supporting data compressed using the Huffman 1D, MR (Modified READ), MMR (Modified Modified READ), and JBIG data compression methods as well. And uncompressed data storage is also supported, as you might expect.
The data area of each variation of SPIFF contains the complete data stream defined by the underlying compression standards. For example, SPIFF-JPEG files contain a complete JPEG interchange data stream as defined by ITU-T T.81; SPIFF-JBIG files contain a complete JBIG bi-level image entity as defined by ITU-T T.82, and so on.
An application profile is a predefined set of features that a SPIFF file reader must support to be able to interpret the contents of a SPIFF file. The ProfileId field of the header contains a value that specifies the profile required by the data stored in the SPIFF file. This field makes it possible for a file reader to determine the contents of the file without reading the entire directory.
The profiles currently defined apply to baseline JPEG data, progressive mode JPEG data (for low-speed communications applications), bi-level image data, and continuous-tone, color, or gray-scale facsimile images. The following profile values are currently defined:
No profile
Continuous-tone base profile
Compression is 5 (JPEG)
ColorSpace is 3 (YCbCr RGB) or 8 (gray-scale)
No Image Orientation directory entry
No indirect directory data allowed
Image data is encoded with baseline JPEG as a single scan with interleaved components
Continuous-tone progressive profile
Continuous-tone base profile
Support for DCT progressive mode JPEG with spectral selection and full progressive
Bi-level facsimile profile
Support per ITU-T T.4 (Modifed Huffman and Modified READ), ITU-T T.6 (Modified Modified READ), or ITU-T T.82|ISO/IEC 11544 (JBIG)
Continuous-tone facsimile profile
8-bits per sample (12-bits optional)
2:1 Chrominance subsampling in each direction (no subsampling optional)
CIE Standard Illuminant D50 (custom illuminant optional)
Default gamut range (custom gamut range optional)
The profile value should be 0 (no profile) if the file uses features that do not fall into any of the other profiles.
When you first read through the SPIFF specification, you may conclude that it is easy to convert a JFIF file to a SPIFF-JPEG file. Just fill in the SPIFF header fields from information found in the JFIF file, write out the header and an End Of Directory entry, and then append the entire JFIF file itself to the SPIFF-JPEG file.
This technique for JFIF-to-SPIFF-JPEG conversion has the advantage of being a simple and quick conversion that also preserves the JFIF markers, allowing older decoders to read the resolution and thumbnail data present in the JFIF data stream. It also allows a SPIFF-JPEG-to-JFIF conversion program to recover the original JFIF data from the SPIFF file without the need to perform any type of data conversions.
This technique, however, has the disadvantage of violating the JFIF specification by including a JFIF APP0 marker that does not immediately follow the SOI marker. While many JFIF encoders may not care about this violation, it is possible that some JFIF decoders will complain. The greatest disadvantage, however, is this is not the proper way to use the SPIFF format.
The JFIF format was created to embed ancillary information directly within a raw JPEG data stream. JFIF accomplishes this by using APP0 markers followed by the ancillary data. Such data defined by the JFIF specification includes number of components, sample precision, image height and width, thumbnail data, and application-specific data.
A primary purpose of SPIFF-JPEG is to replace the function of JFIF's APP0 markers with SPIFF's header and directory information. While it is valid to store JPEG data in a SPIFF file that contains APP0 markers, it is not in the spirit of the design and use of the SPIFF format.
What are the rules for a proper JFIF-to-SPIFF-JPEG conversion? The goal is to convert all ancillary information in the JFIF file to the equivalent SPIFF information structures and only store a raw JPEG data stream in the SPIFF-JPEG file. We offer the following guidelines:
The following JFIF and JPEG information must be used to initialize the fields of the SPIFF header:
| Description | SOF0 (width) |
| SPIFF Header Field | Color space |
| JFIF or JPEG marker code | ColorSpace |
| Number of color components | SOF0 (components) |
| NumberComponents | Type of resolution units |
| SOF0 (components) | ResolutionUnits |
| Number of bits per sample | APP0 (units) |
| BitsPerSample | Vertical resolution |
| SOF0 (sample precision) | VerticalResolution |
| Number of lines in image | APP0 (Ydensity) |
| ImageHeight | Horizontal resolution |
| SOF0 (height) | HorizontalResolution |
| Number of samples per line | APP0 (Xdensity) |
| ImageWidth |
Note that the value of ColorSpace will be 3 if the JPEG number of color components value is 3, or 8 if the same JPEG marker data is 1. These ColorSpace values correspond to the two color spaces allowed by the JFIF spec. Non-JFIF, raw JPEG data files may convert to other SPIFF color-space codes; for example, Adobe Photoshop can emit CMYK JPEG files.
Here is the black art of JFIF-to-SPIFF-JPEG conversion. The JPEG standard does not define the type of information that is stored in a JPEG comment block. It can be anything from your name to the Gettysburg Address to a field of NULL values. It's up to the user and/or application creating the JPEG data stream.
The storage of generic blocks of "unspecified" or "miscellaneous" text is not directly supported by the SPIFF format. The information content of textual data that may be stored in a SPIFF directory entry is somewhat rigidly defined to be the name of the SPIFF file creator, image title, image description, copyright information, and so on.
A converter may choose to store any JPEG comment block information it finds in the SPIFF image description directory entry, but it may not always be the proper place for this information. Another possible solution is to store miscellaneous text in application-specific directory entries, as provided for by the SPIFF specification. This, however, will effectively hide the comment block information from every SPIFF reader that doesn't recognize your application-specific directory tag (which is probably most of them). Your last--and possibly best--solution is to simply leave the comment block in the JPEG data stream. At least this will make it possible for any program that reads JPEG comment blocks to retrieve the information.
It is worth noting that storing indirect data is not harmful. All JFIF readers should stop at the EOI (End of Image) JPEG marker at the end of the compressed data, and should therefore never reach the indirect data. The recommendation against indirect data is made just to accommodate simple-minded SPIFF decoders that don't handle indirect entries.
SPIFF is part of the International Standard and Recommendation "Digital Compression and Coding of Continuous-Tone Still Images," which is published by the ITU in three parts:
ITU-T T.81 Requirements and Guidelines ITU-T T.83 Compliance Testing ITU-T T.84 Extensions
The same standards are also published by the ISO/IEU:
ISO/IEC 10918-1 Requirements and Guidelines ISO/IEC 10918-2 Compliance Testing ISO/IEC 10918-3 Extensions
The actual document containing the SPIFF specification is the ISO/IEC 10918-3 standard, "Digital Compression and Coding of Continuous-Tone Still Images: Extensions." This document is also published as the ITU-T Recommendation T.84 under the same title. Recommendation T.84 is available directly from ITU:
International Telecommunication Union (ITU)
Information Services Department
Place des Nations
1211 Geneva 20
Switzerland
Voice: +41 22 730-6666 or 730-5554
Fax: +41 22 730 533
Email: helpdesk@itu.ch
X.400: S=helpdesk; A=arcom; P=itu; C=ch
You can also order these documents via the ITU and ISO Web pages at:
http://www.itu.ch
http://www.iso.ch
For information about ordering, you can also check out:
ftp://ftp.uu.net/graphics/jpeg/jpeg.documents.gz
A future version of the Independent JPEG Group's JPEG library will implement support for SPIFF and will be an excellent source of SPIFF code.
Copyright © 1996, 1994 O'Reilly & Associates, Inc. All Rights Reserved.
