AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2005.05.20 16:08 "[Tiff] TIFF/EP and TIFF 6.0", by Bob Young
2005.05.20 16:29 "Re: [Tiff] TIFF/EP and TIFF 6.0", by Steve Carlsen
2005.05.20 17:28 "RE: [Tiff] TIFF/EP and TIFF 6.0", by Bob Young
2005.05.20 17:43 "RE: [Tiff] TIFF/EP and TIFF 6.0", by Steve Carlsen
2005.05.20 18:48 "RE: [Tiff] TIFF/EP and TIFF 6.0", by Bob Young
2005.05.20 16:43 "Re: [Tiff] TIFF/EP and TIFF 6.0", by Joris Van Damme
2005.05.20 18:30 "RE: [Tiff] TIFF/EP and TIFF 6.0", by Bob Young
2005.05.24 10:15 "Re: [Tiff] TIFF/EP and TIFF 6.0", by Joris Van Damme

2005.05.24 10:15 "Re: [Tiff] TIFF/EP and TIFF 6.0", by Joris Van Damme

Bob,

Okay, thanks for the explaination. I may have been a bit inaccurate in my termnology, I'm looking at the TIFF/EP spec right now and it appears to rcommend the thumbnail be in IFD0 and the main image be a SubIFD. Here is the exact quote from the spec:

Therefore, if the full-resolution image is stored using compression, the TIFF/EP file should include a thumbnail image stored in the 0th IFD that is readable by a baseline TIFF 6.0 reader. This thumbnail should not be compressed, and should be stored in strips, rather than in tiles, in order to be fully compatible with TIFF 6.0. A SubIFDs tag in the 0th IFD is used to point to the compressed full-resolution image. If the full-resolution image is stored uncompressed as a baseline-readable TIFF image, the full-resolution image could be stored in the 0th IFD. However, TIFF/EP recommends that a thumbnail image be stored in the 0th IFD, regardless of whether the full-resolution image is baseline TIFF readable or not. This provides a version of the image that is small (relative to the full-resolution image) and that may be quickly accessed by reader software. The use of the SubIFDs tag is the TIFF recommended method of performing this "treeing" mechanism.TIFF/EP requires that the SubIFDs "treeing" mechanism be used, rather than the "chaining" mechanism, to associate multiple resolution versions of the same image.

First off, I would like to note that if people start using descriptions such as '0th', all hell breaks loos. 0th is not even a word. The first whatever in a series, is called first, is called 1st. First is first, second is second. Now, we might decide to label the first with a number 0, and the second with a number 1, but still, the first is the first, and still there is no 0th. If people start to use '0th' nevertheless, we need to be aware of their particular convention to be able to interpret whether they mean first or second when they say 1th.

In my previous mail, I said the 'real image' should be in the main chain. Differently sized versions should be in the SubIFDs. However, 'real image' is a bit of a weird, and probably very bad description of what I meant... Perhaps we should rather talk about 'standard' or 'base' image or something...

An example of what is *not* relevant, from a pragmatic point of view, is when a DNG-aware reader reads a DNG TIFF image. The reader is DNG aware, therefore it should be able to recognize the situation perfectly. However, suppose next you feed this DNG image to a naïeve, general-purpose, non-DNG aware image browser. If the standard would have defined the camera raw image to be the 'base' one, DNG files would be unreadable by these image browsers. They would encounter a Photometric like 'Color filter array', and would stop being able to make sense of it. However, by defining the lower resolution version as the 'base' one, these browser still make sense of the file, as if it were a perfectly normal TIFF...

A similar reasoning seems to be applied in the quote of the TIFF/EP spec that you have provided. However, in my opinion, it is a bit strong... One shouldn't suppose that presenting anything but a very small sized uncompressed baseline version as the 'base' is bad. That 'overprotective' towards general-purpose readers, resulting not in interchangeable files, but in files that can hardly be usefully viewed or otherwise processed by these general-purpose readers. Personally, if storing say a 2000*2000 pixels raster, and a 200*200 thumbnail, I would pick the 2000*2000 version to be the 'base' for general-purpose interchange, not the thumbail. However, if, say, I need to store a complete tile pyramide of an image whose biggest ('real') size is 200.000*200.000, then, I would be inclined to not set the biggest image as the main 'base' image in the main IFD chain, but use a downsample there instead...

So....why did Photoshop open the thumbnail, if IFD0 was clearly marked as the reduced resolution image and there was a SubIFD comtaining the main image, and the file was clearly a TIFF/EP file contaning a TIFF/EPStandardID tag?

Does Photoshop not support TIFF/EP?

Photoshop's behaviour is compatible with my reasoning in previous mail, and the above note. But I am not familiar with TIFF/EP in particular, nor with Photoshop's rationale behind this behaviour, and couldn't say more about it...

In regards to my second question, I believe the above quote indicates that I can't use a YcbCr thumb if it is placed in IFD0 per TIFF/EP, as YcbCr is not readable by a baseline TIFF 6.0 reader

To your full statement 'can't use... per TIFF/EP', that seems to be correct. However, an YCbCr thumb placed a SubIFD is perfectly legit according to the TIFF spec, whatever Photometric and compression any other IFD has.

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html