Return-Path: <tiff-bounces@remotesensing.org>
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx005.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id j4KIVFah017001
        for <joris.at.lebbeke@skynet.be>; Fri, 20 May 2005 20:31:21 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id 40D352581957; Fri, 20 May 2005 14:30:37 -0400 (EDT)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from mail.nucoretech.com (mail.nucoretech.com [12.146.132.130])
	by xserve.flids.com (Postfix) with ESMTP id DB82D258193A
	for <tiff@remotesensing.org>; Fri, 20 May 2005 14:30:34 -0400 (EDT)
Received: from paris ([192.9.200.83])
	by mail.nucoretech.com (8.13.1/8.13.1) with SMTP id j4KIUT6T032661
	for <tiff@remotesensing.org>; Fri, 20 May 2005 11:30:32 -0700
From: "Bob Young" <BYoung@nucoretech.com>
To: <tiff@remotesensing.org>
Subject: RE: [Tiff] TIFF/EP and TIFF 6.0
Date: Fri, 20 May 2005 11:30:29 -0700
Message-ID: <FAEEIJPAOFEMBBLKPMJEIEBKCMAA.BYoung@NuCORETech.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
In-Reply-To: <001801c55d5a$ff9fcdf0$9ebbf551@dfgrrxsknr4e>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: 000000000023ceae.0000022f
X-MSP-STORE: Fri, 20 May 2005 20:31:49 +0200
Status:   

Joris,

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.

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?

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


-----Original Message-----
From: tiff-bounces@remotesensing.org
[mailto:tiff-bounces@remotesensing.org]On Behalf Of Joris
Sent: Friday, May 20, 2005 9:43 AM
To: Bob Young; tiff@remotesensing.org
Subject: Re: [Tiff] TIFF/EP and TIFF 6.0

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

_______________________________________________
Tiff mailing list: Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/


_______________________________________________
Tiff mailing list: Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
