Support uploading of JPEG XL

[vishnukvmd]

JPEG XL is an efficient format for storing images. However the format is yet to gain adoption: caniuse.com/jpegxl

On the brighter side of things, FFmpeg now supports this codec. Which means we can generate thumbnails and render them on desktop.

There's also an NPM package (jxl-wasm) that provides a CLI for encoding and decoding, which we could reverse engineer. But FFmpeg will be a better bet since we're already using it for transcoding and generating thumbnails for videos.

Rendering these images on mobile will be a challenge until the underlying platforms support them (unless we ship FFmpeg binaries to decode them there as well, which might not happen in the near future). But if there is enough demand, we could allow uploading them from desktop, ignoring the rendering issues on mobile, gracefully handling them with a "This format isn't supported yet." toast.

[dhcgn]

Thank you for creating this issue and considering the use of JPEG XL in this project.

From my point of view, it is particularly these advantages that are interesting:

• The support of JPEG-XL could reduce the used cloud storage with JPEG-Files (Lossless JPEG transcoding) around 16% to 22% or with JPEG-XL-Files around 50%.
• The cloud storage could be used as an archive, with the support of lossless compression (35% smaller than PNG)
• Future-proof with support for wide gamut and HDR (e.g. 10-bit or 12-bit)

Key Features
The JPEG XL codec is designed to allow users to balance three primary criteria for their application:

1. high fidelity to the source image (closely matching human perception),
2. encoding and/or decoding speed,
3. compression ratio (typically 20:1 to 50:1)

Key features of the JPEG XL codec are:

1. improved functionality and efficiency compared to traditional image formats (e.g. JPEG, GIF and PNG),
2. progressive decoding (by resolution and precision),
3. lossless JPEG transcoding,
4. support for both photographic and synthetic imagery,
5. graceful quality degradation across a large range of bitrates,
6. perceptually optimized reference encoder,
7. designed for wide gamut and HDR,
8. support for animated content,
9. efficient encoding and decoding without requiring specialized hardware.

In terms of compression performance, key results are:

1. Lossless JPEG transcoding reduces JPEG size by around 16% to 22%.
2. Lossless compression (from pixels) is around 35% smaller than (optimized) PNG for 8-bit images, and
   the improvement is even larger for images with a higher bit depth (e.g. 10-bit or 12-bit).
3. JPEG XL is visually lossless at about half the bitrate required by JPEG, i.e. at compression ratios of around
   20:1 (1.2 bpp) where JPEG would compress only around 10:1 (2.4 bpp).
4. Compared to other image codecs, JPEG XL provides superior compression at a given visual quality.

From White Paper: ISO/IEC JTC 1/SC29/WG1 N100400, JPEG White Paper: ​JPEG XL image coding system v2.0, 2023.

[vishnukvmd]

Looks like things might move forward on Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1451807#c16

[RohsCE]

So it seems Chromium dropped support for it, is this apart of why Ente has not added proper support for JXL?

[mnvr]

Right, that is related. Chromium dropping support is unfortunately essentially ensuring that JXL would never become a web standard

(We'd still like to support it, but since it won't be a web standard any Ente support for JXL will have to be a special case, and will require custom decoding logic on Chrome at the very least)

[RohsCE]

I can understand that (and a damn shame that support was dropped by chrome). But then again I am also thinking, JXL has great benefits over standard JPG, and this is a photos app - surely that that is reason enough. Although saying that I am not privy to the effort required for "special cases"

[MrSn0wy]

Google is also currently working on a rust implementation of a jpegxl decryption library that will eventually be merged into firefox (possibly chrome), so I doubt google would be funding that if they aren't gonna use it sooner or later. Also jpegxl decodes fine on android/zen-browser... You could atleast add support for it and put a notice on the website for limited decoding support.

I don't think that writing your own decoding logic for chromium is needed or something that ente should do in the first place, users that want jpegxl will know the potential issues.

[dhcgn]

One of the major image processing software Adobe Lightroom now supports JPEGL-XL in these formats:

• 8Bit
• 16Bit
• HDR
  • Rec.709
  • Rec.2020
  • P3

[getspaghett]

Any progress on implementing jpxl on ente.io? i bought into the 1tb storage plan and would really enjoy if my pictures would load faster. libjxl already offers options to convert existing JPEG files to jxl, which could be used to compress already used storage space even further.

[antiplex]

I just tried uploading a sample set I created in the formats JXL, AVIF, and WEBP and all but the JXL ones (!) could be uploaded and viewed (browser and android-app). Sidenote: a somewhat more elaborate error message like "unsupported format" would be of help in my opinion

So while its nice to see that some more recent than JPEG formats are supported, I definitely would prefer JXL for various reasons (e.g. quality, features, future-proofness and others) and would be delighted to see what direction ente will take on this.

Certainly I don't expect to be a relatively new (standardized in 2022) format to be supported from day 1 or over night but it'd certainly help in my current decision process of choosing a could storage provider to see if this is seriously considered or rather not at this point.

[fabian19vs]

Somehow, I was able to upload and OPEN a jxl image in the app. Maybe they are working on that, because it can be opened only on my iOS app. The Mac app displays the thumbnail but when you try to open the photo, only a black screen with the text "The image could not be loaded" appears. It is also not able to read EXIF info from the file. The web app can open the image (I am using Firefox).

[getspaghett]

I just tested it too. Uploading works but viewing is only possible when the jxl support flag in firefox config has been set. Thumbnails and Exif are not loading as well. Does not work on the Android app.

[RohsCE]

Bumping this -- support for JXL is a must for someone like me who has already converted all photos to JXL

