Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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.

[0]: https://github.com/libjxl/libjxl


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.


Interesting approach


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.


I'm familiar with the concept[1], but I'm unsure if it's a good showcase of code complexity. I've tested some internal microservices I'm deeply familiar with and found no correlation...

[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)


Your method would still judge well-documented code with lots of intermediate variables as more complex than undocumented code golf soup.


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


"It's... a regional dialect."

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


In some areas M is mille as in the Latin/French/Italian word for thousand, e.g.

https://en.wikipedia.org/wiki/Cost_per_mille


Okay, but this is... not finance? And the article itself wrote 100K. Rewriting that as 100M does nobody a favor.


I don't think many (if any) programmers would imagine 100M lines of code to mean 100,000 lines of code and not 1,000,000...


Technically right is the worst kind of right


I'm surprised at the negative reaction to having it pointed out that the OP may not be wrong, just using a dialect.


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.


You are correct, "K" not "M" in my typo.


They wanted to say 100K instead of 100M


They did indeed.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: