AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

1999.11.30 22:23 "libtiff 3.5.3 release.", by Michael L. Welles
1999.11.30 22:53 "Re: libtiff 3.5.3 release.", by Izumi Ohzawa
1999.11.30 23:07 "Re: libtiff 3.5.3 release.", by Tom Lane
1999.12.01 00:08 "Re: libtiff 3.5.3 release.", by Michael L. Welles
1999.11.30 23:22 "Re: libtiff 3.5.3 release.", by Daniel McCoy
1999.12.01 13:56 "Re: libtiff 3.5.3 release.", by Bruce Cameron
1999.12.01 18:35 "Re: libtiff 3.5.3 release.", by Daniel McCoy
1999.12.02 07:06 "", by Ruediger
1999.12.01 03:15 "Re: libtiff 3.5.3 release.", by Bob Friesenhahn
1999.12.01 16:04 "Re: libtiff 3.5.3 release.", by Michael L. Welles
1999.12.01 16:43 "Re: libtiff 3.5.3 release.", by Tom Lane
1999.11.30 23:07 "Re: libtiff 3.5.3 release.", by Martin Bailey
1999.12.01 14:08 "Re: libtiff 3.5.3 release.", by Bruce Cameron
1999.12.01 15:02 "Re: libtiff 3.5.3 release.", by Klaus Bartz
1999.12.01 16:17 "RE: libtiff 3.5.3 release.", by Peter Smith
1999.12.01 16:49 "RE: libtiff 3.5.3 release.", by Darrin Cardani
1999.12.01 19:20 "Re: libtiff 3.5.3 release.", by Chris Hanson
1999.12.01 14:33 "Re: libtiff 3.5.3 release.", by Andy
1999.12.01 14:42 "ZIP compression [was: libtiff 3.5.3 release.]", by Tom Kacvinsky
1999.12.01 15:24 "Re: ZIP compression [was: libtiff 3.5.3 release.]", by Leonard Rosenthol
1999.12.01 15:51 "Re: ZIP compression [was: libtiff 3.5.3 release.]", by Tom Kacvinsky
1999.12.01 18:04 "Re: ZIP compression [was: libtiff 3.5.3 release.]", by Bryan H. Maret
1999.12.02 05:16 "Re: ZIP compression [was: libtiff 3.5.3 release.]", by Leonard Rosenthol
1999.12.01 17:39 "Re: ZIP compression [was: libtiff 3.5.3 release.]", by Bryan H. Maret
1999.12.02 11:42 "Re: ZIP compression [was: libtiff 3.5.3 release.]", by Ivo Penzar
1999.12.06 20:42 "Re: ZIP compression [was: libtiff 3.5.3 release.]", by Andy

1999.12.01 16:49 "RE: libtiff 3.5.3 release.", by Darrin Cardani

In my experience, CCITT G3 and G4 perform well only for certain kinds of images. I can't define for you exactly what will and will not work well (maybe somebody else knows this?), but I do know that images with a lot of small, randomly placed features (like noise) will not compress well at all.

The huffman encodings used in CCITT compression are optimized for handwritten or typed letters and images. That is, the types of things that people usually fax to each other. So it's optimized for images where each scanline is similar to the one above it in terms of where the black and white runs start and how long they are. Using it on images that have Floyd-Steinberg type dithering, for example, will not work very well, in general. The error diffusion used in such algorithms often results in consecutive scanlines being extremely different from one another. Even patterned data, like a Stipple pattern, can cause the compressor to not work very well. You may still get better results than not compressing or compressing with RLE, but it won't be as good as images that have the characteristics for which it was designed.

In one implementation I did of CCITT compression, during testing I had a pointer bug where I was pointing to a random place in memory instead of to the image data. I was supposed to be compressing a 26 Meg bitmap. The resulting file was random noise, and was 192 Megs. Needless to say, I found and fixed the bug immediately! :-)

----
Darrin Cardani
dcardani@totalint.com