Comment by juliobbv
23 days ago
I invite you to re-read the post carefully, with the attention it deserves. Hint: at no point the blog post says JXL will not be improved.
23 days ago
I invite you to re-read the post carefully, with the attention it deserves. Hint: at no point the blog post says JXL will not be improved.
It sounds like you don't recognize the relationship between text and subtext.
The entire post amounts to saying "JXL in its first iterations was better than AVIF's more advanced state of development and support, but AVIF very recently got better only after several years of widespread adoption, and I don't think JXL would too".
The arguments given against JXL cannot be reconciled with the history of codec development.
Maybe you're just bad at reading text. Again, read the post carefully. Look around... nobody else had the same interpretation as you, so maybe that should clue you in something might be off with yours.
The post literally goes over known ways that JXL can be improved. The actual argument (and this is stated!) is whether those improvements will be enough to make JXL compelling to use for the web vs. other established formats (quality efficiency, encode/decode time, progressive loading, etc).
Also, don't assume AVIF or even WebP have maxxed out yet :) There are known ways to improve those two too!
I'll tell you what. In good faith, you should ask your friend to fix the numbers in the post specifically in relation to concerns that people have with the testing methodology in relation to threads and the speedtest flag instead of handwaving them and to be forthright about how significant codec optimization historically comes after adoption.
Because it's understandable that you'd be defensive in the comments here, but you're not being honest about what's written.
> The post literally goes over known ways that JXL can be improved.
You think so? Let's name them, yes? Ok, I'll go first:
* Splines. Explicitly derided as "vastly more difficult" and "I have no reason to believe they'd be better anyway".
Now you point out the next one.
You see, any unfilled area is specifically mentioned only to dismiss it as meaningless. Meanwhile, out of the other side of your mouth, you say "don't assume AVIF or even WebP have maxxed out yet". Sure. I don't. I'm not the one doing that. I'm just the one pointing out the hypocrisy of approach.
The entire argument trajectory is "this path is good, that path is bad, this one will naturally get better, that one surely won't get better enough", and the primary evidence given is deceptively inapt.
4 replies →
>nobody else had the same interpretation as you
I do. Even though it reads as trying to as fair as possible. But remember, your title is "The case against JPEG XL".
And the rest of the article is within the context of the title.