Full JXL is not hardware-friendly enough to be used as-is in a video codec. A trimmed down subset of JXL could work, but I doubt they would accept it in AV2.
Video-derived image formats like WebP, HEIC and AVIF all have issues in the high quality range — they are simply not designed for that, and either cannot reach the very high qualities, or they can do it but not with good compression. Also they don't support fast lossless modes and the precision (bit depth) needed in authoring workflows, so they are delivery formats only, not across-the-workflow formats. Features like progressive decode, region of interest decode, CMYK/spot colors, other additional channels (even just alpha), etc are just not relevant for video codecs, and while some of those shortcomings can be resolved at the file format level (e.g. by implementing extra channels as additional grayscale codestreams, or 'progressive' as a separately coded embedded preview image), it will come at a cost compared to what is possible if the codestream is designed for these features in the first place.
So I think they should stop making these video-derived image formats, and browsers should just accept video formats in img tags (or anywhere where they would currently accept GIF) so if you want you can just use a single-frame video.
I think the motivation for JXL is not just improving the state of image delivery on the web, but also image interchange in general. Currently the only interchange format that can do layers is TIFF. The only interchange formats that can do CMYK are JPEG and TIFF. There is currently no standardized interchange format for images with spot colors (only PSD can do that atm). The only widely supported format that can do lossless 16-bit with some compression is PNG (and J2K, I guess, depending on your definition of "widely supported"). For camera-quality HDR images (with enough precision for further editing), there are currently only the raw formats and OpenEXR. I think these all correspond to important use cases, and it is unlikely that any image format derived from a video codec will support these use cased in a satisfactory way.
JPEG XL is the first image format that has the potential to cover the whole workflow from capture and authoring to delivery. I think that's where its real value lies.
Comments
Full JXL is not hardware-friendly enough to be used as-is in a video codec. A trimmed down subset of JXL could work, but I doubt they would accept it in AV2.
Video-derived image formats like WebP, HEIC and AVIF all have issues in the high quality range — they are simply not designed for that, and either cannot reach the very high qualities, or they can do it but not with good compression. Also they don't support fast lossless modes and the precision (bit depth) needed in authoring workflows, so they are delivery formats only, not across-the-workflow formats. Features like progressive decode, region of interest decode, CMYK/spot colors, other additional channels (even just alpha), etc are just not relevant for video codecs, and while some of those shortcomings can be resolved at the file format level (e.g. by implementing extra channels as additional grayscale codestreams, or 'progressive' as a separately coded embedded preview image), it will come at a cost compared to what is possible if the codestream is designed for these features in the first place.
So I think they should stop making these video-derived image formats, and browsers should just accept video formats in img tags (or anywhere where they would currently accept GIF) so if you want you can just use a single-frame video.
I think the motivation for JXL is not just improving the state of image delivery on the web, but also image interchange in general. Currently the only interchange format that can do layers is TIFF. The only interchange formats that can do CMYK are JPEG and TIFF. There is currently no standardized interchange format for images with spot colors (only PSD can do that atm). The only widely supported format that can do lossless 16-bit with some compression is PNG (and J2K, I guess, depending on your definition of "widely supported"). For camera-quality HDR images (with enough precision for further editing), there are currently only the raw formats and OpenEXR. I think these all correspond to important use cases, and it is unlikely that any image format derived from a video codec will support these use cased in a satisfactory way.
JPEG XL is the first image format that has the potential to cover the whole workflow from capture and authoring to delivery. I think that's where its real value lies.