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 03:22 "Re: IFD / Image data ordering", by Niles Ritter

Brian,

Good question; if anyone has done it and has source, let me know, so I can put links to it on my web page and see that it finds it way into

the "libtiff" baseline (though more likely as a "utility" and not a
patch
of the standard IO package).

In general, "forward-only" TIFF will only survive until the next time it is edited by a TIFF compatible image processing program. 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.

As I read the RFC 2301 spec, it looks like you have more than one challenge, because not only does it say that the offsets SHALL be written out with forward-only IFD pointers, but the byte-order of the file SHALL be little-endian (Intel), so if your code is supposed to run on a Mac or a Sun/Solaris motorolla chip, you'll need to do even more work. It even requires that the Tag values that are too big to fit into the 4-byte TagEntry field be placed *after* the tag entry, and that in fact any offset must only point forward.

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).

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

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...

  --Niles