libjpeg for F14

Ilyes Gouta ilyes.gouta at
Tue May 25 15:40:15 UTC 2010


SSE and friends are arch. specific and according to the feature list
the upstream is displaying, I don't think it would offer any other
benefits for the other archs.

There is one strong point that libjpeg-{6b, 8ab} inherited since it's
been there for a lof time: a *defacto* standard for JPEG
compression/decompression that has been heavily depolyed, used and
tested code for various application/, thoughtout the time, for more
than a decade! I think that's important and would enable it to keep
its place in the destribtion.

libjpeg-6b is at production level code, and it actually offers a
couple of ways to accelerate JPEG decoding by turning on the IDCT
level decimation (basically for free resize) and enabling YUV raw

How about this: since libjpeg is picking momentum and there are
actually people updating the code base, why not push for a
libjpeg-turbo merge into the original ijg's code and get Fedora to
rebase on that unique source instead? That way ijg can test for any
regressions using their conformance tests.

-Ilyes Gouta

On Tue, May 25, 2010 at 3:23 PM, Adam Goode <adam at> wrote:
> On 05/25/2010 10:09 AM, Richard W.M. Jones wrote:
>> Why couldn't we just replace libjpeg with the libjpeg-turbo upstream?
>> (For the primary architectures anyway).
> I think this is a great idea, libjpeg is the bottleneck for a lot of my
> code.
> One issue: are there C fallbacks for all the arch-specific code? It
> would be great if secondary architectures could just use libjpeg-turbo
> as well.
> Adam
> --
> devel mailing list
> devel at

More information about the devel mailing list