LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
June 2010
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
2010.06.24 15:54 "Re: LZMA2 codec for libtiff", by Bob Friesenhahn
On Thu, 24 Jun 2010, Andrey Kiselev wrote: > > On my typical data it is much worse than LZMA. Actually I do not see a reason > to use it because of worse compression ratios. I am talking about libtiff usage > here, of course bzip2 utility is widely adopted as a general purpose > compressor and LZMA stuff is not on par here. When you compared LZMA with bzip2, did you do it by compressing whole image files? What type of images are you testing with? ImageMagick and GraphicsMagick support bzip2 compression in the "MIFF" file format. Compression is done on a per-row basis without any modification via a 'predictor'. This makes it a good test case for bzip2 compression. > If we want to bring some new codec in libtiff world we need something that has > clear advantage over the existing ones, either compression ratio or something > other (decomression speed, like Bob mentioned). What I am looking for is well-balanced compression/decompression so that TIFF can be used as a working format while still using compression. Testing with certain filesystems which implement fast compression (my testing is done with zfs) shows that I/O can be faster with the compression than without. It is not always desireable to use a compressing filesystem so offering similar compression in libtiff could offer the I/O and storage benefits of compression without dependence on an OS feature. Compressors exist which are capable of compressing over 100MB/second on current CPUs. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/