avifdec does not output identical / pixel perfect PNGs

[0fbcb238c0]

Decoding an AVIF using avifdec does result in a PNG with minute differences in image data.
I tested using SDR and HDR images, it happens with all files I've tested.

Choosing aom or dav1d does not make a difference in image hash, as calculated by ImageMagick's identify
Example image from avif-sample-images
kimono.avif -> kimono.png

 * Resolution     : 722x1024
 * Bit Depth      : 8
 * Format         : YUV420
 * Chroma Sam. Pos: 0
 * Alpha          : Absent
 * Range          : Limited
 * Color Primaries: 1
 * Transfer Char. : 13
 * Matrix Coeffs. : 9
 * ICC Profile    : Absent
 * XMP Metadata   : Absent
 * Exif Metadata  : Absent
 * Transformations:
    * pasp (Aspect Ratio)  : 1/1
 * Progressive    : Unavailable
 * Gain map       : Absent

Calculating the image hashes with the aforementioned identify shows this:

PNG 32014df7375ff7c42f9fa0318b4cd0317b67bb8b31429eda6bb88bccdc362078
AVIF f12b6a0b1a50303e6da7f8fdaa49ad30d7f9659517fe9cdbf8d15333687285f3

Converting the file with ImageMagick does work, but only for SDR images, as HDR information is lost with magick

PNG f12b6a0b1a50303e6da7f8fdaa49ad30d7f9659517fe9cdbf8d15333687285f3
AVIF f12b6a0b1a50303e6da7f8fdaa49ad30d7f9659517fe9cdbf8d15333687285f3

Decoding an HDR image has the same issue with differing image hashes.
The attached HDR image is an AVIF, renamed to .png due to GitHub limitations.

 * Resolution     : 2048x858
 * Bit Depth      : 10
 * Format         : YUV444
 * Alpha          : Absent
 * Range          : Full
 * Color Primaries: 9
 * Transfer Char. : 16
 * Matrix Coeffs. : 9
 * ICC Profile    : Absent
 * XMP Metadata   : Absent
 * Exif Metadata  : Absent
 * Transformations: None
 * Progressive    : Unavailable
 * Gain map       : Absent

PNG 2652402b2a98973313152ddcf323aa757332ce621c7cc962783c5b82eb269da9
AVIF 1e9a43ca88013272d5f46e1ee91382c92f3001606098d0e4908da7c49667c2c6

[vrabaud]

Thx for reporting. kimono.avif is 4:2:0. PNG does not deal with chroma subsampling, it is 4:4:4.

Can you paste the command line instructions with identify and avifdec you use? image magick probably has a different chroma upsampler compared to libavif.

[kmilos]

image magick probably has a different chroma upsampler compared to libavif

AFAIK ImageMagick uses libheif, so likely different upsampling indeed.

There's also

* Range          : Limited

to consider and check whether scaling to full is happening.

[0fbcb238c0]

For avifdec I simply do avifdec INPUT.avif OUTPUT.png
I tried out some options for avifdec, but the resulting PNG was always different from the source AVIF
For ImageMagick I used magick INPUT.avif OUTPUT.png
For calculating the image hashes I provided I use identify -format "%m %#\n"

I have multiple HDR AVIFs with gbrp as well, created by Valve's gamescope.
They have the same issue when decoded.

[0fbcb238c0]

I had forgotten to attach the avifdec output for the HDR image, now amended

[y-guyon]

For the HDR asset there is Bit Depth: 10 which cannot be stored as is in a PNG because PNG only supports 8-bit and 16-bit. Could you check if both PNGs have the same bit depth?

On top of that, going from 10-bit to 16-bit or 8-bit may be performed in multiple ways (bit shift, multiplication, rounding etc.).

May I ask why you need the image hashes to match?

[0fbcb238c0]

I don't need image hashes, I simply use them to verify that the images are identical so no information is altered or lost.
The decode process should not be 'lossy' but perfectly preserve the image data.

The 8 bit AVIF decodes to 8 bit PNG
The 10 bit AVIF decodes to 16 bit PNG
The alteration during decode happens with both 8 bit and 10 bit AVIF files.

[y-guyon]

It would be simpler to start the verification with an 8-bit, full range, 4:4:4, identity matrix AVIF. If that leads to different hashes, there may be some concern. Otherwise it is likely due to color conversion, chroma upsampling or bit depth change that are implemented differently, which no specification mandates precisely enough and/or implementations care enough to be compliant with (especially when the spec evolves over time).
With that said, getting closer behavior across libraries is a valuable effort, and may be worth investigating further.

Have you filed a similar issue on ImageMagick's side? They may already be aware of some potential root causes.

[0fbcb238c0]

The issue indeed does not affect 4:4:4 full range 8 bit AVIF images
Example image from Wikimedia
A roundtrip from PNG to AVIF back to PNG resulted in identical files, which is good
512px-Avif-logo-rgb.svg.avif -> 512px-Avif-logo-rgb.svg.png

 * Resolution     : 512x383
 * Bit Depth      : 8
 * Format         : YUV444
 * Alpha          : Not premultiplied
 * Range          : Full
 * Color Primaries: 1
 * Transfer Char. : 4
 * Matrix Coeffs. : 0
 * ICC Profile    : Absent
 * XMP Metadata   : Absent
 * Exif Metadata  : Absent
 * Transformations: None
 * Progressive    : Unavailable
 * Gain map       : Absent

PNG 2b8ff090dd4004ee5393ae69465b0dcb3f0526f564357bcc7596b15e89015268
AVIF 2b8ff090dd4004ee5393ae69465b0dcb3f0526f564357bcc7596b15e89015268

Sadly these AVIFs are rather rare, I can't say that I have multiple of them.
I have lots of lossless gbrp 10 bit HDR AVIFs though, which do not decode in a (at least by me) expected manner.

I did not open an issue with ImageMagick yet, as the loss of HDR metadata is common in my experience - not limited to AVIF conversions with IM.

[0fbcb238c0]

ImageMagick has two open issues regarding this problem
ImageMagick/ImageMagick#7715
ImageMagick/ImageMagick#7308

FFmpeg is also unable to properly decode HDR AVIFs, I will open a ticket with them when I find the time.

[FooIbar]

I looked into it and found that libavif scales the values, while ImageMagick simply uses a bit shift to convert them to 16-bit.
You can use the following command to get identical hashes:

magick 10bit_full_444_identity.avif -fx "u/(2^6)/(2^10-1)*(2^16-1)" png:- | identify -format "%m %#\n" -

[0fbcb238c0]

I looked into it and found that libavif scales the values, while ImageMagick simply uses a bit shift to convert them to 16-bit. You can use the following command to get identical hashes:

ImageMagick works fine for converting and getting an identical hash for AVIF->PNG, but it loses the HDR metadata in the process, making it unviable for transcoding HDR AVIFs.

[FooIbar]

I looked into it and found that libavif scales the values, while ImageMagick simply uses a bit shift to convert them to 16-bit. You can use the following command to get identical hashes:

ImageMagick works fine for converting and getting an identical hash for AVIF->PNG, but it loses the HDR metadata in the process, making it unviable for transcoding HDR AVIFs.

The above command is just to prove that avifdec does output identical PNGs.
The difference you saw comes from ImageMagick converting 10-bit AVIF to 16-bit internally before calculating the hashes.