tifftechnote2.txt

jpeg压缩解压缩算法及源码

DRAFT TIFF Technical Note #2				17-Mar-95
============================

This Technical Note describes serious problems that have been found in
TIFF 6.0's design for embedding JPEG-compressed data in TIFF (Section 22
of the TIFF 6.0 spec of 3 June 1992).  A replacement TIFF/JPEG
specification is given.  Some corrections to Section 21 are also given.

To permit TIFF implementations to continue to read existing files, the 6.0
JPEG fields and tag values will remain reserved indefinitely.  However,
TIFF writers are strongly discouraged from using the 6.0 JPEG design.  It
is expected that the next full release of the TIFF specification will not
describe the old design at all, except to note that certain tag numbers
are reserved.  The existing Section 22 will be replaced by the
specification text given in the second part of this Tech Note.


Problems in TIFF 6.0 JPEG
=========================

Abandoning a published spec is not a step to be taken lightly.  This
section summarizes the reasons that have forced this decision.
TIFF 6.0's JPEG design suffers from design errors and limitations,
ambiguities, and unnecessary complexity.


Design errors and limitations
-----------------------------

The fundamental design error in the existing Section 22 is that JPEG's
various tables and parameters are broken out as separate fields which the
TIFF control logic must manage.  This is bad software engineering: that
information should be treated as private to the JPEG codec
(compressor/decompressor).  Worse, the fields themselves are specified
without sufficient thought for future extension and without regard to
well-established TIFF conventions.  Here are some of the significant
problems:

* The JPEGxxTable fields do not store the table data directly in the
IFD/field structure; rather, the fields hold pointers to information
elsewhere in the file.  This requires special-purpose code to be added to
*every* TIFF-manipulating application, whether it needs to decode JPEG
image data or not.  Even a trivial TIFF editor, for example a program to
add an ImageDescription field to a TIFF file, must be explicitly aware of
the internal structure of the JPEG-related tables, or else it will probably
break the file.  Every other auxiliary field in the TIFF spec contains
data, not pointers, and can be copied or relocated by standard code that
doesn't know anything about the particular field.  This is a crucial
property of the TIFF format that must not be given up.

* To manipulate these fields, the TIFF control logic is required to know a
great deal about JPEG details, for example such arcana as how to compute
the length of a Huffman code table --- the length is not supplied in the
field structure and can only be found by inspecting the table contents.
This is again a violation of good software practice.  Moreover, it will
prevent easy adoption of future JPEG extensions that might change these
low-level details.

* The design neglects the fact that baseline JPEG codecs support only two
sets of Huffman tables: it specifies a separate table for each color
component.  This implies that encoders must waste space (by storing
duplicate Huffman tables) or else violate the well-founded TIFF convention
that prohibits duplicate pointers.  Furthermore, baseline decoders must
test to find out which tables are identical, a waste of time and code
space.

* The JPEGInterchangeFormat field also violates TIFF's proscription against
duplicate pointers: the normal strip/tile pointers are expected to point
into the larger data area pointed to by JPEGInterchangeFormat.  All TIFF
editing applications must be specifically aware of this relationship, since
they must maintain it or else delete the JPEGInterchangeFormat field.  The
JPEGxxTables fields are also likely to point into the JPEGInterchangeFormat
area, creating additional pointer relationships that must be maintained.

* The JPEGQTables field is fixed at a byte per table entry; there is no
way to support 16-bit quantization values.  This is a serious impediment
to extending TIFF to use 12-bit JPEG.

* The 6.0 design cannot support using different quantization tables in
different strips/tiles of an image (so as to encode some areas at higher
quality than others).  Furthermore, since quantization tables are tied
one-for-one to color components, the design cannot support table switching
options that are likely to be added in future JPEG revisions.


Ambiguities
-----------

Several incompatible interpretations are possible for 6.0's treatment of
JPEG restart markers:

  * It is unclear whether restart markers must be omitted at TIFF segment
    (strip/tile) boundaries, or whether they are optional.

  * It is unclear whether the segment size is required to be chosen as
    a multiple of the specified restart interval (if any); perhaps the
    JPEG codec is supposed to be reset at each segment boundary as if
    there were a restart marker there, even if the boundary does not fall
    at a multiple of the nominal restart interval.

  * The spec fails to address the question of restart marker numbering:
    do the numbers begin again within each segment, or not?

