Comment by EMM_386 2 days ago
Isn't this due to the 100M+ line C++ multi-threaded dependency being a potential nightmare when you are dealing with images in browsers/emails/etc. as an attack surface?
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.
According to tokei, the lib/ directory from the reference implementation [0] has 93821 lines of C++ code and 22164 lines of "C Header" (which seems to be a mix of C++ headers, C headers, and headers that are compatible with both C and C++). The tools/ directory adds 16314 lines of C++ code and 1952 lines of "C Header".
So at least if GP was talking about libjxl "100K+" would be more accurate.
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.
It comes from the "intelligence is a form of compression" hypothesis that has been floating around in the ML space. Also, with a good compression algorithm it is a fairly direct measure of entropy, which is quite well correlated with what a developer might consider code size and/or complexity.
>> 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.
I assume this is regional... I work in accounting and finance in New Zealand (generally following ordinary Western/Commonwealth standards) and I've never heard of using M for thousands. If I used that I would confuse the hell out of everyone around me.
The article says 100K, not 100M. I'm guessing that's what the parent comment meant.
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 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
It's a container format that does about a bajillion things - lossy, lossless, multiple modes optimized for different image types (photography vs digital design), modern encode/decode algorithms, perceptual color space, adaptive quantization, efficient ultra-high-resolution decoding and display, partial and complete animation, tile handling, everything JPEG does, and a bunch more.
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.
This is some strange misinformation.
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.
>The compiled compressed binary for an APK
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...
libjxl is is <112,888 lines of code, about 3 orders of magnitude less than you're 100M+ claim.
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.
-> They were concerned about the increased attack surface resulting from including the current 100K+ lines C++ libjxl reference decoder, even though most of those lines are testing code.
Seems like Google has created a memory-safe decoder for it in Rust or something.
because memory safety is the only attack vector, as we all know
> I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation.
It would need to be written in the Safe Rust subset to give safety assurances. It's an important distinction.
99% safe with 1% unsafe mixed in is far, far better than 100k loc of c++ -- look at Google's experience with rust in Android. It's not perfect and they had one "almost vulnerability" but the rate of vulnerabilities is much, much lower even with a bit of unsafe mixed in.
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.
> ...but now in le Rust!!1
I look forward to the next generation of rubes rewriting this all in some newer ""safe"" language in three decades.
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.
100M+ is a bit more than i would expect for an image format. have i not been paying attention