Libjpeg-turbo

[darcymason]

Apparently there is now 12-bit support in libjpeg-turbo as of v3.0.x.

Perhaps it can be investigated as a replacement for / in addition to pylibjpeg-libjpeg, with a more permissive license (BSD-style).

According to the libjpeg-turbo README:

The libjpeg API implementation in libjpeg-turbo is both API/ABI-compatible and mathematically compatible with libjpeg v6b. It can also optionally be configured to be API/ABI-compatible with libjpeg v7 and v8 (see below.)

Which sounds to me (non-expert) like it could be almost a drop-in replacement in the existing libjpeg handler code.

[mrbean-bremen]

Good find! Yes, if it has the same functionality and we are able to integrate it, I see no reason to retain the old version, as the other plugins already are under MIT or compatible licenses. I (also as a non-expert) have recently been told in another context that libjpeg can be completely replaced by libjpeg-turbo featurewise, and that both implement the same standard. And libjpeg-turbo should be faster...
So this sounds very promising to me. I may have a closer look at this, though that may take quite some time, as I'm really no expert here (wish @scaramallion would re-surface...). Or you may have a go, as you already have been diving into this.

[darcymason]

(wish @scaramallion would re-surface...).

Same.

Or you may have a go, as you already have been diving into this.

I've looked some more out of curiosity. Seems to me the key is in building the wheels, after that the drop-in should be okay.
But the source layout and make files etc look quite different, so that might not be completely straightforward, but I'll leep looking.

Given that it look like there will be a fair number of changes, I'll probably create a pylibjpeg-libjpegturbo repo (long name but matches the current style) and get that started at least. I'll start locally and push up to create on github if it seems to be going okay. That leaves the existing -libjpeg repo in place for anyone who needs it and we can just use the turbo from pylibjpeg.

[mrbean-bremen]

Seems to me the key is in building the wheels

I think you can reuse the existing workflow to build the wheels without problems. I think the key is rewiting the _libjpeg.pyx and utils.py (though that won't probably change much) files - basically the interface to the library.

Given that it look like there will be a fair number of changes, I'll probably create a pylibjpeg-libjpegturbo repo

Yes, I have been thinking along the same lines after thinking about it a bit more, so I completely agree. Go ahead!

[darcymason]

basically the interface to the library.

Hmmm ... I started digging into the Cython stuff and all that, then I remembered I had seen PyTurboJPEG - wraps the lib with ctypes calls, but it doesn't build libjpeg-turbo (up to the user to install themselves). Probably enough and simplifies things a lot for us. In fact, can start without even trying to build the wheels ourselves.

And... I was thinking that because pylibjpeg-libjpeg is GPLv3, then we should be careful not to possibly be interpreted as a derived work.

As I look a little more, PyTurboJPEG is really small and simple, we could even just copy the bits we need (it is MIT). I'll start down this line and see how it goes.

[darcymason]

Okay, I've created a structure and opened a public repo: https://github.com/pydicom/pylibjpeg-turbo (I went with the shorter name, too much typing). Still very much WIP, of course.

[mrbean-bremen]

As I look a little more, PyTurboJPEG is really small and simple, we could even just copy the bits we need (it is MIT). I'll start down this line and see how it goes.

Yes, this is possible, though in general I prefer the sub-module approach - much less maintenance needed for moving to a new version. But if we need only a small part, it certainly makes sense.

[darcymason]

I agree, I think I didn't write carefully, what I meant was to start with PyTurboJPEG as a dependency, but if we need something a little different we could just add it ourselves, (modeling on their code, and contribute it back to PyTurboJPEG if it might be of general interest).

[mrbean-bremen]

Ah ok, I didn't indeed understand you correctly. This make sense, of course!

[parneshraniga]

Would imagecodecs (https://pypi.org/project/imagecodecs/) be a good/better alternative as it is already BSD-3 and has "uniform" interfaces to many of the common libraries.

I have a fork with only the dicom relevant parts that I can hopefully bring upto date and cleanup if there is interest? (My use case is/was slightly different in that I also want to infer transfer syntax from just an image in a dicomweb setting).

[scaramallion]

@parneshraniga it relies on the libraries already being installed though, which typically isn't the case on Windows

[parneshraniga]

@scaramallion fair enough. This discussion and some others have directed me towards an alternative path for my use case.