FossifyOrg
Add JPEG XL support
Checklist [X] I made sure that there are no existing issues - open or closed - to which I could contribute my information. [X] I have read the FAQ and my problem isn't listed. [X] I have taken the time to fill in all the required details. I understand that the feature request will be dismissed otherwise. [X] This issue contains only one feature request. [X] I have read and understood the contribution guidelines.
Is your feature request related to a problem? Please describe. It would be great to add JPEG XL support in the Gallery.
Describe the solution you'd like Could maybe be based on this: https://github.com/oupson/jxlviewer
Describe alternatives you've considered None
Additional context JPEG XL is a new modern image format, supporting both lossless and lossy compression. It has about 17-27% better compression than JPEG (mozjpeg), 15-24% better compression than WebP and 5-10% better compression than AVIF (source: https://cloudinary.com/blog/jpeg-xl-how-it-started-how-its-going) It is supported by default by all Apple devices, Linux (KDE and GNOME), various browsers (Safari, GNOME Web, Firefox Nightly, Pale Moon, Waterfox, ...) and well-known industry brand names have publicly voiced support for JPEG XL as their preferred choice, including Facebook, Adobe, Intel, Krita etc.
jxlviewer also provide a library so that other project can integrate jpeg-xl. However, it is not yet ready : it miss thumbnail loading and loading of image is not efficient enough for the moment.
If you want to try the gallery with jpeg-xl support I made a dirty fork here to experiment : https://github.com/oupson/Jxl-Gallery/
For a cleaner support, .jxl file extension should be added in photoExtensions in Commons.
If anyone want to try, there is another library supporting jpeg-xl : https://github.com/awxkee/jxl-coder.
Samsung has also jumped on the JPEG XL bandwagon since the Galaxy S24: https://r2.community.samsung.com/t5/CamCyclopedia/Introducing-the-Galaxy-S24-Camera-Gallery/ba-p/15350511
... Additionally, storage capacity has been reduced while maintaining image quality by providing JPEG XL format ...
... Additionally, storage capacity has beenreducedwhile maintaining image quality by providing JPEG XL format ...
I really hope this is a translation error on Samsung's part & they mean "optimized" or some such. 🤔
In my opinion, the most important feature of JPEG XL is bidirectional, lossless conversion between JPEG and JPEG XL. In other words, this feature would let me keep my whole media library on phone while reducing its size without actually having to sacrifice anything.
Yeah, that's the main reason I'm hoping this goes through. My phone is 7 years old pushing 8, got about 50 GB of photos so that'd be 10+ GB of savings for free
Had an additional thought. Assuming most are transcoding their old gallery of jpegs, the share button could transcode back for compatibility with other apps. Assuming someone makes a PR with libjxl anyway. Similar to Apple with HEIC, but lossless
@jonnyawsom3 Not a bad idea, but make it configurable a few ways b/c:
- Eventually, JxL will become widespread in its own right (e.g., it took PNG a good looong while)
- Don't assume that every JxL is a reconstructible JPG:
- The format has an extraordinary lossless mode far better than PNG's & usually better than WebP's
- The native lossy mode is designed to be best-in-class
- Even the lossless JPG transcoding doesn't have to keep that reconstruction data
Imho, should be chosen upon share button (before choosing receiving app):
- [ ] IfF construction data detected, offer to transcode back to JPG
- [ ] IfF regular lossless mode detected, offer lossless recode to WebP/PNG
- [ ] Always offer sharing JxL directly
@TPS Yeah, it would likely be enabled by default but an option you can disable. Then disabled by default when adoption is widespread
If reconstruction data is available, then share the transcoded jpeg. Otherwise fallback to the JXL file like a standard share
Considering this is a mobile app, and the compression JXL can manage, encoding to WebP or PNG could result in long wait times or files too large to reasonably share. The jpeg transcode is meant to be fast and efficient for exactly this use case. Once again, this is a mobile gallery app, so camera photos are the most likely kind of JXL to see
We don't want to end up with a cluttered UI and far more work for what should hopefully be a temporary issue. Sorry for dragging this out
so camera photos are the most likely kind of JXL to see
Lol. Not for me. I barely take (or receive) photos. I do, however, download tons of images from various sources. It would be nice to conveniently share them without having to worry about whether or not someone can view them. But, my main concern is being able to convert the downloaded images en masse and view them conveniently.
For example, I often casually download images from Pixiv, which allows artists to upload multiple images per post (sometimes above 100) and does not apply any aditional compression to them, which results in a very large download folder very quickly. Especially because the artists either can't into compressing efficiently or they're too concerned about marring their presented work. This results in tons of unnecessary PNGs and mysteriously bloated JPGs. And then I have to spend a ton of time after each spree sorting through and recompressing the images that are "too big," or I have to deal with not being able to update large apps, since my storage is only 32GB
So, I am very much in favor of not just adding viewing support but conversion support as well. @oupson 's fork works well, aside from performance issues (which may be due to how it is loading image previews, since it lags the moment I open a folder with JXL images in it and has the same lag when full-viewing them) and that it needs a non-JXL image file in order to display the folder. But, we'd need to decide which of libjxl's many settings to expose when converting images under the "resize" option. Do we just have the Distance/Quality slider? Or add a toggle for Lossless mode? How about the Effort setting? Expose it or just hardcode some defaults for lossless/lossy encoding to keep speeds good?
There's a JXL room on Matrix that bridges to the JXL Discord server where anyone here could ask the developers and contributors what they would recommend.
Re: cluttered UI This may be worth it, if we consider that the format may be more quickly adopted (in full) than others. When it reaches that point, we can add clarifying info in the "What's New" pop-up dialogue upon updating that explains "the JXL format is now at a point where it can be safely shared without worrying if someone can or can't open it, so we have finally deprecated the JXL-exclusive sharing features offering conversion (however, they can still be enabled in the settings." I'm adding that last part because it may make sense to keep some compatibility capabilities, but just hide them away a bit.
Also, I have one use case that I'm not sure the share function would take care of: uploading an image to a web site/service via the browser. I know that, even if it opens the system file manager, I can choose my file picker, but "sharing" usually just goes to an app and doesn't seem to follow the pipeline that file picking typically uses. 🤔 So, if I were posting to a social media site, like a Pleroma instance (it's like Mastodon and Misskey), and I preferred using the browser, then I may not be able to share the image. I'd have to convert it manually beforehand, since sharing to the browser (I don't think) shares it to the active tab or whatever web element activates the file picking thingy. Unless, of course, someone can figure out a way to have it convert in app (Gallery) and then offer that converted file to browser when picking an image. Or something like that.
JXL is now supported by DNG 1.7 so pros probably will be using it, guessing from how much support JXL has gotten in every issue that got rejected ( https://github.com/web-platform-tests/interop/issues/430 ). Samsung and Microsoft are also going to support it, so the only one not supporting it is Google. This gallery app recently added JXL support (only opening from file manager for now) https://github.com/IacobIonut01/Gallery/issues/145 so maybe looking at it may be useful for implementing here
so the only one not supporting it is Google
My hope is the external pressure will cause them to cave. That's why I think getting every FOSS project we can to support the format is ultimately a good thing.
The best thing would be for the internal team doing the stonewalling to have a free change of heart. But, realistically, I think they'll probably just be looking like this:
So jpeg xl support is still not planned for fossify? then i gonna spend some time and make a fix and a pull request for it...
Someone already implemented this in a fork of fossify gallery: https://github.com/oupson/Jxl-Gallery/releases/tag/1.1.0 Please consider it
Someone already implemented this in a fork of fossify gallery: https://github.com/oupson/Jxl-Gallery/releases/tag/1.1.0 Please consider it
Oh okay. Then what about putting its changes into main? Would that make a big issue somewhere?
I don't know. I didn't make that fork and don't know programming, just wanted to view jxl files and found it
That fork was already shared by Oupson in this issue a while back. @furdiburd I would recommend pinging one of the main contributors of Fossify and Oupson to double-check any ideas or concerns. I already mentioned there are some performance issues, but it seems the basic functionality merges fine.
Someone already implemented this in a fork of fossify gallery: https://github.com/oupson/Jxl-Gallery/releases/tag/1.1.0 Please consider it
Oh okay. Then what about putting its changes into main? Would that make a big issue somewhere?
This was a very work-in-progress proof of concept, so I intentionally made it non-mergeable with upstream. I have implemented the missing features that would be useful with a jxl integration in the gallery.
I intended to publish the library in central portal, but due to lack of time and documentation it is not done yet.
I already mentioned there are some performance issues, but it seems the basic functionality merges fine.
Btw same performance issues exist in rendering HEIC already. But not so bad after thumbnails are generated
I already mentioned there are some performance issues, but it seems the basic functionality merges fine.
A very interesting post on the subject (and also a lot of interesting other information to take): https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
Any updates on this? Can we get an official word from the development team? it seems a fork already exists
I would recommend better use jxl-coder for this implementation, because it have support of animated jxls, and much more, which is all implemented in my own app
Patience, my friend, patience. I'll get back here once I'm done with other apps.
I've been trying to be patient, man. But, I'm getting all fidgity waiting for my JXL fix. My internal storage really needs this. I'm also not sure what would finally convince Deckerst, since he's not the type to be pressured into doing anything.