home *** CD-ROM | disk | FTP | other *** search
/ Internet File Formats / InternetFileFormatsCD.bin / graphics / tiff / unix / archive.z / archive / text0016.txt < prev    next >
Encoding:
Text File  |  1995-09-20  |  1.7 KB  |  47 lines
  1. Greetings,
  2.  
  3.  
  4.     This message concerns the time it takes to retrieve individual
  5. images from a multiple-directory (50-100 entries) TIFF image.
  6.  
  7.     We are presently constructing a database of small (less than 1K,
  8. uncompressed) TIFF images.  We have approximately 180,000 images.
  9. Applications which use this database generally work by retrieving a
  10. large fraction of the images.  We have found that the overhead
  11. incurred by storing each image in a separate file affects other users
  12. of the disk and cpu---there is too much I/O.  We are investigating
  13. alternatives to this organization.
  14.  
  15.     A natural idea is to divide the database into fewer files, say
  16. 3500, and utilitize the directory facilitites of TIFF to store many
  17. images in a single file.  The advantages of this (over manually
  18. concatenating the files and devising an index/retrieval scheme), is
  19. that the TIFF{Read,Write,Set}Directory() routines in libtiff make it
  20. very simple and convenient to implement.
  21.  
  22.     However, we have discovered that this solution, while reducing the
  23. I/O overhead, on average at least doubles the retrieval time.
  24. TIFFSetDirectory() seeks from the first directory; it does not jump
  25. immediately to the desired directory.  It turns out to be faster to
  26. just read the desired image directly off the disk.
  27.  
  28.     We are thus discouraged from using the directory facilities as we
  29. understand them.
  30.  
  31.  
  32.     We would greatly appreciate your input on the following:
  33.  
  34.     *  Is there a way to increase the speed of the directory access
  35.        routines without modifying libtiff?
  36.  
  37.     *  Are there other features of libtiff that we can use instead of
  38.        directories?
  39.  
  40.     *  Do you have any other suggestions?
  41.  
  42.  
  43.  
  44. Thank you,
  45. Victor Zandy
  46.  
  47.