Google unkills JPEG XL?

I think GP only wants to convert images back for users with legacy browsers, not for everyone. So converting 100% of the images needs more compute money than the amount of storage money it saves, but only converting ~1% of the images on-the-fly would be worth it financially.

IIRC they benchmarked it as "not much better" than AVIF, not inferior.

That would make sense, since they would then need support for JXL for the embedded PDF viewer anyway. Unless they want it to choke on valid PDFs that include JXL images.

I see! Thanks for pointing out this very interesting correlation. So we got something better only because someone else equally influential forced their hand. Otherwise the users be damned, for all they care, it seems.

Some of the same people developed both. Pretty sure Jyrki Alakuijala for example led the development of lossless mode for both WebP and JPEG-XL.

my fallible memory of roughly the same sources

BMP decoding may seem easy and fun (I wrote a toy decoder back in the day), but the vulnerabilities are real: https://nvd.nist.gov/vuln/detail/CVE-2025-32468

It's not the format, it's the C / C++ unfortunate baggage.

Happy to report the BMP work is actually being done by our friends on the Edge team at Microsoft! https://chromium-review.googlesource.com/c/chromium/src/+/72...

The most popular software in question is also a giant pile of C++, btw.

Who is saying Google should ship the reference implementation? It's a standard, and Google has the labor to write their own implementation.

Mozilla's position for some time now has been, "we aren't opposed to shipping JXL support, but we'd want to ship a decent implementation in a memory safe language, not the reference C++ implementation". That position hasn't been met with very much criticism.

Google's position, on the other hand, has been a flat-out "no, we will not ship JXL". That's what has been met with criticism. Not an imagined reluctance to shipping a C++ JXL implementation.

I admit it, I was applying Cunningham’s Law. Disappointingly(?), you came to the same answer.

Tiled at different zoom levels

Probably, multiple resolutions of the same thing. E.g. a lower res image of the entire scene and then higher resolution versions of sections. As you zoom in, the higher resolution versions get used so that you can see more detail while limiting memory consumption.

Replicated at different resolutions depending on your zoom level.

One patch at low resolution is backed by four higher-resolution images, each of which is backed by four higher-resolution images, and so on... All on top of an index to fetch the right images for your zoom level and camera position.

I think it means encoded in such a way that you first have low res version, then higher res versions, then even higher res versions etc.

JPEG and friends transforms the image data into the frequency domain. Regular old JPEG uses the discrete cosine transformation[1] for this on 8x8 blocks of pixels. This is why with heavily compressed JPEG images you can see blocky artifacts[2]. JPEG XL uses variable block size DCT.

Lets stick to old JPEG as it's easier to explain. The DCT takes the 8x8 pixels of a block and transforms it to 8x8 magnitudes of different frequency components. In one corner you have the DC component, ie zero frequency, which represents the average of all 8x8 pixels. Around it you have the lowest non-zero frequency components. You have three of those, one which has a non-zero x frequency, one with a non-zero y frequency, and one where both x and y are non-zero. The elements next to those are the next-higher frequency components.

To reconstruct the 8x8 pixels, you run the inverse discrete cosine transformation, which is lossless (to within rounding errors).

However, due to Nyquist[3], you don't need those higher-frequency components if you want a lower-resolution image. So if you instead strip away the highest-frequency components so you're left with a 7x7 block, you can run the inverse transform on that to get a 7x7 block of pixels which perfectly represents a 7/8 = 87.5% sized version of the original 8x8 block. And you can do this for each block in the image to get a 87.5% sized image.

Now, the pyramidal scheme takes advantage of this by rearranging how the elements in each transformed block is stored. First it stores the DC components of all the blocks the image. If you just used those, you'd get an image which perfectly represents a 1/8th-sized image.

Next it stores all the lowest-frequency components for all the blocks. Using the DC and those you have effectively 2x2 blocks, and can perfectly reconstruct a quarter-sized image.

Now, if the decoder knows the target size the image will be displayed at, it can then just stop reading when it has sufficiently large blocks to reconstruct the image near the target size.

Note that most good old JPEG decoders supports this already, however since the blocks are stored one after another it still requires reading the entire file from disk. If you have a fast disk and not too large images it can often be a win regardless. But if you have huge images which are often not used in their full resolution, then the pyramidal scheme is better.

[1]: https://en.wikipedia.org/wiki/Discrete_cosine_transform

[2]: https://eyy.co/tools/artifact-generator/ (artifact intensity 80 or above)

[3]: https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampli...

