@bagder@mastodon.social To put in perspective:

• JPEG: libjpeg 6b encoder+decoder: 24,200 lines of C
• JPEG: libjpeg-turbo encoder+decoder: 127,000 of C and ASM (multi architectures)
• JPEG2000: openjpeg encoder+decoder: 50,000 lines of .C
• JPEG2000: Kakadu commercial encoder+decoder: 214,000 lines of C++ (only coresys component)
• libjxl: 150,000 lines for the core library, encoder+decoder (deps excluded)
  (All above includes blank lines + inline doc)
  So this is pretty much standard for a modern codec

@bagder@mastodon.social or about C++ and the state of coding and programming language tooling...

@bagder@mastodon.social That sounds like an atrocity. But if it shows ads faster...uhm...nevermind.😌

@bagder I think it is a bit misleading (and arguably unfair) to attribute this to Firefox specifically: this is the reference jpeg-xl implementation, originally created and maintained by Google, and in widespread experimental use across all kinds of browsers, including Chromium, Safari, Edge and more

@bagder@mastodon.social I can rewrite the JPEG-XL decoder it in a three day weekend 😅.

@bagder We had 100kloc C++ in a smart radiator valve that saved a bunch of extra energy.

I think it is just a reflection that extracting efficiency requires complexity.

@bagder@mastodon.social
And, just wondering:
How many of those lines are for handling security issues such as boobytrapped JPEGs?
How many lines do the other HTML rendering engine use for the same function?
The graphical web has many sins to make amends for!

@bagder@mastodon.social Wait, so JPEG XL isn't completely dead? That's probably not what you meant to communicate but I'm so happy to hear that

fwiw I think that LOC of the reference implementation doesn't really say anything about anything - even if Firefox "adopted" it, which feels like a sensible choice given the state of things

@bagder@mastodon.social that's why it's called XL! 😂

@bagder@mastodon.social so that's what the XL is there for 🤔🤣

@bagder@mastodon.social It’s what I wondered when I saw https://jxl-art.surma.technology/ and https://jpegxl.info/art/

@bagder@mastodon.social could isolate the decoder in a WASM runtime and only starting the rewrite if and when the format becomes popular enough :-)

@bagder@mastodon.social 100K? That's absurd

@bagder@mastodon.social IT complexity is ever increasing snd our dependence on it too…

@bagder@mastodon.social Bad things about Google's new format they hope to become widely adopted

@bagder@mastodon.social browser vendors should coordinate which subset of JPEG XL they want to support, and only this part of the standard needs to get implemented.

I remember JPEG and that you could never use progressive JPEGs. Some programs even offered an “export for web” feature so that you wouldn't use any unsupported JPEG features.

@bagder@mastodon.social I wonder if it's turing complete... something something Pegasus 0-click iMessage exploit.

@bagder@mastodon.social It's a good hot take, but what amazes me most is the replies so far immediately jumping to conclusions with biased gut reactions as if their identity is tied to one or the other camp.

@bagder@mastodon.social To be clear, this is just the reference implementation at https://github.com/libjxl/libjxl

@bagder@mastodon.social yeah, kinda puts into perspective all the 'negative feedback' the Chrome team received for removing JPEG-XL support. I wouldn't want to have such a monstrosity in my code base either, no matter what advantages the actual encoding might have over existing formats.

@bagder@mastodon.social
I really don't envy the people who'd have to rewrite that monstrosity.
See https://flak.tedunangst.com/post/on-building-jpeg-xl-for-wasm by @tedu@honk.tedunangst.com for the current state of the art method of decoding jpegxl safely, which is both hilarious and sad.