1<pre> 2DRAFT TIFF Technical Note #2 17-Mar-95 3============================ 4 5This Technical Note describes serious problems that have been found in 6TIFF 6.0's design for embedding JPEG-compressed data in TIFF (Section 22 7of the TIFF 6.0 spec of 3 June 1992). A replacement TIFF/JPEG 8specification is given. Some corrections to Section 21 are also given. 9 10To permit TIFF implementations to continue to read existing files, the 6.0 11JPEG fields and tag values will remain reserved indefinitely. However, 12TIFF writers are strongly discouraged from using the 6.0 JPEG design. It 13is expected that the next full release of the TIFF specification will not 14describe the old design at all, except to note that certain tag numbers 15are reserved. The existing Section 22 will be replaced by the 16specification text given in the second part of this Tech Note. 17 18 19Problems in TIFF 6.0 JPEG 20========================= 21 22Abandoning a published spec is not a step to be taken lightly. This 23section summarizes the reasons that have forced this decision. 24TIFF 6.0's JPEG design suffers from design errors and limitations, 25ambiguities, and unnecessary complexity. 26 27 28Design errors and limitations 29----------------------------- 30 31The fundamental design error in the existing Section 22 is that JPEG's 32various tables and parameters are broken out as separate fields which the 33TIFF control logic must manage. This is bad software engineering: that 34information should be treated as private to the JPEG codec 35(compressor/decompressor). Worse, the fields themselves are specified 36without sufficient thought for future extension and without regard to 37well-established TIFF conventions. Here are some of the significant 38problems: 39 40* The JPEGxxTable fields do not store the table data directly in the 41IFD/field structure; rather, the fields hold pointers to information 42elsewhere in the file. This requires special-purpose code to be added to 43*every* TIFF-manipulating application, whether it needs to decode JPEG 44image data or not. Even a trivial TIFF editor, for example a program to 45add an ImageDescription field to a TIFF file, must be explicitly aware of 46the internal structure of the JPEG-related tables, or else it will probably 47break the file. Every other auxiliary field in the TIFF spec contains 48data, not pointers, and can be copied or relocated by standard code that 49doesn't know anything about the particular field. This is a crucial 50property of the TIFF format that must not be given up. 51 52* To manipulate these fields, the TIFF control logic is required to know a 53great deal about JPEG details, for example such arcana as how to compute 54the length of a Huffman code table --- the length is not supplied in the 55field structure and can only be found by inspecting the table contents. 56This is again a violation of good software practice. Moreover, it will 57prevent easy adoption of future JPEG extensions that might change these 58low-level details. 59 60* The design neglects the fact that baseline JPEG codecs support only two 61sets of Huffman tables: it specifies a separate table for each color 62component. This implies that encoders must waste space (by storing 63duplicate Huffman tables) or else violate the well-founded TIFF convention 64that prohibits duplicate pointers. Furthermore, baseline decoders must 65test to find out which tables are identical, a waste of time and code 66space. 67 68* The JPEGInterchangeFormat field also violates TIFF's proscription against 69duplicate pointers: the normal strip/tile pointers are expected to point 70into the larger data area pointed to by JPEGInterchangeFormat. All TIFF 71editing applications must be specifically aware of this relationship, since 72they must maintain it or else delete the JPEGInterchangeFormat field. The 73JPEGxxTables fields are also likely to point into the JPEGInterchangeFormat 74area, creating additional pointer relationships that must be maintained. 75 76* The JPEGQTables field is fixed at a byte per table entry; there is no 77way to support 16-bit quantization values. This is a serious impediment 78to extending TIFF to use 12-bit JPEG. 79 80* The 6.0 design cannot support using different quantization tables in 81different strips/tiles of an image (so as to encode some areas at higher 82quality than others). Furthermore, since quantization tables are tied 83one-for-one to color components, the design cannot support table switching 84options that are likely to be added in future JPEG revisions. 85 86 87Ambiguities 88----------- 89 90Several incompatible interpretations are possible for 6.0's treatment of 91JPEG restart markers: 92 93 * It is unclear whether restart markers must be omitted at TIFF segment 94 (strip/tile) boundaries, or whether they are optional. 95 96 * It is unclear whether the segment size is required to be chosen as 97 a multiple of the specified restart interval (if any); perhaps the 98 JPEG codec is supposed to be reset at each segment boundary as if 99 there were a restart marker there, even if the boundary does not fall 100 at a multiple of the nominal restart interval. 101 102 * The spec fails to address the question of restart marker numbering: 103 do the numbers begin again within each segment, or not? 104 105That last point is particularly nasty. If we make numbering begin again 106within each segment, we give up the ability to impose a TIFF strip/tile 107structure on an existing JPEG datastream with restarts (which was clearly a 108goal of Section 22's authors). But the other choice interferes with random 109access to the image segments: a reader must compute the first restart 110number to be expected within a segment, and must have a way to reset its 111JPEG decoder to expect a nonzero restart number first. This may not even 112be possible with some JPEG chips. 113 114The tile height restriction found on page 104 contradicts Section 15's 115general description of tiles. For an image that is not vertically 116downsampled, page 104 specifies a tile height of one MCU or 8 pixels; but 117Section 15 requires tiles to be a multiple of 16 pixels high. 118 119This Tech Note does not attempt to resolve these ambiguities, so 120implementations that follow the 6.0 design should be aware that 121inter-application compatibility problems are likely to arise. 122 123 124Unnecessary complexity 125---------------------- 126 127The 6.0 design creates problems for implementations that need to keep the 128JPEG codec separate from the TIFF control logic --- for example, consider 129using a JPEG chip that was not designed specifically for TIFF. JPEG codecs 130generally want to produce or consume a standard ISO JPEG datastream, not 131just raw compressed data. (If they were to handle raw data, a separate 132out-of-band mechanism would be needed to load tables into the codec.) 133With such a codec, the TIFF control logic must parse JPEG markers emitted 134by the codec to create the TIFF table fields (when writing) or synthesize 135JPEG markers from the TIFF fields to feed the codec (when reading). This 136means that the control logic must know a great deal more about JPEG details 137than we would like. The parsing and reconstruction of the markers also 138represents a fair amount of unnecessary work. 139 140Quite a few implementors have proposed writing "TIFF/JPEG" files in which 141a standard JPEG datastream is simply dumped into the file and pointed to 142by JPEGInterchangeFormat. To avoid parsing the JPEG datastream, they 143suggest not writing the JPEG auxiliary fields (JPEGxxTables etc) nor even 144the basic TIFF strip/tile data pointers. This approach is incompatible 145with implementations that handle the full TIFF 6.0 JPEG design, since they 146will expect to find strip/tile pointers and auxiliary fields. Indeed this 147is arguably not TIFF at all, since *all* TIFF-reading applications expect 148to find strip or tile pointers. A subset implementation that is not 149upward-compatible with the full spec is clearly unacceptable. However, 150the frequency with which this idea has come up makes it clear that 151implementors find the existing Section 22 too complex. 152 153 154Overview of the solution 155======================== 156 157To solve these problems, we adopt a new design for embedding 158JPEG-compressed data in TIFF files. The new design uses only complete, 159uninterpreted ISO JPEG datastreams, so it should be much more forgiving of 160extensions to the ISO standard. It should also be far easier to implement 161using unmodified JPEG codecs. 162 163To reduce overhead in multi-segment TIFF files, we allow JPEG overhead 164tables to be stored just once in a JPEGTables auxiliary field. This 165feature does not violate the integrity of the JPEG datastreams, because it 166uses the notions of "tables-only datastreams" and "abbreviated image 167datastreams" as defined by the ISO standard. 168 169To prevent confusion with the old design, the new design is given a new 170Compression tag value, Compression=7. Readers that need to handle 171existing 6.0 JPEG files may read both old and new files, using whatever 172interpretation of the 6.0 spec they did before. Compression tag value 6 173and the field tag numbers defined by 6.0 section 22 will remain reserved 174indefinitely, even though detailed descriptions of them will be dropped 175from future editions of the TIFF specification. 176 177 178Replacement TIFF/JPEG specification 179=================================== 180 181[This section of the Tech Note is expected to replace Section 22 in the 182next release of the TIFF specification.] 183 184This section describes TIFF compression scheme 7, a high-performance 185compression method for continuous-tone images. 186 187Introduction 188------------ 189 190This TIFF compression method uses the international standard for image 191compression ISO/IEC 10918-1, usually known as "JPEG" (after the original 192name of the standards committee, Joint Photographic Experts Group). JPEG 193is a joint ISO/CCITT standard for compression of continuous-tone images. 194 195The JPEG committee decided that because of the broad scope of the standard, 196no one algorithmic procedure was able to satisfy the requirements of all 197applications. Instead, the JPEG standard became a "toolkit" of multiple 198algorithms and optional capabilities. Individual applications may select 199a subset of the JPEG standard that meets their requirements. 200 201The most important distinction among the JPEG processes is between lossy 202and lossless compression. Lossy compression methods provide high 203compression but allow only approximate reconstruction of the original 204image. JPEG's lossy processes allow the encoder to trade off compressed 205file size against reconstruction fidelity over a wide range. Typically, 20610:1 or more compression of full-color data can be obtained while keeping 207the reconstructed image visually indistinguishable from the original. Much 208higher compression ratios are possible if a low-quality reconstructed image 209is acceptable. Lossless compression provides exact reconstruction of the 210source data, but the achievable compression ratio is much lower than for 211the lossy processes; JPEG's rather simple lossless process typically 212achieves around 2:1 compression of full-color data. 213 214The most widely implemented JPEG subset is the "baseline" JPEG process. 215This provides lossy compression of 8-bit-per-channel data. Optional 216extensions include 12-bit-per-channel data, arithmetic entropy coding for 217better compression, and progressive/hierarchical representations. The 218lossless process is an independent algorithm that has little in 219common with the lossy processes. 220 221It should be noted that the optional arithmetic-coding extension is subject 222to several US and Japanese patents. To avoid patent problems, use of 223arithmetic coding processes in TIFF files intended for inter-application 224interchange is discouraged. 225 226All of the JPEG processes are useful only for "continuous tone" data, 227in which the difference between adjacent pixel values is usually small. 228Low-bit-depth source data is not appropriate for JPEG compression, nor 229are palette-color images good candidates. The JPEG processes work well 230on grayscale and full-color data. 231 232Describing the JPEG compression algorithms in sufficient detail to permit 233implementation would require more space than we have here. Instead, we 234refer the reader to the References section. 235 236 237What data is being compressed? 238------------------------------ 239 240In lossy JPEG compression, it is customary to convert color source data 241to YCbCr and then downsample it before JPEG compression. This gives 2422:1 data compression with hardly any visible image degradation, and it 243permits additional space savings within the JPEG compression step proper. 244However, these steps are not considered part of the ISO JPEG standard. 245The ISO standard is "color blind": it accepts data in any color space. 246 247For TIFF purposes, the JPEG compression tag is considered to represent the 248ISO JPEG compression standard only. The ISO standard is applied to the 249same data that would be stored in the TIFF file if no compression were 250used. Therefore, if color conversion or downsampling are used, they must 251be reflected in the regular TIFF fields; these steps are not considered to 252be implicit in the JPEG compression tag value. PhotometricInterpretation 253and related fields shall describe the color space actually stored in the 254file. With the TIFF 6.0 field definitions, downsampling is permissible 255only for YCbCr data, and it must correspond to the YCbCrSubSampling field. 256(Note that the default value for this field is not 1,1; so the default for 257YCbCr is to apply downsampling!) It is likely that future versions of TIFF 258will provide additional PhotometricInterpretation values and a more general 259way of defining subsampling, so as to allow more flexibility in 260JPEG-compressed files. But that issue is not addressed in this Tech Note. 261 262Implementors should note that many popular JPEG codecs 263(compressor/decompressors) provide automatic color conversion and 264downsampling, so that the application may supply full-size RGB data which 265is nonetheless converted to downsampled YCbCr. This is an implementation 266convenience which does not excuse the TIFF control layer from its 267responsibility to know what is really going on. The 268PhotometricInterpretation and subsampling fields written to the file must 269describe what is actually in the file. 270 271A JPEG-compressed TIFF file will typically have PhotometricInterpretation = 272YCbCr and YCbCrSubSampling = [2,1] or [2,2], unless the source data was 273grayscale or CMYK. 274 275 276Basic representation of JPEG-compressed images 277---------------------------------------------- 278 279JPEG compression works in either strip-based or tile-based TIFF files. 280Rather than repeating "strip or tile" constantly, we will use the term 281"segment" to mean either a strip or a tile. 282 283When the Compression field has the value 7, each image segment contains 284a complete JPEG datastream which is valid according to the ISO JPEG 285standard (ISO/IEC 10918-1). Any sequential JPEG process can be used, 286including lossless JPEG, but progressive and hierarchical processes are not 287supported. Since JPEG is useful only for continuous-tone images, the 288PhotometricInterpretation of the image shall not be 3 (palette color) nor 2894 (transparency mask). The bit depth of the data is also restricted as 290specified below. 291 292Each image segment in a JPEG-compressed TIFF file shall contain a valid 293JPEG datastream according to the ISO JPEG standard's rules for 294interchange-format or abbreviated-image-format data. The datastream shall 295contain a single JPEG frame storing that segment of the image. The 296required JPEG markers within a segment are: 297 SOI (must appear at very beginning of segment) 298 SOFn 299 SOS (one for each scan, if there is more than one scan) 300 EOI (must appear at very end of segment) 301The actual compressed data follows SOS; it may contain RSTn markers if DRI 302is used. 303 304Additional JPEG "tables and miscellaneous" markers may appear between SOI 305and SOFn, between SOFn and SOS, and before each subsequent SOS if there is 306more than one scan. These markers include: 307 DQT 308 DHT 309 DAC (not to appear unless arithmetic coding is used) 310 DRI 311 APPn (shall be ignored by TIFF readers) 312 COM (shall be ignored by TIFF readers) 313DNL markers shall not be used in TIFF files. Readers should abort if any 314other marker type is found, especially the JPEG reserved markers; 315occurrence of such a marker is likely to indicate a JPEG extension. 316 317The tables/miscellaneous markers may appear in any order. Readers are 318cautioned that although the SOFn marker refers to DQT tables, JPEG does not 319require those tables to precede the SOFn, only the SOS. Missing-table 320checks should be made when SOS is reached. 321 322If no JPEGTables field is used, then each image segment shall be a complete 323JPEG interchange datastream. Each segment must define all the tables it 324references. To allow readers to decode segments in any order, no segment 325may rely on tables being carried over from a previous segment. 326 327When a JPEGTables field is used, image segments may omit tables that have 328been specified in the JPEGTables field. Further details appear below. 329 330The SOFn marker shall be of type SOF0 for strict baseline JPEG data, of 331type SOF1 for non-baseline lossy JPEG data, or of type SOF3 for lossless 332JPEG data. (SOF9 or SOF11 would be used for arithmetic coding.) All 333segments of a JPEG-compressed TIFF image shall use the same JPEG 334compression process, in particular the same SOFn type. 335 336The data precision field of the SOFn marker shall agree with the TIFF 337BitsPerSample field. (Note that when PlanarConfiguration=1, this implies 338that all components must have the same BitsPerSample value; when 339PlanarConfiguration=2, different components could have different bit 340depths.) For SOF0 only precision 8 is permitted; for SOF1, precision 8 or 34112 is permitted; for SOF3, precisions 2 to 16 are permitted. 342 343The image dimensions given in the SOFn marker shall agree with the logical 344dimensions of that particular strip or tile. For strip images, the SOFn 345image width shall equal ImageWidth and the height shall equal RowsPerStrip, 346except in the last strip; its SOFn height shall equal the number of rows 347remaining in the ImageLength. (In other words, no padding data is counted 348in the SOFn dimensions.) For tile images, each SOFn shall have width 349TileWidth and height TileHeight; adding and removing any padding needed in 350the edge tiles is the concern of some higher level of the TIFF software. 351(The dimensional rules are slightly different when PlanarConfiguration=2, 352as described below.) 353 354The ISO JPEG standard only permits images up to 65535 pixels in width or 355height, due to 2-byte fields in the SOFn markers. In TIFF, this limits 356the size of an individual JPEG-compressed strip or tile, but the total 357image size can be greater. 358 359The number of components in the JPEG datastream shall equal SamplesPerPixel 360for PlanarConfiguration=1, and shall be 1 for PlanarConfiguration=2. The 361components shall be stored in the same order as they are described at the 362TIFF field level. (This applies both to their order in the SOFn marker, 363and to the order in which they are scanned if multiple JPEG scans are 364used.) The component ID bytes are arbitrary so long as each component 365within an image segment is given a distinct ID. To avoid any possible 366confusion, we require that all segments of a TIFF image use the same ID 367code for a given component. 368 369In PlanarConfiguration 1, the sampling factors given in SOFn markers shall 370agree with the sampling factors defined by the related TIFF fields (or with 371the default values that are specified in the absence of those fields). 372 373When DCT-based JPEG is used in a strip TIFF file, RowsPerStrip is required 374to be a multiple of 8 times the largest vertical sampling factor, i.e., a 375multiple of the height of an interleaved MCU. (For simplicity of 376specification, we require this even if the data is not actually 377interleaved.) For example, if YCbCrSubSampling = [2,2] then RowsPerStrip 378must be a multiple of 16. An exception to this rule is made for 379single-strip images (RowsPerStrip >= ImageLength): the exact value of 380RowsPerStrip is unimportant in that case. This rule ensures that no data 381padding is needed at the bottom of a strip, except perhaps the last strip. 382Any padding required at the right edge of the image, or at the bottom of 383the last strip, is expected to occur internally to the JPEG codec. 384 385When DCT-based JPEG is used in a tiled TIFF file, TileLength is required 386to be a multiple of 8 times the largest vertical sampling factor, i.e., 387a multiple of the height of an interleaved MCU; and TileWidth is required 388to be a multiple of 8 times the largest horizontal sampling factor, i.e., 389a multiple of the width of an interleaved MCU. (For simplicity of 390specification, we require this even if the data is not actually 391interleaved.) All edge padding required will therefore occur in the course 392of normal TIFF tile padding; it is not special to JPEG. 393 394Lossless JPEG does not impose these constraints on strip and tile sizes, 395since it is not DCT-based. 396 397Note that within JPEG datastreams, multibyte values appear in the MSB-first 398order specified by the JPEG standard, regardless of the byte ordering of 399the surrounding TIFF file. 400 401 402JPEGTables field 403---------------- 404 405The only auxiliary TIFF field added for Compression=7 is the optional 406JPEGTables field. The purpose of JPEGTables is to predefine JPEG 407quantization and/or Huffman tables for subsequent use by JPEG image 408segments. When this is done, these rather bulky tables need not be 409duplicated in each segment, thus saving space and processing time. 410JPEGTables may be used even in a single-segment file, although there is no 411space savings in that case. 412 413JPEGTables: 414 Tag = 347 (15B.H) 415 Type = UNDEFINED 416 N = number of bytes in tables datastream, typically a few hundred 417JPEGTables provides default JPEG quantization and/or Huffman tables which 418are used whenever a segment datastream does not contain its own tables, as 419specified below. 420 421Notice that the JPEGTables field is required to have type code UNDEFINED, 422not type code BYTE. This is to cue readers that expanding individual bytes 423to short or long integers is not appropriate. A TIFF reader will generally 424need to store the field value as an uninterpreted byte sequence until it is 425fed to the JPEG decoder. 426 427Multibyte quantities within the tables follow the ISO JPEG convention of 428MSB-first storage, regardless of the byte ordering of the surrounding TIFF 429file. 430 431When the JPEGTables field is present, it shall contain a valid JPEG 432"abbreviated table specification" datastream. This datastream shall begin 433with SOI and end with EOI. It may contain zero or more JPEG "tables and 434miscellaneous" markers, namely: 435 DQT 436 DHT 437 DAC (not to appear unless arithmetic coding is used) 438 DRI 439 APPn (shall be ignored by TIFF readers) 440 COM (shall be ignored by TIFF readers) 441Since JPEG defines the SOI marker to reset the DAC and DRI state, these two 442markers' values cannot be carried over into any image datastream, and thus 443they are effectively no-ops in the JPEGTables field. To avoid confusion, 444it is recommended that writers not place DAC or DRI markers in JPEGTables. 445However readers must properly skip over them if they appear. 446 447When JPEGTables is present, readers shall load the table specifications 448contained in JPEGTables before processing image segment datastreams. 449Image segments may simply refer to these preloaded tables without defining 450them. An image segment can still define and use its own tables, subject to 451the restrictions below. 452 453An image segment may not redefine any table defined in JPEGTables. (This 454restriction is imposed to allow readers to process image segments in random 455order without having to reload JPEGTables between segments.) Therefore, use 456of JPEGTables divides the available table slots into two groups: "global" 457slots are defined in JPEGTables and may be used but not redefined by 458segments; "local" slots are available for local definition and use in each 459segment. To permit random access, a segment may not reference any local 460tables that it does not itself define. 461 462 463Special considerations for PlanarConfiguration 2 464------------------------------------------------ 465 466In PlanarConfiguration 2, each image segment contains data for only one 467color component. To avoid confusing the JPEG codec, we wish the segments 468to look like valid single-channel (i.e., grayscale) JPEG datastreams. This 469means that different rules must be used for the SOFn parameters. 470 471In PlanarConfiguration 2, the dimensions given in the SOFn of a subsampled 472component shall be scaled down by the sampling factors compared to the SOFn 473dimensions that would be used in PlanarConfiguration 1. This is necessary 474to match the actual number of samples stored in that segment, so that the 475JPEG codec doesn't complain about too much or too little data. In strip 476TIFF files the computed dimensions may need to be rounded up to the next 477integer; in tiled files, the restrictions on tile size make this case 478impossible. 479 480Furthermore, all SOFn sampling factors shall be given as 1. (This is 481merely to avoid confusion, since the sampling factors in a single-channel 482JPEG datastream have no real effect.) 483 484Any downsampling will need to happen externally to the JPEG codec, since 485JPEG sampling factors are defined with reference to the full-precision 486component. In PlanarConfiguration 2, the JPEG codec will be working on 487only one component at a time and thus will have no reference component to 488downsample against. 489 490 491Minimum requirements for TIFF/JPEG 492---------------------------------- 493 494ISO JPEG is a large and complex standard; most implementations support only 495a subset of it. Here we define a "core" subset of TIFF/JPEG which readers 496must support to claim TIFF/JPEG compatibility. For maximum 497cross-application compatibility, we recommend that writers confine 498themselves to this subset unless there is very good reason to do otherwise. 499 500Use the ISO baseline JPEG process: 8-bit data precision, Huffman coding, 501with no more than 2 DC and 2 AC Huffman tables. Note that this implies 502BitsPerSample = 8 for each component. We recommend deviating from baseline 503JPEG only if 12-bit data precision or lossless coding is required. 504 505Use no subsampling (all JPEG sampling factors = 1) for color spaces other 506than YCbCr. (This is, in fact, required with the TIFF 6.0 field 507definitions, but may not be so in future revisions.) For YCbCr, use one of 508the following choices: 509 YCbCrSubSampling field JPEG sampling factors 510 1,1 1h1v, 1h1v, 1h1v 511 2,1 2h1v, 1h1v, 1h1v 512 2,2 (default value) 2h2v, 1h1v, 1h1v 513We recommend that RGB source data be converted to YCbCr for best compression 514results. Other source data colorspaces should probably be left alone. 515Minimal readers need not support JPEG images with colorspaces other than 516YCbCr and grayscale (PhotometricInterpretation = 6 or 1). 517 518A minimal reader also need not support JPEG YCbCr images with nondefault 519values of YCbCrCoefficients or YCbCrPositioning, nor with values of 520ReferenceBlackWhite other than [0,255,128,255,128,255]. (These values 521correspond to the RGB<=>YCbCr conversion specified by JFIF, which is widely 522implemented in JPEG codecs.) 523 524Writers are reminded that a ReferenceBlackWhite field *must* be included 525when PhotometricInterpretation is YCbCr, because the default 526ReferenceBlackWhite values are inappropriate for YCbCr. 527 528If any subsampling is used, PlanarConfiguration=1 is preferred to avoid the 529possibly-confusing requirements of PlanarConfiguration=2. In any case, 530readers are not required to support PlanarConfiguration=2. 531 532If possible, use a single interleaved scan in each image segment. This is 533not legal JPEG if there are more than 4 SamplesPerPixel or if the sampling 534factors are such that more than 10 blocks would be needed per MCU; in that 535case, use a separate scan for each component. (The recommended color 536spaces and sampling factors will not run into that restriction, so a 537minimal reader need not support more than one scan per segment.) 538 539To claim TIFF/JPEG compatibility, readers shall support multiple-strip TIFF 540files and the optional JPEGTables field; it is not acceptable to read only 541single-datastream files. Support for tiled TIFF files is strongly 542recommended but not required. 543 544 545Other recommendations for implementors 546-------------------------------------- 547 548The TIFF tag Compression=7 guarantees only that the compressed data is 549represented as ISO JPEG datastreams. Since JPEG is a large and evolving 550standard, readers should apply careful error checking to the JPEG markers 551to ensure that the compression process is within their capabilities. In 552particular, to avoid being confused by future extensions to the JPEG 553standard, it is important to abort if unknown marker codes are seen. 554 555The point of requiring that all image segments use the same JPEG process is 556to ensure that a reader need check only one segment to determine whether it 557can handle the image. For example, consider a TIFF reader that has access 558to fast but restricted JPEG hardware, as well as a slower, more general 559software implementation. It is desirable to check only one image segment 560to find out whether the fast hardware can be used. Thus, writers should 561try to ensure that all segments of an image look as much "alike" as 562possible: there should be no variation in scan layout, use of options such 563as DRI, etc. Ideally, segments will be processed identically except 564perhaps for using different local quantization or entropy-coding tables. 565 566Writers should avoid including "noise" JPEG markers (COM and APPn markers). 567Standard TIFF fields provide a better way to transport any non-image data. 568Some JPEG codecs may change behavior if they see an APPn marker they 569think they understand; since the TIFF spec requires these markers to be 570ignored, this behavior is undesirable. 571 572It is possible to convert an interchange-JPEG file (e.g., a JFIF file) to 573TIFF simply by dropping the interchange datastream into a single strip. 574(However, designers are reminded that the TIFF spec discourages huge 575strips; splitting the image is somewhat more work but may give better 576results.) Conversion from TIFF to interchange JPEG is more complex. A 577strip-based TIFF/JPEG file can be converted fairly easily if all strips use 578identical JPEG tables and no RSTn markers: just delete the overhead markers 579and insert RSTn markers between strips. Converting tiled images is harder, 580since the data will usually not be in the right order (unless the tiles are 581only one MCU high). This can still be done losslessly, but it will require 582undoing and redoing the entropy coding so that the DC coefficient 583differences can be updated. 584 585There is no default value for JPEGTables: standard TIFF files must define all 586tables that they reference. For some closed systems in which many files will 587have identical tables, it might make sense to define a default JPEGTables 588value to avoid actually storing the tables. Or even better, invent a 589private field selecting one of N default JPEGTables settings, so as to allow 590for future expansion. Either of these must be regarded as a private 591extension that will render the files unreadable by other applications. 592 593 594References 595---------- 596 597[1] Wallace, Gregory K. "The JPEG Still Picture Compression Standard", 598Communications of the ACM, April 1991 (vol. 34 no. 4), pp. 30-44. 599 600This is the best short technical introduction to the JPEG algorithms. 601It is a good overview but does not provide sufficiently detailed 602information to write an implementation. 603 604[2] Pennebaker, William B. and Mitchell, Joan L. "JPEG Still Image Data 605Compression Standard", Van Nostrand Reinhold, 1993, ISBN 0-442-01272-1. 606638pp. 607 608This textbook is by far the most complete exposition of JPEG in existence. 609It includes the full text of the ISO JPEG standards (DIS 10918-1 and draft 610DIS 10918-2). No would-be JPEG implementor should be without it. 611 612[3] ISO/IEC IS 10918-1, "Digital Compression and Coding of Continuous-tone 613Still Images, Part 1: Requirements and guidelines", February 1994. 614ISO/IEC DIS 10918-2, "Digital Compression and Coding of Continuous-tone 615Still Images, Part 2: Compliance testing", final approval expected 1994. 616 617These are the official standards documents. Note that the Pennebaker and 618Mitchell textbook is likely to be cheaper and more useful than the official 619standards. 620 621 622Changes to Section 21: YCbCr Images 623=================================== 624 625[This section of the Tech Note clarifies section 21 to make clear the 626interpretation of image dimensions in a subsampled image. Furthermore, 627the section is changed to allow the original image dimensions not to be 628multiples of the sampling factors. This change is necessary to support use 629of JPEG compression on odd-size images.] 630 631Add the following paragraphs to the Section 21 introduction (p. 89), 632just after the paragraph beginning "When a Class Y image is subsampled": 633 634 In a subsampled image, it is understood that all TIFF image 635 dimensions are measured in terms of the highest-resolution 636 (luminance) component. In particular, ImageWidth, ImageLength, 637 RowsPerStrip, TileWidth, TileLength, XResolution, and YResolution 638 are measured in luminance samples. 639 640 RowsPerStrip, TileWidth, and TileLength are constrained so that 641 there are an integral number of samples of each component in a 642 complete strip or tile. However, ImageWidth/ImageLength are not 643 constrained. If an odd-size image is to be converted to subsampled 644 format, the writer should pad the source data to a multiple of the 645 sampling factors by replication of the last column and/or row, then 646 downsample. The number of luminance samples actually stored in the 647 file will be a multiple of the sampling factors. Conversely, 648 readers must ignore any extra data (outside the specified image 649 dimensions) after upsampling. 650 651 When PlanarConfiguration=2, each strip or tile covers the same 652 image area despite subsampling; that is, the total number of strips 653 or tiles in the image is the same for each component. Therefore 654 strips or tiles of the subsampled components contain fewer samples 655 than strips or tiles of the luminance component. 656 657 If there are extra samples per pixel (see field ExtraSamples), 658 these data channels have the same number of samples as the 659 luminance component. 660 661Rewrite the YCbCrSubSampling field description (pp 91-92) as follows 662(largely to eliminate possibly-misleading references to 663ImageWidth/ImageLength of the subsampled components): 664 665 (first paragraph unchanged) 666 667 The two elements of this field are defined as follows: 668 669 Short 0: ChromaSubsampleHoriz: 670 671 1 = there are equal numbers of luma and chroma samples horizontally. 672 673 2 = there are twice as many luma samples as chroma samples 674 horizontally. 675 676 4 = there are four times as many luma samples as chroma samples 677 horizontally. 678 679 Short 1: ChromaSubsampleVert: 680 681 1 = there are equal numbers of luma and chroma samples vertically. 682 683 2 = there are twice as many luma samples as chroma samples 684 vertically. 685 686 4 = there are four times as many luma samples as chroma samples 687 vertically. 688 689 ChromaSubsampleVert shall always be less than or equal to 690 ChromaSubsampleHoriz. Note that Cb and Cr have the same sampling 691 ratios. 692 693 In a strip TIFF file, RowsPerStrip is required to be an integer 694 multiple of ChromaSubSampleVert (unless RowsPerStrip >= 695 ImageLength, in which case its exact value is unimportant). 696 If ImageWidth and ImageLength are not multiples of 697 ChromaSubsampleHoriz and ChromaSubsampleVert respectively, then the 698 source data shall be padded to the next integer multiple of these 699 values before downsampling. 700 701 In a tiled TIFF file, TileWidth must be an integer multiple of 702 ChromaSubsampleHoriz and TileLength must be an integer multiple of 703 ChromaSubsampleVert. Padding will occur to tile boundaries. 704 705 The default values of this field are [ 2,2 ]. Thus, YCbCr data is 706 downsampled by default! 707</pre> 708