Re:Google set to deprecate JPEG XL support in Chrome 110
by JyrkiAlakuijala on Monday October 31, 2022 @07:06PM
(#33414612)
It 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.
Re:Google set to deprecate JPEG XL support in Chrome 110
by jakub_g on Tuesday November 01, 2022 @08:57AM
(#33420521)
Thanks for clarification! Are those truly independent implementations? (i.e. not derived from each other? I'm not deep into the subject.)
Re:Google set to deprecate JPEG XL support in Chrome 110
by lifthrasiir on Wednesday November 02, 2022 @12:12AM
(#33431353)
I'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.
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.