- 2016.10.24 06:41 "[Tiff] Question regarding tag StripOffsets when there is only one strip", by Recursive
- 2016.10.24 18:43 "Re: [Tiff] Question regarding tag StripOffsets when there is only one strip", by Paavo Helde
2016.10.24 14:54 "Re: [Tiff] Question regarding tag StripOffsets when there is only one strip", by Recursive
On 24.10.2016 13:01, Paavo Helde wrote:
> The TIFF standard does not say that StripOffsets is an offset to a table. Instead, it says:
> = 273 (111.H)
> Type = SHORT or LONG
> For each strip, the byte offset of that strip.
> So indeed, if these values fit in 4 bytes they are written directly in the IFD entry.
Thank you very much. That's exactly what I wanted to know. I already had understood it that way, but I wanted to be sure.
>> I just would like to know if I got this right, i.e. if I really need to implement a special treatment for images with only one strip (or two strips, depending on the type of the offsets). Of course, there are analogies to other tags (StripByteCounts, TileOffsets and so on), so this question is generally about how to handle tables when there is only one table entry.
> You do not need to write special treatment for StripOffsets. Instead, you implement a general IFD entry reading function which for each IFD entry just calculates size-of(field type)*(field count) and then reads the data either from directly the IFD entry or from an offset, without any attention to the TIFF tag value.
You are right. I have chosen the wrong words. The problem indeed is a general one (but I still had a bad feeling especially about the strip (or tile) handling because there are practically no images with only one strip, and in this case it would be especially logical to put all data into a table pointed to by an offset in *every* case). But thanks to your statement, I now know that the "4-byte-rule" is applied without any exceptions.
> In practice, I strongly suggest not to write your own TIFF processing code, but rather rely on libTIFF instead. There are lots of quirks and variations (e.g. BigTIFF) and the libTIFF implementation is the de facto standard.
I have to do some operations on TIFF files which LibTIFF obviously can't do, nor can any of the tools or programs I am aware of. I have dedicated several days to searching and testing all sorts of freeware, shareware and open source software under Windows and Linux, a big part of them using LibTIFF under the hoods, but to no avail. So writing my own software is my last option.
By the way, the TIFF specification is not too bad, is it? I had no serious problems with understanding it (at least the parts which I believe are important for solving my problem). I don't need to support BigTIFF, and I'll have a co-worker test the software for several days, hoping that she is able to find many sample multi-page TIFF files of all sorts on the net.
Thank you very much again,