Google unkills JPEG XL?

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

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

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

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

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

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.

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.

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.

Tiled at different zoom levels

At least I didn't give Dang extra work.

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

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.

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.

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

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

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.

Yeah, they need those resources to pay the CEO!

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

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

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

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.

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.

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

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.

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.