[IzumiSenaSora]

+1 Me too

[fabian19vs]

I think that these logs could help to figure out why are JXL files shown without metadata. I managed to upload photos on my Mac, iOS apps, but I recently tried on Firefox and it failed. I reviewed the logs and seems like this file is not recognized as an image file. Decided to check using a tool for MIME type check, and everything seems to be in place, MIME type is image/jxl .
May be there is no metadata because Ente is not treating those files as photos?? should I create a bug report?

[2025-04-09T07:26:41.902Z] [info] Starting ente-photos-web git 76e7f69 uid 0
[2025-04-09T07:26:41.908Z] [info] Running migrations 0 => 5
[2025-04-09T07:28:05.927Z] [info] Starting ente-photos-web git 76e7f69 uid 0
[2025-04-09T07:29:48.570Z] [info] Uploading 1 files
[2025-04-09T07:29:49.454Z] [info] Upload IMG_1999_peq.jxl | start
[2025-04-09T07:29:49.462Z] [error] Failed to extract image metadata for [object File]: Error: Invalid image format
t6@https://web.ente.io/_next/static/chunks/pages/_app-113f15e131a42783.js:29:593408
az@https://web.ente.io/_next/static/chunks/pages/_app-113f15e131a42783.js:29:655297
aY@https://web.ente.io/_next/static/chunks/pages/_app-113f15e131a42783.js:29:654792
aN@https://web.ente.io/_next/static/chunks/pages/_app-113f15e131a42783.js:29:653316
of@https://web.ente.io/_next/static/chunks/pages/_app-113f15e131a42783.js:29:663820

[2025-04-09T07:29:49.467Z] [error] Upload failed for IMG_1999_peq.jxl: TypeError: f is undefined
eB@https://web.ente.io/_next/static/chunks/pages/_app-113f15e131a42783.js:29:679733

[fabian19vs]

The same applies for viewing photos already uploaded in JXL format. There is an error that can explain why is that this format can be viewed on supported clients (this time was Orion browser, WebKit), but the Exif info cannot be viewed:

[2025-04-22T05:57:39.293Z] [info] download attempted for file id 140506845
[2025-04-22T05:57:39.427Z] [error] Failed to extract exif: Error: Invalid image format

[StefanOltmann]

Ente should support JPEG XL now.

Apple and Microsoft now support it natively.

[MrSn0wy]

These are some of the issues with jpegxl that I have found:
Weird bug is when i try to download a jxl file on mobile i get an error code saying illegal argument, unsupported mime type image/*.
Machine learning doesn't seem to work for jxl.
Image editor doesn't load jxl images.
No resolution or mp count is shown in details.
Exif data doesn't get found.

I really hope these get fixed since i really want to use jpegxl. The top two especially are showstoppers for me.

[Alwaysc0d3]

This issue is 2 years old now. On your site you state that you support all MIME types with images/*
jxl is part of that. What do you need from the community to get this done? And what is the backlog and roadmap currently and where is this item on your roadmap? I just started using Ente today and I already stumbled upon two major issues: you basically only support one very popular and well known format: jpg. I have CR2 (Canon RAW) images that are not supported by the app (thumbnail generation does not work, and therefore it is quite useless to be honest) and my archive contains now over 10.000 photos of Sony RAW which doesn't seem to work either.

So, again: please be open,. share your roadmap so I can decide how long I will support with very limited support on the images I need. Machine learning is something else with respect to ML, but if we can please focus on the basic functionality like thumbnails, a lot of your users would become very happy. The issue I predict is that there is a skewed image of how many users are requiring other formats than jpg. I can tell you: all users considering your service which are photo-enthusiasts, have other formats than jpg. I only don't think they all will find the way to a developer platform like github... Perhaps sharing a voting mechanism on the first items on your roadmap for your users to be prioritized, would be really nice. I then assume the users are the priority, combined with good quality software on your end.

[Alwaysc0d3]

I off course understand that this hits your business model, as storage consumption might be reduced with the use of jxl. But if that is a problem, fix your business-case ;-)

[MrSn0wy]

It seems that with the new update to ente (1.2.0 tested on android) that exif data gets shown now for jxl images, maybe stuff is slowely moving? Weird that this wasn't mentioned in the patch notes tho.

[StefanOltmann]

Is the image shown or just the EXIF with a black image?
If so, that’s just because they may have updated the metadata lib and this slipped in.

[MrSn0wy]

The image is shown on android, it has been for awhile, it also shows on certain browsers that support it (like zen browser).

[StefanOltmann]

I need to check if the Desktop version can also show JXL now.
I'm not interested in only partial support on some platforms.

[inferenceus]

Google have announced their intention to bring back JPEG XL support to Chromium[1], while the format will also be used in the PDF format[2]. This feature is going to be necessary over time as the format continues to explode in adoption and usability.

It seems that Google have decided on jxl-rs, have integrated it into Blink, and it is indeed happening[3].

[1] https://www.phoronix.com/news/JPEG-XL-Possible-Chrome-Back
[2] https://www.theregister.com/2025/11/10/another_chance_for_jpeg_xl/
[3] https://chromium-review.googlesource.com/c/chromium/src/+/7184969

[RadiantPower]

Google just released JXL support on chrome. Hopefully we'll finally start to see wide spread adoption.

https://www.phoronix.com/news/JPEG-XL-Returns-Chrome-Chromium

[Dawnexa]

So I assume there is still no support for JXL on Ente-Photos?

[RadiantPower]

If you turn JXL support in the browsers flag setting, you can both view and generate thumbnails for JXL images, but on other devices the image won't decode and the thumbnail will load in its place.