Talk:TIFF

This is the talk page for discussing improvements to the TIFF article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Archives: 1: 180 days

Computing High‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
High	This article has been rated as High-importance on the project's importance scale.

Compression usage and support

How is the compression usage and support calculated?

I understand that the ZIP (zlib / deflate) compression is quite popular (here marked as "Uncommon"), although I'm unable to measure it. Which methodology was used to set this column of the table? When was it done? Should it be reviewed? — Preceding unsigned comment added by Vini.sch (talk • contribs) 15:26, 2 March 2020 (UTC)[reply]

The non-standard value 0x80b2 for tag 259 is uncommon and obsolete, the standard value 8 should be used instead and for value 8 the table says that support for and usage of this tag value are common. The comment common or uncommon refers to the tag value, not what's behind it, although that could be made clearer. 2A02:A461:E1E:1:21B:FCFF:FE75:6ADE (talk) 15:55, 1 September 2022 (UTC)[reply]

Overview rewrite

It seems appropriate to reorganise the current description of the format (Features and options section) into two sections "Overview" and "Details", to let the reader see the big picture before getting into specific details. Drafting such an overview section here. 90.129.219.218 (talk) 07:50, 23 March 2022 (UTC)[reply]

This drafted text is now live in the article.130.243.94.123 (talk) 12:00, 8 April 2022 (UTC)[reply]

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 we find the tags for which TIFF are named. 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^[1] 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 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”. 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 flavour 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-major order, top to bottom and left to right.

The data for one pixel is made up of one or several samples; for example an 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 (e.g. RGB, RGBA) and subtractive (e.g. 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 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.

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.

References

^ 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.

The .svs suffix

I see that a ".svs" file name suffix can indicate a tiled TIFF format. Would someone who knows what they are talking about add mention of this suffix to the article at an appropriate place? Thanks! — $Q$ uantling (talk | contribs) 15:28, 27 March 2023 (UTC)[reply]

Tag/Tagged

@Quantling, I noticed you reverted @Jojo-schmitz's edit which changed Tag to Tagged, and subsequently edited many pages to expand the acronym as Tag Image File Format. Your citation for this revert was this page on Adobe.com. And since Adobe owns the copyrights, who can argue with that, right? Well, I believe it is not so simple, as can be seen by this other page on Adobe.com that uses Tagged rather than Tag.

From 2005-2020, this article used Tagged. It was only with this edit in 2020 by @Dclunie that we changed to Tag.

If we look at the specs, we see version 4.0 from 1987 uses Tag, but version 5.0 from 1988 declines to expand the acronym, as does version 6 from 1992. If we take those specs at their word, the acronym has no official expansion.

But the Adobe specs aren't the only specs that mention TIFFs. RfC 2302 from 2002 uses Tag, as do RfCs 2301, 3949, 3950, 2306, and possibly more. But RfC 1314 slips and calls it Tagged (despite calling it Tag in its own references section - interestingly, it references version 5.0, the only text of which I can find does not have the title that the RfC gives it).

What about other reliable sources? The Library of Congress calls it Tagged and notes that both Tag and Tagged are in circulation, and that the title page of the 1992 specification does not spell out the abbreviation. It goes on to cite Wikipedia, at which point we should probably consider the issue of WP:CITOGENESIS. Wikipedia is influential. Perhaps our longstanding use of Tagged has influenced this page.

The UK National Archives unequivocally calls it Tagged. Other notable organisations in the Tagged camp include Mozilla, NASA, Microsoft, and Apple

But wait, Apple are also in the Tag camp, as are Microsoft.

What about a broad survey of general usage? I see 646,000 Google search results for "Tagged Image File Format" and 75,100 for "Tag Image File Format". Google Scholar returns 19,500 and 2,990 respectively.

What about Wikipedia readers? Page view analysis shows that readers overwhelmingly use the Tagged Image File Format redirect rather than the Tag Image File Format redirect.

What about the plain sense or style of the thing? To my ear, "Tagged Image File Format" makes a lot more grammatical sense than "Tag Image File Format". What's a tag image anyway?

In conclusion, I think that while Tag was clearly once the official usage, subsequent spec revisions have not endorsed this and there is now no official usage. In terms of common usage in sources, I think there is clear evidence that both usages are valid, with Tagged perhaps edging ahead due to its far greater usage in scholarship and being more grammatically sensical.

How to handle this in the lead sentence? We could write Tag/Tagged Image File Format, or Tag(ged) Image File Format, or perhaps omit any expansion of the acronym, but my preference would be to return the article to its longstanding pre-2020 lead and simply write Tagged Image File Format. The history of the name can come later in the article body. Barnards.tar.gz (talk) 23:00, 3 November 2023 (UTC)[reply]

Thank you for your research! It is definitely more complicated than I realized. I would like to see both versions in the TIFF article because they are both used (WP:COMMONNAME). However, I think it would be awkward to use both on other pages. I would defer to using the article's name, "TIFF", which is neither "Tag Image File Format" nor "Tagged Image File Format". So maybe other pages should say merely "TIFF". (The TIFF article's name is not written in stone of course; you could propose a page move.)

FWIW, I think of "tag image" vs. "tagged image" to be similar to "color image" vs. "colored image"; all sound good to my ear and they are fine in their respective contexts. But I don't see it as all that relevant what your ear or mine says. More importantly, we need to look to WP:COMMONNAME and similar policies. —

Q

uantling (talk | contribs) 02:00, 4 November 2023 (UTC)[reply]

Talk archive

There is a fairly large archive for this Talk page at Talk:TIFF/Archive 1, but there is no link at the top of this page to guide the reader to it. Can somebody fix this? GrindtXX (talk) 12:11, 4 November 2023 (UTC)[reply]

OK, I've added a Talk header template, which seems to have fixed the problem. GrindtXX (talk) 13:19, 5 November 2023 (UTC)[reply]

[1] 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.

[1]