4 ms·
While it seems JPEG XL is very nice, I think the comment 72 from Kornel Lesinski is spot on: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c72
by jakub_g 4y ago
While it seems JPEG XL is very nice, I think the comment 72 from Kornel Lesinski is spot on:
https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c72 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
> In terms of compression performance JPEG XL is really good, but I'm concerned that it does not have more than a single implementation.
> W3C's bar for web standard recommendations is having at least two independent implementations. AVIF has multiple interoperable implementations in multiple languages. JPEG XL doesn't have yet.
> Given the substantial complexity and scope of the JPEG XL format, I'd like to see a proof that a second implementation is possible, and that it's interoperable, so that the Web platform doesn't end needing bug-compatibility with a single C++ codebase.
- JyrkiAlakuijala 4y agoIt is not entirely correct. There is a C (j40.c) and two C++ implementations (libjxl and libjxl-tiny). Kornel would love to see a Rust implementation I believe.
- jakub_g 4y agoThanks for clarification! Are those truly independent implementations? (i.e. not derived from each other? I'm not deep into the subject.)
- lifthrasiir 4y agoI'm the author of J40 and it was intentionally developed from scratch exactly in order to remedy the situation where libjxl serves as a de facto specification as opposed to the actual specification.