48
Adobe Photoshop® TIFF Technical Notes
March 22, 2002
COM (shall be ignored by TIFF readers)
DNL markers shall not be used in TIFF files. Readers should abort if any other marker type is found,
especially the JPEG reserved markers; occurrence of such a marker is likely to indicate a JPEG extension.
The tables/miscellaneous markers may appear in any order. Readers are cautioned that although the SOFn
marker refers to DQT tables, JPEG does not require those tables to precede the SOFn, only the SOS.
Missing-table checks should be made when SOS is reached.
If no JPEGTables field is used, then each image segment shall be a complete JPEG interchange data
stream. Each segment must define all the tables it references. To allow readers to decode segments in any
order, no segment may rely on tables being carried over from a previous segment.
When a JPEGTables field is used, image segments may omit tables that have been specified in the
JPEGTables field. Further details appear below.
The SOFn marker shall be of type SOF0 for strict baseline JPEG data, of type SOF1 for non-baseline lossy
JPEG data, or of type SOF3 for lossless JPEG data. (SOF9 or SOF11 would be used for arithmetic coding.)
All segments of a JPEGcompressed TIFF image shall use the same JPEG compression process, in
particular the same SOFn type.
The data precision field of the SOFn marker shall agree with the TIFF BitsPerSample field. (Note that
when Planar Configuration=1, this implies that all components must have the same BitsPerSample
value; when Planar Configuration=2, different components could have different bit depths.) For SOF0
only precision 8 is permitted; for SOF1, precision 8 or 12 is permitted; for SOF3, precisions 2 to 16 are
permitted.
The image dimensions given in the SOFn marker shall agree with the logical dimensions of that particular
strip or tile. For strip images, the SOFn image width shall equal ImageWidth and the height shall equal
RowsPerStrip, except in the last strip; its SOFn height shall equal the number of rows remaining in the
ImageLength. (In other words, no padding data is counted in the SOFn dimensions.) For tile images, each
SOFn shall have width TileWidth and height TileHeight; adding and removing any padding needed in the
edge tiles is the concern of some higher level of the TIFF software. (The dimensional rules are slightly
different when Planar Configuration=2, as described below.)
The ISO JPEG standard only permits images up to 65535 pixels in width or height, due to 2-byte fields in
the SOFn markers. In TIFF, this limits the size of an individual JPEG-compressed strip or tile, but the total
image size can be greater.
The number of components in the JPEG data stream shall equal SamplesPerPixel for Planar
Configuration=1, and shall be 1 for Planar Configuration=2. The components shall be stored in the same
order as they are described at the TIFF field level. (This applies both to their order in the SOFn marker, and
to the order in which they are scanned if multiple JPEG scans are used.) The component ID bytes are
arbitrary so long as each component within an image segment is given a distinct ID. To avoid any possible
confusion, we require that all segments of a TIFF image use the same ID code for a given component.
In Planar Configuration 1, the sampling factors given in SOFn markers shall agree with the sampling
factors defined by the related TIFF fields (or with the default values that are specified in the absence of
those fields).
When DCT-based JPEG is used in a strip TIFF file, RowsPerStrip is required to be a multiple of 8 times
the largest vertical sampling factor, i.e., a multiple of the height of an interleaved MCU. (For simplicity of
specification, we require this even if the data is not actually interleaved.) For example, if
YCbCrSubSampling = [2,2] then RowsPerStrip must be a multiple of 16. An exception to this rule is
made for single-strip images (RowsPerStrip >= ImageLength): the exact value of RowsPerStrip is
unimportant in that case. This rule ensures that no data padding is needed at the bottom of a strip, except
Page 6 of 13
45
Adobe Photoshop® TIFF Technical Notes
March 22, 2002
perhaps the last strip. Any padding required at the right edge of the image, or at the bottom of the last strip,
is expected to occur internally to the JPEG codec.
When DCT-based JPEG is used in a tiled TIFF file, TileLength is required to be a multiple of 8 times the
largest vertical sampling factor, i.e., a multiple of the height of an interleaved MCU; and TileWidth is
required to be a multiple of 8 times the largest horizontal sampling factor, i.e., a multiple of the width of an
interleaved MCU. (For simplicity of specification, we require this even if the data is not actually
interleaved.) All edge padding required will therefore occur in the course of normal TIFF tile padding; it is
not special to JPEG.
Lossless JPEG does not impose these constraints on strip and tile sizes, since it is not DCT-based.
Note that within JPEG data streams, multibyte values appear in the MSB-first order specified by the JPEG
standard, regardless of the byte ordering of the surrounding TIFF file.
JPEGTables field
The only auxiliary TIFF field added for Compression=7 is the optional JPEGTables field. The purpose of
JPEGTables is to predefine JPEG quantization and/or Huffman tables for subsequent use by JPEG image
segments. When this is done, these rather bulky tables need not be duplicated in each segment, thus saving
space and processing time. JPEGTables may be used even in a single segment file, although there is no
space savings in that case.
Field: JPEGTables
Status: optional
Tag: 347 (15B.H)
Type: UNDEFINED
Count: number of bytes in tables data stream, typically a few hundred
Value: JPEGTables provides default JPEG quantization and/or Huffman tables which are used whenever
a segment data stream does not contain its own tables, as specified below.
Default: none
Notice that the JPEGTables field is required to have type code UNDEFINED, not type code BYTE. This
is to cue readers that expanding individual bytes to short or long integers is not appropriate. A TIFF reader
will generally need to store the field value as an uninterpreted byte sequence until it is fed to the JPEG
decoder.
Multibyte quantities within the tables follow the ISO JPEG convention of MSBfirst storage, regardless of
the byte ordering of the surrounding TIFF file.
When the JPEGTables field is present, it shall contain a valid JPEG “abbreviated table specification” data
stream. This data stream shall begin with SOI and end with EOI. It may contain zero or more JPEG “tables
and miscellaneous” markers, namely:
DQT
DHT
DAC (not to appear unless arithmetic coding is used)
DRI
APPn (shall be ignored by TIFF readers)
COM (shall be ignored by TIFF readers)
Since JPEG defines the SOI marker to reset the DAC and DRI state, these two markers’ values cannot be
carried over into any image data stream, and thus they are effectively no-ops in the JPEGTables field. To
Page 7 of 13
42
Adobe Photoshop® TIFF Technical Notes
March 22, 2002
avoid confusion, it is recommended that writers not place DAC or DRI markers in JPEGTables. However,
readers must properly skip over them if they appear.
When JPEGTables is present, readers shall load the table specifications contained in JPEGTables before
processing image segment data streams. Image segments may simply refer to these preloaded tables
without defining them.
An image segment can still define and use its own tables, subject to the restrictions below. An image
segment may not redefine any table defined in JPEGTables. (This restriction is imposed to allow readers
to process image segments in random order without having to reload JPEGTables between segments.)
Therefore, use of JPEGTables divides the available table slots into two groups: “global” slots are defined
in JPEGTables and may be used but not redefined by segments; “local” slots are available for local
definition and use in each segment. To permit random access, a segment may not reference any local tables
that it does not itself define.
Special considerations for Planar Configuration 2
In Planar Configuration 2, each image segment contains data for only one color component. To avoid
confusing the JPEG codec, we wish the segments to look like valid single-channel (i.e., grayscale) JPEG
data streams. This means that different rules must be used for the SOFn parameters.
In Planar Configuration 2, the dimensions given in the SOFn of a sub sampled component shall be scaled
down by the sampling factors compared to the SOFn dimensions that would be used in planar
Configuration 1. This is necessary to match the actual number of samples stored in that segment, so that
the JPEG codec doesn’t complain about too much or too little data. In strip TIFF files the computed
dimensions may need to be rounded up to the next integer; in tiled files, the restrictions on tile size make
this case impossible.
Furthermore, all SOFn sampling factors shall be given as 1. (This is merely to avoid confusion, since the
sampling factors in a single-channel JPEG data stream have no real effect.)
Any down sampling will need to happen externally to the JPEG codec, since JPEG sampling factors are
defined with reference to the full-precision component. In Planar Configuration 2, the JPEG codec will be
working on only one component at a time and thus will have no reference component to down sample
against.
Minimum requirements for TIFF/JPEG
ISO JPEG is a large and complex standard; most implementations support only a subset of it. Here we
define a “core” subset of TIFF/JPEG which readers must support to claim TIFF/JPEG compatibility. For
maximum cross-application compatibility, we recommend that writers confine themselves to this subset
unless there is very good reason to do otherwise.
Use the ISO baseline JPEG process: 8-bit data precision, Huffman coding, with no more than 2 DC and 2
AC Huffman tables. Note that this implies BitsPerSample
= 8 for each component. We recommend deviating from baseline JPEG only if 12-bit data precision or
lossless coding is required.
Use no sub sampling (all JPEG sampling factors = 1) for color spaces other than YCbCr and CIEL*a*b*.
For YCbCr and CIEL*a*b*, use one of the following choices:
Page 8 of 13
49
Adobe Photoshop® TIFF Technical Notes
March 22, 2002
ChromaSubSampling field
JPEG sampling factors
1,1
1h1v, 1h1v, 1h1v
2,1
2h1v, 1h1v, 1h1v
2,2
(default value)
2h2v, 1h1v, 1h1v
We recommend that RGB source data be converted to YCbCr for best compression results. Other source
data color spaces should probably be left alone. Minimal readers need not support JPEG images with color
spaces other than YCbCr and grayscale (Photometric Interpretation = 6 or 1).
A minimal reader also need not support JPEG YCbCr images with no default values of
YCbCrCoefficients or ChromaPositioning, nor with values of ReferenceBlackWhite other than
[0,255,128,255,128,255]. (These values correspond to the RGB<=>YCbCr conversion specified by JFIF,
which is widely implemented in JPEG codecs.)
If any sub sampling is used, Planar Configuration=1 is preferred to avoid the possibly-confusing
requirements of Planar Configuration=2. In any case, readers are not required to support Planar
Configuration=2.
If possible, use a single interleaved scan in each image segment. This is not legal
JPEG if there are more than 4 SamplesPerPixel or if the sampling factors are such that more than 10
blocks would be needed per MCU; in that case, use a separate scan for each component. (The
recommended color spaces and sampling factors will not run into that restriction, so a minimal reader need
not support more than one scan per segment.)
To claim TIFF/JPEG compatibility, readers shall support multiple-strip TIFF files and the optional
JPEGTables field; it is not acceptable to read only single data stream files. Support for tiled TIFF files is
strongly recommended but not required.
Photoshop 7.0 writes ChromaSubSampling of [1,1] for quality settings above 6 with
ChromaPositioningValue = 2.
Other recommendations for implementers
The TIFF tag Compression=7 guarantees only that the compressed data is represented as ISO JPEG data
streams. Since JPEG is a large and evolving standard, readers should apply careful error checking to the
JPEG markers to ensure that the compression process is within their capabilities. In particular, to avoid
being confused by future extensions to the JPEG standard, it is important to abort if unknown marker codes
are seen.
The point of requiring that all image segments use the same JPEG process is to ensure that a reader need
check only one segment to determine whether it can handle the image. For example, consider a TIFF reader
that has access to fast but restricted JPEG hardware, as well as a slower, more general software
implementation. It is desirable to check only one image segment to find out whether the fast hardware can
be used. Thus, writers should try to ensure that all segments of an image look as much “alike” as possible:
there should be no variation in scan layout, use of options such as DRI, etc. Ideally, segments will be
processed identically except perhaps for using different local quantization or entropy-coding tables.
Writers should avoid including “noise” JPEG markers (COM and APPn markers). Standard TIFF fields
provide a better way to transport any non-image data. Some JPEG codecs may change behavior if they see
an APPn marker they think they understand; since the TIFF spec requires these markers to be ignored, this
behavior is undesirable.
Page 9 of 13
33
Adobe Photoshop® TIFF Technical Notes
March 22, 2002
It is possible to convert an interchange-JPEG file (e.g., a JFIF file) to TIFF simply by dropping the
interchange data stream into a single strip. (However, designers are reminded that the TIFF spec
discourages huge strips; splitting the image is somewhat more work but may give better results.)
Conversion from TIFF to interchange JPEG is more complex. A strip-based TIFF/JPEG file can be
converted fairly easily if all strips use identical JPEG tables and no RSTn markers: just delete the overhead
markers and insert RSTn markers between strips. Converting tiled images is harder, since the data will
usually not be in the right order (unless the tiles are only one MCU high). This can still be done losslessly,
but it will require undoing and redoing the entropy coding so that the DC coefficient differences can be
updated.
There is no default value for JPEGTables: standard TIFF files must define all tables that they reference.
For some closed systems in which many files will have identical tables, it might make sense to define a
default JPEGTables value to avoid actually storing the tables. Or even better, register a private field for
selecting one of N default JPEGTables settings, so as to allow for future expansion. Either of these
suggestions must be regarded as a private extension that will render the files unreadable by other
applications.
References
[1] Wallace, Gregory K. “The JPEG Still Picture Compression Standard”, Communications of the ACM,
April 1991 (vol. 34 no. 4), pp. 30-44.
This is the best short technical introduction to the JPEG algorithms. It is a good overview but does not
provide sufficiently detailed information to write an implementation.
[2] Pennebaker, William B. and Mitchell, Joan L. “JPEG Still Image Data Compression Standard”, Van
Nostrand Reinhold, 1993, ISBN 0-442-01272-1. 638pp.
This textbook is by far the most complete exposition of JPEG in existence. It includes the full text of the
ISO JPEG standards (DIS 10918-1 and draft DIS 10918-2). No would-be JPEG implementer should be
without it.
[3] ISO/IEC IS 10918-1, “Digital Compression and Coding of Continuous-tone Still Images, Part 1:
Requirements and guidelines”, February 1994. ISO/IEC DIS 10918-2, “Digital Compression and Coding of
Continuous-tone Still Images, Part 2:Compliance testing”, final approval expected 1994.
These are the official standards documents. Note that the Pennebaker and Mitchell textbook are likely to be
cheaper and more useful than the official standards.
Page 10 of 13
Documents you may be interested
Documents you may be interested
