libjpeg for F14

Tom Lane tgl at redhat.com
Mon May 31 17:37:11 UTC 2010


Toshio Kuratomi <a.badger at gmail.com> writes:
> The issue would be that it's a fork.  So libjpeg from the independent jpeg
> group and libjpeg-turbo can gain incompatible API in isolation from each
> other.  (The situtation seems a bit complex, there's three projects that
> I can see working on libjpeg:

> * libjpeg.sf.net -- working on API compatible updates to libjpeg-6b
> * independent jpeg group (one person?) -- working on jpeg-8b and beyond
> * libjpeg-turbo -- seems to be based on libjpeg-6b has speedups on modern
>   x86 (w/SSE), licensed under the wxwindows license instead of BSD due to
>   using code from that project.  (according to the README in libjpeg-turbo,
>   wxwindows license is a less restrictive form of the LGPL -- it allows
>   static linking without the resulting work having to take on the LGPL
>   license.)

> tgl, is this your understanding of the separate projects as well?

[ sorry for slow response ]  libjpeg-turbo is news to me, but as far as
the other two go:

* the sf.net project was started to produce ABI-compatible updates of
libjpeg 6b, but I'm beginning to despair of ever seeing a release from
them.

* libjpeg7/8/etc is pretty much one person, and I'm not terribly happy
with the direction that that's going either.  Guido doesn't seem to be
very concerned with even file-level compatibility, let alone source-code
compatibility (libjpeg7 is known to have broken multiple dependent
packages), and he's also not worrying much about patent issues.  The
move to add arithmetic-coding support seems a bad idea on at least two
of those grounds, and it doesn't even buy that much in file size.

I suppose this is all my fault for having let libjpeg languish for so
many years, but that's water under the bridge now.  If the libjpeg-turbo
group is doing active development and is taking care not to break things
unnecessarily, I'm happy to see them become the forefront of libjpeg
development.  Especially if it means I don't have to do the work ;-)

			regards, tom lane
			ex-organizer, Independent JPEG Group


More information about the devel mailing list