Previous Next


TIFF 6.0 Specification                                                                   Final—June 3, 1992




                         DotRange
                         Tag    = 336 (150.H)
                         Type = BYTE or SHORT
                         N      = 2, or 2*SamplesPerPixel
                         The component values that correspond to a 0% dot and 100% dot. DotRange[0]
                         corresponds to a 0% dot, and DotRange[1] corresponds to a 100% dot.
                         If a DotRange pair is included for each component, the values for each component
                         are stored together, so that the pair for Cyan would be first, followed by the pair
                         for Magenta, and so on. Use of multiple dot ranges is, however, strongly discour-
                         aged in the interests of simplicity and compatibility with ANSI IT8 standards.
                         A number of prepress systems like to keep some “headroom” and “footroom” on
                         both ends of the range. What to do with components that are less than the 0% aim
                         point or greater than the 100% aim point is not specified and is application-depen-
                         dent.
                         It is strongly recommended that a CMYK TIFF writer not attempt to use this field
                         to reverse the sense of the pixel values so that smaller values mean more ink in-
                         stead of less ink. That is, DotRange[0] should be less than DotRange[1].
                         DotRange[0] and DotRange[1] must be within the range [0, (2**BitsPerSample) -
                         1].
                         Default: a component value of 0 corresponds to a 0% dot, and a component value
                         of 255 (assuming 8-bit pixels) corresponds to a 100% dot. That is, DotRange[0] =
                         0 and DotRange[1] = (2**BitsPerSample) - 1.


                         TargetPrinter
                         Tag    = 337 (151.H)
                         Type = ASCII
                         N      = any
                         A description of the printing environment for which this separation is intended.


History
                         This Section has been expanded from earlier drafts, with the addition of the
                         InkSet, InkNames, NumberOfInks, DotRange, and TargetPrinter, but is
                         backward-compatible with earlier draft versions.
                         Possible future enhancements: definition of the characterization information so
                         that the CMYK data can be retargeted to a different printing environment and so
                         that display on a CRT or proofing device can more accurately represent the color.
                         ANSI IT8 is working on such a proposal.




                                              71

TIFF 6.0 Specification Final—June 3, 1992 Section 17: HalftoneHints This section describes a scheme for properly placing highlights and shadows in halftoned images. Introduction The single most easily recognized failing of continuous tone images is the incor- rect placement of highlight and shadow. It is critical that a halftone process be capable of printing the lightest areas of the image as the smallest halftone spot capable of the output device, at the specified printer resolution and screen ruling. Specular highlights (small ultra-white areas) as well as the shadow areas should be printable as paper only. Consistency in highlight and shadow placement allows the user to obtain predict- able results on a wide variety of halftone output devices. Proper implementation of theHalftoneHints field will provide a significant step toward device indepen- dent imaging, such that low cost printers may to be used as effective proofing devices for images which will later be halftoned on a high-resolution imagesetter. The HalftoneHints Field HalftoneHints Tag = 321 (141.H) Type = SHORT N =2 The purpose of the HalftoneHints field is to convey to the halftone function the range of gray levels within a colorimetrically-specified image that should retain tonal detail. The field contains two values of sixteen bits each and, therefore, is contained wholly within the field itself; no offset is required. The first word speci- fies the highlight gray level which should be halftoned at the lightest printable tint of the final output device. The second word specifies the shadow gray level which should be halftoned at the darkest printable tint of the final output device. Portions of the image which are whiter than the highlight gray level will quickly, if not immediately, fade to specular highlights. There is no default value specified, since the highlight and shadow gray levels are a function of the subject matter of a par- ticular image. Appropriate values may be derived algorithmically or may be specified by the user, either directly or indirectly. The HalftoneHints field, as defined here, defines an achromatic function. It can be used just as effectively with color images as with monochrome images. When used with opponent color spaces such as CIE L*a*b* or YCbCr, it refers to the achromatic component only; L* in the case of CIELab, and Y in the case of 72

