4 ms·

I agree with this, and I think for this reason it is best if a new codec gets wide adoption also outside browsers, instead of having the approach of a "web code

I agree with this, and I think for this reason it is best if a new codec gets wide adoption also outside browsers, instead of having the approach of a "web codec" where it suffices that servers and browsers know about it but the wider ecosystem doesn't support it. WebP in particular, as the name suggests, was conceived as an "image format for the web" and while I think it's good to have the web in mind when designing an image codec, I think it's a bad idea to limit the scope like that. Design decisions like limiting the maximum dimensions and bit depth at the codec level "because that's all the web needs" plus limited attention/focus to adoption outside browsers does lead to the phenomenon you describe where "it doesn't work for everyone", causing the small gain of improved compression to be dwarfed by the huge inconvenience of breaking workflows. Any new codec of course has this problem even if they do target wide adoption (like JPEG XL): adoption is never instantaneous. It is a fact that the release cycle of browsers is more suitable for innovation than that of most other software, so it does make sense to start there even when it will still cause things to break in software that doesn't support it yet. To mitigate that, I think it would help a lot of browsers would have a "Save As..." dialog box on images that gives users the choice to save the actual image in whatever format it is in, or to convert it to PNG or JPEG.

jacobolus 5y ago
> It is a fact that the release cycle of browsers is more suitable for innovation than that of most other software, Also there is a huge financial incentive for large web hosting companies (e.g. Google, Facebook) to adopt compression formats that save bandwidth, using automated tools to apply those wherever possible. People making e.g. image archives or building image capture hardware are going to be slower. They don’t want to use new untested technologies that might not succeed, and they don’t want to switch more frequently than necessary. When they do transition it will be by applying new technologies to new images but not immediately transforming older images to use the new technology.
- jonsneyers 5y ago
  True — which is one of the reasons why JPEG XL includes a risk-free JPEG recompression option: if needed, you can just undo it and get the bit-exact same JPEG files back. Applying lossy recompression on already-lossy-compressed images is something you should avoid at all cost, since it inevitably causes generation loss (and it is also likely to not be very effective, since you're basically spending a lot of bits in the new codec on replicating compression artifacts of the old codec).
- JyrkiAlakuijala 5y ago
  Happy users, faster growing userbase, more e-store revenue, higher click-through rates, lower latency, better quality-of-experience, or more 7-day-returning users can be more important financial incentives than bandwidth. Humans are more than thousands of times more valuable than a computer. When image quality and observed latency are at a level where users don't care even subconsciously (say, images look like camera originals and load in 100 ms), then bandwidth cost optimization may become a good 2nd objective.
  - fshr 5y ago
    This is a strange argument. The larger companies have plenty of people to work on all the things you mentioned plus bandwidth optimizations. Also, they’re rarely the same people.
    - jacobolus 5y ago
      The claim (from one of the people working on JPEG XL at Google) is that better image compression is going to reduce latency (or allow higher-quality images) and thereby improve other metrics besides bandwidth costs, giving internet companies even more incentive to adopt better codecs.
im3w1l 5y ago
Another solution could be that "someone" creates a library supporting all these formats that everyone else can then use. If the supported formats are queried at run-time, this means that just updating the library will automagically add support into other programs.
- bmn__ 5y ago
  I believe AmigaOS and BeOS had that, ROX Desktop too? We could replicate the same nowadays via GStreamer, but adoption is hampered by its plug-in system, meaning that most installations are incomplete.
- chungy 5y ago
  You are basically describing libavformat and libavcodec (part of the ffmpeg project)
dgb23 5y ago
We automatically convert user generated images to WebP if feasible and then use the <picture> element to display alternatives (the original format as the fallback). I'm pretty sure that this might be a common pattern. Browsers could allow a selection of all sources provided by the picture element (this would also include differently scaled variants based on media queries) in a download dialog.
- Zardoz84 5y ago
  It's not a option doing that if you need to serve a TiB of images and you need, yet, to support IE 11. JPEG XL on fly conversion to JPEG, offers a nice solution for this use case.
  - dgb23 5y ago
    We support IE11 with a polyfill. The images are converted and stored when they are uploaded or changed. I can see this being an issue with that kind of volume though. But it’s a performance gain for the clients while content doesn’t need to worry about it.
txtsd 5y ago
I'm worried about whether it will get adoption outside of browsers.
onedognight 5y ago
This would significantly increases browser attack surface area. Coders are usually much more complicated than decoders.
- nine_k 5y ago
  The browser has to decompress the image into raw pixels to display it anyway. Dumping these raw pixels into a trivial intermediate format, like uncompressed PNG or BMP, should not increase the attack surface in any noticeable way.
- jonsneyers 5y ago
  Browsers already have to include an encoder for JPEG and PNG. They need that anyway for things like toDataURL(), see https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toDataURL https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE...
- astrange 5y ago
  The input data to an encoder is very simple since it's just pixels. It's possible to find a crash but it would be surprising to find an exploitable one.

jacobolus 5y ago

> It is a fact that the release cycle of browsers is more suitable for innovation than that of most other software, Also there is a huge financial incentive for large web hosting companies (e.g. Google, Facebook) to adopt compression formats that save bandwidth, using automated tools to apply those wherever possible. People making e.g. image archives or building image capture hardware are going to be slower. They don’t want to use new untested technologies that might not succeed, and they don’t want to switch more frequently than necessary. When they do transition it will be by applying new technologies to new images but not immediately transforming older images to use the new technology.

jonsneyers 5y ago
True — which is one of the reasons why JPEG XL includes a risk-free JPEG recompression option: if needed, you can just undo it and get the bit-exact same JPEG files back. Applying lossy recompression on already-lossy-compressed images is something you should avoid at all cost, since it inevitably causes generation loss (and it is also likely to not be very effective, since you're basically spending a lot of bits in the new codec on replicating compression artifacts of the old codec).
JyrkiAlakuijala 5y ago
Happy users, faster growing userbase, more e-store revenue, higher click-through rates, lower latency, better quality-of-experience, or more 7-day-returning users can be more important financial incentives than bandwidth. Humans are more than thousands of times more valuable than a computer. When image quality and observed latency are at a level where users don't care even subconsciously (say, images look like camera originals and load in 100 ms), then bandwidth cost optimization may become a good 2nd objective.
- fshr 5y ago
  This is a strange argument. The larger companies have plenty of people to work on all the things you mentioned plus bandwidth optimizations. Also, they’re rarely the same people.
  - jacobolus 5y ago
    The claim (from one of the people working on JPEG XL at Google) is that better image compression is going to reduce latency (or allow higher-quality images) and thereby improve other metrics besides bandwidth costs, giving internet companies even more incentive to adopt better codecs.

im3w1l 5y ago

Another solution could be that "someone" creates a library supporting all these formats that everyone else can then use. If the supported formats are queried at run-time, this means that just updating the library will automagically add support into other programs.

bmn__ 5y ago
I believe AmigaOS and BeOS had that, ROX Desktop too? We could replicate the same nowadays via GStreamer, but adoption is hampered by its plug-in system, meaning that most installations are incomplete.
chungy 5y ago
You are basically describing libavformat and libavcodec (part of the ffmpeg project)

dgb23 5y ago

We automatically convert user generated images to WebP if feasible and then use the <picture> element to display alternatives (the original format as the fallback). I'm pretty sure that this might be a common pattern. Browsers could allow a selection of all sources provided by the picture element (this would also include differently scaled variants based on media queries) in a download dialog.

Zardoz84 5y ago
It's not a option doing that if you need to serve a TiB of images and you need, yet, to support IE 11. JPEG XL on fly conversion to JPEG, offers a nice solution for this use case.
- dgb23 5y ago
  We support IE11 with a polyfill. The images are converted and stored when they are uploaded or changed. I can see this being an issue with that kind of volume though. But it’s a performance gain for the clients while content doesn’t need to worry about it.

txtsd 5y ago

I'm worried about whether it will get adoption outside of browsers.

onedognight 5y ago

This would significantly increases browser attack surface area. Coders are usually much more complicated than decoders.

nine_k 5y ago
The browser has to decompress the image into raw pixels to display it anyway. Dumping these raw pixels into a trivial intermediate format, like uncompressed PNG or BMP, should not increase the attack surface in any noticeable way.
jonsneyers 5y ago
Browsers already have to include an encoder for JPEG and PNG. They need that anyway for things like toDataURL(), see https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toDataURL https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE...
astrange 5y ago
The input data to an encoder is very simple since it's just pixels. It's possible to find a crash but it would be surprising to find an exploitable one.