A 200MP smartphone is a nonsensical idea, their lenses are not big enough to utilize that many pixels. Even if it was actually possible, that 200MP is getting auto compressed the moment you message or upload it anywhere. I'm asking about legitimate uses.
Max image size is limited to 4K (3840x2160) in AVIF, which is a deal breaker to me. You can tile images, but seams are visible at the edges, which makes this unusable. JPEG XL supports image sizes of up to 1,073,741,823x1,073,741,824. You won’t run out of image space anytime soon.
JXL offers lossless recompression of JPEG images. This is important for compatibility, as you can re-encode JPEG images into JXL for a 30% reduction in file size for free. AVIF has no such feature.
JXL has a maximum of 32 bits per channel. AVIF supports up to 10.
JXL is more resilient to generation loss.5
JXL supports progressive decoding, which is essential in web delivery, IMO. AVIF has no such feature.
AVIF is notoriously based on the AV1 video encoder. That makes it far superior for animated image sequences, outperforming JXL in this department by a wide margin. However, JXL also supports this feature.
AVIF is supported in most major browsers. This includes Chrome (and derivatives) and Firefox (and forks). JXL is supported by almost nobody right now. Only Thorium, Pale Moon, LibreWolf, Waterfox, Basilisk and Firefox Nightly incorporate it. Most of these are community-maintained forks of Firefox. That is a big downside for adoption, as I already ranted about in this post.
Both formats support transparency and wide gamut (HDR).
> AVIF has different limitations when it comes to the highest megapixel count / largest dimensions. Several decoders may not support larger images, so single-coded photos do not exceed 4k resolution. According to AV1, AVIF Baseline profile coded image items must not have more pixels than 8912896 or wider widths or higher heights than 8192 or 4352. The Baseline profile can still be used to create larger images using grid derivation. You might encounter discontinuities along the grid boundaries, depending on how the image is decomposed. For this particular case, however, the maximum size of a coded picture is 65536x65536.
So as I understand this, anything with more than ~9 MP would be encoded in some kind of tiled way, possibly introducing artifacts where tiles meet.
However, another blog post claims different limits
> The default limit of AVIF is 8K. Video professionals will recognize this as the size of an 8K video frame. It is possible to break this limit for both formats by independently encoded tiles of 8K frames. But this method introduces artifacts at the tile boundaries, affecting the overall appearance of images.
The profiles only matter if you want to be decodable by hardware decoders. If you only care about software decoders, which must be true if JPEG-XL is your comparison, then you don't have to use the HEIF grid for large dimensions, and the better question is how much memory your application will allow to be allocated. Because chances are JPEG's maximum 65535x65535 exceeds it that too.
AV1 itself allows a maximum of 65536x65536 for a single picture, whereas the HEIF grid hypothetically allows even more than that regardless of how large each individual picture is (HEIF grid dimensions are 32-bits). As a practical example, libavif will not use the grid for large dimensions unless explicitly told to do so, by default producing files that aren't compliant to either baseline or advanced profiles.
(to further my pedantry against your source: AVIF is a subset of HEIF; what people usually mean by "HEIF" is the HEIC subset)
It is that simple, you're just noving the goal posts.
The concept of profiles is nothing new to ensure HW decoder compatibility and JPEG-XL offers nothing extra there either (except no support for the concept ensuring that HW decode isn't possible at all).
Pretty much all newer formats are tiled in some way too - even JPEG.
The format supports that technically (the resolution is stored in two uint32_t variables), but libavif however currently seems to have pretty small limits in this area based off attempts a few months ago to try using it for high res photos: I couldn't get it to save images of size 8192 x 5464 (native Canon R5 res). avifEncoderAddImage() just returns a generic error when the size is too big. If I reduced the size of the image a bit, it then worked.
Given I was trying to store high res panoramas of even larger dimensions, I was pretty surprised at the apparent limits, wherever they exist in the callstack.
>Max image size is limited to 4K (3840x2160) in AVIF, which is a deal breaker to me. You can tile images, but seams are visible at the edges, which makes this unusable. JPEG XL supports image sizes of up to 1,073,741,823x1,073,741,824. You won’t run out of image space anytime soon.
>JXL has a maximum of 32 bits per channel. AVIF supports up to 10.
Max resolution and bit depth is certainly massively higher for for JPEG XL, but spec [0] says that:
>"NOTE: [AV1] supports 3 bit depths: 8, 10 and 12 bits, and the maximum dimensions of a coded image is 65536x65536, when seq_level_idx is set to 31 (maximum parameters level)."
And 12-bits per channel is considered a lot for end user final display formats? It also seems to be supported in browsers too so it's not just theoretical. It looks like back in 2021 there was discussion around this and clarifying that the profiles decided on in 2018/2019 were more about giving targets for hardware acceleration of the time, but software decoders by 2021 supported essentially the whole spec (and it appears to me that another 2 years later now final lingering stuff has been dealt with) [1,2]:
>Cyril has proposed a pull request (#130) to better clarify what is and is not supported in AVIF. In short, AVIF supports everything that AV1 supports, which includes 12-bit encoding. The current software decoder implementations also support more or less all of AV1, which can be seen if you try to decode a 12-bit AVIF file in a web browser.
And for still images, hardware acceleration isn't important, so as a practical matter unlike AV1 video pure software for max features is fine. So 65k x 65k and 36-bit color appear to be the limit, which definitely isn't as much as JPEG XL, but is pretty respectable for majority of end user usage?
Edit to add: the comments there also mention complaints that the JPEG XL author has a history of spreading misinformation about AVIF, "See the article and infographic recently posted by the JPEG-XL author that claims (among other things) that AVIF does not support 12-bit images". So apparently there has been some good old dev drama going on during the last few years which means one may need to be a little suspicious about any "Good summaries" :(.
> And 12-bits per channel is considered a lot for end user final display formats?
WebP and AVIF introduced a bifurcation between general purpose image formats and ‘end user final display formats’ (i.e. internet delivery to consumer entertainment devices). I don't think this is a good thing.
> and the maximum dimensions of a coded image is 65536x65536
As pointed out in another comment, this is less of 65536 by 65536 and more of 65536* by 65536* if you followed some more complicated steps. Considering that the original JPEG supports that without relying internally on multiple images (the trick AVIF used to "support" the full 65536 by 65536), it seems not suitable for software which writes images in one pass.
No, it's AV1 that uses (up to) 16-bit fields for image dimensions. HEIF grids, which is the AVIF feature that combines multiple AV1 images into one, have 32-bit fields for dimensions so are limited only by what the decoder is willing to allocate.
Claiming someone to 'spread misinformation' is not helpful. All the people related to compression that I know are trying their best to find the technically best solution by ethically best means. No dirty fighting observed.
"Meanwhile, it has been clarified that the AVIF limits listed above apply to the highest currently defined AVIF profile (the “Advanced” profile). It is also possible to use AVIF without a profile, and then the AV1 limits apply: a precision of up to 12-bit, and maximum dimensions of up to 65535x65535 (or more using grids). For HEIC, it is possible to use the container with a HEVC payload with a precision of up to 16-bit and with 4:4:4, although most hardware implementations do not support that."
No AVIF implementation supports all what the clarification there claims. Sometimes it has happened that the implementations led to the practical standardization, instead of what is written in the spec.
No one has yet seen the tile grid artefacts. One could expect that there will be barely visible stripes extending from one side of the image to the other, and from bottom to top. This would be because of 'loop filtering' and 'noise synthesis' states not shared between frames.
No one really knows how the coding performance is for 12-bit photographs. AV1 needs to double escape large values which can reduce entropy coding performance of large values. Lossless coding commonly codifies larger values than lossy (due to less quantization). One might be able to observe this in the performance of the lossless coding.
No one knows how much progressive AVIF will compress. The implementation doesn't exist yet. The progressive approach chosen is new, very different from JPEG1/JPEG XL approach. It will be interesting to learn about its performance.
Votes and comments aren’t a measure of popularity or importance. They’re super easily skewed by specific communities deciding to hammer the reports or similar - often about things they don’t have technical understanding of.
Other examples would be when Libc++ announced adding bounds checking by default and a huge number of people (from HN and similar) came in to provide votes/+1s or comments with little actual technical feedback
You'd need to exploit an implementation bug, or have the user be streaming or something (so some squares appear before others as the output of your timing attack).
