3 ms·

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.

BugsJustFindMe 12d ago
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.
- juliobbv 12d ago
  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!
  - BugsJustFindMe 12d ago
    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.
    - juliobbv 11d ago
      Yes, he'll fix the speedtest flag thing (which BTW, several people were accidentally using it wrong because the feature is unergonomic AF, but it's convenient to blame the user for "holding it wrong" right?). No, single-threaded encoding/decoding is a valid use case and not a testing methodology flaw. > ... to be forthright about how significant codec optimization historically comes after adoption. Well, this trend has now been broken, so it's irrelevant to mention it. Codecs are now expected to be optimized well before adoption. Take the case of AV2: the AOM folks are currently improving the reference encoder, libavm. SVT-AV2 has just been announced. This is the reality we're now live in. The fact we're having this conversation is an instance of that trend change. > "I have no reason to believe they'd be better anyway". Why are you now selectively quoting fragments? That sentence goes "...and I have no reason to believe they'd be better *than dir-pred* anyway." The part you omitted makes the entire difference. Implementing splines will improve JXL's efficiency (again, this was never contested), but it IS unlikely that they'll fully compensate for the lack of dir-pred. You know why? I *did* take a shot at writing an automated splines implementation for libjxl, and I failed. Not because I didn't know what I had to do, but because I couldn't find a quick way to generate high-quality spline candidates that improve overall quality while making up for their size and encode compute overhead. I'm sure that there's a hypothetical clever way to do it, but the point is that the equivalent tool (dir-pred) is dead easy to implement in comparison, done countless times independently, and it just works. Efficiently leveraging JXL's splines into the encoding loop is legitimately a very hard problem. No, problems of this kind shouldn't be this hard, and it's healthy to call this stuff out instead of pretending that, some time in the future, the "potential" of "alien technology" coding tools will somehow be untapped. > You see, any unfilled area is specifically mentioned only to dismiss it as meaningless. Oh, you're still doing the weird "subtext" thing... you know what? I'm done. Have a nice day.
      - computerbuster 11d ago
        Well-put.
      - BugsJustFindMe 11d ago
        > Codecs are now expected to be optimized well before adoption. Maybe I hallucinated, but I seem to recall that your very fine AVIF work happened only well after major browser adoption. "Rules for thee, not for me", I guess. Talk about trying to pull up the ladder. > SVT-AV2 has just been announced Best of luck to it and AV2. That's a non-sequitur. > The part you omitted makes the entire difference. It really does not. Because... > Implementing splines will improve JXL's efficiency (again, this was never contested) your given position is that it will never be improved enough. That is the problem. That your position is that it will never be improved enough to be better than AVIF (I mean again, though it was previously until quite recently) is entirely the problem. You grip tight to this idea now that if JXL ever improves even one iota then you're vindicated in having graciously allowed it to improve, but you have not granted it the capacity to be improved any bit more than AVIF. > than dir-pred This is what I'm talking about. > I *did* take a shot at writing an automated splines implementation for libjxl, and I failed. I'm sure you're very good and very smart, and you've clearly done very good things. You're not the only very good and very smart person, of course. But you do have very strong opinions about what is and is not worthwhile for the world to pursue. > Oh, you're still doing the weird "subtext" thing. What can I say. I'm used to very good and very smart people knowing about subtext, so I guess I assumed you would.
  - ksec 11d ago
    >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.

BugsJustFindMe 12d ago

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.

juliobbv 12d ago
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!
- BugsJustFindMe 12d ago
  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.
  - juliobbv 11d ago
    Yes, he'll fix the speedtest flag thing (which BTW, several people were accidentally using it wrong because the feature is unergonomic AF, but it's convenient to blame the user for "holding it wrong" right?). No, single-threaded encoding/decoding is a valid use case and not a testing methodology flaw. > ... to be forthright about how significant codec optimization historically comes after adoption. Well, this trend has now been broken, so it's irrelevant to mention it. Codecs are now expected to be optimized well before adoption. Take the case of AV2: the AOM folks are currently improving the reference encoder, libavm. SVT-AV2 has just been announced. This is the reality we're now live in. The fact we're having this conversation is an instance of that trend change. > "I have no reason to believe they'd be better anyway". Why are you now selectively quoting fragments? That sentence goes "...and I have no reason to believe they'd be better *than dir-pred* anyway." The part you omitted makes the entire difference. Implementing splines will improve JXL's efficiency (again, this was never contested), but it IS unlikely that they'll fully compensate for the lack of dir-pred. You know why? I *did* take a shot at writing an automated splines implementation for libjxl, and I failed. Not because I didn't know what I had to do, but because I couldn't find a quick way to generate high-quality spline candidates that improve overall quality while making up for their size and encode compute overhead. I'm sure that there's a hypothetical clever way to do it, but the point is that the equivalent tool (dir-pred) is dead easy to implement in comparison, done countless times independently, and it just works. Efficiently leveraging JXL's splines into the encoding loop is legitimately a very hard problem. No, problems of this kind shouldn't be this hard, and it's healthy to call this stuff out instead of pretending that, some time in the future, the "potential" of "alien technology" coding tools will somehow be untapped. > You see, any unfilled area is specifically mentioned only to dismiss it as meaningless. Oh, you're still doing the weird "subtext" thing... you know what? I'm done. Have a nice day.
    - computerbuster 11d ago
      Well-put.
    - BugsJustFindMe 11d ago
      > Codecs are now expected to be optimized well before adoption. Maybe I hallucinated, but I seem to recall that your very fine AVIF work happened only well after major browser adoption. "Rules for thee, not for me", I guess. Talk about trying to pull up the ladder. > SVT-AV2 has just been announced Best of luck to it and AV2. That's a non-sequitur. > The part you omitted makes the entire difference. It really does not. Because... > Implementing splines will improve JXL's efficiency (again, this was never contested) your given position is that it will never be improved enough. That is the problem. That your position is that it will never be improved enough to be better than AVIF (I mean again, though it was previously until quite recently) is entirely the problem. You grip tight to this idea now that if JXL ever improves even one iota then you're vindicated in having graciously allowed it to improve, but you have not granted it the capacity to be improved any bit more than AVIF. > than dir-pred This is what I'm talking about. > I *did* take a shot at writing an automated splines implementation for libjxl, and I failed. I'm sure you're very good and very smart, and you've clearly done very good things. You're not the only very good and very smart person, of course. But you do have very strong opinions about what is and is not worthwhile for the world to pursue. > Oh, you're still doing the weird "subtext" thing. What can I say. I'm used to very good and very smart people knowing about subtext, so I guess I assumed you would.
- ksec 11d ago
  >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.