TIFF 6.0 Specification Final—June 3, 1992 YCbCr. When used with tri-stimulus spaces such as RGB, it suggests to retain tonal detail for all colors with an NTSC gray component within the bounds of the R=G=B=Highlight to R=G=B=Shadow range. Comments for TIFF Writers TIFF writers are encouraged to include the HalftoneHints field in all color or grayscale images where BitsPerSample >1. Although no default value is speci- fied, prior to the introduction of this field it has been common practice to implic- itly specify the highlight and shadow gray levels as 1 and 2**BitsperSample-2 and manipulate the image data to this definition. There are some disadvantages to this technique, and it is not feasible for a fixed gamut colorimetric image type. Appropriate values may be derived algorithmically or may be specified by the user directly or indirectly. Automatic algorithms exist for analyzing the histogram of the achromatic intensity of an image and defining the minimum and maximum values as the highlight and shadow settings such that tonal detail is retained throughout the image. This kind of algorithm may try to impose a highlight or shadow where none really exists in the image, which may require user controls to override the automatic setting. It should be noted that the choice of the highlight and shadow values is somewhat output dependent. For instance, in situations where the dynamic range of the output medium is very limited (as in newsprint and, to a lesser degree, laser out- put), it may be desirable for the user to clip some of the lightest or darkest tones to avoid the reduced contrast resulting from compressing the tone of the entire im- age. Different settings might be chosen for 150-line halftone printed on coated stock. Keep in mind that these values may be adjusted later (which might not be possible unless the image is stored as a colorimetric, fixed, full-gamut image), and that more sophisticated page-layout applications may be capable of presenting a user interface to consider these decisions at a point where the halftone process is well understood. It should be noted that although CCDs are linear intensity detectors, TIFF writers may choose to manipulate the image to store gamma-compensated data. Gamma- compensated data is more efficient at encoding an image than is linear intensity data because it requires fewer BitsPerPixel to eliminate banding in the darker tones. It also has the advantage of being closer to the tone response of the display or printer and is, therefore, less likely to produce poor results from applications that are not rigorous about their treatment of images. Be aware that the PhotometricInterpretation value of 0 or 1 (grayscale) implies linear data because no gamma is specified. The PhotometricInterpretation value of 2 (RGB data) specifies the NTSC gamma of 2.2 as a default. If data is written as something other than the default, then a GrayResponseCurve field or a TransferFunction field must be present to define the deviation. For grayscale data, be sure that the densities in the GrayResponseCurve are consistent with the PhotometricInterpretation field and the HalftoneHints field. 73

TIFF 6.0 Specification Final—June 3, 1992 Comments for TIFF Readers TIFF readers that send a grayscale image to a halftone output device, whether it is a binary laser printer or a PostScript imagesetter should make an effort to maintain the highlight and shadow placement. This requires two steps. First, determine the highlight and shadow gray level of a particular image. Second, communicate that information to the halftone engine. To determine the highlight and shadow gray levels, begin by looking for a HalftoneHints field. If it exists, it takes precedence. The first word represents the gray level of the highlight and the second word represents the gray level of the shadow. If the image is a colorimetric image (i.e. it has a GrayResponseCurve field or a TransferFunction field) but does not contain a HalftoneHints field, then the gamut mapping techniques described earlier should be used to determine the highlight and shadow values. If neither of these conditions are true, then the file should be treated as if a HalftoneHints field had indicated a highlight at gray level 1 and a shadow at gray level 2**BitsPerPixel-2 (or vice-versa depending on the PhotometricInterpretation field). Once the highlight and shadow gray levels have been determined, the next step is to communicate this information to the halftone module. The halftone module may exist within the same application as the TIFF reader, it may exist within a separate printer driver, or it may exist within the Raster Image Processor (RIP) of the printer itself. Whether the halftone process is a simple dither pattern or a general purpose spot function, it has some gray level at which the lightest printable tint will be rendered. The HalftoneHint concept is best implemented in an environment where this lightest printable tint is easily and consistently specified. There are several ways in which an application can communicate the highlight and shadow to the halftone function. Some environments may allow the applica- tion to pass the highlight and shadow to the halftone module explicitly along with the image. This is the best approach, but many environments do not yet provide this capability. Other environments may provide fixed gray levels at which the highlight and shadow will be rendered. For these cases, the application should build a tone map that matches the highlight and shadow specified in the image to the highlight and shadow gray level of the halftone module. This approach re- quires more work by the application software, but will provide excellent results. Some environments will not have any consistent concept of highlight and shadow at all. In these environments, the best an application can do is characterize each of the supported printers and save the observed highlight and shadow gray levels. The application can then use these values to achieve the desired results, providing the environment doesn’t change. Once the highlight and shadow areas are selected, care should be taken to appro- priately map intermediate gray levels to those expected by the halftone engine, which may or may not be linear Reflectance. Note that although CCDs are linear intensity detectors and many TIFF files are stored as linear intensity, most output devices require significant tone compensation (sometimes called gamma correc- tion) to correctly display or print linear data. Be aware that the PhotometricInterpretation value of 0, 1 implies linear data because no gamma is specified. The PhotometricInterpretation value of 2 (RGB data) specifies the NTSC gamma of 2.2 as a default. If a GrayResponseCurve field or a TransferFunction field is present, it may define something other than the default. 74

