[Feature] JPEG-XL Support

[Adrian-Grimm]

I have searched the existing feature requests to make sure this is not a duplicate request.

• Yes

The feature

Background

JPEG-XL is ready for getting mainstream - https://jpegxl.info

Just a few reasons:

• Quality is far better than every alternative by a lower file size in every case
• iPhone 16 is able to shoot JPEG-XL by default
• iOS 17+, macOS, and further OS have full support
• Browsers are all getting or have already base support
• ...

Target

1. Immich should support JPEG-XL photos to store and show such in native JPEG-XL if the platform supports it and photo was saved in that format.
2. If there is no support on an old platform Immich should always convert it seamless to the old JPEG format for compatibility reasons.
3. May this feature should be an opt-out feature which could get deactivated on server side.

Out-of-Scope

• The creation of previews doesn't need to get modified regarding the target format for easy compatibility as long as JPEG-XL support is not everywhere given by default. Something like 50% of the devices should support it before considering this as an optional feature.

Platform

• Server
• Web
• Mobile

[bo0tzz]

Immich already supports uploading jxl files, what are you asking for exactly?

[Adrian-Grimm]

To also show such files in native JPEG-XL if the platform supports it (except of such small previews).

[mertalev]

Since that basically means Safari at the moment, it'd be as simple as adding it in this line.

We can present the original JPEG XL image for other browsers when they start supporting it. I've read that Firefox is interested in JPEG XL, but wants a Rust-based decoder for it. I haven't seen an update on the Chromium team's stance following Apple's push for JPEG XL, but maybe it will force their hand at some point.

[alextran1502]

Not being supported on mainstream clients yet

[Adrian-Grimm]

right for the web browsers - but still already some important ones support it and it would be also able to be supported in the Apps...

[Adrian-Grimm]

would also help to get the adoption to JPEG-XL pushed.

[AngelaDMerkel]

As much as I like JXL, Interop rejected it in their last voting round and only Apple supports read and writing the format. Some camera manufacturers outside of Apple including Samsung support it, but in a very limited capacity. When the format is widely support the progressive decode could save a lot of bandwidth and storage in immich by foregoing the need to generate additional thumbnails

[Adrian-Grimm]

I think adoption will speed up from now on - was the same game with HEIF - as soon as Apple pushed it ...

[NicholasFlamy]

I would like to add an almost side-note feature request, Transcoding JPEG to JPEGXL losslessly to save storage space and have an option to revert back to the original JPEGs since JPEGXL claims this as a key feature.
https://jpegxl.info

From FAQ:

Is Lossless JPEG Transcoding really bit-for-bit accurate?
Converting a JPEG to JPEG XL using cjxl and then back to JPEG with djxl results in a bit-identical copy of the original JPEG image. However, it’s important to note JPEG standard leaves room for some interpretation, leading to potential minor variations between different decoders.

Do other JPEG XL tools support Lossless JPEG Transcoding?
Other encoders may not support lossless transcoding, so it’s best to check any support documention to verify. Note that lossless encoding of a JPEG file to JPEG XL is not the same as lossless transcoding. Transcoding uses a specific mode to achieve its 20% size gain while maintaining pixel-level accuracy.

[AngelaDMerkel]

I suggested this in another feature request but it was closed as not being within the project scope

[NicholasFlamy]

Yep, I see #8907.

You were talking about compression in general too.

One thing I will add to my comment is, having this as an immich feature could make it possible to store the images as JPEGXL and on the fly convert to the original JPEG losslessly for clients not supporting JPEGXL. (And what I mentioned about being able to download the original JPEG as though it was never converted.)

[NicholasFlamy]

What I'm suggesting might still be out of the scope of the project, but maybe they would be okay with someone like me implementing it and PRing.

That or they give more addon options such that these features could be an addon, because the Lossless Transcode to JPEGXL could already be done by a separate tool, and clients can use the thumbnail and preview images, but if you hit load original image or you zoom in, but your client doesn't support JPEGXL, then on the fly transcoding to JPEG losslessly would be beneficial. So some integration for that and a way to download the losslessly converted back to JPEG image is needed.

[bo0tzz]

We have no intent to add any changing of original files to Immich, but the idea is to make it easy to do this via a community addon at some point yes.

[Qhilm]

iPhone 16 is able to shoot JPEG-XL by default

iPhone 16 shoots DNG with a JPEG XL inside the DNG container, that is not a JPEG XL file, just to be clear, it's a DNG file.

Secondly, it is for ProRAW pictures only and that is not the default.

I am big fan of JPEG XL, but pushing it based on inaccurate facts is counterproductive.

We need Chrome to support it, that would move the tides.

[jarrodmoldrich]

I haven't tested this, but I know it's more than HW decoding for sure. Based on my Ryzen 5 5600X, it's probably pretty bad, luckily my Radeon RX 6700XT has HW AV1 decode.

Went into a rabbit hole on this. Seems that at 32 QP @ 1080p 30/60fps, the March 2022 version of dav1d uses close to 3 cores on a selection of Android devices (from 2018-2020). Seems like most recent phones can handle it, but they might get a bit warm.

https://www.linkedin.com/feed/update/urn:li:activity:6968047760256241664/

There is a thumbnail and preview option that stores a converted COPY. Immich DOES NOT alter your original photos.

So previews are what are seen on the app/web when you click on the picture? Does that mean that all images, even JPGs, are copied? If so, then I'll chose jxl just to reduce on server space, though it would be nice if it used it for display as well.

[NicholasFlamy]

Seems like most recent phones can handle it, but they might get a bit warm.

And that heat is from electricity and that electricity is from the 3700 mAH battery in my phone. My phone doesn't last long enough as it is. I've considered the amazing Asus Zenphone 10 but they gave it only two years of software update and are such sh*tholes that they got rid of bootloader unlocking while the Zenphone 9 was still for sale.

[jarrodmoldrich]

@NicholasFlamy Just reposting this question to you because I buried it a bit in the last one

There is a thumbnail and preview option that stores a converted COPY. Immich DOES NOT alter your original photos.

So previews are what are seen on the app/web when you click on the picture? Does that mean that all images, even JPGs, are copied? If so, then I'll chose jxl just to reduce on server space, though it would be nice if it used it for display as well.

[NicholasFlamy]

So previews are what are seen on the app/web when you click on the picture?

Yes with the default setting of show originals turned off. (When you zoom in it'll load the original.)

Does that mean that all images, even JPGs, are copied?

Yes, you can select JPEG or WebP.

[jarrodmoldrich]

(When you zoom in it'll load the original.)

Right! So the timeline/album view are the thumbnail copies. When you click on the image it shows the preview copy, and when zooming it shows the original. That makes sense. Wish that was more obvious or documented somewhere. So I guess if you zoom into a jxl on an unsupported browser it just shows the preview. Which I'm okay with.