2008.11.21 20:18 "[Tiff] Patch Legacy App for Updated libtiff?", by Kevin Myers

2008.11.22 14:34 "Re: [Tiff] Re: LZW compression in your legacy app", by Toby Thain

On 21-Nov-08, at 11:10 PM, Kevin Myers wrote:

If they are 'naturally noisy' like photographs then LZW would not help much either.

--Toby

My images consist primarily of *technical* documents that are *originally* created using a relatively *limited* number of colors.

  1. None of the images discussed here are really like photographs of natural scenes.
  1.  In a "clean" image such as those generated directly by computer, there are reasonably large areas that consist of single colors, and there are also a lot of repeated color patterns for grid lines, etc. LZW compresses those kinds of image features fairly effectively. So I don't need to do much for those iimages beyond palettizing, as discussed earlier in this thread.

Gotcha.

  1.  The scanned images are much more difficult to handle. As you noted, LZW won't have much success on images with seemingly random color variations. That is why an appropriate color reduction algorithm is extremely important
  1.  Now the problem is just how to go about achieving or approaching such an ideal color reduction. I have already tried a number of color reduction algorithms in various graphics applications (e.g. GIMP, Corel, GraphicsMagick) with relatively limited success on the scanned images. The reduced color images were generally either very poor representations of the original colors, or did not reduce the number of colors enough to have the desired impact on compressibility of the images.

Dithering will affect compressibility. Obviously compression would be much greater if simple quantisation to the new palette is done, rather than error diffusion, but I am sure you know that. You could also try ordered dither.

  1. Most of the algorithms that I tried either appeared to be too simplistic (e.g simple bit depth reductions), or placed too much emphasis on color occurance frequency as opposed to color space distance.
  2. I am working on an algorithm at the present time that I believe might work somewhat better. Although I have done some full time development work in the past, it was with 4GLs, and not too helpful for the much lower level C coding that needs to go into writing an efficient color reduction algorithm. And efficiency *is* quite important when dealing when multi-hundred megapixel images containing millions of distinct colors!

Colour reduction is a fairly sophisticated process, indeed. Your case is also complicated by the need to process incrementally.

If that weren't a factor, then this is an interesting solution: http://members.ozemail.com.au/~dekker/NEUQUANT.HTML

--Toby