Message-ID: 39E2E0BF.39401448@office-logic.com
To: Niles Ritter <ritter@earthlink.net>
Subject: Re: IFD / Image data ordering
From: Brian Stafford <brian.stafford@office-logic.com>
Date: Tue, 10 Oct 2000 09:26:24 +0000
CC: TIFF Mailing List <tiff@olympiakos.com>
Organization: OfficeLogic International Ltd
References: <39E19CC2.3DBDF747@office-logic.com> <39E28B62.2D9F8262@earthlink.net>
Sender: owner-tiff@olympiakos.com


Niles,

thanks for your response.  A few observations and thoughts follow.

Niles Ritter wrote:
> 
> Brian,
> 
> In general, "forward-only" TIFF will only survive until the next time
> it is edited by a TIFF compatible image processing program.

Agreed.  The RFC 2301 application of TIFF though, is to prepare image
data for MIME encoding and transfer via RFC 821/822 et al. electronic mail.
The applciations that depend on the RFC 2301 profile of TIFF will only
be present at the receiving end of the mail transfer.  Beyond this point
any additional TIFF processing could be done by any TIFF 6.0 application,
however if a TIFF were to be resubmitted as an internet fax, it will need
to be reprocessed into an RFC 2301 profile TIFF if the application has not
already written it in that format.

> The TIFF
> spec requires all TIFF readers to make no assumptions about the
> location of data in the file, and so there is little incentive for TIFF
> writers to go through all that additional work for nothing.

Yes, unfortunately an RFC 2301 reader is not necessarily a TIFF 6.0
reader, however a RFC 2301 writer *IS* a TIFF 6.0 writer.  Because of some
of RFC 2301's goals (i.e. limited memory devices) a conscious decision
was made to simplify the design of the reader at the expense of complexity
in the writer.

> 
>   It is pretty tricky to do, because you first have to write out the
> entire TIFF image directory, and then the compressed data, and then
> go back and update the StripByteCount and StripOffset tags with
> the corrected values, and then update the NextIFD offset to point
> to the next Image IFD.  It is probably a lot easier to do if a
> normal TIFF file has already been generated, because then you
> already know the bytecounts of the raw compressed data, and
> its just a matter of shuffling bytes around (taking care to put
> them on word-aligned boundaries of course).

I agree.  I started off with my own TIFF implementation which suffered
the same limitations that the libtiff does in this respect.  My motivation
for changing is the stability of the code base and flexibility of libtiff
in other respects, e.g. the wide range of available codecs.

FWIW, here are my thoughts on writing an RFC 2301 compliant TIFF.

It should be possible to make a preliminary pass over libtiff's internal
representation of the IFD and estimate the space required in the file
to contain the IFD and those tags too big to be written within the IFD.
Then, seek forward by that amount and write the compressed image data.
When this is done, seek back and write the IFD and tags.

I'm pretty certain that if this functionality were to be incorporated into
libtiff it would have to be done as an option or a set of APIs parallel to
the existing ones for writing (I'd go for the latter).  There would be
constraints when writing forward reference only TIFFs which are not relevant
when ordering doesn't matter, e.g. if image length is unknown prior to
writing and the image is to be split into multiple strips or tiles, the
size of the StripByteCount etc. tags will be unknown.

I currently lack the familarity with the internals of libtiff to do any
coding of this kind, however if any help/expertise is forthcoming in this
respect I will contribute what I can.

> 
>   Thanks for the pointer to the RFC; I did not know this RFC existed,
> but will put a link into my TIFF web page to the thing. For those
> interested, look at any of your favorite RFC indexes, such as:
> 
>     http://www.csl.sony.co.jp/cgi-bin/hyperrfc?2301

You might also want to have a look at draft-ietf-fax-tiff-fx-07.txt
available from
   http://www.ietf.org/internet-drafts/draft-ietf-fax-tiff-fx-07.txt
This defines new tags etc. for use with additional codecs such as JBIG
(ITU T.85), JBIG color (ITU T.43) etc. which are not in TIFF 6.0.
Presumably these will become part of TIFF 7.0 since the tags for these
additional fields are registered with Adobe.

> 
> It is also encouraging to see Adobe tech support people contributing
> to RFC specs on TIFF as late as 1998.  It may well wind up that
> TIFF 7.0  will appear in the form of an RFC...

AFAIK, the Adobe folks are still active in the IETF FAX WG.

I think that the Adobe document series will continue to be the official
TIFF spec and the RFC series will define a profile of the official spec.
for use in internet fax.

--
Brian Stafford, OfficeLogic International Ltd.
PGP fingerprint: 23DE 0A02 95B2 EC3C D521  0CD1 97D8 6BF2 B673 DC11

