back
25 comments
I benchmarked libjpeg-turbo on iOS and Mac and it was significantly faster than the built-in stuff (typically around 2-3x), which includes the hardware decoder on iPhone.
I did a few benchmarks on the Raspberry Pi a year ago and got similar results. CPU decoding is a lot faster using libjpeg-turbo compared to using the hardware jpeg decoder: https://info-beamer.com/blog/omx-jpeg-decoding-performance-v...
Any context why this is suddenly trending? libjpeg-turbo is awesome, but hardly new.
Version 1.5.1 was released yesterday: https://github.com/libjpeg-turbo/libjpeg-turbo/releases
Sometimes I wish there was a package/library of the week. So many great discussions to be had!
This is something that the old freshmeat.net site would do. It was a great place to see releases of software all in one place. I'm sad that it's gone.
Someone could make an account called "package/library of the week", and make weekly posts.
freshmeat tried a variation of that model and ohloh did as well, it could be executed better and reduce the amount of noise in a anonymously-personalized way.
There was a Fedora update a couple of days ago.
>a JPEG image codec that uses SIMD instructions (MMX, SSE2, NEON, AltiVec)

Wow, it's been a long time since I heard anything about AltiVec.

The one real downside of Apple moving to Intel is that it's quite difficult to get cheap-ish PowerPC hardware.

At least we have ubiquitous ARM now, if you want to test your code on non-x86 platforms.

Honest questions: is this a complete re-implementation of libjpeg? (It was mentioned that this was originally based off libjpeg/SIMD, a libjpeg v6b fork.) If not, why can't this be backported to upstream libjpeg?
http://www.libjpeg-turbo.org/About/FUD

> libjpeg/SIMD predates libjpeg v7 by several years, which means that our SIMD extensions are not compatible with some of the new features in libjpeg v7 and v8. Thus, merging with the upstream libjpeg code would have been very difficult, if not impossible (more recent comments by the current maintainer of libjpeg indicated that our SIMD extensions would not have been accepted, anyhow.)

> In fact, since jpeg-7, every new release of the IJG's software has broken backward ABI compatibility with prior releases (needlessly, in the case of jpeg-9), and both jpeg-8 and jpeg-9 introduced new, non-standard image formats that couldn't be decoded by previous IJG releases or by other JPEG codecs.

Upstream libjpeg after v6 has appeared a little... weird lately: https://github.com/LuaDist/libjpeg/blob/master/README#L353
Odd. This insanity is also present in the original source on http://www.ijg.org/ .
Wow, is that a freemen-on-the-land open source project!?
v6 is the most widely used. v7 and later broke API compatibility. I'm glad of libjpeg-turbo using v6.
If you need to save/encode images you really want mozjpeg instead.
... but if you want something that is fast, you probably want libjpeg-turbo

> When compared to baseline (the only mode that is fully accelerated in libjpeg-turbo), the combination of progressive JPEG, jpgcrush, and trellis quantization improved the compression ratio by 15-27% (average 20%) in our testing but increased encoding time by approximately 34-59x. More than half of the compression ratio improvement came from the use of progressive JPEG, which is supported in libjpeg-turbo as well. Decoding time was increased by anywhere from 17% to 3x, with most of this again being due to the use of progressive JPEG.

More about the fork at the time it happened in 2014: http://www.libjpeg-turbo.org/About/Mozjpeg
The libjpeg.so in Debian (from the current stable release onwards) and Ubuntu is libjpeg-turbo.
Ditto FreeBSD, Fedora, and (probably) CentOS).
FreeBSD only made it default throughout the ports tree somewhat recently.
A little over a year ago, yes: https://svnweb.freebsd.org/ports?view=revision&revision=r397...
Is there a way to express SIMD in C? I'd expect that it's a solved problem.