TIFF 6.0 Specification Final—June 3, 1992 Some Background on the Halftone Process To obtain the best results when printing a continuous-tone raster image, it is sel- dom desirable to simply reproduce the tones of the original on the printed page. Most often there is some gamut mapping required. Often this is because the tonal range of the original extends beyond the tonal range of the output medium. In some cases, the tone range of the original is within the gamut of the output me- dium, but it may be more pleasing to expand the tone of the image to fill the range of the output. Given that the tone of the original is to be adjusted, there is a whole range of possibilities for the level of sophistication that may be undertaken by a software application. Printing monochrome output is far less sophisticated than printing color output. For monochrome output the first priority is to control the placement of the high- light and the shadow. Ideally, a quality halftone will have sufficient levels of gray so that a standard observer cannot distinguish the interface between any two adja- cent levels of gray. In practice, however, there is often a significant step between the tone of the paper and the tone of the lightest printable tint. Although usually less severe, the problem is similar between solid ink and the darkest printable tint. Since the dynamic range between the lightest printable tint and the darkest print- able tint is usually less than one would like, it is common to maximize the tone of the image within these bounds. Not all images will have a highlight (an area of the image which is desirable to print as light as possible while still retaining tonal detail). If one exists, it should be carefully controlled to print at the lightest print- able tint of the output medium. Similarly, the darkest areas of the image to retain tonal detail should be printed as the darkest printable tint of the output medium. Tones lighter or darker than these may be clipped at the limits of the paper and ink. Satisfactory results may be obtained in monochrome work by doing nothing more than a perceptually-linear mapping of the image between these rigorously controlled endpoints. This level of sophistication is sufficient for many mid-range applications, although the results often appear flatter (i.e. lower in contrast) than desired. The next step is to increase contrast slightly in the tonal range of the image that contains the most important subject matter. To perform this step well requires considerably more information about the image and about the press. To know where to add contrast, the algorithm must have access to first the keyness of the image; the tone range which the user considers most important. To know how much contrast to add, the algorithm must have access to the absolute tone of the original and the dynamic range of the output device so that it may calculate the amount of tone compression to which the image is actually subjected. Most images are called normal key. The important subject areas of a normal key image are in the midtones. These images do well when a so-called “sympathetic curve” is applied, which increases the contrast in midtones slightly at the expense of contrast in the lighter and darker tones. White china on a white tablecloth is an example of a high key image. High key images benefit from higher contrast in lighter tones, with less contrast needed in the midtones and darker tones. Low key images have important subject matter in the darker tones and benefit from increas- ing the contrast in the darker tones. Specifying the keyness of an image might be attempted by automatic techniques, but it will likely fail without user input. For example, a photo of a bride in a white wedding dress it may be a high key image if 75

TIFF 6.0 Specification Final—June 3, 1992 you are selling wedding dresses, but may be a normal key image if you are the parents of the bride and are more interested in her smile. Sophisticated color reproduction employs all of these principles, and then applies them in three dimensions. The mapping of the highlight and shadow becomes only one small, albeit critical, portion of the total issue of mapping colors that are too saturated for the output medium. Here again, automatic techniques may be employed as a first pass, with the user becoming involved in the clip or compress mapping decision. The HalftoneHints field is still useful in communicating which portions of the intensity of the image must be retained and which may be clipped. Again, a sophisticated application may override these settings if later user input is received. 76

TIFF 6.0 Specification Final—June 3, 1992 Section 18: Associated Alpha Handling This section describes a scheme for handling images with alpha data. Introduction A common technique in computer graphics is to assemble an image from one or more elements that are rendered separately. When elements are combined using compositing techniques, matte or coverage information must be present for each pixel to create a properly anti-aliased accumulation of the full image [Porter84]. This matting information is an example of additional per-pixel data that must be maintained with an image. This section describes how to use the ExtraSamples field to store the requisite matting information, commonly called the associated alpha or just alpha. This scheme enables efficient manipulation of image data during compositing operations. Images with matting information are stored in their natural format but with an additional component per pixel. The ExtraSample field is included with the image to indicate that an extra component of each pixel contains associated alpha data. In addition, when associated alpha data are included with RGB data, the RGB com- ponents must be stored premultiplied by the associated alpha component and component values in the range [0,2**BitsPerSample-1] are implicitly mapped onto the [0,1] interval. That is, for each pixel (r,g,b) and opacity A, where r, g, b, and A are in the range [0,1], (A*r,A*g,A*b,A) must be stored in the file. If A is zero, then the color components should be interpreted as zero. Storing data in this pre-multiplied format, allows compositing operations to be implemented most efficiently. In addition, storing pre-multiplied data makes it possible to specify colors with components outside the normal [0,1] interval. The latter is useful for defining certain operations that effect only the luminescence [Porter84]. Fields ExtraSamples Tag = 338 (152.H) Type = SHORT N =1 This field must have a value of 1 (associated alpha data with pre-multiplied color components). The associated alpha data stored in component SamplesPerPixel-1 of each pixel contains the opacity of that pixel, and the color information is pre- multiplied by alpha. 77

