LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
January 2007
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2007.01.15 16:06 "Re: TiffOpen opens file too long", by Tomasz Bywalec
Joris wrote: > Tomasz, > > Tomasz Bywalec wrote: > >> 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? > > > Best regards, > > Joris Van Damme > info@awaresystems.be > http://www.awaresystems.be/ > Download your free TIFF tag viewer for windows here: > http://www.awaresystems.be/imaging/tiff/astifftagviewer.html > 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