2007.01.15 15:12 "[Tiff] TiffOpen opens file too long", by Tomasz Bywalec

2007.01.15 16:06 "Re: [Tiff] TiffOpen opens file too long", by Tomasz Bywalec

I compiled libTiff 3.8.2 library for PocketPC platform, using Visual C++ 2005 compiler (with optimalization turned on). I use it to open quite large (about 12000x8000) black-and-white images. I noticed that TiffOpen spends about 2 seconds just opening the file and reading it's directory (reading and decoding stripes is much faster, so I think that it's not because of slow I/O or something like that). With option 'h' (read header only), TiffOpen returns almost immediately, so I suppose that it spends so much time on reading file's first directory. And here's my question - is it possible to speed up the execution of TiffOpen (including: opening the file and reading it's directory), in that case?

Just in case - images, which my program reads, are usually divided in stripes, each having height of about 30 pixels (so file consists of few hundred stripes).

Is it possible there are huge tags in there? Can you show us a tiffdump, tagdump, tag viewer dump, or anything that would allow us to correlate the problem with the particular TIFF features?

Thanks for your reply - tiffdump of one of these tiffs is as follows:

first_file.tif:
Magic: 0x4949 <little-endian> Version: 0x2a
Directory 0: offset 8 (0x8) next 0 (0)
SubFileType (254) LONG (4) 1<0>
OldSubFileType (255) SHORT (3) 1<1>
ImageWidth (256) SHORT (3) 1<12743>
ImageLength (257) SHORT (3) 1<8096>
BitsPerSample (258) SHORT (3) 1<1>
Compression (259) SHORT (3) 1<4>
Photometric (262) SHORT (3) 1<0>
FillOrder (266) SHORT (3) 1<1>
DocumentName (269) ASCII (2) 5<NONE\0>
StripOffsets (273) LONG (4) 405<3790 4428 5060 5678 6480 7240 7730 8382
9074 9738 10572 11374 11924 12364 12648 13052 13460 13790 14078 14282
14482 14766 15094 15356 ...>
Orientation (274) SHORT (3) 1<1>
SamplesPerPixel (277) SHORT (3) 1<1>
RowsPerStrip (278) LONG (4) 1<20>
StripByteCounts (279) LONG (4) 405<638 632 618 802 760 490 652 692 664
834 802 550 440 284 404 408 330 288 204 200 284 328 262 256 ...>
XResolution (282) RATIONAL (5) 1<400>
YResolution (283) RATIONAL (5) 1<400>
Group4Options (293) LONG (4) 1<0>
ResolutionUnit (296) SHORT (3) 1<2>
Software (305) ASCII (2) 35<TSL Raster Converters, V ...>
DateTime (306) ASCII (2) 20<2006:04:12 11:21:16\0>

33550 (0x830e) DOUBLE (12) 3<0.03175 0.03175 0> 33922 (0x8482) DOUBLE (12) 6<0 0 0 6.50831e+006 5.7085e+006 0> 34735 (0x87af) SHORT (3) 24<1 1 0 5 1024 0 1 32767 1025 0 1 1 1026 34737 28 0 3076 0 1 9001 3077 34736 1 0>

34736 (0x87b0) DOUBLE (12) 1<1>
34737 (0x87b1) ASCII (2) 29<Non Geodetic 2D (TSL met ...>

As you can see, there are lot of strips. There are also some strange tags at the end, but - if I read this dump correctly - these don't take too much space.

I don't know exactly how libTiff works - is it possible that it prefetches some (or all) of image data during TiffOpen, or does it read data from file only when necessary (for example, when I call TiffReadEncodedStrip)?

When I was trying to compile libTiff for PocketPC, I've had to made one little "fix" - standard C library for PocketPC which is included in my Visual C++ doesn't contain bsearch function. I fixed it in that way that I copied it from CRT library source code and pasted into some file in LibTiff which needed that function. There were some macros doing argument checks at the beginning of function - however I just removed them and compiled the library. And it works quite good :) (at least, I've never seen any core dump made by libTiff :) - however, maybe it could be the reason?

Again, thanks for your reply, Joris!

Greetings,

Tomasz Bywalec