5 ms·
Is there a patent, copyright, or royalty reason why JPEG-XL isn't championed for the web? It would be awful to have another format that can't be used in certain
by Slix 4y ago
Is there a patent, copyright, or royalty reason why JPEG-XL isn't championed for the web? It would be awful to have another format that can't be used in certain Linux distros or browsers.
- jbverschoor 4y agoNope. It’s the best thing out there atm. It’s just big tech wanting to control the IP
- mort96 4y agoOr is it their desire to be slightly careful about which image formats they have to support in perpetuity? With AVIF you get to re-use a bunch of your AV1 decoding code too. And the reference JPEG-XL decoder is still on version 0.x, with no sign that they'll make a stable release any time soon. Why everyone is all up in arms about the fact that the industry is finally standardizing on a good royalty-free image format is beyond me.
- Dylan16807 4y agoAVIF doesn't do everything, and a codec that's designed to encode video frames will always be limited compared to a pure image codec. It especially has trouble with lossless. If we were picking a single royalty-free image codec for the 2018-2026 range, it should be JXL.
- CharlesW 4y ago> AVIF doesn't do everything, and a codec that's designed to encode video frames will always be limited compared to a pure image codec. Image encoding is a subset of video encoding, so any limits are mostly arbitrary, and in AV1's case image-only encoding was a consideration from the start. AVIF in particular supports color depths up to 12 bits, wide color gamuts, many color spaces and standards for color space signaling, etc., so I'm curious what aspect you consider limited.
- Dylan16807 4y agoThe key part is support for real-time hardware decoding. You can't have parts of images refer to far-off parts to save on redundant encoding, and your budget for calculation time and complexity is relatively small.
- adgjlsfhk1 4y ago> Image encoding is a subset of video encoding This isn't true. There are a number of things that make sense for images but not videos. 1. Progressive rendering. 2. Big images (up to 2^30 by 2^30) 3. More channels (up to 4099) (this can be useful for transparency, depth, or tracking random other things for scientific purposes) 5. High bit depth (up to 32 bit) (this is mostly useful for sciency stuff) 4. Lossless encoding. Basically no one wants lossless video (it's way too big), but lossless images often make sense.
- deleted 4y ago[deleted]
- adgjlsfhk1 4y agoAlso images use a wider range of resolutions. AV1 has a minimum 4x4 block size (compared to 2x2 for jpeg-xl) which will hurt it for small images (e.g. icons). For example, The ycombinator icon is 18 by 18 pixels which would make AVIF store a 20x20 image which is 23% more pixels. (I can't find a source but I think I remember hearing that AV1 actually has a minimum size of 64x64 but I can't find a source for that)
- jonsneyers 4y agoI can think of a few aspects where avif is limited. 12-bit is fine for delivery, but it's not enough for authoring. Cameras are typically 14-bit and during authoring you'll want some footroom on top of that. Also avif is not usable for lossless: it is slower than png and often worse. Lossless is crucial for authoring workflows. For high-fidelity lossy compression, avif can be worse than even jpeg. Avif cannot do CMYK at all, so for printing use cases it is not usable. Basically it is targeted at web delivery, but it's not really a general-purpose image format that can be applied in a broad range of use cases.
- danielheath 4y agoJXL offers re-encoding of existing jpeg at smaller size with no quality loss, and has an efficient progressive mode. As the head of tech for a site with a few tb of user-supplied jpeg files (which are thumbnailed), I can see the appeal…
- jbverschoor 4y agoNot just no quality loss. Byte-for-byte identical
- Eisenstein 4y agoIf something is 'byte-for-byte identical' wouldn't it be the same size?
- adgjlsfhk1 4y agoIt's byte for byte identical once you expand to an array of pixels. The storage format uses more advanced (lossless) compression, but the pixels that come out are identical.
- edflsafoiewq 4y agoWhen you transcode back to JPEG, the JPEG is byte-for-byte identical to the original JPEG. But if you decode to pixels you do not always get identical results as the JPEG because the JPEG standard does not specify bit-exact decoding and different decoders may differ slightly.
- dvhh 4y agoSound more like a chicken and egg issue, look like "big tech" are mostly using the format for archival purpose. As Mozilla put it, adopting a new format increase the attack surface ( that is already quite large ) of a browser, they can not simply take the reference decoder and integrate it into their codebase, they also have to use resources toward maintaining it. Firefox currently integrate jxl support behind an experimental flag, but that could mean the feature is in testing and could be deprecated in order to better allocate their resources.
- jbverschoor 4y agoJxl can be byte for byte identical as the original jpeg at an around 80% iirc. Google isn’t interested in perfect archiving, they’d rather have lossy compression, which you can also do. Why can’t they take the reference decoder? As for the attack surface, why would their own codes be less vulnerable? They don’t tend to support each other’s codecs either, not because of attack surface
- gsich 4y agoGoogle doesn't want it so they FUD against it.
- vetinari 4y agoOr: parts of the internets are salty, because Google didn't get the message that nowadays it is mandatory to support their shiny toy in Google's product. Well, Chrome doesn't support bunch of things, and the world didn't end. The usual topic is, that is supports too many things actually, more than it should.
- gsich 4y agoNot "or". The FUD is real. The bugreport even states: "There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL". Not sure on how Google "measured" that.
- izacus 4y agoBy looking at their developer which would have to do the work and those developers said "I'm not interested." Then looking at Mozilla developers which said "I'm not interested." Then looking at Safari developers which also said "I'm not interested." Having developers decide they won't invest into your toy format forever is not FUD.
- deleted 4y ago[deleted]