-
Notifications
You must be signed in to change notification settings - Fork 384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for JXL (JPEG XL) #692
Comments
Lossless compression to 47% of PNG is very impressive. How does lossless webp compare? And what level of zlib compression in the png was used in your study? As you saw in #546, I have no interest in adding yet another image compression format to support in leptonica. It's a huge amount of work with each format, because (1) these formats all have many features and for any feature there exist people who want it supported, (2) the reading and writing shims have to be meticulously tested with fuzzing to prevent attacks that can cause any type of failure, including crashes, memory overruns and memory smashes. For jpeg xl, we have the additional problem that Google has removed (or is in the process of removing) support in Chrome; e.g.,
Leptonica was an early adopter with webp, because I saw the level of internal support at Google, and I understood the advantages in perceptual quality and rate/distortion that webp has using wevelet encoding, compared to jpeg's DCT. I'm fine with waiting a few years to see how things progress with support for jxl. |
I did not do excessive tests with WebP since I saw this table that somebody created a while ago: https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/ Regarding zlib compression level: Regard adding it JXL to leptonica: Maybe some kind of development fund could be used here in case funding is an issue... I know that Germany has quite a few. And well... Google's Chromium is a web browser. Sure, the web is important nowadays but should not be the main factor when it comes to determining if it is worth supporting a file format or not (especially not if the decision to not include it in the browser was made against a lot of known — and some very huge — names in the IT space — Facebook, Adobe, Intel, VESA, Krita, The Guardian, libvips, Cloudinary, Shopify. CTRL+F here: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 — and just to push a overall worse format). Most formats are not used on the web anyways and there are actually JXL viewer extensions for web browsers. Well, maybe somebody with some free time and enough experience with image formats sees this issue and decides to contribute here. |
I appreciate your interest and concern with efficient codecs. I have been responsible for the generation and storage of about 100 pB of images, so I share your interest and understand the importance of using good compression. And when I first heard about jxl it seemed like a codec worth supporting, especially if the high-level interface to the library is essentially the same as jpeg. As mentioned above, I haven't given up on it. Decisions on which codecs to support are complicated. Leptonica was an early adopter of the openjpeg implementation of jpeg2000 (because it uses wavelet compression which avoids jpeg DCT artifacts at edges), and it was a mess, with interfaces changing over the first 5 years, and very poor encoding performance. I also reluctantly wrote shims for gif, which for 20 years had patent issues with their compression, has relatively poor universal compression, max of 256 colors, and a big interface change about 5 or 6 years ago with gif5. But it has widespread use, so supporting it in leptonica was the right thing to do. Direct monetary support for leptonica development has never been an issue, or a consideration. I understand that interest in jxl will continue to grow, especially if the codex library can be made fast (especially decoding) and effective for both lossy and lossless compression compared to other wavelet-based codecs. We'll keep the issue open. |
Ah, I see. Thanks for keeping it open. I got a reply from a xfce4-screenshooter dev and they told me it is likely zlib compression level 5: Can't say much about changing interfaces for JXL. But "the file format and core coding system were formally standardized on 13 October 2021 and 30 March 2022 respectively" (https://en.wikipedia.org/wiki/JPEG_XL) and all JXL files created with that standard since then will be decodable by future versions. Also yep, it seems like there is a lot of potential to make handling JXL faster (and less memory using): |
Small update: Looks like the iOS 17 beta introduces OS-level JXL support. They also have JPEG XL on Safari release notes: https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes |
I saw #546 in which JPEG XL was mentioned in a few comments and decided to create this separate issue so that discussion can be done here instead of in an issue that is about a different format.
I want to use a software using this library to search text in screenshots stored in JXL. But this library doesn't support JXL yet.
I have hundreds of thousands in screenshots in JXL by now since those files take on average, after lossless convertion only about 47% of the space compared to when they were PNG (
cjxl -q 100 -m 1 -e 9 --brotli_effort 11 -E 3 -I 100 -g 3 -j 1 in.png out.jxl
).No other common file format can compete there.
It could be even better now since 0.8.1 is out but I used 0.7 to test this (1777M PNG → 838M JXL after converting 1681 screenshots; ca. 52.841868 % reduction); in 0.6.1 I achieved about 53% new size (after converting 163552 screenshots by using
cjxl -q 100 -m -s 9 -E 3 -I 1
: 112216M → 59561M; ca. 46.9228986953732 % reduction. I know those are way more images but I tried 0.7 with images I converted before and did not want to spend months to get a preciser value after the comma. Also, no: I did not switch reduction and total size on accident, even tho it is kinda funny how those reduction values changed).In a recent release -e 10 was introduced but it is experimental and it takes way longer to complete and way more RAM (20 GiB+ and almost 2 hours for a image of about one Megs; -e 9 takes usally less than 1 GiB and maybe one minute on my machine with a Ryzen 7 3700X) and thus I have only done tests with very few files with -e 10 so far and got varying results from additional 0.5 percent points to 6 percent points saved.
The text was updated successfully, but these errors were encountered: