home *** CD-ROM | disk | FTP | other *** search
/ Internet File Formats / InternetFileFormatsCD.bin / graphics / tiff / unix / archive.z / archive / text0046.txt < prev    next >
Encoding:
Text File  |  1995-09-20  |  1.9 KB  |  45 lines
  1.     To:  kg@mykonos.rc.rit.edu (Kyriakos Georgiou)
  2.     Subject:  Re: JBIG compression
  3.     Cc:  sam@cthulhu.engr.sgi.com, tiff@sgi.sgi.com
  4.     Date: Fri, 16 Dec 1994 16:04:19 CST
  5.     From:  rick@digibd.com (Rick Richardson)
  6.  
  7.     Kyriakos Georgiou writes...
  8.     > 
  9.     > In response to Sam's comments:
  10.     > 
  11.     > >     Also, can the current libtiff G4 decompression implementation be
  12.     > >     improved ? What sort of improvements can be expected ?
  13.     > > 
  14.     > > What's wrong with the current implementation?
  15.     > 
  16.     > The current implementation is fine, but.. I have in my hands a commercial
  17.     > product (no source) that does decompression in noticable less time.
  18.     > That suggests that there are faster ways to decompress G4 in software,
  19.     > alas my question.
  20.     
  21.     I cannot speak for the G4 decompression in libtiff, but I can vouch for the
  22.     fact that the libtiff G3 decompression is not as fast as at least my own
  23.     implementation.  However, I am not at liberty to provide the source code
  24.     since it belongs to my employer.
  25.     
  26.     In my experience with G3, I found the fastest way was to completely unroll
  27.     the decompression.  I tried numerous different 'elegant' algorithmic
  28.     approaches over a period of about 3 years and discovered that the simple
  29.     brute force unrolled approach was always fastest.  The decoder itself is
  30.     something like 700 lines of nested C language if-else statements.
  31.  
  32. The algorithm that Peter Deutsch uses in the 3.x versions of
  33. Ghostscript are similar to the algorithm you seem to be describing.
  34. My feeling on all this is that the current decoder in the library is
  35. reasonably portable and plenty fast enough for most people's needs.
  36. Until it's not, I have no motivation to change it.  I'd welcome a
  37. replacement for it.  I'd also welcome some good performance analysis
  38. of the existing code.  I wouldn't stop with the G3/G4 decoder however,
  39. hit the other ones too! (I'm sure folks would like a faster LZW decoder
  40. too.)
  41.  
  42.     Sam
  43.  
  44.  
  45.