Simple-Gallery
Simple-Gallery copied to clipboard
SimpleMobileTools
[Feature Request] Support JPEG XL (JXL)
Since the format is not yet widely adopted and is finishing up finalizations, this is a placeholder request for later. The request is to completely support all features of the format, including animation, transparency, and maybe even the layers/extra channels. And to encode files to that format, as well.
google itself is abandoning this nonsense format as well, so dont expect having it
nonsense format
Could you elaborate on why you consider it a nonsense format?
While that particular team has announced the dropping of support from Chromium, their reasoning has universally been considered less than satisfactory (as seen in the official issue tracker). Many large companies have voiced their support for the format, including their displeasure at the Chromium team's decision, including Adobe, Facebook, Shopify, The Guardian (newspaper), FFmpeg, nvidia, Intel, and more (examples pictured below). There is also a sizable list of software that has adopted the format early, including Krita and GIMP, Affinity, Qt/KDE (including Gwenview), PAINT.net, MacOS viewer/QuickLook plugin, Windows Imaging Component & thumbnail handler, and more.
Even though it is still early, it could be useful to add support for it. When I started a thread on a technology message board, several users asked specifically about support appearing in this app, even though the topic was just generally about the format and Google's move and not mobile apps support. Here is the official encoder reference implementation: https://github.com/libjxl/libjxl
(Example comments from developers and representatives on the Chromium issue ticket)
I dont see any use of it yet. Once it is used anywhere, we will reconsider it.
I dont see any use of it yet. Once it is used anywhere, we will reconsider it.
Thank you. This is reasonable. Would it be alright to leave this issue open, so that it doesn't get lost/forgotten and so others can more easily see it and your stated precondition?
I reached this page after searching a lot for how to open a jxl image. I was experimenting converting jpeg into jxl. I mean if implementing is hard just leave it but i would like to see this added even if its the bare ability to 'unstably' view the image. I see zero image viewers compatible with jxl on android
I think it's too soon for it to be implemented in this app, especially since the developer is not personally interested, right now. Let's let it develop a bit further (libjxl) before expecting it in our gallery apps. In the mean time, on the JPEG XL issue for Aves, someone shared this project that looks like a proof-of-concept for JXL support in Android applications. I haven't tried it out, but I'd suggest going there to give feedback while we're still in the experimental stage. I also tried out the JXL format when I saw it available in GIMP. My JPG was 2.7~MB, while the JXL was 1 at the same visual quality (I just used defaults). Thankfully, KDE has good initial format support, so I had no problem viewing thumbnails or full versions of the image. I'm really excited about it, but I'm also trying to be realistic about where it's at and how to proceed.
I think it's too soon for it to be implemented in this app, especially since the developer is not personally interested, right now. Let's let it develop a bit further (libjxl) before expecting it in our gallery apps. In the mean time, on the JPEG XL issue for Aves, someone shared this project that looks like a proof-of-concept for JXL support in Android applications. I haven't tried it out, but I'd suggest going there to give feedback while we're still in the experimental stage. I also tried out the JXL format when I saw it available in GIMP. My JPG was 2.7~MB, while the JXL was 1 at the same visual quality (I just used defaults). Thankfully, KDE has good initial format support, so I had no problem viewing thumbnails or full versions of the image. I'm really excited about it, but I'm also trying to be realistic about where it's at and how to proceed.
I just really wanna use it and there is almost no apps out there which can open jxl images. Moreover how would an image format gain any amount of popularity if people can't even open it? Well you are right maybe it needs more developement i can't say if its developed enough but i was able to view jxl with firefox nightly so well i don't see anything wrong with the image developement yet. Or maybe we just need a seperate app for just opening jxl images untill its developed entirely
Or maybe we just need a seperate app for just opening jxl images untill its developed entirely
Yes, that is what I linked to: https://github.com/oupson/jxlviewer If you look at the closed issues and pull requests, you'll see they made an effort to have a standalone JXL library that other android apps can implement. They are doing very good work. Also, it seems they might be building a user interface for converting other formats to JXL inside the app (still an open issue).
They might be key to pushing support forward, so I would suggest giving them a try and make issues on their Github, for now.
Hello, since yesterday Darktable can export to JXL and my first tests are fantastic:
- quality
- size
- speed
- format options
See https://jpegxl.info
Please add JXL support!
Hello, since yesterday Darktable can export to JXL
Woo! Glad to see more apps supporting it.
and my first tests are fantastic:
- quality
- size
- speed
- format options
Nice! I did some tests with GIMP and some of the online ones linked to on here:
See https://jpegxl.info
I'm surprised how good AVIF and the (now deprecated) WebP2 formats do with preserving accurate detail at low quality settings, even compared to JXL. But, I was also surprised at how big the difference was in file size between JXL and AVIF when doing lossless compression. JXL was noticeably smaller by a pretty decent margin. And, of course, both were far surperior to PNG.
Please add JXL support!
He said he will when he sees more general support for the format. We're getting there, slowly but surely. But, we're not there, yet. In the mean time, besides generally encouraging developers everywhere to consider implementing at least basic support, I would recommend focusing your efforts towards supporting https://github.com/oupson/jxlviewer and the work he's doing, as well as giving strong encouragement to Mozilla to add full support in Firefox. I might make an account on their Bugzilla site just to do that. Pale Moon is currently the only browser that has formally adopted support for JXL, without hiding it behind an experimental flag. It is based on an older version of Firefox, so I don't know if that will help the Mozilla version or not. But, Firefox now has the chance to be an innovator and leader in an industry shift (something it hasn't been able to do in quite a while).
Correction: I said Bugzilla, but apparently the place to +1 this is here - https://connect.mozilla.org/t5/ideas/support-jpeg-xl/idi-p/18433
JPEG XL is a great format, but the file format is currently under development and many things are missing. I tested many things with the new format (loseless transcoding jpg to jpeg xl, etc.).
For Android devices (smartphone and tablets) the webp format is at the moment the best format to save space, get a high quality pictures, best compatibility, save battery power und saving picture files within this format is very fast.
I also tested AVIF format, which Simple gallery pro can read, but the performance, battery usage and writing in this format is extremly slow at highest quality level.
Best tools under Windows to save these file format: XnViewMP (supports reading/writing AVIF, JPEG XL, HEIF/HEIC, WEBP).
If you want great quality and great compression you can use HEIC Format under Android 12 or higher in Simple Gallery Pro. The reading of this format is slow. That is the reason, why I currently use webp format for photos on tablet for viewing.
The reading of this format is slow. That is the reason, why I currently use webp format for photos on tablet for viewing.
I guess that's because of gpu acceleration. You may also try viewing HEIC on older android devices, its so much slower than jxl. Jxl will be faster when devices ships JXL hardware acceleration. I hope having more apps supporting jxl, and browsers too, results in making it popular and supporting hardware accrleration. I didn't see any problems in jxl regarding "under developement" or "missing features" yet.
WebP
One of the reasons I say "ew" is because it degrades the image quality in a particular way with a smoothing/blurring effect, compared to the minor noise added by JPEG. I agree it does save space, but it hasn't been worth it, in my subjective opinion. Plus, there are still cases where sharing of the format is not possible (particular websites). So, it is more convenient for me to stick to JPEG, unless it's a case where PNG compresses better (eg plain text on sokid color background) or I need transparency.
Missing features
Which features are currently missing from the implementation?
Hardware acceleration
From what I understand, the goal is to have the encoder/decoder library not need hardware acceleration to perform at that expected speed. It's obviously not there, yet. But they seem confident they will achieve this goal (from what little I've heard). One thing that has come from this effort is a new potential encoder/decoder for regular JPEG that is higher quality and as fast, if not faster than mozjpeg. It's called jpegli. We'll see where it goes.
Best tools under Windows
Thanks for the tip. I'm currently using Linux with a KDE desktop environment and it supports viewing these formats out of the box. GIMP is good for exporting them, especially since it gives you full settings controls (not sure about XnViewMP) and is cross-platform.
Not there yet
That's why we're waiting, but also pushing for initial support. We want this format to succeed, so it's important to have it be usable in the real world once the format itself is fully usable in the real world. If you look above, you'll see a link to the Mozilla discussion page where you can voice your support. You'll also find my reasoning why everyone should, even if you are not a Firefox user.
Edit: Also, I just came across this in the pull requests for libjxl when I was searching for jpegli: less ringing for anime It is an improvement designed specifically to get higher quality images in both the manga and anime style, which typically are hit the hardest and worst by the traditional JPEG compression artifacts. This will be a good selling point for regular users and artists, as well as hosting services like Pixiv, DeviantArt, or even Facebook and Twitter.
JPEG XL is a great format, but the file format is currently under development and many things are missing.
Sorry, what? Format was finalized somewhere in march of 2022.
Btw already supported by telegram.
The reading of this format is slow. That is the reason, why I currently use webp format for photos on tablet for viewing.
I guess that's because of gpu acceleration. You may also try viewing HEIC on older android devices, its so much slower than jxl. Jxl will be faster when devices ships JXL hardware acceleration. I hope having more apps supporting jxl, and browsers too, results in making it popular and supporting hardware accrleration. I didn't see any problems in jxl regarding "under developement" or missing features yet
@mexicancartel Why did you post the same response again?
Whoopssss sorry... Last time i opened the same page my comment was there in the input box. I thought i didn't sent that and clicked comment again. Sorry
I've had a large collection of images on my phone that were taking up a lot of space. After converting them to jxl i've had more than half size reduction 16gig>7 at no quality loss. This format should really be getting implemented everywhere.
I agree. One thing to wait for is the 1.0 release of the referrence encoder (currently working on 0.9). Once they're satisfied enough with the state it's in to release that, then we should see more and more official software including support for it. Also because, by that point, other implementations of the encoder (Java, Rust versions, etc.) should be mature enough to make it easy for app developers to implement what they need into their app for it to support JXL.
The two software tools we're really waiting for to support it are Photoshop and Chrome. Some forks of Chrome and Firefox support it pretty well out of the box (Thorium, Pale Moon, Waterfox), but once those main programs support it, everything else should follow suit a lot quicker.
I've had a large collection of images on my phone that were taking up a lot of space. After converting them to jxl i've had more than half size reduction 16gig>7 at no quality loss. This format should really be getting implemented everywhere.
All thanks to Jarek and his ANS.
I agree. One thing to wait for is the 1.0 release of the referrence encoder (currently working on 0.9). Once they're satisfied enough with the state it's in to release that, then we should see more and more official software including support for it. Also because, by that point, other implementations of the encoder (Java, Rust versions, etc.) should be mature enough to make it easy for app developers to implement what they need into their app for it to support JXL.
I don't think we should wait for encoder 1.0 release, because bitstream is already finalized and decoder part was finished long ago.
All thanks to Jarek and his ANS.
@uis246 Thanks for mentioning this. A quick search brought up the fascinating info @ https://en.wikipedia.org/wiki/Asymmetric_numeral_systems
I don't think we should wait for encoder 1.0 release, because bitstream is already finalized and decoder part was finished long ago.
Part of what I meant was waiting in general, rather than expecting JXL to be a universally adopted standard today. There's still a lot of irregularities and areas to be improved, and even whole features to be added, if the JPEG XL Matrix/Discord bridged channel is anything to go by. For gallery apps, I partly agree, but both Simple gallery Pro and Aves have the ability to encode (either reencoding or transcoding) to a number of the formats they can read. So, it would be beneficial for them to be able to easily support encoding out of the box, as well, without having to do much of the leg work themselves. Another reason I was encouraging the waiting is because neither developer (of SGP or Aves) seems to have any personal interest in the format, let alone putting in extra work to support it. Both of them seem to be waiting for more ubiquitous adoption first, which would likely happen sometime around or after the 1.0 release of the reference encoder, given the steady and gradual rate of adoption by software and the regular improvements to the encoder.
In all honesty, it's pretty amazing how JXL is getting adopted so much, despite being so new of a format compared to even AVIF and without anywhere near the same level and kind of industry backing. So, I'm comfortable with being patient, for now. But, I am definitely eagerly awaiting the day when I can just easily batch convert all my image files and not worry about whether or not I can share them with friends or on the web or not.
google itself is abandoning this nonsense format as well, so dont expect having it
You surely should have information that I don't have but from what I get, to the contrary, it seems to be a very appealing format.
Just the lossless jpeg recompression with a gain of around 20% is a killer feature for all the web images. In term of performance (quality of result and speed of compression and decompression ) is seems to perform better that all the contenders.
And the impressive progressive decoding feature (ok, it's for the web...): https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-jpeg-xl-images.html
And jpeg XL offer more features that would allows it to be used in a broader usage than other file format
Google move seems to be for reasons outside the technical one and reasons given seems also be bad faith...
You could get more information on all that here (really interesting read!): https://cloudinary.com/blog/the-case-for-jpeg-xl Or here: https://jpegxl.info/
A summary:
The only thing missing to Jpeg-XL is the broad adoption and on that, you could help!
So it would be great if Simple Gallery become one of the first gallery supporting this very good file format on Android!
I think he gets it, by now. Lol
If you read the rest of the discussion in this issue, we already hammered that point home pretty hard. (Your post is very well formatted and presented, though)
He basically develops this app as he feels like it. Pressuring him will not help speed things up. So, let's let him get around to it if/when he decides to and give encouragement to other app developers, since broader adoption is what's needed (as you stated) and is what tibbi said he intends to wait for.
And, I believe, this is an updated version of the "Industry Support" graphic I shared earlier.
I don't get why would we wait for mass adoption without adopting it ourself. Like if everyone waits for everyone else to adopt it its not gonna get mass adopted. Simple Gallery is very simple but suppots a lot of formats unlike many other gallery apps. So in my opinion this app is one of the first few apps to adopt jxl as it already does support lot of niche formats we don't normally use while with jxl i can save a lot of space in my device too without tiny bit of quality loss.
In short, we are the ones that should mass adopt. And the lack of a gallery app in android which supports jxl is the thing preventing mass adoption(for me atleast).
So for some reason this has no "feature request" tag (AV1 issue has one).
Tachiyomi (and forks like TachiJ2K which I prefer for manga reading) has JXL support as well btw. If you just need a way to view files on Android and a basic organization into titles and chapters then that can serve you. So yeah in principle it can be used as a gallery app but it is a bit more setup work and not a "simple" gallery app.
Would be great to see this. It is now a natively supported format on iPhones and arguably the best image format around at the moment
I recently successfully advocated for support to be included in the privacy browser Cromite (fork/continuation of Bromite): https://github.com/uazo/cromite/issues/351 The main issue preventing adoption for mobile is support in browser and gallery amd camera apps. So far, Thorium and Cromite satisfy the first. And, hopefully, this will help others like Brave and Vivaldi, and finally Firefox, support it, too. I'm not sure this success is enough to tip the scales for Simple Gallery Pro, but it's definitely a large step in that direction. I'll also inform the developer of Aves, too. And, if any of you want to push for other app devs to include it, please do.