tifftechnote2.txt

jpeg压缩解压缩算法及源码

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 datastream have no real effect.)

Any downsampling will need to happen externally to the JPEG codec, since
JPEG sampling factors are defined with reference to the full-precision
component.  In PlanarConfiguration 2, the JPEG codec will be working on
only one component at a time and thus will have no reference component to
downsample 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 subsampling (all JPEG sampling factors = 1) for color spaces other
than YCbCr.  (This is, in fact, required with the TIFF 6.0 field
definitions, but may not be so in future revisions.)  For YCbCr, use one of
the following choices:
	YCbCrSubSampling 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 colorspaces should probably be left alone.
Minimal readers need not support JPEG images with colorspaces other than
YCbCr and grayscale (PhotometricInterpretation = 6 or 1).

A minimal reader also need not support JPEG YCbCr images with nondefault
values of YCbCrCoefficients or YCbCrPositioning, 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.)

Writers are reminded that a ReferenceBlackWhite field *must* be included
when PhotometricInterpretation is YCbCr, because the default
ReferenceBlackWhite values are inappropriate for YCbCr.

If any subsampling is used, PlanarConfiguration=1 is preferred to avoid the
possibly-confusing requirements of PlanarConfiguration=2.  In any case,
readers are not required to support PlanarConfiguration=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-datastream files.  Support for tiled TIFF files is strongly
recommended but not required.


Other recommendations for implementors
--------------------------------------

The TIFF tag Compression=7 guarantees only that the compressed data is
represented as ISO JPEG datastreams.  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.

It is possible to convert an interchange-JPEG file (e.g., a JFIF file) to
TIFF simply by dropping the interchange datastream 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, invent a
private field selecting one of N default JPEGTables settings, so as to allow
for future expansion.  Either of these 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 implementor 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 is likely to be cheaper and more useful than the official
standards.


Changes to Section 21: YCbCr Images
===================================

[This section of the Tech Note clarifies section 21 to make clear the
interpretation of image dimensions in a subsampled image.  Furthermore,
the section is changed to allow the original image dimensions not to be
multiples of the sampling factors.  This change is necessary to support use
of JPEG compression on odd-size images.]

Add the following paragraphs to the Section 21 introduction (p. 89),
just after the paragraph beginning "When a Class Y image is subsampled":

	In a subsampled image, it is understood that all TIFF image
	dimensions are measured in terms of the highest-resolution
	(luminance) component.  In particular, ImageWidth, ImageLength,
	RowsPerStrip, TileWidth, TileLength, XResolution, and YResolution
	are measured in luminance samples.

	RowsPerStrip, TileWidth, and TileLength are constrained so that
	there are an integral number of samples of each component in a
	complete strip or tile.  However, ImageWidth/ImageLength are not
	constrained.  If an odd-size image is to be converted to subsampled
	format, the writer should pad the source data to a multiple of the
	sampling factors by replication of the last column and/or row, then
	downsample.  The number of luminance samples actually stored in the
	file will be a multiple of the sampling factors.  Conversely,
	readers must ignore any extra data (outside the specified image
	dimensions) after upsampling.

	When PlanarConfiguration=2, each strip or tile covers the same
	image area despite subsampling; that is, the total number of strips
	or tiles in the image is the same for each component.  Therefore
	strips or tiles of the subsampled components contain fewer samples
	than strips or tiles of the luminance component.

	If there are extra samples per pixel (see field ExtraSamples),
	these data channels have the same number of samples as the
	luminance component.

Rewrite the YCbCrSubSampling field description (pp 91-92) as follows
(largely to eliminate possibly-misleading references to
ImageWidth/ImageLength of the subsampled components):

	(first paragraph unchanged)

	The two elements of this field are defined as follows:

	Short 0: ChromaSubsampleHoriz:

	1 = there are equal numbers of luma and chroma samples horizontally.

	2 = there are twice as many luma samples as chroma samples
	horizontally.

	4 = there are four times as many luma samples as chroma samples
	horizontally.

	Short 1: ChromaSubsampleVert:

	1 = there are equal numbers of luma and chroma samples vertically.

	2 = there are twice as many luma samples as chroma samples
	vertically.

	4 = there are four times as many luma samples as chroma samples
	vertically.

	ChromaSubsampleVert shall always be less than or equal to
	ChromaSubsampleHoriz.  Note that Cb and Cr have the same sampling
	ratios.

	In a strip TIFF file, RowsPerStrip is required to be an integer
	multiple of ChromaSubSampleVert (unless RowsPerStrip >=
	ImageLength, in which case its exact value is unimportant).
	If ImageWidth and ImageLength are not multiples of
	ChromaSubsampleHoriz and ChromaSubsampleVert respectively, then the
	source data shall be padded to the next integer multiple of these
	values before downsampling.

	In a tiled TIFF file, TileWidth must be an integer multiple of
	ChromaSubsampleHoriz and TileLength must be an integer multiple of
	ChromaSubsampleVert.  Padding will occur to tile boundaries.

	The default values of this field are [ 2,2 ].  Thus, YCbCr data is
	downsampled by default!