4 ms·

Actual users, perhaps. Or maybe concern trolls paid by a patent holder who's trying to prepare the ground for a patent-based extortion scheme. Or maybe Jon Sney

Actual users, perhaps. Or maybe concern trolls paid by a patent holder who's trying to prepare the ground for a patent-based extortion scheme. Or maybe Jon Sneyers with an army of sock puppets. These "actual users" are just as real to me as Chrome's telemetry. That said: these actual users didn't demonstrate any hacker spirit or interest in using JXL in situations where they could. Where's the wide-spread use of jxl.js (https://github.com/niutech/jxl.js https://github.com/niutech/jxl.js) to demonstrate that there are actual users desperate for native codec support? (aside: jxl.js is based on Squoosh, which is a product of GoogleChromeLabs) If JXL is sooo important, surely people would use whatever workaround they can employ, no matter if that convinces the Chrome team or not, simply because they benefit from using it, no? Instead all I see is people _not_ exercising their freedom and initiative to support that best-thing-since-slices-bread-apparently format but whining that Chrome is oh-so-dominant and forces their choices of codecs upon everybody else. Okay then...

149765 3y ago
I tried jxl.js, it was very finicky on iPad, out of memory errors [0] and blurry images [1]. In the end I switched to a proxy server, that reencoded jxl images into png. [0]: https://github.com/niutech/jxl.js/issues/6 https://github.com/niutech/jxl.js/issues/6 [1]: https://github.com/niutech/jxl.js/issues/7 https://github.com/niutech/jxl.js/issues/7
- pgeorgi 3y ago
  Both issues seem to have known workarounds that could have been integrated to support JXL on iOS properly earlier than by waiting on Apple (who integrated JXL in Safari 17 apparently), so if anything that's a success story for "provide polyfills to support features without relying on the browser vendor."
  - 149765 3y ago
    The blur issue is an easy fix, yes, but the memory one doesn't help that much.
JyrkiAlakuijala 3y ago
We have been active on wasm implementations of jpeg xl but it doesn't really work with progressive rendering, HDR canvas was still not supported, threadpools and simd had hickups etc. etc. Browser wasn't and still isn't ready for high quality codecs as modules. We are continually giving gentle guidance for these but in the heart our small team is an algorithm and data format research group, not a technology lobbyist organization — so we haven't yet been successful there. In the current scenario jpeg xl users are most likely to emerge outside of the web, in professional and prosumer photography, and then we will have — unnecessarily — two different format worlds. Jpeg xl for photography processing and a variety of web formats, each with their problems.

149765 3y ago

I tried jxl.js, it was very finicky on iPad, out of memory errors [0] and blurry images [1]. In the end I switched to a proxy server, that reencoded jxl images into png. [0]: https://github.com/niutech/jxl.js/issues/6 https://github.com/niutech/jxl.js/issues/6 [1]: https://github.com/niutech/jxl.js/issues/7 https://github.com/niutech/jxl.js/issues/7

pgeorgi 3y ago
Both issues seem to have known workarounds that could have been integrated to support JXL on iOS properly earlier than by waiting on Apple (who integrated JXL in Safari 17 apparently), so if anything that's a success story for "provide polyfills to support features without relying on the browser vendor."
- 149765 3y ago
  The blur issue is an easy fix, yes, but the memory one doesn't help that much.

JyrkiAlakuijala 3y ago

We have been active on wasm implementations of jpeg xl but it doesn't really work with progressive rendering, HDR canvas was still not supported, threadpools and simd had hickups etc. etc. Browser wasn't and still isn't ready for high quality codecs as modules. We are continually giving gentle guidance for these but in the heart our small team is an algorithm and data format research group, not a technology lobbyist organization — so we haven't yet been successful there. In the current scenario jpeg xl users are most likely to emerge outside of the web, in professional and prosumer photography, and then we will have — unnecessarily — two different format worlds. Jpeg xl for photography processing and a variety of web formats, each with their problems.