[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#602034: jpeg8 vs jpeg-turbo



On Wed, Apr 24, 2013 at 01:48:48PM +0200, Mike Gabriel wrote:
> >C. Decide which package should provide default libjpeg-dev library
 
> Last statement from Bill: libjpeg by IJG

The current IJG has nothing to do with the IJG that originally created JPEG. 
The last activity of original IJG was in 1998, while new IJG surfaced in 2009.
Thus we actually have two forks:

1) the "new IJG" libjpeg, which changes API/ABI of the original libjpeg
library, and adds new features to JPEG image format. However the new
image format features have been rejected as not improving image quality
or compression ratio[1].

The "new IJG" has no mailing list, VCS or any or other sign of actually
being group - all apparent IJG work seems to come from a single person.
The website of IJG[2] is void of details - who is in IJG? - how does
it make decisions like changing the JPEG image format to add "SmartScale
support? There is even no place to send bug reports! 

2) libjpeg-turbo remains API/ABI and binary format compatible with original
libjpeg. The most significant improvements are in supporting SIMD
features to make JPEG image encoding and decoding faster on modern
cpu's.

Libjpeg-turbo website [3] has all the signs of an healthy open source
project - A SVN repo with many commiters, bug tracker, a mailing list
with open discussion etc.

So the Debian options is to choose a libjpeg fork that changes the jpeg image
format, or one that renders images fast. At the moment the first
fork is being advertized with IJG name, thus painting an image of
"official upstream". But it isn't - especially not now when the changes
libjpeg8 added to JPEG standard have been rejected from the ISO standard.

Riku

[1] http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/
[2] http://www.ijg.org/
[3] http://www.libjpeg-turbo.org/


Reply to: