[Feature Request] Support JPEG XL (JXL) #2669
Comments
|
google itself is abandoning this nonsense format as well, so dont expect having it |
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). 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. (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. |
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? |
|
sure |
|
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. |
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. |
Yes, that is what I linked to: https://github.com/oupson/jxlviewer 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:
Please add JXL support! |
Woo! Glad to see more apps supporting it.
Nice! I did some tests with GIMP and some of the online ones linked to on here: 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.
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. 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. |
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. |
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.
Which features are currently missing from the implementation?
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.
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.
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 |
Sorry, what? Format was finalized somewhere in march of 2022. Btw already supported by telegram. |
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 |
|
@mexicancartel No problem. I've had that happen to me, too. |
|
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. |
All thanks to Jarek and his ANS.
I don't think we should wait for encoder 1.0 release, because bitstream is already finalized and decoder part was finished long ago. |
@uis246 Thanks for mentioning this. A quick search brought up the fascinating info @ https://en.wikipedia.org/wiki/Asymmetric_numeral_systems |
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. 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. |
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. 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 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 |
|
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): uazo/cromite#351 |
Just came across this issue and thought I'd point out it's ecosystem wide support from Apple, Everything from Apple Watch and Safari to the new Vision Pro (We presume since it isn't quite out yet) |
|
@jonnyawsom3 SMT apps were sold to ad company. Fork is here https://github.com/FossifyOrg |
|
Ah, ironically it was the link in that issue which brought me here, my bad |
|
»Yes, Safari 17 supports JPEG XL. On macOS Sonoma, macOS Ventura and macOS Monterey, as well as iOS, iPadOS, watchOS, and soon, visionOS.« |
|
Someone already implemented this in a fork of fossify |
|
This project is no longer supported as it was. Fossify is the continuation and all requests should be redirected there. |
and others
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.
The text was updated successfully, but these errors were encountered: