Integration into the image crate

[Shnatsel]

Would you be interested in adding jxl-oxide integration to the image crate?

It would be very convenient if users of image could decode jxl-oxide through its format-agnostic API without having to write code specific to JPEG XL themselves.

The format integrations are not complicated. For example, here's the qoi codec integration: https://github.com/image-rs/image/blob/master/src/codecs/qoi.rs

[Shnatsel]

FWIW the zune-image library already uses jxl-oxide, but it is not as widely used as image because it supports fewer formats and its API is still unstable.

[Quackdoc]

this was rejected by image-rs maintainers image-rs/image#1979

I no longer plain on maintaining the PR to add it unless something changes

[Shnatsel]

I see. Thank you!

[Aerocatia]

Strange for a Microsoft employee to have such a hard-line stance on what denotes a "free" format. I would not hold my breath on this, unfortunately.

[Shnatsel]

It is possible to provide APIs for easy interoperability with the image crate's types without having to modify the image crate itself. For example, https://crates.io/crates/turbojpeg does this behind the image feature.

If the integration PR is already written, perhaps it's best to just put the integration into this crate behind a feature flag instead.

[Quackdoc]

It is possible to provide APIs for easy interoperability with the image crate's types without having to modify the image crate itself. For example, https://crates.io/crates/turbojpeg does this behind the image feature.

this could be nice to have. Considering the maintainer of the image crate doesn't seem to want JXL inside of it, it may be the best route forwards or maybe a small shim crate.

[Quackdoc]

@Shnatsel I completely forgot to mention this a while ago, zune-image provides interop with the image crate, which is probably going to be good enough

[Shnatsel]

zune-image stores all the channels in separate vectors. So if one were to load a JPEG XL image into zune-image and then back into image, it would waste CPU cycles and memory on deinterleaving and then interleaving the data right back.