libwebp VS libjpeg-turbo

The thing that concerns me most is looking at the fix it is very difficult to see why this fix is correct. It also appears as there is lots of code without explicit bounds checks. It makes me worried because while the logic may be safe this makes the logic very complex. I wonder what the cost would be to add an explicit, local bounds check at every array access. This would serve as a backup that is much easier to verify. I suspect the cost would be relatively small. Small enough that I personally would be happy to pay it.

https://github.com/webmproject/libwebp/commit/902bc919033134...

This is also a great reminded that fuzzing isn't a solution to memory unsafe languages and libraries. If anything the massive amount of bugs found via fuzzing should scare us as it is likely only scratching the surface of the vulnerabilities that still lie in the code, a couple too many branches away from being likely to be found by fuzzing.

There's a follow-up fix, according to Debian[0]: https://github.com/webmproject/libwebp/commit/95ea5226c87044...

[0]: https://security-tracker.debian.org/tracker/CVE-2023-4863

The breakage [0] was introduced by the creator [1] of the project. If you want to audit 1674 commits over the past 12 years, it'd be easier to just audit the full project.

[0] https://github.com/webmproject/libwebp/commit/21735e06f7c1cb...

[1] https://github.com/webmproject/libwebp/commit/c3f41cb47e5f32...

If you like the command line, then you can use ffmpeg and ImageMagick, or use libwebp directly

The webp parser code is open source. Which means that even if Google decides to hide/obscure the code for webp, they'd legally not be allowed to prevent you from using older versions of the webp parser library. The only thing they could do is patent it, and then companies in the US (which has software patents, unfortunately) would have to pay royalties to decode it anyway; but here comes the next point

> all decoders will render the same pixels

Not true. Even just within libjpeg, there are three different IDCT implementations (jidctflt.c, jidctfst.c, jidctint.c) and they produce different pixels (it's a classic speed vs quality trade-off). It's spec-compliant to choose any of those.

A few years ago, in libjpeg-turbo, they changed the smoothing kernel used for decoding (incomplete) progressive JPEGs, from a 3x3 window to 5x5. This meant the decoder produced different pixels, but again, that's still valid:

https://github.com/libjpeg-turbo/libjpeg-turbo/commit/6d91e9...

Last vestiges of this fact AFAIK were libjpeg, which had a macro NEED_SHORT_EXTERNAL_NAMES that shortens all public identifiers to have unique 6-letter-long prefixes. Libjpeg-turbo nowadays has removed them though [1].

[1] https://github.com/libjpeg-turbo/libjpeg-turbo/commit/52ded8...

While I think the move to safer code through Rust and other alternatives is a nice breath of fresh air, I doubt you can get these kinds of optimization without using unsafe code in Rust. These optimized implementations often require some kind of safety-bypassing memory modifications to work as efficiently ad they do.

There's a reason https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim... is filled with assembly files with conditional loading.

Sure. You'll see it very often in codec implementations. From rav1e, a fast AV1 encoder mostly written in Rust: https://github.com/xiph/rav1e/tree/master/src/x86

Large portions of the algorithm have been translated into assembly for ARM and x86. Shaving even a couple percent off something like motion compensation search will add up to meaningful gains.

Or the current reference implementation of JPEG: https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim...

zune-jpeg is 1.5x to 2x faster than jpeg-decoder and is on par with libjpeg-turbo.

This is interesting from the standpoint of how new JVM features can be used to improve performance (what I presume the article's main purpose to have been), but the image processing improvement itself isn't head-turning. Also, we've found that libjpeg-turbo (https://libjpeg-turbo.org/) is ~5x (IIRC, can re-run my JMH benchmark if anyone wants me to) as fast for decoding JPEGs as ImageIO, so we wouldn't even benefit from this change in 21 much.

libjpeg-turbo: https://github.com/libjpeg-turbo/libjpeg-turbo/blob/main/simd/x86_64/jsimdcpu.asm

libjpeg-turbo

For all but the simplest formats (basically BMP), the difficulty of implementing encoding/decoding from scratch is significant - well beyond a beginner's ability, and challenging/time-consuming even for senior developers. So, libraries are used in practice - e.g. libpng and libjpeg-turbo.