Firefox 157 Will Include JPEG XL By Default On All Platforms (phoronix.com) 39
Mozilla plans to enable JPEG XL decoding by default in Firefox 157, which is due at the end of September. Phoronix reports: Firefox Nightly has JPEG-XL support enabled by default right now to help in vetting this support while Mozilla believes the support is in good enough shape for a stable debut with Firefox 157. This follows Chrome shipping JPEG-XL and Google Research developing jxl-rs as a Rust-based JPEG-XL image decoder that is both performant and secure.
In today's Mozilla Hacks blog post they elaborate on JPEG-XL vs. AVIF image formats: "JPEG XL: Excels at lossless imagery, progressive rendering, and further compressing JPEGs without quality loss. AVIF: Excels at web-quality photographic images, and images that have a mix of sharp edges and flat surfaces. ... Although AVIF tends to produce smaller files at web-quality than JPEG XL, AVIF only has basic progressive rendering support. So, for very large images, it may be worth taking the filesize hit with JPEG XL."
In today's Mozilla Hacks blog post they elaborate on JPEG-XL vs. AVIF image formats: "JPEG XL: Excels at lossless imagery, progressive rendering, and further compressing JPEGs without quality loss. AVIF: Excels at web-quality photographic images, and images that have a mix of sharp edges and flat surfaces. ... Although AVIF tends to produce smaller files at web-quality than JPEG XL, AVIF only has basic progressive rendering support. So, for very large images, it may be worth taking the filesize hit with JPEG XL."
Double or nothing (Score:4, Funny)
” So, for very large images, it may be worth taking the filesize hit with JPEG XL”
XL it is. If the file already is large, make it even larger!
JPEG was good enough (Score:2)
JPEG was good enough for DECADES and we have tons more speed and bandwidth today than in the 1990s. It's lacking just a few things that don't matter a whole lot for the web today.
Many replacements have been attempted but nobody has supplanted it because picky nerd battles do not matter over what is established as getting the job done for most everybody. Google did not help with it pushing it's own crap which wouldn't have gone anywhere without a monopoly and even then they didn't replace JPEG.
XL seems to m
Re: (Score:2)
Having real alpha without requiring lossless photos is probably the big benefit on the web as far as file size. But this format seems like a kitchen sink. It might as well not be named JPEG-XL and be named WebP-XL considering the feature overlap.
Re: (Score:2)
and even then they didn't replace JPEG
I'm using webp for all my images needs these days.
Re: (Score:1)
My last donation to Mozilla was nothing, so I'll be completely happy to double it for another feature I don't need or want.
I might consider donating if it would get them to stop creating new security vulnerabilities in unneeded features. Or if my donation would get them to fix ancient problems like the memory leak that makes Firefox essentially unusable in Linux. (That one goes back many months and I saw it again about two days ago. However the main reason I don't do any serious work with Linux now is the l
Our long national nightmare is over (Score:3)
WebPee can finally go back into the yellow googlehole it crawled out of.
Re: (Score:3)
It won't. JPEG-XL isn't supported by anything or anyone outside of the PDF specification (the only reason why Firefox is adopting XL support). On the flip side webp is used extensively in many image heavy platforms.
What reason would you present for anyone to bother putting any effort into migrating from webp to jpeg-xl? Frame your response in terms of profit.
'Web Quality' ??? (Score:5, Interesting)
As if AI slop wasn't a problem. For years image quality has tanked as many have been re-compressed many times over, often for no reason. Then you have the people that think upscaling an image 3x makes it more detailed and sharper... Ugh.
Quality (Score:2)
Tell us you mean crap without saying crap.
So "Good enough for general web use" is crap? Do you think everything should be sent as deflate compressed WQUXGA PNGs?
Re: (Score:2)
I would never use such a low resolution image.
Re: (Score:2)
The tech is fine when used correctly, but that's not how it works out in the real world.
Upload an image to a service and it probably wants to blindly re-compress it down to it's own standards to conserve bandwidth. For most people that is an image downloaded from a site that already re-compressed it down to it's own standards to conserve bandwidt
Re: (Score:3)
If the compressed image is from the original source it will be just fine. The problem is that most re-compressed images comes from an already compressed copy.
And that was a design criteria for JPEG-XL. It's designed to recompress existing JPEGs without loosing much fidelity. I've played around with it and it's pretty good. It's very source-dependent, if a JPEG is already poorly compressed it will look worse. A good quality JPEG, say from a phone, recompresses nicely. You have to blow up the image quite a bit to notice any difference, hence it's fine for general web use. My current standard for lossy compression is AVIF, and I'm seriously considering switching o
Re: Quality (Score:2)
It sounds like you're still recoding it. I believe the design goal you are referring to is *absolutely no change* in the image. In fact, it goes futher: I believe there's a path to convert a JPEG to a JPEG XL that is typically much smaller such that you can undo the conversion from the JXL and get back the exact bit-identical JPEG file you started from.
Re: (Score:2)
JPEG XL is more efficient in terms of CPU time needed to encode and decode than AVIF, but still not nearly as good as JPEG.
For web it's a trade off between the server saving bandwidth and the device using more energy to display the page.
Re: (Score:2)
It doesn't? You might want to tell these folks [youtube.com].
Re: (Score:2)
For years image quality has tanked
Can you provide examples? Beyond a few internet memes I've not seen any example of image quality that hasn't been perfectly fine for its purpose. In fact it's been a long long time since I've seen bad images with either compression artefacts or low resolution, and certainly in the examples I have seen I've not seen any backwards step (some sites just were rubbish from the onset).
Re: 'Web Quality' ??? (Score:2)
Upscaling an image with AI can absolutely make it sharper and more detailed. It's just that the added details are all hallucinations.
One day there will likely be an AI image compression system similar to the Brotli text compression system.
Umm.. Are you sure its 157??? (Score:2)
I'm running what Ubuntu presents as the current version of FF, which is 147.0.4.. HOW is FF going to get to 157 by the end of next month???
Re: (Score:3)
You're probably running the extended support release. Usual versions (in particular Windows) get every two weeks a new Firefox. Ubuntu LTS, Debian, etc. install a ESR release, which gets maintenance updates when needed and only every few month a major update (leaving out in-between versions).
Re: (Score:3)
Firefox ESR were 91, 102, 115, 140, 153.
Latest release is 154.0.1
Re: (Score:2)
I'm running what Ubuntu presents as the current version of FF
You installed it from Apt instead of the flatpack right? The flatpacks are currently at 154
Re: (Score:2)
I do not use snaps (I assume you meant snaps vs flatpack). Removing the snap FF and installing the dpkg one is one of the first things I do when setting up a new Ubuntu system.
Look at the "Related Links" (Score:4, Informative)
One of the Related Links I saw here was https://slashdot.org/story/26/01/13/2026229/jpeg-xl-image-support-returns-to-latest-chromechromium-code [slashdot.org] - Chrome has been offering this since mid January. If it works on Chrome - and is a positive feature - then it is time for Firefox to offer it.
Re: (Score:3)
Nothing to do with anything. JPEG-XL was *dropped* from Chrome a few years ago as it was seen as an unused waste of code. It was the PDF-A which selected JPEG-XL as the codec for HDR images in the PDF standard that caused this change. Chrome and Firefox both ship with a native PDF viewer, so if they want to actually continue to be conformant to the PDF standard they need to support JPEG-XL before the next PDF standard is released.
That is all. That's the only reason anyone is suddenly giving a crap about JPE
Re: (Score:2)
It was also because there is now a Rust JPEG XL decoder, which is reasonably safe. The C decoder seems to have been abandoned and still has some serious issues with performance. It hasn't had a proper security audit either.
Firefox and Chrome are both using the Rust decoder.
Re: (Score:3)
Not disputing your points, but JPEG2000 is used pretty extensively in the remote sensing world (think overhead satellite imagery from companies like Maxar [was Worldview]). These images are often huge (think GB+), benefit well from the compression and especially the inherent res levels J2K provides. It is a common compression format in NITF formatted imagery files. A niche area to be sure, but it is used.
Re: (Score:2)
Interesting to know, thanks.
Re: (Score:2)
JPEG2000 was brought down by patent licensing. No-one wanted to pay the fees required to implement it. It was never about technical considerations.
Re: (Score:2)
No-one wanted to pay the fees required to implement it.
Largely because people don't care. The media world is full of proprietary licensed formats which people have paid fees to implement. But your point emphasises mine: The marginal gain is not worth enough to put effort, time, or money into it unless you have a specific need for a format capability.
By the way for at least 20 years now there has been no fee for licensing JPEG2000 thanks to an agreement with the license holders, and there are open source implementations of the codecs as well. Still no one uses i
Re: (Score:2)
IIRC it isn't enabled by default, and is considered a dev feature.
Shout it from the rooftops (Score:2)
With Firefox capturing 3% of the market is this really newsworthy?
Re: (Score:2)
I am one of the 3%. My mother says I'm special!
But (a) it's written in Rust because Mozilla didn't trust C++ (b) Google did the implementation so it's an example of both parties collaborating regardless of the Chromium/Gecko divide.
Re: (Score:2)
But (a) it's written in Rust because Mozilla didn't trust C++
It was not that they did not trust C++ (itself) but it is easier to verify the rust implementation (because rust does a lot of the memory safety checks at compile time), and there is a long long long history of codecs having memory safety issues. One less potential future exploit is always a good thing (one should note that rust does not protect against logic errors, so the code may still be wrong, just potentially less wrong).
Re: (Score:2)
But (a) it's written in Rust because Mozilla didn't trust C++
It was not that they did not trust C++ (itself) but it is easier to verify the rust implementation (because rust does a lot of the memory safety checks at compile time), and there is a long long long history of codecs having memory safety issues. One less potential future exploit is always a good thing (one should note that rust does not protect against logic errors, so the code may still be wrong, just potentially less wrong).
So... they didn't trust C++ for this job.
Re: (Score:2)
No, they didn't trust people to code in C++ for the job. C++ is a tool, there's nothing trustworthy or untrustworthy about it. It can't lie to you.
Re: (Score:2)
Well, I wouldn't trust a screwdriver to plant a nail. Not because the screwdriver is "untrustworthy", but because it's the wrong tool for the job.
Same here. If you don't want buffer overflows and threading issues, C++ is a pretty poor choice for the job. Rust was designed to address precisely these kinds of problems.
k but (Score:2)
'k, but how 'bout txt comp? Just for the web, course. Qnty over qlty, 'k?
I have an idea (Score:2)