2008.05.26 19:32 "Re: [Tiff] beta2 release - predictors", by Edward Lam
Just I've been doing some testing with tiff 4.0 beta 2, and with predictors in particular. I've noticed that the following cases result in a larger compressed sizes when a predictor is used:
- 8/16-bit PixarLog (PREDICTOR_HORIZONTAL)
- 32-bit floating point LZW (PREDICTOR_FLOATINGPOINT)
- 32-bit floating point AdobeDeflate/Deflate (PREDICTOR_FLOATINGPOINT)
For PixarLog, I'm not sure it makes sense to create them out of 8 or 16-bit integer values in the first place so I'm not particularly surprised. It does result in smaller compressed sizes when 32-bit floating point is used.
However, for the 32-bit floating point cases, I would expect that PREDICTOR_FLOATINGPOINT would produce better compressed file sizes.
Mind you, I'm perhaps basing this too much on my single image test case, but I figure I'll throw it out there. Maybe someone will tell me that PREDICTOR_FLOATINGPOINT is not ready yet in libtiff. :)
Frank Warmerdam wrote:
> There are no earth shattering changes, but I have prepared a libtiff 4.0.0
> beta2. Mostly this is to roll in some changes based on an old coverity
> scan of libtiff, and to produce a new tarball I can pass off to coverity
> for analysis.
> Coverity produces a static code analysis tool that can identify bugs not
> easily discovered by code inspection, lint style tools, compiler
> warnings or
> runtime analysis with tools like valgrind. They kind provide free support
> for a variety of projects including libtiff. I, umm, failed to followup
> on their previous report some 12 months ago, but talking to their open
> project support fellow at PGCon this week got me off my duff and looking
> stuff. It's pretty sweet, and I'd like to see it become part of the
> libtiff release development and release process over time.
> If any of the other libtiff core developers would like access to the
> reports let me know.
> Anyways, beta2 is available at:
> Best regards,