That last point is particularly nasty.  If we make numbering begin again
within each segment, we give up the ability to impose a TIFF strip/tile
structure on an existing JPEG datastream with restarts (which was clearly a
goal of Section 22's authors).  But the other choice interferes with random
access to the image segments: a reader must compute the first restart
number to be expected within a segment, and must have a way to reset its
JPEG decoder to expect a nonzero restart number first.  This may not even
be possible with some JPEG chips.

The tile height restriction found on page 104 contradicts Section 15's
general description of tiles.  For an image that is not vertically
downsampled, page 104 specifies a tile height of one MCU or 8 pixels; but
Section 15 requires tiles to be a multiple of 16 pixels high.

This Tech Note does not attempt to resolve these ambiguities, so
implementations that follow the 6.0 design should be aware that
inter-application compatibility problems are likely to arise.


Unnecessary complexity
----------------------

The 6.0 design creates problems for implementations that need to keep the
JPEG codec separate from the TIFF control logic --- for example, consider
using a JPEG chip that was not designed specifically for TIFF.  JPEG codecs
generally want to produce or consume a standard ISO JPEG datastream, not
just raw compressed data.  (If they were to handle raw data, a separate
out-of-band mechanism would be needed to load tables into the codec.)
With such a codec, the TIFF control logic must parse JPEG markers emitted
by the codec to create the TIFF table fields (when writing) or synthesize
JPEG markers from the TIFF fields to feed the codec (when reading).  This
means that the control logic must know a great deal more about JPEG details
than we would like.  The parsing and reconstruction of the markers also
represents a fair amount of unnecessary work.

Quite a few implementors have proposed writing "TIFF/JPEG" files in which
a standard JPEG datastream is simply dumped into the file and pointed to
by JPEGInterchangeFormat.  To avoid parsing the JPEG datastream, they
suggest not writing the JPEG auxiliary fields (JPEGxxTables etc) nor even
the basic TIFF strip/tile data pointers.  This approach is incompatible
with implementations that handle the full TIFF 6.0 JPEG design, since they
will expect to find strip/tile pointers and auxiliary fields.  Indeed this
is arguably not TIFF at all, since *all* TIFF-reading applications expect
to find strip or tile pointers.  A subset implementation that is not
upward-compatible with the full spec is clearly unacceptable.  However,
the frequency with which this idea has come up makes it clear that
implementors find the existing Section 22 too complex.


Overview of the solution
========================

To solve these problems, we adopt a new design for embedding
JPEG-compressed data in TIFF files.  The new design uses only complete,
uninterpreted ISO JPEG datastreams, so it should be much more forgiving of
extensions to the ISO standard.  It should also be far easier to implement
using unmodified JPEG codecs.

To reduce overhead in multi-segment TIFF files, we allow JPEG overhead
tables to be stored just once in a JPEGTables auxiliary field.  This
feature does not violate the integrity of the JPEG datastreams, because it
uses the notions of "tables-only datastreams" and "abbreviated image
datastreams" as defined by the ISO standard.

To prevent confusion with the old design, the new design is given a new
Compression tag value, Compression=7.  Readers that need to handle
existing 6.0 JPEG files may read both old and new files, using whatever
interpretation of the 6.0 spec they did before.  Compression tag value 6
and the field tag numbers defined by 6.0 section 22 will remain reserved
indefinitely, even though detailed descriptions of them will be dropped
from future editions of the TIFF specification.


Replacement TIFF/JPEG specification
===================================

[This section of the Tech Note is expected to replace Section 22 in the
next release of the TIFF specification.]

This section describes TIFF compression scheme 7, a high-performance
compression method for continuous-tone images.

Introduction
------------

This TIFF compression method uses the international standard for image
compression ISO/IEC 10918-1, usually known as "JPEG" (after the original
name of the standards committee, Joint Photographic Experts Group).  JPEG
is a joint ISO/CCITT standard for compression of continuous-tone images.

The JPEG committee decided that because of the broad scope of the standard,
no one algorithmic procedure was able to satisfy the requirements of all
applications.  Instead, the JPEG standard became a "toolkit" of multiple
algorithms and optional capabilities.  Individual applications may select
a subset of the JPEG standard that meets their requirements.

The most important distinction among the JPEG processes is between lossy
and lossless compression.  Lossy compression methods provide high
compression but allow only approximate reconstruction of the original
image.  JPEG's lossy processes allow the encoder to trade off compressed
file size against reconstruction fidelity over a wide range.  Typically,
10:1 or more compression of full-color data can be obtained while keeping
the reconstructed image visually indistinguishable from the original.  Much
higher compression ratios are possible if a low-quality reconstructed image
is acceptable.  Lossless compression provides exact reconstruction of the
source data, but the achievable compression ratio is much lower than for
the lossy processes; JPEG's rather simple lossless process typically
achieves around 2:1 compression of full-color data.

The most widely implemented JPEG subset is the "baseline" JPEG process.
This provides lossy compression of 8-bit-per-channel data.  Optional
extensions include 12-bit-per-channel data, arithmetic entropy coding for
better compression, and progressive/hierarchical representations.  The
lossless process is an independent algorithm that has little in
common with the lossy processes.

It should be noted that the optional arithmetic-coding extension is subject
to several US and Japanese patents.  To avoid patent problems, use of
arithmetic coding processes in TIFF files intended for inter-application
interchange is discouraged.

All of the JPEG processes are useful only for "continuous tone" data,
in which the difference between adjacent pixel values is usually small.
Low-bit-depth source data is not appropriate for JPEG compression, nor
are palette-color images good candidates.  The JPEG processes work well
on grayscale and full-color data.

Describing the JPEG compression algorithms in sufficient detail to permit
implementation would require more space than we have here.  Instead, we
refer the reader to the References section.


What data is being compressed?