On 6 October 2011 06:44, Fathi Boudra fathi.boudra@linaro.org wrote:
On 6 October 2011 00:43, Mans Rullgard mans.rullgard@linaro.org wrote:
On 5 October 2011 18:35, Christian Robottom Reis kiko@linaro.org wrote:
On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
Debian/Ubuntu P are going to move to libjpeg8 by default making current package obsolete in the future.
Note that when we asked Darrell about this he questioned the performance benefits of version 8. Mans probably knows more.
There is no benefit to v8. v7 added support for the rarely/never used arithmetic coding option, left out of earlier versions due to patent issues. Since nobody uses this mode, supporting it is irrelevant. v8 only adds some experimental, non-standard coding options even less relevant to any real-world uses. What is relevant is, however, that v8 is significantly slower than v6 in the default configuration. I don't remember if this slowdown was present already in v7.
According to Bill Allombert, v8 support more image format
Yes, v8 (and v7) supports the arithmetic coding mode defined in the JPEG spec. Since nobody ever uses this, it is not important. If you mean more non-JPEG formats are supported by the cjpeg/djpeg tools, that is of little importance since nobody uses those in "production" either.
and provide a higher image quality.
Maybe. I have not seen any tests to substantiate this claim. When *decoding* v8 actually produces poorer results in some cases due to using dct-based upscaling of chroma planes (this is also the cause of the slowdown).
There's probably benefit to v8 if a distribution switch from v6 to v8.
Distributions sometimes do things without good reasons.