LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
November 2008
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
2008.11.22 14:34 "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 >> > > Hi Toby, > > My images consist primarily of *technical* documents that are > *originally* created using a relatively *limited* number of > colors. ... > > None of the images discussed here are really like photographs of > natural scenes. ... > > 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. > > 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 ... > > 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. > 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. > > 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