Add support for JPEGXL encoded images

[Sir-Photch]

Hey there. This is a proof-of-concept for JPEGXL decoding of the image/jxl mimetype. I figured that if there is WEBP support, there should be JPEGXL as well. After all, indie web requires indie codecs, amirite?

Right now, this adds an (optional) dependency on libjxl. That is a BSD-3-clause license, so it should be compatible? If you think this is something you'd merge, I can have a look about android (are there build instructions available already?). Can't do iOS though since I don't have apple hardware.

[skyjake]

Thanks. This looks reasonable, although I recommend running Clang-Format on your additions using the included .clang-format file in the repository. I can merge this once you're happy with it.

When it comes to mobile, I've been building the image decoder libraries from source and using those in the build, so in theory little is needed to use this on Android and iOS except for some fiddling with the build environment. Of course, it would be nicer if the platform's native APIs were used, since they might be more efficient, but I don't think it's worth the implementation cost. Images are not Gemini's core use case.

[Sir-Photch]

One more thing that might be interesting: since you track isPartial on media files, it would make sense to pass that down to makeTexture_GmImage and then to loadJxl_ since jxl supports progressive decoding. Though, then it would probably be necessary to keep the decoder state somewhere, for it to continue on data that comes in later. Not sure if that would be a sensible thing to do, but the possibility exists. Maybe for another PR.

When it comes to mobile, I've been building the image decoder libraries from source and using those in the build, so in theory little is needed to use this on Android and iOS except for some fiddling with the build environment.

So, will you figure this out then? Available Android build instructions would be nice though!

Of course, it would be nicer if the platform's native APIs were used.

I'm not sure if any android native implementations for jxl even exist though.

[Sir-Photch]

Hey there again. I had some time on my hands and gave progressive decoding a shot. You can see it in action when receiving a jxl over a slow internet connection or decoding a rather large image.

If you think that this is too much for now / needs further testing, feel free to tell me; My suggestion for this PR would then be to revert faec6f6 and create another PR for that.

If not, there are a couple of concerns I have. There is now a global map to keep track of the iStatefulJxlDecoders, which is not thread-safe. I wasn't sure if your drawing code is multi threaded? If yes, this probably needs a mutex as well I think. Other than that, I chose the iGmLinkId to be the hashmap's keys. This assumes, that they stay consistent... Maybe there needs to be a more robust one?

For some jxl images, you can try gemini://sir-photch.xyz/jxltest.gmi.

[skyjake]

Nice! Progressive decoding sounds useful, although I'll have to review your code when I have some more time available. It's certainly not mandatory to have, though, if the complexity is too high.

I wasn't sure if your drawing code is multi threaded?

Anything related to drawing is done in the main thread. Other threads are used for network requests, subscription updates, and searching for navbar lookup terms, not for anything that touches the UI widgets.

[Sir-Photch]

It's certainly not mandatory to have, though, if the complexity is too high.

Well as I see it there are two ways to do it:

• Create-destroy decoders with every chunk of the image we receive. This is less complex, but also less efficient, since a JxlDecoder can keep it's progress when it has output an intermediate image, to then continue on any chunks that conclude the original stream
• Create encoders upon first request, then keep them somewhere until we have fed them with all data, step by step, while we consume intermediate images to then receive the final image and free the decoder

I opted with the latter since it seemed like the proper way to me. The actual usage of the libjxl API does not get more complicated. And for larger images, keeping progress makes sense.

But as I have looked at the_Foundation now, I have probably misinterpreted on how to create a subclass of iMapNode. I'll see what you suggest in your review though before I continue hacking on this :)