[SUGGESTION] switch from simplejpeg to libjpeg-turbo

[carlodri]

Please only include one suggestion or features request per issue!

Is your feature request related to a problem? Please describe.
The simplejpeg dependency is much less maintained and optimized with respect to the well-established and battle-tested libjpeg-turbo.

Describe the solution you'd like
Switch from simplejpeg to libjpeg-turbo. It should be very straightforward.

Describe alternatives you've considered
None.

Additional context
None

[davidplowman]

Hi, thanks for the suggestion. I'm curious if the use of simplejpeg has been causing problems for you?

Did you have a particular Python package in mind that exposes libjpeg-turbo? Actually simplejpeg is just such a package which provides a thin layer of bindings that gives you access to libjpeg-turbo itself.

There's also been some work done on simplejpeg recently that enables it encode images where the line-to-line pitch is larger than the image width. This makes it more efficient to pass in images that have been produced by hardware (such as that on the Pi) that needs to pad image rows to achieve a particular level of byte-alignment. Previously, we used to have to copy such images so as to remove the padding.

The most recent simplejpeg is also enable to encode YUV420 images directly, without converting to RGB. This is also more efficient, and helpful to lower-spec hardware that can avoid allocating large RGB buffers. It can also handle YUV420 with end-of-line padding.

But if you know of other packages that offer these features, and similar or better performance, then we'd love to learn more about it. Thanks!

[carlodri]

Thanks for your feedback @davidplowman!

My concern is mostly related to the simplejpeg library itself and its intricate build system to bring in vendored pieces of specific libjpeg-turbo versions. This is mainly in view of what I am trying to do here with the aim of bringing picamera2 to the conda-forge ecosystem. Also related: raspberrypi/libcamera#251.

The package I currently use for Python is https://github.com/lilohuang/PyTurboJPEG.

Concerning the compression from YUV, it should be implemented in the Python bindings: https://github.com/lilohuang/PyTurboJPEG/blob/87bdba487a6198afd6d4c3cbfb2b544c59f7ea8f/turbojpeg.py#L513

I'm looking into compression settings with strides (or pitches, I think this is how libjpeg-turbo calls your line-skipping), and it should definitely be feasible, although I don't know if it is exposed in pyturbojpeg.

[davidplowman]

For our apt package (python3-simplejpeg) I believe we actually link against the system version of libjpeg-turbo, rather than building another version. There's still one more PR to merge (#1209) to finish the job of encoding YUV420 images without copying, but I mean to merge that shortly. Don't know why I haven't yet.

Beyond that I don't mind using a different JPEG package if it is better in some respects, and doesn't cause any feature or performance loss. I'm not going to have any time to look at this myself, however.