Add JPEG XL support #3
Comments
|
Please adjust your feature request report to the issue template. EDIT: Thanks! |
|
You can use image toolbox for editing and previewing jxl 👀 |
|
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. |
|
SimpleMobileTools/Simple-Gallery#2669 (17 likes) |
|
Samsung has also jumped on the JPEG XL bandwagon since the Galaxy S24:
|
I really hope this is a translation error on Samsung's part & they mean "optimized" or some such. 🤔 |
|
Dont they just mean size of the image has been reduced while .... ? |
|
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. |
|
@jonnyawsom3 Not a bad idea, but make it configurable a few ways b/c:
Imho, should be chosen upon share button (before choosing receiving app): |
|
@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. 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 |
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 |
|
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. 🤔 |
|
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 ( web-platform-tests/interop#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) IacobIonut01/Gallery#145 so maybe looking at it may be useful for implementing here |
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. |
|
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... |
|
@furdiburd yes, please, PRs are welcome |
|
Someone already implemented this in a fork of fossify gallery: |
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. |
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. |
Btw same performance issues exist in rendering HEIC already. But not so bad after thumbnails are generated |
A very interesting post on the subject (and also a lot of interesting other information to take): |
|
Any updates on this? Can we get an official word from the development team? it seems a fork already exists |
(I tested the new 1.2.0 version) edit: looks like the pictures extension (.jxl) got somehow removed when I moved those from my pc |
|
Ah. So it can display JXL images but only when invoked by another program. Is that right? (Also, I misspoke. I meant to say "weren't", not "were" in my initial comment. Apologies.) |
|
Universal app size could lowered if we drop support for |
That's weird, I have a folder with both normal jpeg and jpeg xl, and I don't need any file manager to invoke the app, I just open the album and see both jpeg and jxl images there, all this without leaving the gallery app. |
Maybe you added those files using some unconventional method like |
Just needed to manualy add the file extension to the pictures, those somehow got cut from the filename when I copied those from my PC to the phone |
|
For the record, I don't want to force extra work on anyone but if application size with JXL library is a concern, I think JXL could be moved to a separately installed plugin. I don't know how that's exactly done, I'm afraid, but I've seen some apps doing that. |
|
Perhaps split apk building would be fine? I know gallery is used on x86 systems |
|
FYI, for directories containing jxl files to show up or even to open jxl images via intent, from a file manager for example, the app needs to be given access to all files and not just media files. This is because Android still doesn't recognize jxl as an image format. As it stands, support is still quite bare-bones. The plugin fails at decoding most practical resolutions. i.e. resolutions most smart phone cameras nowadays take photos at. |
|
can you give an example image it fails on? |
|
I created a small test image of SMPTE bars with the same dimensions and that didn't fail so I suppose it's not strictly a resolution issue. Here's a standard 12MP photo taken using a smartphone: https://files.catbox.moe/vs1iho.jxl Decoding fails like so: |
|
By the way, it's good that we're discussing jxl-format again. There is another bug that appears when viewing long (vertical) images. For example, screenshots of web pages. See, these are regular screenshots I took now, where two programs show what a long screenshot looks like, taken by a browser in png format and converted to lossless jxl using Image Toolbox. 1) Fossify gallery, 2) "Proof Of Concept of jpeg-xl integration in Simple Gallery". On the first screenshot the picture is blurred, on the second one it is clear. The blurring occurs starting from some height limit.
Tech. info by image: |
I have tasker losslessly recompress jpegs into jxls when they are created in my DCIM folder, using termux and libjxl's cjxl command. It seems to be a dimension limitation (or maybe filesize, they correlate), not lossy vs lossless. Fossify gallery correctly generates thumbnails for and loads the jxls that are 4000x3000, but fails to do both for the ones that are 8000x6000. I also tested a small lossless jxl I specifically encoded with modular mode, gallery had no issues displaying it. |
|
Dropping JXL support until awxkee/jxl-coder-glide#4 is resolved. |
|
Glad to see a fix is in the works. And thanks for taking this so seriously, instead of just leaving in a faulty implementation. Plus, I think (and hope) that the work you did to centralize awareness of the partial/regional decoding issues will help in driving selective pressure for them to get resolved at their source. |
|
Speaking of, could I (or you or anyone) open an issue ticket dedicated to just tracking the decoding issue? It'd make it easier to point to for people who haven't read this thread, if nothing else. |
|
|
@naveensingh Would you mind tagging a new release so that the JxL fixed support could be published @ F-Droid? |
No, these:
|
It'll be released soon, just need to make some little adjustments here and there. Update: https://github.com/FossifyOrg/Gallery/releases/tag/1.2.1
Feel free to raise one for JXL. We already have it raised for AVIF: #252 |
Decoding images of those sizes should be fine unless Glide requested image in original size. If you checked that image is not requesting in original size and still not loading raise an issue here or here |
|
@awxkee
Funny thing is that the old and demo version 1.1.0 of POC dev. Oupson handles all three tasks fine. Hence my question: what to do? Where to open the issue? :) |
1 - At the moment without region decoding it is intented |
and others
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.
The text was updated successfully, but these errors were encountered: