Allow YCgCoRe and YCgCoRo decoding.

[vrabaud]

Now that the https://www.itu.int/rec/T-REC-H.273 update is to be published, we can allow for decoding by default.
Encoding will come once decoding is sufficiently deployed.

This is the first phase of
#2077

[vrabaud]

I rebased and updated the enums that indeed got changed.

[y-guyon]

H.273 V4 was published:

Value	Matrix coefficients
16	YCgCo-Re
17	YCgCo-Ro

This PR can be merged.

I would like to also remove the encoding compile flag:

• libavif v1.2.0 will likely stick for a long time
• It makes it easier to cite a command line without having to mention a compile flag
• YCgCo-Re/o is not enabled by default so it still requires an explicit action by the user

[wantehchang]

LGTM. Thanks!

[wantehchang]

It would be good to add a comment to explain why this option is disabled by default and the risk of enabling it.

I guess we are concerned that there isn't widespread decoder-side support initially?

[y-guyon]

It would be good to add a comment to explain why this option is disabled by default and the risk of enabling it.

Would it be enough to do that on avifenc --help and print a warning on avifenc --cicp x/x/16? See #2078 (comment).

I guess we are concerned that there isn't widespread decoder-side support initially?

Yes.
What happens when decoding such files with current versions of libavif and libheif with all compile flags set to OFF?

[vrabaud]

Right now, it depends on what you do with it. E.g., using avifdec: outputing to a png creates an error but not outputing to a y4m ... That should be fixed first.

[wantehchang]

I just saw Yannis's comment:

I would like to also remove the encoding compile flag:

• libavif v1.2.0 will likely stick for a long time
• It makes it easier to cite a command line without having to mention a compile flag
• YCgCo-Re/o is not enabled by default so it still requires an explicit action by the user

I agree with Yannis's suggestion. I also think we are being a little too cautious. Maybe we can note in a comment the date of addition to alert the users, something like this:

diff --git a/include/avif/avif.h b/include/avif/avif.h
index 0de5b92f..9abc26c7 100644
--- a/include/avif/avif.h
+++ b/include/avif/avif.h
@@ -402,8 +402,8 @@ enum
     AVIF_MATRIX_COEFFICIENTS_CHROMA_DERIVED_NCL = 12,
     AVIF_MATRIX_COEFFICIENTS_CHROMA_DERIVED_CL = 13,
     AVIF_MATRIX_COEFFICIENTS_ICTCP = 14,
-    AVIF_MATRIX_COEFFICIENTS_YCGCO_RE = 16,
-    AVIF_MATRIX_COEFFICIENTS_YCGCO_RO = 17,
+    AVIF_MATRIX_COEFFICIENTS_YCGCO_RE = 16,  // Added to libavif in Feb 2025
+    AVIF_MATRIX_COEFFICIENTS_YCGCO_RO = 17,  // Added to libavif in Feb 2025
     AVIF_MATRIX_COEFFICIENTS_LAST
 };
 typedef uint16_t avifMatrixCoefficients; // AVIF_MATRIX_COEFFICIENTS_*

Also, if the decoding application doesn't support YCgCo-Re, the result is either a failure or noticeable wrong colors. So the lack of support will be detected quickly.

[vrabaud]

YCgCo encoding is now enabled. I added a test for it.

[y-guyon]

Should there be a warning when using avifenc --cicp x/x/16? Such as "YCgCo-Ro was added in libavif 1.2.0 (Feb 2025) and will render incorrectly in older implementations, use at your own risk" for users of avifenc that do not look at avif.h.

[wantehchang]

Yannis: The reason you gave before, "libavif v1.2.0 will likely stick for a long time", is also a reason against having avifenc --cicp x/x/16 emit a warning message. Fortunately the lack of support is either a failure or obviously wrong colors, so it will be detected quickly.

[wantehchang]

LGTM. Thanks!