5 ms·

>The attempt to provide a second JPEG-XL implementation has stalled What do you mean by "the attempt"? There are at least three independent decoder implementat

>The attempt to provide a second JPEG-XL implementation has stalled What do you mean by "the attempt"? There are at least three independent decoder implementations: jxl-oxide (Rust): https://github.com/tirr-c/jxl-oxide https://github.com/tirr-c/jxl-oxide J40 (C): https://github.com/lifthrasiir/j40 https://github.com/lifthrasiir/j40 jxlatte (Java): https://github.com/thebombzen/jxlatte https://github.com/thebombzen/jxlatte None of them is feature complete, but it's because each of them is a hobby, single-person project. You're making it sound like some billion-dollar company tried to implement JPEG XL and failed, because it's too complex or something. However, it should be noted that those independent implementations, despite being hobby projects, helped to iron-out some minor issues in the standard. >Then AVIF got in, because AV1 was already in. AVIF uses its own container format that had to be implemented. Implementing AV1 does not give you AVIF support for free.

infogulch 4y ago
The point of requiring a second implementation is to prove that the standard is stable and consistent enough that at least two of them can agree on how it works. It doesn't matter who is building the second implementation, it just needs to exist in a feature complete and maintained state. If hobbyist implementations have been uncovering issues in the standard, that just further justifies the "two independent implementations" rule. Bug-for-bug compatibility problems are browser vendors' worst nightmare.
kstenerud 4y ago
> None of them is feature complete, but it's because each of them is a hobby, single-person project Which is why they're not considered implementations to meet this bar. You need multiple FULL implementations to ensure that it is actually FULLY viable, otherwise you risk taking on a potentially broken format that you can't remove. > You're making it sound like some billion-dollar company tried to implement JPEG XL and failed, because it's too complex or something. I doubt any big company actually tried (or tried very hard). Cost of implementation becomes a kind of implicit test here, because companies like things cheap. > AVIF uses its own container format that had to be implemented. Implementing AV1 does not give you AVIF support for free. It gives AVIF support for cheap due to code/algorithm re-use. Companies like things cheap, so that's a big selling point.
- pornel 4y ago
  To be fair, you don't need a FULL implementation. You just need some safe subset that everyone agreed on. For example, even the old JPEG was never fully implemented in browsers — arithmetic coding is not supported.
- prirun 4y ago
  > I doubt any big company actually tried (or tried very hard). Cost of implementation becomes a kind of implicit test here, because companies like things cheap. So if an individual unpaid volunteer spends their time doing a 2nd implementation, <bigco> might consider it for their browser. But they won't pay for a 2nd implementation with their own staff, even if they own a humongous chunk of the browser market (which comes with responsibilities) and even if it is a better algorithm. Sounds about right.
  - kstenerud 4y ago
    It's all about incentives. If there's enough incentive for them to do it, they will. "Better" doesn't always have much to do with it. We make incremental gains as a human race, not necessarily optimal ones.
pornel 4y ago
I was thinking about j40. It's cool that there's a Rust implementation in progress. If it works out, it will make it much easier for me to support JXL. I've been waiting to RIIR the j40 instead. AVIF (HEIF) container format is MP4, which browsers already parse for video. There is a bit of extra work to extract image-specific data, but it's minor compared to AV1 implementation. AVIF even contains a completely redundant copy of key AV1 metadata (av1C) to spare implementations from parsing the AV1 payload.
- timoteostewart 4y ago
  RIIR = rewrite it in Rust

infogulch 4y ago

The point of requiring a second implementation is to prove that the standard is stable and consistent enough that at least two of them can agree on how it works. It doesn't matter who is building the second implementation, it just needs to exist in a feature complete and maintained state. If hobbyist implementations have been uncovering issues in the standard, that just further justifies the "two independent implementations" rule. Bug-for-bug compatibility problems are browser vendors' worst nightmare.

kstenerud 4y ago

> None of them is feature complete, but it's because each of them is a hobby, single-person project Which is why they're not considered implementations to meet this bar. You need multiple FULL implementations to ensure that it is actually FULLY viable, otherwise you risk taking on a potentially broken format that you can't remove. > You're making it sound like some billion-dollar company tried to implement JPEG XL and failed, because it's too complex or something. I doubt any big company actually tried (or tried very hard). Cost of implementation becomes a kind of implicit test here, because companies like things cheap. > AVIF uses its own container format that had to be implemented. Implementing AV1 does not give you AVIF support for free. It gives AVIF support for cheap due to code/algorithm re-use. Companies like things cheap, so that's a big selling point.

pornel 4y ago
To be fair, you don't need a FULL implementation. You just need some safe subset that everyone agreed on. For example, even the old JPEG was never fully implemented in browsers — arithmetic coding is not supported.
prirun 4y ago
> I doubt any big company actually tried (or tried very hard). Cost of implementation becomes a kind of implicit test here, because companies like things cheap. So if an individual unpaid volunteer spends their time doing a 2nd implementation, <bigco> might consider it for their browser. But they won't pay for a 2nd implementation with their own staff, even if they own a humongous chunk of the browser market (which comes with responsibilities) and even if it is a better algorithm. Sounds about right.
- kstenerud 4y ago
  It's all about incentives. If there's enough incentive for them to do it, they will. "Better" doesn't always have much to do with it. We make incremental gains as a human race, not necessarily optimal ones.

pornel 4y ago

I was thinking about j40. It's cool that there's a Rust implementation in progress. If it works out, it will make it much easier for me to support JXL. I've been waiting to RIIR the j40 instead. AVIF (HEIF) container format is MP4, which browsers already parse for video. There is a bit of extra work to extract image-specific data, but it's minor compared to AV1 implementation. AVIF even contains a completely redundant copy of key AV1 metadata (av1C) to spare implementations from parsing the AV1 payload.

timoteostewart 4y ago
RIIR = rewrite it in Rust