Jpegli: A new JPEG coding library
opensource.googleblog.com
opensource.googleblog.com
The suffix -li is used in Swiss German dialects. It forms a diminutive of the root word, by adding -li to the end of the root word to convey the smallness of the object and to convey a sense of intimacy or endearment.
This obviously comes out of Google Zürich.
Other notable Google projects using Swiss German:
https://github.com/google/gipfeli high-speed compression
Gipfeli = Croissant
https://github.com/google/guetzli perceptual JPEG encoder
Guetzli = Cookie
https://github.com/weggli-rs/weggli semantic search tool
Weggli = Bread roll
https://github.com/google/brotli lossless compression
Brötli = Small bread
Apparently Zopfli = small sweet breat
And write it in Rust
I’ve never seen a .tar.br file, but I frequently download .tar.xz files.
And therefore, a Rust implementation by Google of xz compression and decompression would be most welcome :)
For example in C++ array[index] has Undefined Behaviour on a bounds miss. Rust's array[index] will panic at runtime on a bounds miss, at least we know what will happen but what happens isn't great... WUFFS array[index] will not compile if it could incur a bounds miss. Show the compiler why index will be a value that's always in-bounds when the index occurs.
$ git clone --quiet --depth=1 https://github.com/google/wuffs.git
$ gcc -O3 wuffs/example/mzcat/mzcat.c -o my-mzcat
$ ./my-mzcat < linux-6.8.2.tar.xz | sha256sum
d53c712611ea6cb5acaf6627a84d5226692ae90ce41ee599fcc3203e7f8aa359 -
$ /usr/bin/xz -d < linux-6.8.2.tar.xz | sha256sum
d53c712611ea6cb5acaf6627a84d5226692ae90ce41ee599fcc3203e7f8aa359 -
No need to trust – it's actually easily verified :) Your activity pattern (blue) is entirely different than jia tan's (orange): https://i.k8r.eu/vRRvVQ.png
(Each day is a row, each column is an hour in UTC. A pixel is filled if a user made a commit, wrote a comment, etc during that hour)
> Is it possible? Definitely. But that's extremely rare, especially if you want to keep a relatively natural pattern for the commits and replies.
> You'd basically have to have a team of devs working at really odd times and a queuing system that automatically queues all emails, github interactions, commits, etc to dispatch them at correctly distributed timestamps.
> And you'd need a source pattern to base your distribution on, which is hard to correctly model as well.
Note that while what you suggest is possible, it'd become visible if you look at issues, questions, emails, etc sent to the project author and how long it took for the author to reply to them. If you plot this reply delay by the hour of day that the message arrived, a pattern emerges.
Still, Wuffs doesn't use autotools, and if you're pulling the library from the https://github.com/google/wuffs-mirror-release-c repository then that repo doesn't even contain any binary-data test files.
Seems similar to -let in English.
JPEGlet
Or -ito/-ita in Spanish.
JPEGito
(Joint Photographers Experts Grupito)
Or perhaps, if you want to go full Spanish
GEFCito
(Grupito de Expertos en Fotografía Conjunta)
Hell, I question if AVIF is even worth it with Jpegli.
It's obviously "better" (higher compression) but wait! It's 1) a crappy, limited image format for anything but basic use with obvious video keyframe roots and 2) terribly slow to encode AND 3) decode due to not having any streaming decoders. To decode, you first need to download the entire AVIF to even begin decoding it, which makes it worse than even JPEG/MozJPEG in many cases despite their larger sizes. Yes, this has been benchmarked.
JPEG XL would've still been worth it though because it's just covering so much more ground than JPEG/Jpegli and it has a streaming decoder like a sensible format geared for Internet use, as well as progressive decoding support for mobile networks.
But without that one? Why not just stick with JPEG's then.
I believe Jpegli beats WebP for medium to high quality compression. I would guess that more than half of all WebP images on the net would definitely be smaller as Jpegli-encoded JPEGs of similar quality. And note that Jpegli is actually worse than MozJPEG and libjpeg-turbo at medium-low qualities. Something like libjpeg-turbo q75 is the crossover point I believe.
> Hell, I question if AVIF is even worth it with Jpegli.
According to another test [1], for large (like 10+ Mpix) photographs compressed with high quality, Jpegli wins over AVIF. But AVIF seems to win for "web size" images. Though, as for point 2 in your next paragraph, Jpegli is indeed much faster than AVIF.
> JPEG XL would've still been worth it though because it's just covering so much more ground than JPEG/Jpegli and it has a streaming decoder like a sensible format geared for Internet use, as well as progressive decoding support for mobile networks.
Indeed. At a minimum, JXL gives you another 20% size reduction just from the better entropy coding.
[1] https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
That was what I expected a long time ago but it turns out to be a false assumption. According to Google with data from Chrome. 80%+ of images on the web are bpp 1.0+.
May I ask how you came to this conclusion?
The Cloudinary article appears to show jpegli beating mozjpeg and turbojpeg even at the "Medium" setting (less bits per pixel).
There was an earlier version which was not very good at medium or low quality, but Zoltan fixed that about six months ago.
The good thing is that the author of XL ( Jyrki's ) claims there are potential of 20-30% bitrate savings at the low end. So I hope JPEG XL encoder continues to improve.
We also provide a ~7000 lines-of-code libjxl-tiny that is more similar to jpeg encoders in complexity and coding approach, and a great starting point for building a hardware encoder.
This reminded of something. I so wish iOS 18 could support JPEG XL out of the box rather than Safari only. I have 80GB of Photos on my iPhone. Vast Majority of them were sent over by WhatsApp ( JPEG ). If iOS could simply recompress those into JPEG XL I would instantly gain ~10GB+ of storage.
It can be a question of if the photo fits as an email attachment etc.
'Zillions' of seconds of aggregate latency waiting time is spent each day on waiting for web sites to load. Back-of-the-envelope calculations can suggest that the value of reducing waiting time can be in hundreds of billions over the whole time of the deployment. Bandwidth cost to users and energy use may also be significant factors.
Looking further [1]:
> It consists in requiring a choice between two different distortions of the same image, and computes an Elo ranking (an estimate of the probability of each method being considered higher quality by the raters) of distortions based on that. Compared to traditional Opinion Score methods, it avoids requiring test subjects to calibrate their scores.
This seems like a bad way to evaluate image quality. Humans can tend towards liking more highly saturated colours, which would be a distortion of the original image. If it was just a simple kernel that turned any image into a GIF cartoon, and then I had it rated by cartoon enthusiasts, I'm sure I could prove GIF is better than JPEG.
I think that to produce something more fair, it would need to be "Given the following raw image, which of the following two images appears to better represent the above image?" The allowed answers should be "A", "B" and "unsure".
ELO would likely be less appropriate. I would also like to see an analysis regarding which images were most influential in deciding which approach is better and why. Is it colour related, artefact related, information frequency related? I'm sure they could gain some deeper insight into why one method is favoured over the other.
[1] https://github.com/google-research/google-research/blob/mast...
It appears this was in response to Hacker News comments.
android with google photos did/does this whereas apple went with enhanced contrast.
as far as i can tell, they're both wrong but one mostly notices the 'distortion' if used to the other.
If you must use JPEG, I suspect you might get better visual quality by halving the resolution and upsampling on the client.
By doing so, you are effectively setting the lower and right halves of the DCT to zero (losing all high resolution info), but get to have 32x32 pixel macroblocks which lets you better make use of low frequency spacial patterns.
There are infinite use-cases for everything beside one's own tiny personal experience and imagination. It's not remarkable that someone tested for the best version of something you personally don't have a use for.
Pretend they hadn't answered the question. The answer is it doesn't matter.
They stated a goal of x, and compared present-x against testing-x and found present-x was the better-x.
"Why do they want x when I only care about y?" is irrelevant.
I mean you may be idly curious and that's not illegal, but you also stated a reason for the question which makes the question not idle but a challenge (the "when I only care about y" part).
What I mean by "doesn't matter" is, whatever their use-case is, it's automatically always valid, and so it doesn't change anything, and so it doesn't matter.
Their answer happened to be something you probably agree is a valid use-case, but that's just happenstance. They don't have to have a use-case you happen to approve of or even understand.
How are the extra bits encoded?
Is this the JPEG_R/"Ultra HDR" format, or has Google come up with yet another metadata solution? Something else altogether?
Ultra HDR: https://developer.android.com/media/platform/hdr-image-forma...
Ultra HDR is a standard SDR JPEG + a gain map that allows the construction of an HDR version. Specifically it's an implementation of Adobe's Gain Map specification, with some extra (seemingly pointless) Google bits. Adobe gain Map: https://helpx.adobe.com/camera-raw/using/gain-map.html
Hypothetically, both jpegs can be created with jpegli.
Hypothetically, both Ultra HDR jpegs can be decoded with jpegli.
In theory jpegli would remove the 8 bit striping that would otherwise be present in Ultra HDR.
I am not aware of jpegli-based Ultra HDR implementations.
A personal preference for me would be a single Jpegli JPEG and very fast great local tone mapping (HDR source, tone mapping to SDR). Some industry experts are excited about Ultra HDR, but I consider it is likely too complicated to get right in editing software and automated image processing pipelines.
Does anyone have a link to any example images that illustrate this improvement? I guess the examples would need to be encoded in some other lossless image format so I can reliably view them on my computer.
Here's an original: https://gist.githubusercontent.com/simonw/5a8054f18f9ea3c560...
And the jpegli-q95- version: https://gist.githubusercontent.com/simonw/5a8054f18f9ea3c560...
And the same thing with mozjpeg-a95 https://gist.githubusercontent.com/simonw/5a8054f18f9ea3c560...
Not true. Even just within libjpeg, there are three different IDCT implementations (jidctflt.c, jidctfst.c, jidctint.c) and they produce different pixels (it's a classic speed vs quality trade-off). It's spec-compliant to choose any of those.
A few years ago, in libjpeg-turbo, they changed the smoothing kernel used for decoding (incomplete) progressive JPEGs, from a 3x3 window to 5x5. This meant the decoder produced different pixels, but again, that's still valid:
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/6d91e9...
I believe the standard does not specify what the intermediate progressive renderings should look like.
I developed that interpolation mechanism originally for Pik, and Moritz was able to formulate it directly in the DCT space so that we don't need to go into pixels for the smoothing to happen, but he computed it using a few of the low frequency DCT coefficients.
This is possibly getting too academic, but IIUC for a progressive JPEG, e.g. encoded by cjpeg to have 10 0xDA Start Of Scan markers, it's actually legitimate to post-process the file, truncating to fewer scans (but re-appending the 0xD9 End Of Image marker). The shorter file is still a valid JPEG, and so still relevant for discussing whether all decoders will render the same pixels.
I might be wrong about validity, though. It's been a while since I've studied the JPEG spec.
Nonetheless, for this particular case, comparing jpegs decoded into lossless formats is unnecessary -- you can simply compare the two jpegs directly based on the default renderer in your browser.
Granted, the introduced artefacts aren't massive, but under certain circumstances they are noticeable, which is how I stumbled across that topic in the first place.
Thankfully, most software that isn't still stuck on libjpeg 6 has switched to libjpeg-turbo or some other library instead which continues using a more sensible algorithm for chroma upscaling.
Some earlier results. Perhaps these were with XYB color space, I don't remember ...
Finally, writing "ELO" instead of "Elo" is incorrect (this is just one of my pet peeves but indulge me nevertheless). This is some guy's name not an abbreviation, nor a prog rock band from the 70's! You would not write "ELO's" rating system for the same reason you wouldn't write "DIJKSTRA's" algorithm.
Looks like this is the implementation.
I mean, of course this is still valuable (JPEG-only consumers will probably be around for decades, just like MP3-only players), and I realize Google is a large company, but man, the optics on this...
It’s so prominent running into files you can’t open in your tools that I have a right click convert to PNG context menu
Because Chromium doesn’t support it, Electron doesn’t.
Because Electron doesn’t, Teams and other modern web apps and web sites don’t either, etc…
If Google just added JPEG XL support instead then it would be… a supported alternative to JPEG.
You’re saying working in that is a waste of time because… it’s not supported.
These formats are in Chromium because of Google politics, not because of their technical merit.
And a graphics format better be damn good (i.e. much, not just a little bit, better than what it's hoping to replace) if it aspires to become widely supported across applications, operating systems, libraries etc.
The article has 35% compression improvements over JPEG mentioned and that's at least as much as usually thrown around when discussing WebP.
If I had just used the internet quality images, WebP lossless would have improved size by -42 %.
Yet another 'marketing textbook' way to overstate -42 % is to turn it into 'loading speed': 1/(1-0.42) = 72 % faster.
None of this was made for the lossless and the most conservative estimate was shown. I didn't do any hacking or cherry picking to produce the number and I had several internal verification approaches to be correct.
It's really hard to say this in public, because people are treating it like a divisive "us or them" issue that's obvious, but the JPEG-XL stuff is _weird_.
I've been in codecs for 15 years, and have never seen as unconstructive behavior like the JPEG-XL work. If I had infinite time and money and it came across my plate, we'd have a year or two of constructive work to do, so we didn't just rush something in with obvious issues and opportunities.
It turned into "just figure out how to merge it in, and if you don't like it, that's malfeasance!" Bread and circus for commentators, maybe, but, actively preventing even foundational elements of a successful effort.
In light of the recent security incident, I'd see that completely hypothetical situation as more admirable.
In that case, that would just be extremely bad messaging (which I also wouldn't put past Google). Why agitate half of the people on here and in other tech-affine parts of the Internet when they could have just publicly stated that they're working on it and to please have some patience?
Public support by Google, even if it's just in the form of a vague "intent to implement", would be so important for a nascent JPEG successor.
I use asking questions as a way to keep contentious discussions on track without being boorish. And you're right, it can easily be smarmy instead of Socratic without tone, a la the classic internet sarcasm problem.
Gentle note: I only asked one question, and only in the post you replied to.
Same thing with Firefox, which has had basic support merged into Nightly, and a couple more patches gathering dust due to lack of involvement from the side of Firefox. Mozilla has since decided to take a neutral stance on JPEG XL, seemingly without doing any kind of proper evaluation. Many other programs (like GIMP, Krita, Safari, Affinity, darktable) already support JPEG XL.
People are not getting upset because projects don’t invest their resources into supporting JPEG XL. People are getting upset because Google (most notably), which has a decisive say in format interoperability, is flat out refusing to give JPEG XL a fair consideration. If they came up with a list of fair conditions JPEG XL has to meet to earn their support, people could work towards that goal, and if JPEG XL failed to meet them, people would easily come to terms with it. Instead, Google has chosen to apply double standards, present vague requirements, and refuse to elaborate. If anyone is ‘preventing even foundational elements of a successful effort’, it’s Google, or more specifically, the part that’s responsible for Chromium.
I read the parent post as saying that this is the problem, i.e. that "complete" support is a mess, because AFAIK even the reference implementation is incomplete and buggy, and that then getting angry at the consumers of it is besides the point and won't lead anywhere (which is what we see in practice).
Browsers supporting a format "a little" is almost worse than not supporting it at all, because it makes the compatibility and interoperability problems worse.
It isn't not accepting it or hostile. That is completely not true.
They actively push against JPEG XL, despite all the data, prior to even 1.0 suggest it is or could be better than AVIF in many cases. To the point where they even make up false benchmarks to downplay JPEG XL.
Companies were even willing to paid ( wont name ) and put resources into getting JPEG XL because they see it to be so good. But they still refused.
It is at this point people thought something doggy is going on. And then not only did Google not explain themselves. They were even more hostile.
So why the extra hate? Well partly because this is a company who gave us an over promised WebP and underdelivered.
Before making that kind of claim, I would spend some time looking at the names of the folks who contributed heavily to the development of JPEG XL and the names of the folks who wrote jpegli.
Here: https://www.mail-archive.com/blink-dev@chromium.org/msg04351...
"can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format"
It's a yes!
Of course full JPEG XL is quite a bit better still, but this helps old compatible JPEG to support HDR without 8-bit banding artefacts or gainmaps, gives a higher bit depth for other uses where more precision is valuable, and quite a bit better compression, too.
Only within pretty narrow limits.
Classic JPEG will never be as efficient given its age, in the same way that LAME is doing incredible things for MP3 quality, but any mediocre AAC encoder still blows it out of the water.
This is in addition to the things you've already mentioned (HDR) and other new features (support for lossless coding).
And I'd find their sentiment much easier to believe if Google/Chrome weren't hell-bent on making WebP (or more recently AVIF) a thing themselves! That's two formats essentially nobody outside of Google has ever asked for, yet they're part of Chrome and Android.
Reminds me of "You Scientists Were So Preoccupied With Whether Or Not You Could, You Didn't Stop To Think If You Should."
The arithmetic coding feature was already painful enough. I'm simply not in need of yet another thing that makes jpeg files more complicated to deal with.
> After weighing the data, we’ve decided to stop Chrome’s
> JPEG XL experiment and remove the code associated with
> the experiment.
> We'll work to publish data in the next couple of weeks.
Did that ever happen?
If they don't, literally nothing happens.
I fail to see a major downside. Perhaps open up your thinking on this?
Yes, Chrome published data.
People said the same thing last time and it took more than 10 years until decoding worked reliably. I'm simply not interested in dealing with another JPEG++.
> Perhaps open up your thinking on this?
Nah, I'm fine. I went JXL-only for anything new I'm publishing, and if people need to switch browsers to see it – so be it.
(Of course JXL is better still.)
This makes your website only viewable on Safari (and by extension Apple devices) only, right?
I liked guetzli but it's way too slow to use in production. Glad there is an alternative.
Otherwise it would be called ... Pumpernikkeli.
"Gonna cause quite the firestorm, creating something new everyone will be expected to support and maintain, after Google balked at bringing in jpegxl because they would have to support it."
I still really find the messaging here to be awful. There's tons of comments asking how this related to JXL. @JyrkAlakuijala chimes in in https://news.ycombinator.com/item?id=39921484 that yes it uses JXL techniques, but also it's just using that repo because it had infrastructure which was easy to get started with (absolutely cannot argue with that).
I'm not sure what my ask is, but this felt like a really chaotic release. It's unclear how much good from JPEG XL got chopped off. I'm glad for the iteration, this just seemed really chaotic & unexpected, & NIMBY-istic.
It would have been clearer to make it its own repo.
Image quality folks are more cautious and tradition-centric than codec devs, so quite an initial effort would be needed to use something as advanced and risky as butteraugli, ssimulacra or XYB. With traditional objective metrics it would be very difficult to make a competing format as they would start with a 10–15 % disadvantage.
So, I think it is not easy and would need substantial investment.
I am not.
> what would it take to develop another widely supported image format? Would the research stage already need to be carried out as a multi-corporate effort?
I believe JXL will be very successful sooner or later, it already has a lot more support than many other attempts at new image formats.
But in general, the main way to get fast adoption on the web is to have Chromium's codec team be the main developers.
- Guetzli at q=84 (the minimum allowed by Guetzli) takes 47s and produces a 403kB image.
- Jpegli at q=84 takes 73ms (MILLIseconds) and produces a mostly-indistinguishable 418kB image. "Mostly" because:
A. it's possible to find areas with subtle color gradients where Guetzli does a better job at keeping it smooth over a large area.
B. "Little specks" show a bit more "typical JPG color-mush artifacting" around the speck with Jpegli than Guetzli, which stays remarkably close to the original
Also, compared to the usual encoder I'm used to (e.g. the one in GIMP, libjpeg maybe?), Jpegli seems to degrade pretty well going into lower qualities (q=80, q=70, q=60). Qualities lower than q=84 are not even allowed by Guetzli (unless you do a custom build).
I'm immediately switching my "smallify jpg" Nautilus script from Guetzli to Jpegli. The dog-slowness of Guetzli used to be tolerable when there was no close contender, but now it feels unjustified in comparison to the instant darn excellent result of Jpegli.
With guetzli I added manually overprovisioning for slow smooth gradients. If you have an example where guetzli is better with gradients you could post an issue with a sample image. That would help us to potentially fix it for jpegli, too.
So, I started creating an issue in the repo, and as I was creating a side-by-side-by-side comparison of A=orig, B=guetzli, C=jpegli ... I realize that wait-a-minute, Jpegli is actually doing a better job at preserving the original image :D
The B/guetzli version is actually too smoothed, obviating a couple gradient anomalies observable in A/orig. Conversely, C/jpegli actually better "preserves" these imperfections, by not smoothening the broader area into a gradient that is "smoother" but loses some detail.
So, not creating an issue :D. If you wish to see the image and do the A/B/C comparison yourself, it is screenshot 14 of videogame [1], direct link [2]. The area where I noticed differences in gradients is the top / top-right area with black arches and blue fog.
Thanks for Jpegli and Guetzli.
[1] https://store.steampowered.com/app/1671480/ABRISS__build_to_...
[2] https://cdn.cloudflare.steamstatic.com/steam/apps/1671480/ss...
Maybe a fork of https://squoosh.app/ ? The code for that is https://github.com/GoogleChromeLabs/squoosh
Not underestimating the value in this, but the presentation is very weak.
Java, C#, Go, Rust, Python, modern C++ with smartpointer,...
I mean a concepts for handling files in a safe way are an awesome (and really needed) thing, but inventing a whole new programming language around a single task (even if it's just a transpiler to c)?
Ah yeah, because the endless stream of exploits and “new CVE allows for zero-click RCE, please update ASAP” doesn't feel repetitive?
> I mean a concepts for handling files in a safe way are an awesome (and really needed) thing, but inventing a whole new programming language around a single task (even if it's just a transpiler to c)?
It's a “single task” in the same way “writing compilers” is a single task. And like we're happy that LLVM IR exists, having a language dedicated to writing codecs (of which there are dozens) is a worthwhile goal, especially since they are both security critical and have stringent performance needs for which existing languages (be it managed languages or Rust) aren't good enough.
Probably would be a good idea to get a port though, if possible, improving both safety and performance sounds like a win to me.
Wuffs doesn't support global variables, but when I'm writing my own research phase code, sometimes I like to just tweak some global state (without checking the code in) just to get some experimental data: hey, how do the numbers change if I disable the blahblah phase when the such-and-such condition (best evaluated in some other part of the code) holds?
Also, part of Wuffs' safety story is that Wuffs code cannot make any syscalls at all, which implies that it cannot allocate or free memory, or call printf. Wuffs is a language for writing libraries, not whole programs, and the library caller (not callee) is responsible for e.g. allocating pixel buffers. That also makes it harder to use during the research phase.
(I work at Google, but have nothing to do with Jpegli or Wuffs)
Decoding takes a compressed image file as input, which have complicated formats. Roughly speaking, encoding just takes a width x height x 4 pixel buffer, with very regular structure. It's much easier to hide something malicious in a complicated format.
Higher priority means that, when deciding whether to work on a Wuffs PNG encoder or a Wuffs JPEG decoder next, when neither existed at the time, I chose to have more decoders.
(I work at Google, and am the Wuffs author, but have nothing to do with Jpegli. Google is indeed a big company.)
So, instead of supporting JPEG XL, this is the nonsense they come up with? Lock-in over a JPEG overlay?
What should happen: websites/applications shouldn't recompress images if they already deliver good pixel bitrate. Websites/applicates shouldn't recompress images just to add own watermarks.
It's not the fisherman's job to preserve ecosystem quality. That would be mixing up concerns.
You guys should up your web game
FWIW Firefox mobile lets you override zooming on a site.
What in heavens name and why is this not a default option? Thankee Sai!
Apparently about:config is still not available on Firefox Mobile main release it seems.
Supposedly available on Dev/Beta/Nightly or similar - unverified statement though.
Annoying.
Firefox 3 dot menu -> Settings -> Accessibility -> Zoom on all websites
If you are making a new image/video codec in 2024 please don't just give us 2 measly extra bits of DR. Support up to 16 bit unsigned integer and floating point options. Sheesh.
> Introducing Jpegli: A New JPEG Coding Library
I don't consider it to necessarily mean a new data format.
One data format can be implemented by multiple codecs.
Semantics and nomenclature within our field is likely underdeveloped and the use of these terms varies.
> Support for 16-bit unsigned and 32-bit floating point input buffers.
"10+" means 10 bits or more.
log(4096/3)/log(2) = 10.41
So, very handwavy analysis.
Experimentally it seems to roughly hold.
The data is carefully encoded in the dct-coefficients. They are 12 bits so in some situations you can get even 12 bit precision. Quantization errors however sum up and worst case is about 7 bits. Luckily it occurs only in the most noisy environments and in smooth slopes we can get 10.5 bits or so.
I might be wrong, but it seems like Apple is the primary game in town for supporting HDR. How do you intend to persuade Apple to upgrade their JPG decoder to support Jpegli?
p.s. keep up the great work!
I didn't follow up and I don't know if she read it or understood the proposal.
16 bits is useful for image capture and manipulation. But then you should just use RAW/DNG.
JpegXL was kicked out. This thing is added, but the repo and code seems to be from jxl.
I'm very confused.