Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
TIFF
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Overview == A TIFF file contains one ''or several'' images, termed ''subfiles'' in the specification. The basic use case for having multiple subfiles is to encode a multipage [[telefax]] in a single file, but it is also allowed to have different subfiles be different variants of the same image, for example scanned at different resolutions. Rather than being a continuous range of bytes in the file, each subfile is a data structure whose top-level entity is called an ''image file directory'' (IFD). Baseline TIFF readers are only required to make use of the first subfile, but each IFD has a field for linking to a next IFD. The IFDs are where the ''tags'' for which TIFF is named are located. Each IFD contains one or several ''entries'', each of which is identified by its tag. The tags are arbitrary 16-bit numbers; their symbolic names such as ImageWidth often used in discussions of TIFF data do not appear explicitly in the file itself. Each IFD entry has an associated ''value'', which may be decoded based on general rules of the format, but it depends on the tag what that value then ''means''. There may within a single IFD be no more than one entry with any particular tag. Some tags are for linking to the actual image data, other tags specify how the image data should be interpreted, and still other tags are used for image [[metadata]]. TIFF images are made up of rectangular<ref>Nothing prevents someone defining a TIFF extension that would introduce some other kind of pixel geometry, or even house non-pixel-based graphics in a TIFF container, but so far there does not seem to have been any need for that. Hence TIFF images have a rectangular pixel geometry.</ref> grids of pixels. The two axes of this geometry are termed horizontal (or X, or width) and vertical (or Y, or length). Horizontal and vertical [[image resolution|resolution]] need not be equal (since in a telefax they typically would not be equal). A baseline TIFF image divides the vertical range of the image into one or several ''strips'', which are encoded (in particular: compressed) separately. Historically this served to facilitate TIFF readers (such as fax machines) with limited capacity to store uncompressed data β one strip would be decoded and then immediately printed β but the present specification motivates it by "increased editing flexibility and efficient I/O buffering".<ref name="tiff6" />{{rp|19}} A TIFF extension provides the alternative of ''tiled'' images, in which case both the horizontal and the vertical ranges of the image are decomposed into smaller units. An example of these things, which also serves to give a flavor of how tags are used in the TIFF encoding of images, is that a striped TIFF image would use tags 273 (StripOffsets), 278 (RowsPerStrip), and 279 (StripByteCounts). The StripOffsets point to the blocks of image data, the StripByteCounts say how long each of these blocks are (as stored in the file), and RowsPerStrip says how many rows of pixels there are in a strip; the latter is required even in the case of having just one strip, in which case it merely duplicates the value of tag 257 (ImageLength). A tiled TIFF image instead uses tags 322 (TileWidth), 323 (TileLength), 324 (TileOffsets), and 325 (TileByteCounts). The pixels within each strip or tile appear in [[Row- and column-major order|row-major]] order, left to right and top to bottom. The data for one pixel is made up of one or several ''samples''; for example an [[RGB color model|RGB]] image would have one Red sample, one Green sample, and one Blue sample per pixel, whereas a greyscale or palette color image only has one sample per pixel. TIFF allows for both [[additive color|additive]] (e.g. RGB, [[RGBA]]) and [[subtractive color|subtractive]] (e.g. [[CMYK color model|CMYK]]) color models. TIFF does not constrain the number of samples per pixel (except that there must be enough samples for the chosen color model), nor does it constrain how many bits are encoded for each sample, but baseline TIFF only requires that readers support a few combinations of color model and bit-depth of images. Support for custom sets of samples is very useful for scientific applications; 3 samples per pixel is at the low end of [[multispectral image|multispectral imaging]], and [[hyperspectral imaging]] may require hundreds of samples per pixel. TIFF supports having all samples for a pixel next to each other within a single strip/tile (PlanarConfiguration = 1) but also different samples in different strips/tiles (PlanarConfiguration = 2). The default format for a sample value is as an unsigned integer, but a TIFF extension allows declaring them as alternatively being signed integers or [[IEEE-754]] floats, as well as specify a custom range for valid sample values. TIFF images may be uncompressed, compressed using a [[lossless compression]] scheme, or compressed using a [[lossy compression]] scheme. The lossless [[LZW]] compression scheme has at times been regarded as the standard compression for TIFF, but this is technically a TIFF extension, and the TIFF6 specification notes the patent situation regarding LZW. Compression schemes vary significantly in at what level they process the data: LZW acts on the stream of bytes encoding a strip or tile (without regard to sample structure, bit depth, or row width), whereas the JPEG compression scheme both transforms the sample structure of pixels (switching to a different color model) and encodes pixels in 8Γ8 blocks rather than row by row. Most data in TIFF files are numerical, but the format supports declaring data as rather being textual, if appropriate for a particular tag. Tags that take textual values include Artist, Copyright, DateTime, DocumentName, InkNames, and Model. ===MIME type=== The MIME type ''image/tiff'' (defined in RFC 3302) without an application parameter is used for Baseline TIFF 6.0 files or to indicate that it is not necessary to identify a specific subset of TIFF or TIFF extensions. The optional "application" parameter (Example: Content-type: image/tiff; application=foo) is defined for image/tiff to identify a particular subset of TIFF and TIFF extensions for the encoded image data, if it is known. According to RFC 3302, specific TIFF subsets or TIFF extensions used in the application parameter must be published as an RFC.<ref name="jdf" /> [[MIME]] type ''image/tiff-fx'' (defined in RFC 3949 and RFC 3950) is based on TIFF 6.0 with TIFF Technical Notes TTN1 (Trees) and TTN2 (Replacement TIFF/JPEG specification). It is used for [[Internet fax]] compatible with the ITU-T Recommendations for Group 3 black-and-white, grayscale and color [[fax]]. === Digital preservation === Adobe holds the copyright on the TIFF specification (aka TIFF 6.0) along with the two supplements that have been published. These documents can be found on the Adobe TIFF Resources page.<ref>{{cite web |url=https://www.adobe.io/open/standards/TIFF.html |title=Adobe TIFF Resources page |access-date=2022-06-29 |archive-url=https://web.archive.org/web/20210108172855/https://www.adobe.io/open/standards/TIFF.html |archive-date=8 January 2021 |url-status=dead}}</ref> The [[Fax]] standard in RFC 3949 is based on these TIFF specifications.<ref name="LoC">{{cite web|url=http://www.digitalpreservation.gov/formats/fdd/fdd000022.shtml|title=TIFF, Revision 6.0|publisher=[[Library of Congress]]|work=Digital Preservation|date=2014-01-08|access-date=2014-03-11}}</ref> TIFF files that strictly use the basic "tag sets" as defined in TIFF 6.0 along with restricting the compression technology to the methods identified in TIFF 6.0 and are adequately tested and verified by multiple sources for all documents being created can be used for storing documents. Commonly seen issues encountered in the content and [[document management]] industry associated with the use of TIFF files arise when the structures contain proprietary headers, are not properly documented, or contain "wrappers" or other containers around the TIFF datasets, or include improper compression technologies, or those compression technologies are not properly implemented. Variants of TIFF can be used within [[document imaging]] and content/document management systems using [[ITU-T|CCITT]] [[Group 4 compression|Group IV 2D compression]] which supports [[black-and-white]] (bitonal, [[monochrome]]) images, among other compression technologies that support [[color]]. When storage capacity and network bandwidth was a greater issue than commonly seen in today's server environments, high-volume storage scanning, documents were scanned in black and white (not in color or in grayscale) to conserve storage capacity. The inclusion of the SampleFormat tag in TIFF 6.0 allows TIFF files to handle advanced pixel data types, including integer images with more than 8 bits per channel and floating point images. This tag made TIFF 6.0 a viable format for scientific image processing where extended precision is required. An example would be the use of TIFF to store images acquired using scientific CCD cameras that provide up to 16 bits per [[photosite]] of intensity resolution. Storing a sequence of images in a single TIFF file is also possible, and is allowed under TIFF 6.0, provided the rules for multi-page images are followed.{{Citation needed|date=July 2024}}
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)