AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2000.10.09 10:24 "IFD / Image data ordering", by Brian Stafford
2000.10.10 03:22 "Re: IFD / Image data ordering", by Niles Ritter
2000.10.10 06:09 "Re: IFD / Image data ordering", by Tom Lane
2000.10.10 08:29 "Re: IFD / Image data ordering", by Martin Bailey
2000.10.10 08:41 "Re: IFD / Image data ordering", by Brian Stafford
2000.10.10 10:39 "Re: IFD / Image data ordering", by Andreas R. Kleinert
2000.10.10 09:26 "Re: IFD / Image data ordering", by Brian Stafford

2000.10.10 09:26 "Re: IFD / Image data ordering", by Brian Stafford

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