WebP is much more limiting than JPEG XL. in lossy mode WebP has forced 4:2:0 chroma subsampling, supports only 8 bit per channel colors (really only about 7.8 bits, because thanks to WebP being tv-range the values aren't in a 0-255 range but in a 16-235 range, causing even more color banding than 8 bit per channel already has), no HDR, a maximum resolution of 16385 x 16385 making it unsuitable for larger images...
JPEG XL on the other hand supports up to 4099 color channels, a bit depth up to 32 bit per channel (technically up to 64 bit, but this currently isn't used), supports HDR natively, can use splines to compress elements like strands of hair, thin tree branches or line art that are typically hard to compress with DCT, supports patches for compressing repeating image elements, supports thermal, depth and alpha channels, supports losslessly recompressing existing JPEGs saving about 20%, supports CMYK and spot colors for printing, supports layers and selection masks, supports storing raw camera sensor data in bayer patterns, etc.
WebP is just a web delivery format, JPEG XL was designed to support many uses cases like web delivery, medical imaging, raw camera sensor data, authoring, multi-spectral imaging... the list goes on. if we support JPEG XL now, chances are it'll be quite a while before we need a new general purpose image format because JPEG XL covers so many current use cases and was designed to accommodate potential future use cases as well.
I didn't realize WebP was limited-RGB in addition to 4:2:0.
According to RFC 9649, this is accurate.
While the ITU-R Recommendation 601 on color is only a "SHOULD" in the RFC, you'd need a custom decoder to break out of limited RGB:
> The VP8 specification describes how to decode the image into Y'CbCr format. To convert to RGB, Recommendation 601 [REC601] SHOULD be used. Applications MAY use another conversion method, but visual results may differ among decoders.
The names and extensions of JPEG XL files aren't specified, except that the IANA media type is `image/jxl`. I think an argument could be made to use the double extension convention when the encoder performs lossless JPEG recompression, so image.jpg becomes image.jpg.jxl (while not entirely semantically correct, since it's not an additional layer of compression around the JPEG, it's a reimplementation of the image using identical coding features as JPEG, in JXL).
But like I said in my other comment (which got hidden for some reason), it should be noted that a recompressed JPEG is also a valid JXL on its own. If you have the means to turn a recompressed JPEG into the original, you also have the means to view native JXLs.
Hopefully adoption is widespread and we won't really have to worry about it. JPEG XL is a much more appealing format than WebP, and unlike WebP there are great arguments for software to support it other than "Google started using them, so they're everywhere now."
I'm not sure if that will be an issue in practice. in any case, you need a JPEG XL decoder to perform the transition from a recompressed-JPEG-JXL to the original JPEG, so whatever tool is doing this, it can already handle native-JXL too. it could be the conversion happens on the server side and the client always sees JPEG, in which case a native JXL can also be decoded to a JPEG (or if lossless a PNG), though obviously with information loss since JPEG is a subset of JXL (to put it lightly)
> Nonsense. It has a lossy mode (which is its primary mode so to speak), so of course it has banding. Only lossless codecs can plausibly be claimed to be "immune to banding".
color banding is not a result of lossy compression*, it results from not having enough precision in the color channels to represent slow gradients. VarDCT, JPEG XL's lossy mode, encodes values as 32-bit floats. in fact, image bit depth in VarDCT is just a single value that tells the decoder what bit depth it should output to, not what bit depth the image is encoded as internally. optionally, the decoder can even blue-noise dither it for you if your image wants to be displayed in a higher bit depth than your display or software supports
this is more than enough precision to prevent any color banding (assuming of course the source data that was encoded into a JXL didn't have any banding either). if you still want more precision for whatever reason, the spec just defines that the values in XYB color channels are a real number between 0 and 1, and the header supports signaling an internal depth up to 64 bit per channel
* technically color banding could result from "lossy compression" if high bit depth values are quantized to lower bit depth values, however with sophisticated compression, higher bit depths often compress better because transitions are less harsh and as such need fewer high-frequency coefficients to be represented. even in lossless images, slow gradients can be compressed better if they're high bit depth, because frequent consistent changes in pixel values can be predicted better than sudden occasional changes (like suddenly transitioning from one color band to another)
JPEG XL on the other hand supports up to 4099 color channels, a bit depth up to 32 bit per channel (technically up to 64 bit, but this currently isn't used), supports HDR natively, can use splines to compress elements like strands of hair, thin tree branches or line art that are typically hard to compress with DCT, supports patches for compressing repeating image elements, supports thermal, depth and alpha channels, supports losslessly recompressing existing JPEGs saving about 20%, supports CMYK and spot colors for printing, supports layers and selection masks, supports storing raw camera sensor data in bayer patterns, etc.
WebP is just a web delivery format, JPEG XL was designed to support many uses cases like web delivery, medical imaging, raw camera sensor data, authoring, multi-spectral imaging... the list goes on. if we support JPEG XL now, chances are it'll be quite a while before we need a new general purpose image format because JPEG XL covers so many current use cases and was designed to accommodate potential future use cases as well.
reply