tifftechnote2.txt

jpeg压缩解压缩算法及源码

------------------------------

In lossy JPEG compression, it is customary to convert color source data
to YCbCr and then downsample it before JPEG compression.  This gives
2:1 data compression with hardly any visible image degradation, and it
permits additional space savings within the JPEG compression step proper.
However, these steps are not considered part of the ISO JPEG standard.
The ISO standard is "color blind": it accepts data in any color space.

For TIFF purposes, the JPEG compression tag is considered to represent the
ISO JPEG compression standard only.  The ISO standard is applied to the
same data that would be stored in the TIFF file if no compression were
used.  Therefore, if color conversion or downsampling are used, they must
be reflected in the regular TIFF fields; these steps are not considered to
be implicit in the JPEG compression tag value.  PhotometricInterpretation
and related fields shall describe the color space actually stored in the
file.  With the TIFF 6.0 field definitions, downsampling is permissible
only for YCbCr data, and it must correspond to the YCbCrSubSampling field.
(Note that the default value for this field is not 1,1; so the default for
YCbCr is to apply downsampling!)  It is likely that future versions of TIFF
will provide additional PhotometricInterpretation values and a more general
way of defining subsampling, so as to allow more flexibility in
JPEG-compressed files.  But that issue is not addressed in this Tech Note.

Implementors should note that many popular JPEG codecs
(compressor/decompressors) provide automatic color conversion and
downsampling, so that the application may supply full-size RGB data which
is nonetheless converted to downsampled YCbCr.  This is an implementation
convenience which does not excuse the TIFF control layer from its
responsibility to know what is really going on.  The
PhotometricInterpretation and subsampling fields written to the file must
describe what is actually in the file.

A JPEG-compressed TIFF file will typically have PhotometricInterpretation =
YCbCr and YCbCrSubSampling = [2,1] or [2,2], unless the source data was
grayscale or CMYK.


Basic representation of JPEG-compressed images
----------------------------------------------

JPEG compression works in either strip-based or tile-based TIFF files.
Rather than repeating "strip or tile" constantly, we will use the term
"segment" to mean either a strip or a tile.

When the Compression field has the value 7, each image segment contains
a complete JPEG datastream which is valid according to the ISO JPEG
standard (ISO/IEC 10918-1).  Any sequential JPEG process can be used,
including lossless JPEG, but progressive and hierarchical processes are not
supported.  Since JPEG is useful only for continuous-tone images, the
PhotometricInterpretation of the image shall not be 3 (palette color) nor
4 (transparency mask).  The bit depth of the data is also restricted as
specified below.

Each image segment in a JPEG-compressed TIFF file shall contain a valid
JPEG datastream according to the ISO JPEG standard's rules for
interchange-format or abbreviated-image-format data.  The datastream shall
contain a single JPEG frame storing that segment of the image.  The
required JPEG markers within a segment are:
	SOI	(must appear at very beginning of segment)
	SOFn
	SOS	(one for each scan, if there is more than one scan)
	EOI	(must appear at very end of segment)
The actual compressed data follows SOS; it may contain RSTn markers if DRI
is used.

Additional JPEG "tables and miscellaneous" markers may appear between SOI
and SOFn, between SOFn and SOS, and before each subsequent SOS if there is
more than one scan.  These markers include:
	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)
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 datastream.  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 JPEG-compressed 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 PlanarConfiguration=1, this implies
that all components must have the same BitsPerSample value; when
PlanarConfiguration=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 PlanarConfiguration=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 datastream shall equal SamplesPerPixel
for PlanarConfiguration=1, and shall be 1 for PlanarConfiguration=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 PlanarConfiguration 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 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 datastreams, 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.

JPEGTables:
	Tag = 347 (15B.H)
	Type = UNDEFINED
	N = number of bytes in tables datastream, typically a few hundred
JPEGTables provides default JPEG quantization and/or Huffman tables which
are used whenever a segment datastream does not contain its own tables, as
specified below.

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
MSB-first 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" datastream.  This datastream 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 datastream, and thus
they are effectively no-ops in the JPEGTables field.  To 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 datastreams.
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 PlanarConfiguration 2
------------------------------------------------

In PlanarConfiguration 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 datastreams.  This
means that different rules must be used for the SOFn parameters.

In PlanarConfiguration 2, the dimensions given in the SOFn of a subsampled
component shall be scaled down by the sampling factors compared to the SOFn
dimensions that would be used in PlanarConfiguration 1.  This is necessary