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 43176]

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 43176]

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 18]

Yes, it is working.  Thanks!

[gbcox 18]

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.

[gbcox 18]

Follow-up: I narrowed down the Emby JPEG XL issue. Emby ignores an album’s cover.jxl, but if I copy the exact same file bytes to cover.png and refresh the album, the correct artwork appears. The file is still JPEG XL; only its name changed.

So Emby’s image decoder can handle the file. The local music-artwork scanner appears to exclude .jxl from its supported filename extensions. Adding jxl to that discovery list may be all that’s needed, though the Emby team would need to confirm whether there are other paths to update.

[Luke 43176]

17 hours ago, gbcox said:

Follow-up: I narrowed down the Emby JPEG XL issue. Emby ignores an album’s cover.jxl, but if I copy the exact same file bytes to cover.png and refresh the album, the correct artwork appears. The file is still JPEG XL; only its name changed.

So Emby’s image decoder can handle the file. The local music-artwork scanner appears to exclude .jxl from its supported filename extensions. Adding jxl to that discovery list may be all that’s needed, though the Emby team would need to confirm whether there are other paths to update.

Right currently it is supported in a photo library but as far as the images for videos and series and things along those lines, those are still looking for a small subset of extensions. so that's something we'll need to review.

[gbcox 18]

4 minutes ago, Luke said:

Right currently it is supported in a photo library but as far as the images for videos and series and things along those lines, those are still looking for a small subset of extensions. so that's something we'll need to review.

Thanks @Luke!   As a temporary workaround, I created a relative symlink, cover.webp → cover.jxl, and Emby picks up and displays the artwork correctly after a refresh. It avoids converting or duplicating the image, but it’s a bit janky. Native .jxl discovery would eliminate the need for it.