Libjpeg-Turbo 2.0 Released With AVX2 SIMD Additions, Better Error Handling

[phoronix]

Phoronix: Libjpeg-Turbo 2.0 Released With AVX2 SIMD Additions, Better Error Handling

Libjpeg-Turbo 2.0 was released in the past few days as the JPEG image codec library known for being quite speedy thanks to its various optimizations on different CPU instruction sets, by as much as two to six times faster than the conventional JPEG library...

http://www.phoronix.com/scan.php?page=news_item&px=Libjpeg-Turbo-2.0-Released

[tildearrow]

Typo:

chroma down/up-samping,

[TheLexMachine]

I don't understand why devs aren't open to using this instead of the creaky libjpeg that pretty much every Linux distro and program has been using for ages.

[Palu Macil]

I don't understand why devs aren't open to using this instead of the creaky libjpeg that pretty much every Linux distro and program has been using for ages.

It takes time from the few developers who understand this level of an application, it means refactoring makefiles and code, and it has less of a track record. The best option isn't always the one that sticks around and gets maintained.

[cl333r]

I don't understand why devs aren't open to using this instead of the creaky libjpeg that pretty much every Linux distro and program has been using for ages.

Or even better - use a better image format like WebP, PNG, AV1 unless to many of your users don't support them.

[schmidtbag]

Interesting... I'm writing something in OpenCV that feeds from a MJPEG stream, and the transcoding is soaking up a lot more CPU time than I'm comfortable with. This could make a pretty dramatic performance difference.

[curaga]

I don't understand why devs aren't open to using this instead of the creaky libjpeg that pretty much every Linux distro and program has been using for ages.

Many distros default to -turbo, resulting in all jpeg apps being faster. It's the same API and ABI, nothing for devs to support.

[coder]

Or even better - use a better image format like WebP, PNG, AV1 unless to many of your users don't support them.

PNG and JPEG are apples and oranges.

As for WebP, support for it is much worse, encoding is slower, and it hasn't been shown to offer significant advantages.

https://research.mozilla.org/2013/10/17/studying-lossy-image-compression-efficiency/

http://webpjs.appspot.com/lossy_compressed_image_study_november_2013/

Support for AV1 is virtually nonexistent, and it's surely much slower.

[cl333r]

PNG and JPEG are apples and oranges.

As for WebP, support for it is much worse, encoding is slower, and it hasn't been shown to offer significant advantages.

https://research.mozilla.org/2013/10/17/studying-lossy-image-compression-efficiency/

http://webpjs.appspot.com/lossy_compressed_image_study_november_2013/

Support for AV1 is virtually nonexistent, and it's surely much slower.

Agree with anything except "significant advantages" as the very point of WebP is to offer lots of advantages, but you don't even see that there's no point arguing.

[coder]

Agree with anything except "significant advantages" as the very point of WebP is to offer lots of advantages, but you don't even see that there's no point arguing.

If you click the second link, the gains offered are hardly worthwhile - especially when better options are available.