That is awesome. In my domain, images (TIFFs usually) are up to 1m x 1m pixels and scaling usually goes 4x so that if you need 2x scaling you can just read 4 times as many tiles from the higher resolution level and downscale. With 8x scaling you need to go a level further - reading 16 pixels from the image to create 1 pixel of output. Not great but it would work and 4096 scaling would make the lowest resolution image 256 x 256 which is just what you need.

A better Gemini also works. Google Search seems to use the most minimal of Geminis, giving it a bad rep.

Prompt: “How many A4 pages would a 1073741823×1073741824 image printed at 600dpi be?”

Gemini Pro: “It would require approximately 33.1 billion (33,127,520,230) A4 pages to print that image.

To put that into perspective, the image would cover an area of 2,066 square kilometers […].

The Math

1. Image Dimensions: 1,073,741,823 × 1,073,741,824 pixels.

2. Physical Size: At 600 DPI, the image measures roughly 45.45 km wide by 45.45 km tall.

3. A4 Area: A single sheet of A4 paper (210 mm * 297 mm) covers approximately 0.06237 m².

4. Result: 2,066,163,436 m² / 0.06237 m² ≈ 33,127,520,230 pages.”

Alternatively, rink (https://rinkcalc.app/) :

> (1073741823 / (600/inch))**2 / A4paper

approx. 3.312752e10 (dimensionless)

Grok 4.1 beta finds the answer: approximately 33.1 billion pages.

svg is also just kind of annoying to deal with, because the image may or may not even have a size, and if it does, it can be specified in a bunch of different units, so it's a lot harder to get this if you want to store the size of the image or use it anywhere in your code

It couldn't have been a wrapper - it understood a tiny tiny fraction of the things that Gnu units does.

Another one I've noticed is using "I've" as a contraction in e.g. "I've a meeting to attend". Seems totally reasonable but for some reason native speakers just don't use it that way.

German speakers usually have very good English, but this is already one of their tells.

Fixed that for you.

Could also be French speakers. They would say "J'utilise le format .avif depuis quelques années." I think the "depuis" throws off the French speakers when they translate that literally as "since some years" instead of "for some years".

Another common tell: I wake up in the morning in the US/Pacific time zone, and see the European writers on HN using "I have ran" instead of "I have run".

The Linux kernel is 40M lines of code after 34 years of development.

OP might have well have said "infinite lines of code" for JPEGXL and wouldn't have been much less accurate. Although I'm guessing they meant 100k.

>> 100M+ is a bit more than i would expect for an image format. have i not been paying attention

> So at least if GP was talking about libjxl "100K+" would be more accurate.

M can mean thousands and I think it's common to use it used that way in finance and finance-adjacent areas: https://www.chicagomanualofstyle.org/qanda/data/faq/topics/A...:

> A. You’ve identified two commonly used conventions in finance, one derived from Greek and the other from Latin, but neither one is standard.

Starting with the second convention, M is used for amounts in the thousands and MM for amounts in the millions (usually without a space between the number and the abbreviation—e.g., $150M for $150,000 and $150MM for $150 million). This convention overlaps with the conventions for writing roman numerals, according to which a thousand is represented by M (from mille, the Latin word for “thousand”). Any similarity with roman numerals ends there, however, because MM in roman numerals means two thousand, not a thousand thousands, or one million, as in financial contexts...

https://www.accountingcoach.com/blog/what-does-m-and-mm-stan...:

> An expense of $60,000 could be written as $60M. Internet advertisers are familiar with CPM which is the cost per thousand impressions.

> The letter k is also used represent one thousand. For example, an annual salary of $60,000 might appear as $60k instead of $60M.

One of the best ways to measure code complexity is to zip up the source code. This eliminates a lot of the redundancies and is a more direct measure of entropy/complexity than almost anything else.

By that metric, jpeg-xl is about 4x the size of the jpeg or png codebase.

They did indeed.

the article includes test code and encoder code, that is not the way how we compute the decoder size

the decoder is something around 30 kloc

100M+ lines of code isn't a hyperbole for some codebases, though. google3 is estimated at about 2 billion lines of code, for example.

Maybe it was hyperbole. But if it was it wasn't obvious to me, unfortunately.

Agreed, and Google developers can probably be trusted to 'act responsibly', but too often people forget the distinction. Some Rust codebases are wildly unsafe, and too often people see written in Rust and falsely conclude it's a memory-safe codebase.

If this was a real problem then you could have just `s/[]/at()/g` across your codebase and called it a day.

But you all don't even bother to do that, so I guess it's not actually a problem in practice.

Then again PDF also technically supports embedded audio, video, 3D graphics, and arbitrary Javascript. If Flash hadn't died it would probably still support that too. It's a clown car format where everyone besides Adobe just tacitly agrees to ignore huge chunks of the spec.

Web standard I meant. The OP didn't talk about PDFs from context.

One thing I like about PDF is the annotations (notes & highlights) are embedded in the PDF itself. That is not the case for EPUB files, each EPUB reader stores annotations in its own proprietary format.

> Lack of metadata for collecting

PDFs have pretty excellent support for metadata. If the collection software doesn't support at least Dublin Core, that may be kind of their own fault...

I am mostly reading on a tablet, not a phone. I think if you are reading on a phone you are already screwed —- if people are “reading” on phones I think 80% of it is that you just read less.

I oversee ebook production for a uni press so I am familiar with how the proverbial sausage is made. Which is why I still mainly prefer print books.

There is a mode for PDF files that reflows and is logically similar to EPUB in that there is an HTML-derived data model and you have images embedded in the PDF much as they are embedded in the EPUB. Of course if you hate how complex PDF is it is more to hate.

I don't know much about webp. Just have checked the wiki, it looks nice. So for which reason you hate it?

VP8 is in all major browsers due to WebRTC, and webp uses little more code than the VP8 keyframe decoder, so it also has baseline support and is unlikely to be deprecated any time soon. https://caniuse.com/?search=vp8

Similarly, AVIF uses little more code than the AV1 keyframe decoder, so since every browser supports AV1, every browser also supports AVIF.

It's all arbitrary. WEBP is deprecated, just like GIF is deprecated.

Usually it’s Mozilla not wanting to implement something Google wants to implement, not the other way around.

They have many millions to spend on engineers. They should do that.

Yeah, they need those resources to pay the CEO!

> maintain a feature that no one can actually use;

If only there was a way to detect which features a browser supports. Something maybe in the html, the css, javascript or the user agent. If only there was a way to do that, we would not be stuck in a world pretending that everything runs on IE6. /s

With all due respect, this is a completely HN-brained take.

No significant number of users chooses their browser based on support for image codecs. Especially not when no relevant website will ever use them until Safari and Chrome support them.

And websites which already do not bother supporting Firefox very much will bother even less if said browser by-default refuses to allow them to make revenue. They may in fact go even further and put more effort into trying to block said users unless they use a different browser.

Despite whatever HN thinks, Firefox lost marketshare on the basis of:

A) heavy marketing campaigns by Google including backdoor auto-installations via. crapware installers like free antivirus, Java and Adobe, and targeted popups on the largest websites on the planet (which are primarily google properties). The Chrome marketing budget alone nearly surpasses Mozilla's entire budget and that's not even accounting for the value of the aforementioned self-advertising.

