> One final significant benefit of JPEG XL is that it has a broad scope: while it is a great format for web delivery, this is not the only use case it was designed for. JPEG XL can also be used as a capture format, where it can play a role similar to current camera raw formats: high precision, high dynamic range, lossless or minimal lossy compression. It can also be used as an authoring format, supporting named layers, selection masks, multiple alpha channels. It can be used for printing use cases, supporting e.g. CMYK and spot colors. It can be used for medical or scientific applications, supporting high-precision lossless compression and multispectral imaging. And so on. It is a general-purpose format that covers many different use cases for digital imaging.
So that's all impressive and useful and probably quite good, but my first reaction is that sinking feeling from being faced with unexpected complexity. Is the JXL format a nightmare internally? Is it a nightmare to use the library as an inexperienced app developer? Do you need to care about those unusual features if you just want to display an image? I expect that it's all fine, since what little I've heard has been good. If so, kudos to the designers because that's an ambitious feature list. It feels uncommon for a format of any kind to set out to be all things to all people and succeed.
Features such as spot colors are mostly just a matter of understanding a wide range of requirements; this particular one just boils down to an extra image layer.
And here we immediately see one important difference between them: the first link is to a 681-page PDF, which opens immediately in my browser. The second link is to a place where one can buy access to what it says is a 101-page PDF, after paying more money than it would cost to buy a basic laptop.
Yeah, a lot of things cost more than a basic laptop. Last I checked, you can get Chromebooks on the order of $20 or so per machine. That metric isn't useful to anybody.
That's a difference between AOM and ISO: ISO puts specs behind a paywall but anyone interested can participate in the actual standardization process through their national standardization body, AOM makes specs publicly available but participating in the standardization process costs about as much as a nice car. I don't really like either model, but I don't think I particularly prefer AOM's model.
We created avenues for open source / community participation in AOM that did not require people to pay any money. Specifically, Mozilla sponsored the membership of VideoLAN, which in theory anyone could join, and a number of people did and do participate through that organization.
Is there a "latest draft" standard available legally and for free for wider audiences? C++, also ISO standardized, does this and I believe it has contributed greatly to its adoption and post-C++11 renaissance. See https://en.cppreference.com/w/cpp/links#C.2B.2B_Language_and... . For now, JPEG XL might as well be a proprietary closed format for most hackers here.
Recent drafts do tend to get circulated amongst the image compression community. For wide audiences I don't think this type of document is very readable nor relevant; the number of people who are going to make their own independent implementation is relatively small. In this sense the spec audience is not quite the same as that of a spec for a programming language, which is important not just for compiler implementers but also for programmers in general.
That said, I do hope that ISO will change its policy to put specs behind a paywall.
As one of the authors of the spec, I would be open to also publishing it with another standardization organization that makes specs publicly available, if the legal issues can somehow be sorted out. I think the other spec authors would also be open to that. We certainly have no desire to have a spec that is behind a paywall; that is just the way ISO operates, unfortunately.
JPEG XL format internals are beautiful -- control structures are self-similar and the image coding itself is used to code substructures, similar to WebP lossless.
libjxl C++ implementation is modern high-performance multi-threaded SIMD code, with layering, animation, streaming and progressive features, it can look scary. With some less emphasis on performance it could be written rather elegantly.
So that's all impressive and useful and probably quite good, but my first reaction is that sinking feeling from being faced with unexpected complexity. Is the JXL format a nightmare internally? Is it a nightmare to use the library as an inexperienced app developer? Do you need to care about those unusual features if you just want to display an image? I expect that it's all fine, since what little I've heard has been good. If so, kudos to the designers because that's an ambitious feature list. It feels uncommon for a format of any kind to set out to be all things to all people and succeed.