With AV1 video and AVIF browsers got buy-1-get-1-free deal. The video codec was a necessity, and decoding one frame from a slightly different flavor of MP4 container is a relatively minor addition.
AVIF is not as good as JPEG XL, but it's good enough to the point JXL is a nice to have rather than a burning need. For the same reason I don't expect WebP2 to go anywhere unless Google is willing to make it a compatibility headache for other vendors.
I might be incorrect here, but I thought that AVIF is using same/similar container format as MP4/HEIF. Is there clarity on patent situation for container formats?
Wikipedia article briefly mentions patents for HEIF and it does not inspire much confidence there.
HEIF has a ton of issues when you use it with H.256 (HEIC).
But basic usage of it is almost identical to any MP4 video file, it just has a few bits of metadata saying "I'm an image". That's too trivial to be patentable.
In terms of burning needs you could argue that AVIF and WebP also don't really fill those, since they are not _that_ much better than JPEG with a good encoder while they lack progressive decode.
There was no good format for wide gamut and HDR. JPEG XT didn't catch on. If only WebP had been based on VP9 instead of VP8, it may have been good enough to stop AVIF too.
You should propose JXL as intra frames in AV2. Seriously. Browsers got a video-derived image format twice in a row now, and without video there may never be a strong-enough motivation ever again.
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.
While JPEG XL is awesome if measured with DSSIM, SSIMULACRA 2, Butteraugli or human viewers, JPEG XL is an average or bad codec if measured with AOM's current image quality metrics (MS-)SSIM, PSNR and VMAF(neg).
AOM's image quality group is not receptive to adding new image quality metrics. I proposed it, they told that they want to rather reduce the number of metrics, not increase.
To accept JPEG XL as an intraframe they would need to have political will for it -- to deviate from they usual image quality procedures.
JPEG XL seems to give an extra 10-15 % of density on average, but it cannot be measured using the current AOM processes. If it had been possible, they would have already based AV2 on JPEG XL keyframes instead of AV1 keyframes. They are hunting a lot of small improvements, even 1 % improvements, with substantial effort.
Comments
With AV1 video and AVIF browsers got buy-1-get-1-free deal. The video codec was a necessity, and decoding one frame from a slightly different flavor of MP4 container is a relatively minor addition.
AVIF is not as good as JPEG XL, but it's good enough to the point JXL is a nice to have rather than a burning need. For the same reason I don't expect WebP2 to go anywhere unless Google is willing to make it a compatibility headache for other vendors.
I might be incorrect here, but I thought that AVIF is using same/similar container format as MP4/HEIF. Is there clarity on patent situation for container formats?
Wikipedia article briefly mentions patents for HEIF and it does not inspire much confidence there.
[0] https://en.m.wikipedia.org/wiki/High_Efficiency_Image_File_F...
HEIF has a ton of issues when you use it with H.256 (HEIC).
But basic usage of it is almost identical to any MP4 video file, it just has a few bits of metadata saying "I'm an image". That's too trivial to be patentable.
In terms of burning needs you could argue that AVIF and WebP also don't really fill those, since they are not _that_ much better than JPEG with a good encoder while they lack progressive decode.
There was no good format for wide gamut and HDR. JPEG XT didn't catch on. If only WebP had been based on VP9 instead of VP8, it may have been good enough to stop AVIF too.
You should propose JXL as intra frames in AV2. Seriously. Browsers got a video-derived image format twice in a row now, and without video there may never be a strong-enough motivation ever again.
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.
While JPEG XL is awesome if measured with DSSIM, SSIMULACRA 2, Butteraugli or human viewers, JPEG XL is an average or bad codec if measured with AOM's current image quality metrics (MS-)SSIM, PSNR and VMAF(neg).
AOM's image quality group is not receptive to adding new image quality metrics. I proposed it, they told that they want to rather reduce the number of metrics, not increase.
To accept JPEG XL as an intraframe they would need to have political will for it -- to deviate from they usual image quality procedures.
JPEG XL seems to give an extra 10-15 % of density on average, but it cannot be measured using the current AOM processes. If it had been possible, they would have already based AV2 on JPEG XL keyframes instead of AV1 keyframes. They are hunting a lot of small improvements, even 1 % improvements, with substantial effort.