B) being a slower, heavier browser at the time, largely because the extension model that HN loved so much and fought the removal of was an architectural anchor, and beyond that, XUL/XPCOM extensions were frequently the cause of the most egregious examples of bad performance, bloat and brokenness in the first place.

C) being "what their cellphone uses" and Google being otherwise synonymous with the internet, like IE was in the late 1990s and early 2000s. Their competitors (Apple, Microsoft, Google) all own their own OS platforms and can squeeze alternative browsers out by merely being good enough or integrated enough not to switch for the average person.

> all sorts of things that the community wants, like JpegXL, XSLT, RSS/Atom, Gemini (protocol, not AI), ActivityPub, etc.

What “community” is this? The typical consumer has no idea what any of this is.

The other key browser implementers are also part of WHATWG.

Who do you suppose should be in charge of web standards? I can’t imagine the train wreck of incompetence if standards were driven by bureaucrats instead of stakeholders.

> and another that wanted to create the platform on which Microsoft Word could be built.

Apparently they failed. The web version of Word is still far from having feature parity. Of course doc is one of those everything and the kitchen sink formats, so implementing it on top of a platform that was originally intended to share static documents is kind of a tall order.

It's a meta-commentary about the death of critical thinking and the ease with which mindless mobs can be whipped.

From the jump, the article commits a logical error, suggesting that Google killed jpegxl because it favors avif, which is "homegrown". jpegxl, of course, was also written by Google, so this sentence isn't even internally consistent.

The web was designed from the start to solve this problem and you can serve alternate formats to user agents which will select the one they support.

I'm using mine to develop 3D apps, which became way to cumbersome and eventually impossible since Firefox dragged its feet on inplementing important stuff.