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...

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

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

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.

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

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.

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.

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.

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.

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...

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.

> 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.

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

the decoder is something around 30 kloc

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

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

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.

Fixed that for you.

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".