[mapserver-users] Image Speed Questions---Generic

[Richard Greenwood]

Hello List,

Ed McNierney sent this reply to me in which he explains strips and rows in 
TIFF files. I found his explanation useful and informative. Since I did not 
see it come thru the list, I thought I'd forward it.

Rich

>Each TIFF file is made up of one or more strips, each of which contains
>one or more rows.  Files with lots of rows per strip are smaller (under
>any compression method) while files with few rows per strip are faster.
>That's because the strip needs to be read from its beginning in order to
>find any row inside it.  This is pretty insignificant for uncompressed
>TIFFs, because the location of any row start inside a strip can be
>readily calculated, and the file read pointer moved right there.
>
>For compressed TIFFs (packbits, lzw, or other) this is more of a
>problem.  Each strip is compressed as a single block of data, and
>(especially with LZW) you can't just jump to the start of data in the
>middle of a compressed block.  You need to actually start uncompressing
>the whole strip starting from the beginning until you generate the
>appropriate number of output bytes to get you to the start of your
>desired row.  THEN you can decompress and read your data.
>
>The worst possible case is if you need the last row of a single-strip
>TIFF/LZW file.  The entire file needs to be read from disk AND
>decompressed in order to get your data.  For a typical topo map, that's
>reading and decoding some 7,000 rows just to figure out the starting
>point of the last row!
>
>LZW vs. packbits is a tricky question - it depends.  LZW compression is
>more compute-intensive, but it uses computation that modern, fast
>processors do well.  If you have a fast CPU, that's a point in LZW's
>favor.  If you have a slow disk, that's in LZW's favor, too, because
>you'll need to read less from the disk.  This is particularly true for a
>non-SCSI disk.  You should look carefully at your data set, too.  Aerial
>photos (DOQQs) are pretty incompressible under any of these methods, and
>you're better off just leaving them uncompressed.  For DRGs, LZW
>compression produces files that are about 1/3rd the size of PackBits
>compression, and (with a fast CPU) the tradeoff is certainly worth it.
>
>Look at http://www.remotesensing.org for the libtiff and libgeotiff
>projects.  They'll give you all the tools you need to fiddle with TIFFs.
>
>         - Ed
>
>Ed McNierney
>Chief Mapmaker
>TopoZone.com
>ed at topozone.com
>(978) 251-4242
>
>
>-----Original Message-----
>From: Richard Greenwood [mailto:Rich at GreenwoodMap.com]
>Sent: Tuesday, July 31, 2001 1:48 PM
>To: Ed McNierney
>Subject: RE: [mapserver-users] Image Speed Questions---Generic
>
>
>Ed,
>
>Thanks for your excellent discussion of image speed issues. I was with
>you
>for about the first 2/3, but you lost me when you went over the various
>stripping options. How would you go about determining how many rows and
>strips your tiff file had? What tools would you recommend for altering
>tiff
>file formats? What about LZW compression; what effect does that have on
>performance issues?
>
>Thanks for sharing your expertise.
>
>Rich
>
>Richard W. Greenwood, PLS
>Greenwood Mapping, Inc.
>Rich at GreenwoodMap.com
>(307) 733-0203
>http://www.GreenwoodMap.com