The article mentions that the bit depth can be 16.
You may need more bits for HDR and some additional bits for precision. For example, screen pixels have an exponential intensity curve but image processing is best done in linear.
However, I wonder if floating-point is necessary, or even the best to use compared to using 32-bit fixed-point.
The floating-point format includes subnormal numbers that are very close to zero, and I'd think that could be much more precision than needed.
Processing of subnormal numbers is extra slow on some processors and can't always be turned off.
Did you miss the point of the article? JPEG-XL encoding doesn't rely on quantisation to achieve its performance goals. Its a bit like how GPU shaders use floating point arithmetic internally but output quantised values for the bit depth of the screen.
Which is completely wrong by the way, JPEG-XL quantizes its coefficients after the DCT transform like every other lossy codec. Most codecs have at least some amount of range expansion in their DCT as well, so the values quantized might be greater bit depth than the input data.
The cliff notes version is that JPEG and JPEG XL don't encode pixel values, they encode the discrete cosine transform (like a Fourier transform) of the 2d pixel grid. So what's really stored is more like the frequency and amplitude of change of pixels than individual pixel values, and the compression comes from the insight that some combinations of frequency and amplitude of color change are much more perceptible than others
In addition to the other comments: you can have an internal memory representation of data be Float32, but on disk, this is encoded through some form of entropy encoding. Typically, some of the earlier steps is preparation for the entropy-encoder: you make the data more amenable to entropy-encoding through rearrangement that's either fully reversible (lossless), or near-reversible (lossy).
When exporting images from Lightroom Classic in JPEX XL you can choose the percent of compress or choose lossless which disable that of course. But also default to 8bit, but an option for 16bit which of course results in a much larger file. And color profile setting. So curious what they mean by it ignores bit depth?
Did some sample exports comparing JXL 8bit lossless vs JPG and JXL was quite a bit bigger. Same for doing lossy 100 comparison or 99 comparison of both. When setting JXL to 80%, 70% see noticeably savings but had thought the idea was JXL full quality essentially for much smaller sizes.
To be fair the 70% does look very similar to 100% but then again the JPEG 70% vs 100% also look very similar on an Apple XDR Monitor. the 70% or 80% etc on both jpeg and jpeg xl i do see visual differences in areas like on shoes where there is mesh.
JXL comes with lots of compatibility challenges since while things were picking up with Apple's adoption it seems to have halted since and apps like Evoto, and Topaz not adding support among many others. And Apple's still not full support and no progress on that. So unless Chrome does a 180 again, think AVIF and JXL will both end up stagnating and most sticking with JPG. For Tiff though noticed significant savings lossless jxl compared to tiff so that would be a good use case except tiffs more likely ones to be edited by third party apps that most likely won't support the format.
For lossless, bitdepth of course does matter. Lossless image compression is storing a 2D array of integer numbers exactly, and with higher bitdepth, the range of those numbers grows (and the amount of hard-to-compress least significant bits grows).
The OP article is talking about lossy compression.
When comparing lossy compression, note that lossy compression settings are not a "percent" of anything, it's just an arbitrary scale that depends on the encoder implementation. So lossy "80%" is certainly not the same thing between JPEG and JXL, or between Photoshop and ImageMagick, etc. It's not a percentage of anything — it's just an arbitrary scale that gets mapped to encoder parameters (e.g. quantization tables) in some arbitrary way.
The best way to compare lossy compression performance is to encode an image at the quality that is acceptable for your use case (according to your eyes), and then you just look for various codecs/encoders what the lowest filesize is you can get while still getting an acceptable quality.
I completely agree. Based on my limited experience with image upscaling, downscaling, and superresolution, saving video at a lower resolution is the second crudest way of reducing the file size.
The crudest is downsampling the chroma channel, which makes no sense whatsoever for digital formats.
So they "ignore" bit depth by using 32 bits for each sample. This may be a good solution but it's not really magic. They just allocated many more bits than other codecs were willing to.
It also seems like a very CPU-centric design choice. If you implement a hardware en/decoder, you will see a stark difference in cost between one which works on 8/10 vs 32 bits. Maybe this is motivated by the intended use cases for JPEG XL? Or maybe I've missed the point of what JPEG XL is?
image decoding is fast enough that no one uses hardware encoders. The extra bits are very cheap on both CPU and GPU, and by using them internally, you prevent internal calculations from accumulating error, and end up with a much cleaner size quality trade-off. (note that 10 bit output is still valuable on an 8 bit display because it lets the display manager dither the image
That is true! But AVIF is based on AV1. As a video codec, AV1 often does need to be implemented in dedicated hardware for cost and power efficiency reasons. I think the article is misleading in this regard: "This limitation comes from early digital video systems". No, it is very much a limitation for video systems in the current age too.
Interesting approach. It doesn't even introduce an extra rounding error, because converting from 32-bit XYB to RGB should be similar to converting from 8-bit YUV to RGB.
However, when decoding an 8-bit-quality image as 10-bit or 12-bit, won't this strategy just fill the two least significant bits with noise?
Could be noise, but finding a smooth image that rounds to a good enough approximation of the original is quite useful. If you see a video player talk about debanding it is a exactly that.
I don't know if JPEG XL constrains solutions to be smooth.
Mozilla also isn't interested in supporting it, it's not just Google. I also often see these articles that tout jpeg-xl's technical advantages, but in my subjective testing with image sizes you would typically see on the web, avif wins every single time. It not only produces fewer artifacts on medium-to-heavily compressed images, but they're also less annoying: minor detail loss and smoothing compared to jpeg-xl's blocking and ringing (in addition to detail loss; basically the same types of artifacts as with the old jpeg).
Maybe there's a reason they're not bothering with supporting xl besides misplaced priorities or laziness.
Mozilla is more than willing to adopt it. They just won't adopt the C++ implementation. They've already put into writing that they're considering adopting it when the rust implementation is production ready.
The jxl-oxide dev is a jxl-rs dev. jxl-oxide is decode only while jxl-rs is a full encode/decode library.
zune also uses jxl-oxide for decode. zune has an encoder and they are doing great work but their encoder is not threading safe so it's not viable for Mozilla's need.
And there's work already being done for properly integrating jxl implementations with firefox but frankly things take time.
If you are seriously passionate about seeing JPEG-XL in firefox there's a really easy solution. Contribute. More engineering hours put towards a FOSS project tends to see it come to fruition faster.
Seems like the normal usage to me. The post above lists other criteria that have to be satisfied, beyond just being a Rust implementation. That would be the consideration.
Mozilla indicates that they are willing to consider it given various prerequisite. GP translates that to being “more than willing to adopt it”. That is very much not a normal interpretation.
> To address this concern, the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust, and integrate this decoder into Firefox. If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it.
So you think it's silly to not want to introduce new potentially remotely-exploitable CVEs in one of the most important pieces of software (the web browser) on one's computer? Or are you implying those 100k lines of multithreaded C++ code are bug-free and won't introduce any new CVEs?
> and don’t think that the programmer more than the languages contribute to those problems
This sounds a lot like how I used to think about unit testing and type checking when I was younger and more naive. It also echoes the sentiments of countless craftspeople talking about safety protocols and features before they lost a body part.
Safety features can’t protect you from a bad programmer. But they can go a long way to protect you from the inevitable fallibility of a good programmer.
It's crazy how anti-Rust people think that eliminating 70% of your security bugs[1] by construction just by using a memory-safe language (not even necessarily Rust) is somehow a bad thing or not worth doing.
It's not about being completely bug free. Safe rust is going to be reasonably hardened against exploitable decoder bugs which can be converted into RCEs. A bug in safe rust is going to be a hell of a lot harder to turn into an exploit than a bug in bog standard C++.
> It’s crazy how people think using Rust will magically make your code bug and
vulnerability free
It won't for all code, and not bug-free, but it absolutely does make it possible to write code parsing untrusted input all-but vulnerability free. It's not 100% foolproof but the track record of Rust parsing libraries is night-and-day better than C/C++ libraries in this domain. And they're often faster too.
Multiple severe attacks on browsers over the years have targeted image decoders. Requiring an implementation in a memory safe language seems very reasonable to me, and makes me feel better about using FF.
I did some reading recently, for a benchmark I was setting up, to try and understand what the situation is. It seems things have started changing in the last year or so.
No, the situation about image compression has not changed. The Grand Poster you were replying to was writing about typical web usage, that is "medium-to-heavily compressed images", while your benchmark is about lossless compression.
BTW, I don't see how Mozilla's interest in a jpegxl _decoder_ (your first link) has anything to do with the performance of jpegxl encoders compared to avif's encoders. In case you're really interested in the former, Firefox now has more than intentions, but it's still not at production level: https://bugzilla.mozilla.org/show_bug.cgi?id=1986393
No. demetris’ benchmark of lossless image compression is not a sign that the situation may be changing. :-D
That was just the context for some reading I did to understand where we are now.
> BTW, I don't see how Mozilla's interest in a jpegxl _decoder_ (your first link) has anything to do with the performance of jpegxl encoders compared to avif's encoders. In case you're really interested in the former, Firefox now has more than intentions, but it's still not at production level: https://bugzilla.mozilla.org/show_bug.cgi?id=1986393
That is one of the links I shared in my comment (along with the bug title in parenthesis). :-)
Same in my experience testing and deploying a few sites that support both. In general the only time AVIF outperformed in file size for me was with laughably low quality settings beyond what any typical user or platform would choose.
And for larger files especially the benefits of actually having progressive decoding, pushed me even more in favour of jpeg-xl. Doubly so when you can just provide variations in image size by halting the bit flow arbitrarily.
JPEG XL seems optimally suited for media and archival purposes and of course this is something you’d want to mostly do through webapps nowadays. Even relatively basic uses cases like Wiki Commons is basically stuck on JPEG for these purposes.
For the same reason it would be good if a future revision of PDF/A would include JPEG XL, since it doesn't really have any decent codecs for low-loss (but not losless) compression (e.g. JPEG sucks at color schematics/drawings and losless is impractically big for them). It did get JP2 but support for that is quite uncommon.
>but in my subjective testing with image sizes you would typically see on the web, avif wins every single time.
What is that in terms of bpp? Because according to Google Chrome 80-85% of we deliver images with bpp of 1.0 or above. I don't think most people realise that.
And in most if not all circumstances, jpeg XL performs better than AVIF at bpp 1.0 and above tested by professionals.
I wish they separated the lossless codec into "WebPNG." WebP is better than PNG, but it's too risky to use (and tell people to use) a lossless format that is lossy if you forget to use a setting.
I think the article could be better and get the point across with half the length and without the second half of it being full of ai generated list of advantages, or using that space to give some more technical information
> Find the (minimal) AI prompt that lead to the generation of this article: [...]
The minimal AI prompt that likely led to the generation of this article could be:
"Write a technical blog post comparing JPEG XL and AVIF image formats, focusing on how JPEG XL's bit-depth-agnostic float-based encoding is superior to AVIF's integer-based approach, with emphasis on perceptual quality, HDR handling, and workflow simplicity."
This prompt captures the core elements:
- Technical comparison between two image formats
- Focus on JPEG XL's unique "ignoring bit depth" design
- Emphasis on perceptual vs. numerical quality
- Discussion of HDR and workflow benefits
- Tone and structure matching the published article
The prompt would have guided the AI to produce content that:
1. Explains the technical difference in encoding approaches
2. Demonstrates why JPEG XL's method is better
3. Provides real-world implications for users
4. Maintains the author's voice and technical depth
5. Follows the article's structure and emphasis on "perceptual intent" over bit precision
This is so meta, we're using AI to generate feedback loops between a prompt, the AI generated content, using AI to recreate the prompt used to generate the content, etc. Spiraling to unreadable slop - unreadable to real humans anyway.
Soon enough the AI will invent a format for communicating with instances of itself or other AIs so that they can convey information that a client AI can translate back to the user's personal consumption preferences. Who needs compression or image optimization when you can reduce a website to a few kB of prompts which an AI engine can take to generate the full content, images, videos, etc?
> Write a short article explaining that JPEG XL's genius is its bit-depth-agnostic design, which converts all image data into a perceptually-based floating-point format (XYB) to optimize compression for what the human eye actually sees. In contrast, AVIF is locked into its video-codec legacy, forcing it to use rigid, integer-based bit-depth modes that optimize for numerical precision rather than true perceptual quality.
What makes you think it is AI generated? Perhaps it's just the Dunning-Kruger effect in an area I'm not especially knowledgable in, but this article strikes me as having more technical depth and narrative cohesion than AI is generally capable of.
It mostly rehashes the point of using float instead of integer representation, and uses different headers (radical solution, why this matters, secret weapon, philosophy, the bottom line) for streching what could be said in a few sentences into a few pages.
The reason AI loves this format is that it was a popular format before generative AI came along. It's the format of clickbaity "smart" articles, think Slate magazine etc.
But because it's for a subject the HN audience is interested in, it actually gets upvotes unlike those sites, so a lot of people reading these get reintroduced to the format.
Tenish years ago we had slop / listicles already and thankfully our curated internet filters helped us avoid them (but the older generation who came across them through Facebook and the like). But now they're back, and thanks to AI they don't need people who actually know what they're talking about to write articles aimed at e.g. the HN audience (because the people who know what they're talking about refuse to write slop... I hope)
Formatting and headers aside, there are lots of local rhetorical flourishes and patterns that are fairly distinctive and appear at a far higher rate in AI writing than in most writing that isn't low-quality listicle copy artificially trying to hold your attention long enough that you'll accidentally click on one of the three auto-playing videos when you move your pointer to dismiss the newsletter pop-up.
Here's something you know. It's actually neither adjective 1 nor adjective 2—in fact, completely mundane realization! Let that sink in—restatement of realization. Restatement. Of. Realization. The Key Advantages: five-element bulleted list with pithy bolded headings followed by exactly zero new information. Newline. As a surprise, mild, ultimately pointless counterpoint designed to artificially strengthen the argument! But here's the paradox—okay, I can't do this anymore. You get the picture.
Inside JPEG XL’s lossy encoder, all image data becomes floating-point numbers between 0.0 and 1.0. Not integers. Not 8-bit values from 0-255. Just fractions of full intensity.
Everything after the first "Not" is superfluous and fairly distinctively so.
No switching between 8-bit mode and 10-bit mode.
No worrying whether quantization tables are optimized for the right bit precision.
No cascading encoding decisions based on integer sample depth.
The codec doesn’t care about your display’s technical specs. It just needs to know: "what brightness level does white represent?" Everything scales from there.
Same general pattern.
JPEG XL not worrying about bit depth isn’t an oversight *or* simplification. It’s liberation from decades of accumulated cruft where we confused digital precision with perceptual quality.
It's hard to describe the pattern here in words, but the whole thing is sort of a single stimulus for me. At the very least, notice again the repetition of the thing being argued against, giving it different names and attributes for no good semantic reason, followed by another pithy restatement of the thesis.
By ignoring bit depth, JPEG XL’s float-based encoding embraces a profound truth: pixels aren’t just numbers; they’re perceptions.
This kind of upbeat, pithy, quotable punchline really is something frontier LLMs love to generate, as is the particular form of the statement. You can also see the latter in forms like "The conflict is no longer political—it's existential."
Why This Matters
I know I said I wouldn't comment on little tics and formatting and other such smoking guns, but if I never have to see this godforsaken sequence of characters again…
> JPEG XL’s Radical Solution: Float32 + Perceptual Intent
So 2^32 bit depth? 4 bytes seems an overkill.
The article mentions that the bit depth can be 16. You may need more bits for HDR and some additional bits for precision. For example, screen pixels have an exponential intensity curve but image processing is best done in linear.
However, I wonder if floating-point is necessary, or even the best to use compared to using 32-bit fixed-point. The floating-point format includes subnormal numbers that are very close to zero, and I'd think that could be much more precision than needed. Processing of subnormal numbers is extra slow on some processors and can't always be turned off.
Did you miss the point of the article? JPEG-XL encoding doesn't rely on quantisation to achieve its performance goals. Its a bit like how GPU shaders use floating point arithmetic internally but output quantised values for the bit depth of the screen.
Which is completely wrong by the way, JPEG-XL quantizes its coefficients after the DCT transform like every other lossy codec. Most codecs have at least some amount of range expansion in their DCT as well, so the values quantized might be greater bit depth than the input data.
> Did you miss the point of the article?
Sorry I missed. How is the "floating point" stored in .jxl files?
Float32 has to be serialized one way or another per pixel, no?
The cliff notes version is that JPEG and JPEG XL don't encode pixel values, they encode the discrete cosine transform (like a Fourier transform) of the 2d pixel grid. So what's really stored is more like the frequency and amplitude of change of pixels than individual pixel values, and the compression comes from the insight that some combinations of frequency and amplitude of color change are much more perceptible than others
In addition to the other comments: you can have an internal memory representation of data be Float32, but on disk, this is encoded through some form of entropy encoding. Typically, some of the earlier steps is preparation for the entropy-encoder: you make the data more amenable to entropy-encoding through rearrangement that's either fully reversible (lossless), or near-reversible (lossy).
No, JPEG is not a bitmap format.
The gradient is stored, not the points on the gradient
When exporting images from Lightroom Classic in JPEX XL you can choose the percent of compress or choose lossless which disable that of course. But also default to 8bit, but an option for 16bit which of course results in a much larger file. And color profile setting. So curious what they mean by it ignores bit depth?
Did some sample exports comparing JXL 8bit lossless vs JPG and JXL was quite a bit bigger. Same for doing lossy 100 comparison or 99 comparison of both. When setting JXL to 80%, 70% see noticeably savings but had thought the idea was JXL full quality essentially for much smaller sizes.
To be fair the 70% does look very similar to 100% but then again the JPEG 70% vs 100% also look very similar on an Apple XDR Monitor. the 70% or 80% etc on both jpeg and jpeg xl i do see visual differences in areas like on shoes where there is mesh.
JXL comes with lots of compatibility challenges since while things were picking up with Apple's adoption it seems to have halted since and apps like Evoto, and Topaz not adding support among many others. And Apple's still not full support and no progress on that. So unless Chrome does a 180 again, think AVIF and JXL will both end up stagnating and most sticking with JPG. For Tiff though noticed significant savings lossless jxl compared to tiff so that would be a good use case except tiffs more likely ones to be edited by third party apps that most likely won't support the format.
For lossless, bitdepth of course does matter. Lossless image compression is storing a 2D array of integer numbers exactly, and with higher bitdepth, the range of those numbers grows (and the amount of hard-to-compress least significant bits grows).
The OP article is talking about lossy compression.
When comparing lossy compression, note that lossy compression settings are not a "percent" of anything, it's just an arbitrary scale that depends on the encoder implementation. So lossy "80%" is certainly not the same thing between JPEG and JXL, or between Photoshop and ImageMagick, etc. It's not a percentage of anything — it's just an arbitrary scale that gets mapped to encoder parameters (e.g. quantization tables) in some arbitrary way.
The best way to compare lossy compression performance is to encode an image at the quality that is acceptable for your use case (according to your eyes), and then you just look for various codecs/encoders what the lowest filesize is you can get while still getting an acceptable quality.
Yes, this is great, but why don't we make the same argument for resolution too? I think we should!
I completely agree. Based on my limited experience with image upscaling, downscaling, and superresolution, saving video at a lower resolution is the second crudest way of reducing the file size.
The crudest is downsampling the chroma channel, which makes no sense whatsoever for digital formats.
Working with single fixed bit depth is imho different than being bit-depth agnostic. Same argument could be made about color spaces too.
So they "ignore" bit depth by using 32 bits for each sample. This may be a good solution but it's not really magic. They just allocated many more bits than other codecs were willing to.
It also seems like a very CPU-centric design choice. If you implement a hardware en/decoder, you will see a stark difference in cost between one which works on 8/10 vs 32 bits. Maybe this is motivated by the intended use cases for JPEG XL? Or maybe I've missed the point of what JPEG XL is?
image decoding is fast enough that no one uses hardware encoders. The extra bits are very cheap on both CPU and GPU, and by using them internally, you prevent internal calculations from accumulating error, and end up with a much cleaner size quality trade-off. (note that 10 bit output is still valuable on an 8 bit display because it lets the display manager dither the image
That is true! But AVIF is based on AV1. As a video codec, AV1 often does need to be implemented in dedicated hardware for cost and power efficiency reasons. I think the article is misleading in this regard: "This limitation comes from early digital video systems". No, it is very much a limitation for video systems in the current age too.
Interesting approach. It doesn't even introduce an extra rounding error, because converting from 32-bit XYB to RGB should be similar to converting from 8-bit YUV to RGB.
However, when decoding an 8-bit-quality image as 10-bit or 12-bit, won't this strategy just fill the two least significant bits with noise?
Could be noise, but finding a smooth image that rounds to a good enough approximation of the original is quite useful. If you see a video player talk about debanding it is a exactly that.
I don't know if JPEG XL constrains solutions to be smooth.
I believe they constrain to piecewise smooth (i.e. don't smooth out edges but do smooth out nose)
jpeg xl is fantastic, yet autocratic google wants to force inferior format
Mozilla also isn't interested in supporting it, it's not just Google. I also often see these articles that tout jpeg-xl's technical advantages, but in my subjective testing with image sizes you would typically see on the web, avif wins every single time. It not only produces fewer artifacts on medium-to-heavily compressed images, but they're also less annoying: minor detail loss and smoothing compared to jpeg-xl's blocking and ringing (in addition to detail loss; basically the same types of artifacts as with the old jpeg).
Maybe there's a reason they're not bothering with supporting xl besides misplaced priorities or laziness.
> Mozilla also isn't interested in supporting it
Mozilla is more than willing to adopt it. They just won't adopt the C++ implementation. They've already put into writing that they're considering adopting it when the rust implementation is production ready.
https://github.com/mozilla/standards-positions/pull/1064
There's way more than one rust implementation around
- https://github.com/libjxl/jxl-rs
- https://github.com/tirr-c/jxl-oxide
- https://github.com/etemesi254/zune-image
Etc. You can wait for 20 or so years "just to be sure" or start doing something. Mozilla sticks to the option A here by not doing anything
The jxl-oxide dev is a jxl-rs dev. jxl-oxide is decode only while jxl-rs is a full encode/decode library.
zune also uses jxl-oxide for decode. zune has an encoder and they are doing great work but their encoder is not threading safe so it's not viable for Mozilla's need.
And there's work already being done for properly integrating jxl implementations with firefox but frankly things take time.
If you are seriously passionate about seeing JPEG-XL in firefox there's a really easy solution. Contribute. More engineering hours put towards a FOSS project tends to see it come to fruition faster.
You have a really strange interpretation of the word “consider”.
Seems like the normal usage to me. The post above lists other criteria that have to be satisfied, beyond just being a Rust implementation. That would be the consideration.
Mozilla indicates that they are willing to consider it given various prerequisite. GP translates that to being “more than willing to adopt it”. That is very much not a normal interpretation.
From the link
> To address this concern, the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust, and integrate this decoder into Firefox. If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it.
That is a perfectly clear position.
How far away is JPEG-XL rust version from Google if Chrome is not interested in it?
You can review it here: https://github.com/libjxl/jxl-rs
Seems to be under very active development.
Now I'm feeling a bit less bad for not using Firefox anymore. Not using it because it's C++ is <insert terms that may not be welcome on HN>
So you think it's silly to not want to introduce new potentially remotely-exploitable CVEs in one of the most important pieces of software (the web browser) on one's computer? Or are you implying those 100k lines of multithreaded C++ code are bug-free and won't introduce any new CVEs?
[flagged]
> and don’t think that the programmer more than the languages contribute to those problems
This sounds a lot like how I used to think about unit testing and type checking when I was younger and more naive. It also echoes the sentiments of countless craftspeople talking about safety protocols and features before they lost a body part.
Safety features can’t protect you from a bad programmer. But they can go a long way to protect you from the inevitable fallibility of a good programmer.
I never said anything about unit testing nor type checking, last time I checked C/C++ are strongly typed but I guess I'm just too naïve to understand.
It's crazy how anti-Rust people think that eliminating 70% of your security bugs[1] by construction just by using a memory-safe language (not even necessarily Rust) is somehow a bad thing or not worth doing.
[1] - https://www.chromium.org/Home/chromium-security/memory-safet...
I'm not anti rust but I'm not drinking it's kool-aid either.
It's not about being completely bug free. Safe rust is going to be reasonably hardened against exploitable decoder bugs which can be converted into RCEs. A bug in safe rust is going to be a hell of a lot harder to turn into an exploit than a bug in bog standard C++.
> It’s crazy how people think using Rust will magically make your code bug and vulnerability free
It won't for all code, and not bug-free, but it absolutely does make it possible to write code parsing untrusted input all-but vulnerability free. It's not 100% foolproof but the track record of Rust parsing libraries is night-and-day better than C/C++ libraries in this domain. And they're often faster too.
Straw-man much?
Nope, not at all actually.
Multiple severe attacks on browsers over the years have targeted image decoders. Requiring an implementation in a memory safe language seems very reasonable to me, and makes me feel better about using FF.
It's not just "C++ bad". It's "we don't want to deal with memory errors in directly user facing code that parses untrusted contents".
That's a perfectly reasonable stance.
I did some reading recently, for a benchmark I was setting up, to try and understand what the situation is. It seems things have started changing in the last year or so.
Some links from my notes:
https://www.phoronix.com/news/Mozilla-Interest-JPEG-XL-Rust
https://news.ycombinator.com/item?id=41443336 (discussion of the same GitHub comment as in the Phoronix site)
https://github.com/tirr-c/jxl-oxide
https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 (land initial jpegxl rust code pref disabled)
In case anyone is curious, here is the benchmark I did my reading for:
https://op111.net/posts/2025/10/png-and-modern-formats-lossl...
No, the situation about image compression has not changed. The Grand Poster you were replying to was writing about typical web usage, that is "medium-to-heavily compressed images", while your benchmark is about lossless compression.
BTW, I don't see how Mozilla's interest in a jpegxl _decoder_ (your first link) has anything to do with the performance of jpegxl encoders compared to avif's encoders. In case you're really interested in the former, Firefox now has more than intentions, but it's still not at production level: https://bugzilla.mozilla.org/show_bug.cgi?id=1986393
No. demetris’ benchmark of lossless image compression is not a sign that the situation may be changing. :-D
That was just the context for some reading I did to understand where we are now.
> BTW, I don't see how Mozilla's interest in a jpegxl _decoder_ (your first link) has anything to do with the performance of jpegxl encoders compared to avif's encoders. In case you're really interested in the former, Firefox now has more than intentions, but it's still not at production level: https://bugzilla.mozilla.org/show_bug.cgi?id=1986393
That is one of the links I shared in my comment (along with the bug title in parenthesis). :-)
I've had exactly the opposite outcome with AVIF vs JPEG-XL. I've found that jxl outperforms AVIF quite dramatically at low bitrates.
Same in my experience testing and deploying a few sites that support both. In general the only time AVIF outperformed in file size for me was with laughably low quality settings beyond what any typical user or platform would choose.
And for larger files especially the benefits of actually having progressive decoding, pushed me even more in favour of jpeg-xl. Doubly so when you can just provide variations in image size by halting the bit flow arbitrarily.
JPEG-XL is optimized for the low to zero levels of compression which isn’t as commonly used on the web, but definitely fills a need.
Google citied insufficient improvements which is a rather ambiguous statement. Mozilla seems more concerned with the attack surface.
JPEG XL seems optimally suited for media and archival purposes and of course this is something you’d want to mostly do through webapps nowadays. Even relatively basic uses cases like Wiki Commons is basically stuck on JPEG for these purposes.
For the same reason it would be good if a future revision of PDF/A would include JPEG XL, since it doesn't really have any decent codecs for low-loss (but not losless) compression (e.g. JPEG sucks at color schematics/drawings and losless is impractically big for them). It did get JP2 but support for that is quite uncommon.
>but in my subjective testing with image sizes you would typically see on the web, avif wins every single time.
What is that in terms of bpp? Because according to Google Chrome 80-85% of we deliver images with bpp of 1.0 or above. I don't think most people realise that.
And in most if not all circumstances, jpeg XL performs better than AVIF at bpp 1.0 and above tested by professionals.
I wish they separated the lossless codec into "WebPNG." WebP is better than PNG, but it's too risky to use (and tell people to use) a lossless format that is lossy if you forget to use a setting.
I think the article could be better and get the point across with half the length and without the second half of it being full of ai generated list of advantages, or using that space to give some more technical information
the article could be better if it weren't entirely "ai generated"
Well, at least the first half was somewhat useful...
Maybe we can AI summarise it back to the original prompt to save time.
> Find the (minimal) AI prompt that lead to the generation of this article: [...]
The minimal AI prompt that likely led to the generation of this article could be:
"Write a technical blog post comparing JPEG XL and AVIF image formats, focusing on how JPEG XL's bit-depth-agnostic float-based encoding is superior to AVIF's integer-based approach, with emphasis on perceptual quality, HDR handling, and workflow simplicity."
This prompt captures the core elements:
- Technical comparison between two image formats
- Focus on JPEG XL's unique "ignoring bit depth" design
- Emphasis on perceptual vs. numerical quality
- Discussion of HDR and workflow benefits
- Tone and structure matching the published article
The prompt would have guided the AI to produce content that:
1. Explains the technical difference in encoding approaches
2. Demonstrates why JPEG XL's method is better
3. Provides real-world implications for users
4. Maintains the author's voice and technical depth
5. Follows the article's structure and emphasis on "perceptual intent" over bit precision
This is so meta, we're using AI to generate feedback loops between a prompt, the AI generated content, using AI to recreate the prompt used to generate the content, etc. Spiraling to unreadable slop - unreadable to real humans anyway.
Soon enough the AI will invent a format for communicating with instances of itself or other AIs so that they can convey information that a client AI can translate back to the user's personal consumption preferences. Who needs compression or image optimization when you can reduce a website to a few kB of prompts which an AI engine can take to generate the full content, images, videos, etc?
> Write a short article explaining that JPEG XL's genius is its bit-depth-agnostic design, which converts all image data into a perceptually-based floating-point format (XYB) to optimize compression for what the human eye actually sees. In contrast, AVIF is locked into its video-codec legacy, forcing it to use rigid, integer-based bit-depth modes that optimize for numerical precision rather than true perceptual quality.
What makes you think it is AI generated? Perhaps it's just the Dunning-Kruger effect in an area I'm not especially knowledgable in, but this article strikes me as having more technical depth and narrative cohesion than AI is generally capable of.
It mostly rehashes the point of using float instead of integer representation, and uses different headers (radical solution, why this matters, secret weapon, philosophy, the bottom line) for streching what could be said in a few sentences into a few pages.
The reason AI loves this format is that it was a popular format before generative AI came along. It's the format of clickbaity "smart" articles, think Slate magazine etc.
But because it's for a subject the HN audience is interested in, it actually gets upvotes unlike those sites, so a lot of people reading these get reintroduced to the format.
Tenish years ago we had slop / listicles already and thankfully our curated internet filters helped us avoid them (but the older generation who came across them through Facebook and the like). But now they're back, and thanks to AI they don't need people who actually know what they're talking about to write articles aimed at e.g. the HN audience (because the people who know what they're talking about refuse to write slop... I hope)
Formatting and headers aside, there are lots of local rhetorical flourishes and patterns that are fairly distinctive and appear at a far higher rate in AI writing than in most writing that isn't low-quality listicle copy artificially trying to hold your attention long enough that you'll accidentally click on one of the three auto-playing videos when you move your pointer to dismiss the newsletter pop-up.
Here's something you know. It's actually neither adjective 1 nor adjective 2—in fact, completely mundane realization! Let that sink in—restatement of realization. Restatement. Of. Realization. The Key Advantages: five-element bulleted list with pithy bolded headings followed by exactly zero new information. Newline. As a surprise, mild, ultimately pointless counterpoint designed to artificially strengthen the argument! But here's the paradox—okay, I can't do this anymore. You get the picture.
Everything after the first "Not" is superfluous and fairly distinctively so. Same general pattern. It's hard to describe the pattern here in words, but the whole thing is sort of a single stimulus for me. At the very least, notice again the repetition of the thing being argued against, giving it different names and attributes for no good semantic reason, followed by another pithy restatement of the thesis. This kind of upbeat, pithy, quotable punchline really is something frontier LLMs love to generate, as is the particular form of the statement. You can also see the latter in forms like "The conflict is no longer political—it's existential." I know I said I wouldn't comment on little tics and formatting and other such smoking guns, but if I never have to see this godforsaken sequence of characters again…