2 ms·
Feels like I'm quite wrong when I said (and got flagged for saying), "Gonna cause quite the firestorm, creating something new everyone will be expected to supp
by jauntywundrkind 3y ago
Feels like I'm quite wrong when I said (and got flagged for saying),
"Gonna cause quite the firestorm, creating something new everyone will be expected to support and maintain, after Google balked at bringing in jpegxl because they would have to support it."
I still really find the messaging here to be awful. There's tons of comments asking how this related to JXL. @JyrkAlakuijala chimes in in https://news.ycombinator.com/item?id=39921484 https://news.ycombinator.com/item?id=39921484 that yes it uses JXL techniques, but also it's just using that repo because it had infrastructure which was easy to get started with (absolutely cannot argue with that).
I'm not sure what my ask is, but this felt like a really chaotic release. It's unclear how much good from JPEG XL got chopped off. I'm glad for the iteration, this just seemed really chaotic & unexpected, & NIMBY-istic.
- JyrkiAlakuijala 3y agoI think technically it is it's own github repo, just under libjxl user. I could be mistaken, I'm still learning git and GitHub.
- JyrkiAlakuijala 3y agoI got this wrong. We actually did the implementation in the libjxl/libjxl repo. There is no physical reuse of the jpeg xl code, however. It would have been clearer to make it its own repo.