LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
May 2005
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2005.05.24 10:15 "Re: 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