> JPEG XL: Better than JPEG in every way aside from legacy support, while being royalty free and open.
And decoder complexity. A software JPEG decoder is a weekend project. A hardware JPEG decoder not much more. Doing the same for arbitrary JPEG XL files is much, much more complicated. In any world where any of development cost, implementation complexity, expected code quality (especially when using first-order assumptions like constant number of defects per line of code), or decoder resources (especially for hardware implementations) are important, JPEG has serious advantages.
If we were talking about some abstract hypothetical format, this is entirely reasonable. Only there are a number of extremely high quality JPEG XL decoders. There is zero need for hardware assistance for decoding JPEG or JPEG XL, so that difference is a non-difference.
Every device in the world with iOS 17 or macOS 14 or better has JPEG XL support across the system.
This is a complete and utter non-issue. Google had even added JPEG XL support to Chromium, and then bizarrely removed it (not long before Apple fully supported JXL across all their platforms which invariably would have pushed it over the top), presumably to try to anoint WebP as the successor. Only WebP has so many disadvantages that all they did was entrench classic JPEG.
JPEG XL is unquestionably the best current next gen format for images.
> There is zero need for hardware assistance for decoding JPEG or JPEG XL, so that difference is a non-difference.
This depends on the system requirements, doesn't it? Suppose you're compositing a low-safety-impact video stream with (well, under) safety-impacting information in an avionics application, and you're currently using a direct GMSL link. There's an obvious opportunity to cost-down and weight-down the system by shifting to a lightly compressed stream over an existing shared Ethernet bus, and MJPEG is a reasonable option for this application (as is H.264, and other options -- trade study needed). When considering replacing JPEG with JPEG XL in this implementation, what's your plan for providing partitioning between the "extremely high quality" but QM software implementation and the DAL components? Are you going to dedicate a core to avoid timing interference? At that point you're spending more silicon than a dedicated JPEG decoder would take. You likely already have an FPGA in the system for doing the compositing itself, but what's the area trade-off between an existing "extremely high quality" JPEG XL hardware decoder and the JPEG one that you've been using for decades?
I don't doubt that in a world where everything is an iPhone (with a token nod to Android), "someone already wrote the code once and it's good enough" is sufficient. But there's a huge field of software engineering where complexity and quality drive decision making, and JPEG XL really is much more complex than JPEG Classic Flavor.
Seems like a hard thing to know. I’ve only written and shipped one (MJPEG w/ Speex audio slipstreamed in COM blocks), but I’m only one person… so based on that sample, somewhere between zero and the number of software engineers?
And decoder complexity. A software JPEG decoder is a weekend project. A hardware JPEG decoder not much more. Doing the same for arbitrary JPEG XL files is much, much more complicated. In any world where any of development cost, implementation complexity, expected code quality (especially when using first-order assumptions like constant number of defects per line of code), or decoder resources (especially for hardware implementations) are important, JPEG has serious advantages.