4 ms·

I'm not really familiar with the space, but the article kind of suggests another reason I could imagine not supporting JPEG XL: if it has the long list of advan

by sfink 4y ago

I'm not really familiar with the space, but the article kind of suggests another reason I could imagine not supporting JPEG XL: if it has the long list of advantages described, then how much of a single thing is it? Do you have to implement every feature in order to be considered supporting JPEG XL? Or would a browser implementing from scratch run the risk of splitting what the format means? I don't think having an existing library that all browsers could "just use" is a good argument. That just means that the implementation is the specification, no matter what the official spec says. Note that I'm not saying that this is a problem or that JPEG XL shouldn't be supported. I just don't know what the real situation is, and this article smelled a little like it might be sweeping some things under the rug. (And for the other other side, the justification in the bug also seemed lacking.) Anyone know more?

xeeeeeeeeeeenu 4y ago
There are a few alternative decoder implementations in progress. I believe J40 is the most complete one: https://github.com/lifthrasiir/j40 https://github.com/lifthrasiir/j40
lifthrasiir 4y ago
> if it has the long list of advantages described, then how much of a single thing is it? Do you have to implement every feature in order to be considered supporting JPEG XL? Or would a browser implementing from scratch run the risk of splitting what the format means? You have a very good point. In fact I think this is the first time I ever seen such a question, which was also something I wanted to answer by making J40. Of course in the practical standpoint you should just use existing libraries, but I wanted to answer that from the library author's perspective. I'm happy to report that JPEG XL's design is better than I hoped and it successfully tried to do many things out of a reasonable number of components. This means that library authors can mostly implement those components and they will combine reasonably well. There are still some imperfect edges though. For example JPEG XL splits a full image into multiple tiles to faciliate parallel decoding, and the Table of Contents is used to locate individual tile data. But TOC requires a full entropy coding to decode, so you can't easily determine how many bytes are needed for decoding, say, 1/2 of the full image. Those kind of imperfections are harmless for JPEG XL's main use cases but still something I would definitely fix if I'm even given a chance (not to say that I'm a good person to do so).

by sfink 4y ago

xeeeeeeeeeeenu 4y ago

There are a few alternative decoder implementations in progress. I believe J40 is the most complete one: https://github.com/lifthrasiir/j40 https://github.com/lifthrasiir/j40

lifthrasiir 4y ago

> if it has the long list of advantages described, then how much of a single thing is it? Do you have to implement every feature in order to be considered supporting JPEG XL? Or would a browser implementing from scratch run the risk of splitting what the format means? You have a very good point. In fact I think this is the first time I ever seen such a question, which was also something I wanted to answer by making J40. Of course in the practical standpoint you should just use existing libraries, but I wanted to answer that from the library author's perspective. I'm happy to report that JPEG XL's design is better than I hoped and it successfully tried to do many things out of a reasonable number of components. This means that library authors can mostly implement those components and they will combine reasonably well. There are still some imperfect edges though. For example JPEG XL splits a full image into multiple tiles to faciliate parallel decoding, and the Table of Contents is used to locate individual tile data. But TOC requires a full entropy coding to decode, so you can't easily determine how many bytes are needed for decoding, say, 1/2 of the full image. Those kind of imperfections are harmless for JPEG XL's main use cases but still something I would definitely fix if I'm even given a chance (not to say that I'm a good person to do so).