Completed JPEG XL (.jxl) image format

[olavrb 3]

For future proofing, it would be great if Emby added general support for JPEG XL (.jxl). It could be used for multiple things, like:

• Storing and viewing photos
• Media metadata (album art)
  • Recompress existing JPEG and PNG losslessly to shave down the metadata database

More info on the format:

• https://jpegxl.info/ 
• https://cloudinary.com/blog/the-case-for-jpeg-xl 

Decode support is probably dependent on support in browsers and OS-es? Apple will have JPEG XL in their next major OS version. More about adoption:

• https://caniuse.com/jpegxl
• https://github.com/libjxl/libjxl/blob/main/doc/software_support.md 
• https://en.wikipedia.org/wiki/JPEG_XL#Official_support

Edited June 28, 2023 by olavrb

[Luke 43172]

HI, yes I agree we should support this. Currently we use a combination of Skia and libvips for image processing, so the holdup on this would be related to them first adding support for it, e.g.: https://github.com/libvips/libvips/discussions/2055

[olavrb 3]

@Luke libvips now have JPEG XL support.

[Luke 43172]

3 hours ago, olavrb said:

@Luke libvips now have JPEG XL support.

Perfect. So the next time we update libvips then we should gain support for it. Thanks.

[gbcox 17]

Yes, it is working.  Thanks!

[gbcox 17]

Correction to my earlier post: I said Emby could use my cover.jxl files because its installed package had JPEG XL decoding support. I tested that assumption, and it was wrong.

Emby could read the album directory and the JXL file, but refreshing the album did not pick up cover.jxl. Adding cover.png alongside it made the correct cover appear. Some albums had still shown artwork because Emby had other images available; that did not mean it was reading the JXL covers.

The practical conclusion is that JPEG XL decoding support does not mean Emby’s local album artwork scanner recognizes .jxl files.