diff options
author | Jörg Frings-Fürst <debian@jff-webhosting.net> | 2015-11-06 05:38:49 +0100 |
---|---|---|
committer | Jörg Frings-Fürst <debian@jff-webhosting.net> | 2015-11-06 05:38:49 +0100 |
commit | 9491825ddff7a294d1f49061bae7044e426aeb2e (patch) | |
tree | 06e651099f87140ec534ae47fb8ce1ac6ec7976d /tiff/html/TIFFTechNote2.html | |
parent | fa756339d4204bff7f2820067f58214d32780d17 (diff) |
Imported Upstream version 1.8.3
Diffstat (limited to 'tiff/html/TIFFTechNote2.html')
-rwxr-xr-x | tiff/html/TIFFTechNote2.html | 707 |
1 files changed, 707 insertions, 0 deletions
diff --git a/tiff/html/TIFFTechNote2.html b/tiff/html/TIFFTechNote2.html new file mode 100755 index 0000000..92bace4 --- /dev/null +++ b/tiff/html/TIFFTechNote2.html @@ -0,0 +1,707 @@ +<pre> +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? +------------------------------ + +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 +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! +</pre> |