AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

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



Valid HTML 4.01!



Thread

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

2005.05.20 16:43 "Re: TIFF/EP and TIFF 6.0", by Joris Van Damme

Bob,

> TIFF/EP recommends the thumbnail be described by IFD0,
> and TIFF6 requires that IFD1 be used, as IFD0 must be the main image.

Neither of these is good. In my opinion, neither of these conforms to the most
current specification, which should mean to include supplement 1 on the SubIFDs
tag. Also, in my opinion, neither of these works.

For a full list of pointers to what is regarded the current specification, see:
http://www.awaresystems.be/imaging/tiff/faq.html#q4

Seperate IFDs in the main IFD chain should be independent on any level. That
means there is no place of a set of 'global' tags that should apply to all IFDs,
for example (thus GlobalParametersIFD tag is a problem), but it also means there
should be no 'meaningfull' relationsship between the IFDs in the main chain. The
necessity for the last part can be understood from two different angles.

From the storage point of view, the 'page' relationship is the highest. Suppose
you have two images, both consisting of two layers. You wouldn't describe this
as two layers both consisting of two pages or something, that's a whole other
piece of meat. The 'highest' relationship between rasters is therefore the
'different page' relationship, and the highest level of TIFF, the main IFD
chain, should start at that point. Looking at the same thing from a negative
point of view, suppose you would encode a big image and a thumbnail as different
IFDs in the same main chain. You build two such files, different images. Next
your customer says 'but TIFF is multi-page, I want a single file with exactly
that. Sorry, your reader must be build to interpret the highest IFD chain as
differently sized versions of the same image, so there's no way you can still
put meaning to the multi-page part.

From the reader point of view, as in image browser or image editor or such, you
have the same need to standardize the 'upper level of relationships'. If vendor
A codes different fax pages in a multi-page TIFF, and vendor B codes different
layers of the same image in the same way, then general image browsers loos the
capability to present anything meaningfull. TIFF becomes no longer meaningfully
interchangeable, you'd have to first agree with the receiving party on how to
interpret the upper level of storage.

One more spicy detail... Suppose different rasters are different layers of a
same image. You'd have to know something more in order to meaningfully make
sense of the bunch, like what their different relative coordinates are, what
blending modes are used, etc. So there's surely data that is meaningfully
related to the bunch as a while, most probably, too. That's impossible to store
without a parent IFD, remember that no tag in no IFD can have any meaning inside
the scode of a sibling IFD.

This is all why the specification supplement 1 adds the SubIFDs tag. In short,
it became clear the concept of 'IFD tree' was necessary. The proper way to store
a downsample of an image is to store it as a SubIFD. The meaningfully 'real'
image is the IFD in the main chain, the other or others is/are regarded as
differently sized versions of the same if they have proper SubFiletype value.
Therefore, the meaningfull 'real' width and height of the 'page' is the the
width and height of the image in the main chain, not of any SubIFD. This is the
reason for your following observation:

> but I was surprised to
> find that when I opened a TIFF/EP image (denoted by having a
> TIFF/EPStandardID tag in IFD0) in PhotoshopCS, it displayed the
> thumbnail instead of the main image.

Photoshop CS follows the above reasoning, and thus the image in IFD0 is regarded
a seperate page. Without any specific hacks (I'm not aware if there are or are
not), Photoshop CS would have to regard the second image as an unrelated second
page. (Photoshop 6 would simply ignore, being able to handle only the first
page, I'm no longer up to date as to newer versions.)

> I would have thought that if any
> APP were TIFF/EP "Aware" it would have been Adobe.

It's TIFF/EP convention is simply conflicting with the only possible convention
that is logically solid.

> Secondly, regardless of whether the thumb is placed in IFD0 or IFD1, is
> it legal for the thumb to be of a different photometric interpretation
> than the main image, specifically can I use a YCbCr thumb with a RGB
> main image?

Yes, you can.



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