[Digikam-devel] libjpeg 8 requirement considered harmful

Kevin Kofler kevin.kofler at chello.at
Mon Jan 21 23:17:20 GMT 2013

On Friday 18 January 2013 at 18:52:17, I wrote:
> * IJG libjpeg, on the other hand, started making API and ABI changes to
> their  code to support some new features. While libjpeg-turbo has some
> support for the IJG lijpeg 8 ABI, libjpeg-turbo's upstream considers the
> additions and changes unnecessary and useless (mainly because JPEG files
> using the new features cannot be read with older libjpeg implementations!),
> will not guarantee that any added functionality actually works (only ABI
> compatibility) and strongly recommends against enabling the new ABI:
> http://sourceforge.net/mailarchive/message.php?msg_id=30352465

PS: FYI, Tom Lane, the former Organizer of the Independent JPEG Group (IJG) 
(see http://en.wikipedia.org/wiki/Tom_Lane_(computer_scientist) ) and former 
libjpeg developer (see http://libjpeg.sourceforge.net/ ), agrees that
libjpeg 8 and 9 are a dead end distributions shouldn't be going into:


He writes:
| Personally I concur with Adam's newfound opinion that jpeg8 is a dead
| end we shouldn't be going down.  The original point of libjpeg (which
| succeeded beyond my wildest dreams really) was to promote universal
| JPEG file compatibility.  The latest jpeg8 and jpeg9 versions are
| antithetical to that goal because they create nonstandard files that
| can't be read by standard implementations, including older libjpeg.
| If there were a huge improvement in compression performance maybe
| there'd be some chance of establishing a new de facto standard, but
| there isn't --- so this will accomplish little except to fragment
| the market.  I don't think Fedora should be contributing to that,
| not even to the small extent of breaking ABI compatibility to be
| ABI-compatible with those library versions.

(I'll also point out that ISO rejected the libjpeg 8 additions to the JPEG 
standard (this came up elsewhere in the Fedora discussion), so those files 
really are nonstandard.)

        Kevin Kofler

More information about the Digikam-devel mailing list