TIFF 6.0 Specification Final—June 3, 1992 Comments Associated alpha data is just another component added to each pixel. Thus, for example, its size is defined by the value of the BitsPerSample field. Note that since data is stored with RGB components already multiplied by alpha, naive applications that want to display an RGBA image on a display can do so simply by displaying the RGB component values. This works because it is effec- tively the same as merging the image with a black background. That is, to merge one image with another, the color of resultant pixels are calculated as: Cr = Cover * Aover + Cunder * (1–Aover ) Since the “under image” is a black background, this equation reduces to Cr = Cover * Aover which is exactly the pre-multiplied color; i.e. what is stored in the image. On the other hand, to print an RGBA image, one must composite the image over a suitable background page color. For a white background, this is easily done by adding 1 - A to each color component. For an arbitrary background color C back, the printed color of each pixel is Cprint = Cimage + Cback * (1–Aimage) (since Cimage is pre-multiplied). Since the ExtraSamples field is independent of other fields, this scheme permits alpha information to be stored in whatever organization is appropriate. In particu- lar, components can be stored packed (PlanarConfiguration=1); this is important for good I/O performance and for good memory access performance on machines that are sensitive to data locality. However, if this scheme is used, TIFF readers must not derive the SamplesPerPixel from the value of the PhotometricInterpretation field (e.g., if RGB, then SamplesPerPixel is 3). In addition to being independent of data storage-related fields, the field is also independent of the PhotometricInterpretation field. This means, for example, that it is easy to use this field to specify grayscale data and associated matte informa- tion. Note that a palette-color image with associated alpha will not have the colormap indices pre-multiplied; rather, the RGB colormap values will be pre- multiplied. Unassociated Alpha and Transparency Masks Some image manipulation applications support notions of transparency masks and soft-edge masks. The associated alpha information described in this section is different from this unassociated alpha information in many ways, most impor- tantly: • Associated alpha describes opacity or coverage at each pixel, while clipping- related alpha information describes a boolean relationship. That is, associated alpha can specify fractional coverage at a pixel, while masks specify either 0 or 100 percent coverage. • Once defined, associated alpha is not intended to be removed or edited, except as a result of compositing the image; it is an integral part of an image. 78

TIFF 6.0 Specification Final—June 3, 1992 Unassociated alpha, on the other hand, is designed as an ancillary piece of information. References [Porter84] “Compositing Digital Images”. Thomas Porter, Tom Duff; Lucasfilm Ltd. ACM SIGGRAPH Proceedings Volume 18, Number 3. July, 1984. 79

TIFF 6.0 Specification Final—June 3, 1992 Section 19: Data Sample Format This section describes a scheme for specifying data sample type information. TIFF implicitly types all data samples as unsigned integer values. Certain applica- tions, however, require the ability to store image-related data in other formats such as floating point. This section presents a scheme for describing a variety of data sample formats. Fields SampleFormat Tag = 339 (153.H) Type = SHORT N = SamplesPerPixel This field specifies how to interpret each data sample in a pixel. Possible values are: 1 = unsigned integer data 2 = two’s complement signed integer data 3 = IEEE floating point data [IEEE] 4 = undefined data format Note that the SampleFormat field does not specify the size of data samples; this is still done by the BitsPerSample field. A field value of “undefined” is a statement by the writer that it did not know how to interpret the data samples; for example, if it were copying an existing image. A reader would typically treat an image with “undefined” data as if the field were not present (i.e. as unsigned integer data). Default is 1, unsigned integer data. SMinSampleValue Tag = 340 (154.H) Type = the field type that best matches the sample data N = SamplesPerPixel This field specifies the minimum sample value. Note that a value should be given for each data sample. That is, if the image has 3 SamplesPerPixel, 3 values must be specified. The default for SMinSampleValue and SMaxSampleValue is the full range of the data type. 80

Previous Next