Windows displays incorrect colors

[JacobDev1]

Description

The encoded image is displayed incorrectly in Windows Photos and File Explorer.

Steps to reproduce

Images: attachment.zip

Requirements:

• Windows 11 with AVIF support (AV1 and HEIF extensions from Microsoft store installed).
• a 16-bit PNG image with an ICC profile exported with Affinity Studio.
• avifenc v1.3.0

The bug occurs when cicp is 2/2/6.

avifenc src.png dst.avif

Notice how dst.avif is much brighter than the original. The dst_range_limited.avif file was encoded with --range limited, and it's even brighter.

Full view, respectively, full range avif / limited range avif / original png

Additional info

This may be a bug in the Windows integration as no other image viewer I tested displays a broken image. If this is the case, is there any way we can reach out to them?

[y-guyon]

Thank you for your interest in AVIF. This would indeed be a problem on the Windows side if you cannot reproduce the issue with avifdec and other image viewers. I will let you know if I find someone to redirect this bug to.

[aklemets]

@JacobDev1 The problem seems to be caused by your .avif file having multiple 'colr' boxes. I see your file has one 'colr' box with various CICP values and a second one with an ICC profile. Originally, this was not supported by HEIF. I just checked the 2nd edition of the HEIF spec, and it says that at most one 'colr' box is allowed. (Multiple boxes are allowed in a more recent revision of the spec.) So, for maximum interoperability, it would be best to refrain from using multiple 'colr' boxes for the same image.

That said, as it happens, we are currently rolling out a HEIF update, version 1.2.28.0, that can handle the presence of both CICP tags and an ICC profile for the same image, so it basically adds support for multiple 'colr' boxes and should fix the issue that you observed. I compared the src.png and dst.avif images that you provided and notice no difference between the images.

The new version should be fully rolled out by mid-December 2025. To check if you already had version 1.2.28.0, you can open a PowerShell command prompt and type this command: Get-AppxPackage microsoft-heif*

Please wait for your PC to receive version 1.2.28.0 and if you still see a problem with dst.avif, please let me know.

As for the Limited Range AVIF image, I see that the Limited Range flag is not applied during the conversion to RGB if an ICC profile is present. Again, a problem caused by the unusual presence of two 'colr' boxes. We can make another update to the HEIF parser (probably will have to wait until January) to make that work properly.

[JacobDev1]

@aklemets thanks for the update.

I tried looking into this.

Currently, avifenc embeds an nclx colr box even if an ICC profile is present. This is done to include the matrix coefficients enum, the rest is set to 2 (unspecified).

nclx could be treated as mutually exclusive with an ICC profile. However, because an ICC profile cannot signal matrix coefficients enum, it would mean having decoders rely on the AV1 OBU for it.

Another option is to leave it as it is. The specification was already revised to support two colr boxes.

In any case, I'll wait for the HEIF extension update, and let you know if I see any issues.

[y-guyon]

an ICC profile cannot signal matrix coefficients enum

It can actually: https://www.color.org/specification/ICC.1-2022-05.pdf#page=60

The cicpType specifies Coding-independent code points for video signal type identification. The byte
assignment and encoding shall be as given in Table 32.
The fields ColourPrimaries, TransferCharacteristics, MatrixCoefficients, and VideoFullRangeFlag shall be
encoded as specified in Recommendation ITU-T H.273.

[JacobDev1]

It looks like the ICC specification was revised in 2022 to allow for a cicpType tag. source

Still, this tag is optional so we cannot rely on it being present.

The vision of the original libavif author was to treat the ICC profile like a black box.

I think the ICC profile should just be a black box (binary blob) to libavif, and all YUV conversion it offers should be signaled entirely by the CICP values either in the nclx box or the OBU (as a fallback).

source

[ueyome]

use jpegview