So at least if GP was talking about libjxl "100K+" would be more accurate.
By that metric, jpeg-xl is about 4x the size of the jpeg or png codebase.
[1] for the past ~15 years actually, got introduced to the concept through works of mr. Hutter, after becoming aware of his Prize, and I'm dabbling in compression to this day (right now trying to improve on Bellard's nncp)
> 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.
"What region?"
"Er, upstate New York."
"Really. Well, I'm from Utica and I've never heard anyone use the phrase '100M' to mean '100 thousand'"
"Oh, no, not in Utica. It's an Albany expression."
100MLOC for an image format would be bananas. You could fit the entire codebases of a couple of modern operating systems, a handful of AAA videogames, and still have room for several web apps and command line utilities in 100MLOC.
the decoder is something around 30 kloc
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.
The C++ JPEG XL decoder is ~30'000 lines, i.e., 3000x smaller than you claim. A non-multithreaded, non-simdified code would be much simpler, around 8000 to 10000 lines of code.
It is not difficult to measure from the repository. The compiled compressed binary for an APK is 5x smaller than that of full AVIF. The complete specification at under 100 pages is ~13x more compact than that of full AVIF.
This doesn't undermine your argument at all, but we should not be compressing native libs in APKs.
https://developer.android.com/guide/topics/manifest/applicat...
Maybe it was hyperbole. But if it was it wasn't obvious to me, unfortunately.
Seems like Google has created a memory-safe decoder for it in Rust or something.
I look forward to the next generation of rubes rewriting this all in some newer ""safe"" language in three decades.
But you all don't even bother to do that, so I guess it's not actually a problem in practice.
Thankfully you can fix that with one sed command. Why don't you?
It would need to be written in the Safe Rust subset to give safety assurances. It's an important distinction.
I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation.
I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we've had since forever.