Add Recommendations for Matrix and Signal Range values

[digitaltvguy]

Is your feature request related to a problem? Please describe.

1. Matrix values other than 0 should throw a warning since all PNG with CICP values will be RGB
2. Narrow range values (seeing full range flag to 0) should throw a warning since RGB are typically full range

Describe the solution you'd like
Some values should throw errors to advise users of a recommendation.

Describe alternatives you've considered
Users should be advised of these recommendations

Additional context
See H.273 for full/narrow boolean usage.

1. matrix_coefficients value must be 0 (RGB doesn't need matrix conversion)
2. video_full_range_flag value should be either 0 or 1.

Note: Specific flags use values from ITU-T H.273. Not all values are valid.
PNG puts further restrictions on which values are valid.

[svgeesus]

I'm in two minds as to whether this should give an error, or proceed with a warning.

Normal users are best served by not being allowed to write --matrix_coefficients 3; it should warn, and write 0.

Those few people writing deliberately incorrect files for testing though, will be annoyed.

[svgeesus]

Here is what I tested for in pngcheck:

matrix == 0
range < 2
primaries <= 22
transfer <= 18

That deals with the "reserved" values for primaries and transfer.

I feel all of those should be warnings.

[ProgramMax]

I agree.
I think what I'll do is print a warning for each value outside the expected range, explaining why that value is problematic.
But then execution will continue, allowing test files to be made.

I also think I'll add a --silent or --disable-warnings or some such flag.

[svgeesus]

Those both sound good (warning not error, and silencing warnings)

[svgeesus]

Also, when specifying individual CICP values, should there be sensible defaults for the full-range flag and for the matrix if those are omitted.

chris@SuperNomad:/mnt/c/Users/chris/Documents/PNG$ png_cicp_editor overwrite --color_primaries 5 WK-test.png
chris@SuperNomad:/mnt/c/Users/chris/Documents/PNG$ pngcheck -c -v WK-test.png
File: WK-test.png (78090 bytes)
  chunk IHDR at offset 0x0000c, length 13
    1000 x 1000 image, 64-bit RGB+alpha, non-interlaced
  chunk pHYs at offset 0x00025, length 9: 2835x2835 pixels/meter (72 dpi)
  chunk iCCP at offset 0x0003a, length 354
    profile name = Photoshop ICC profile, compression method = 0 (deflate)
    compressed profile = 331 bytes
  chunk iTXt at offset 0x001a8, length 14903, keyword: XML:com.adobe.xmp
    uncompressed, no language tag
    no translated keyword, 14882 bytes of UTF-8 text
  chunk cHRM at offset 0x03beb, length 32
    White x = 0.28056 y = 0.29583,  Red x = 0.67637 y = 0.32362
    Green x = 0.25801 y = 0.68017,  Blue x = 0.12657 y = 0.05052
  chunk cICP at offset 0x03c17, length 4unrecognised (reserved or historical)
primaries: 5
transfer function: 0
    Narrow range
ERRORS DETECTED in WK-test.png

It seems to have inferred a transfer function of zero? Or that might be the checker. The chunk is of the right length. I need to check in hex what is actually there.

[ProgramMax]

Good idea.
Right now, I default to 0 for primaries and transfer function.
But that is kinda a useless default.

I think it would make sense to guess at something reasonable and issue a warning that it was forced to guess.

[digitaltvguy]

Seems like there are two choices: 1. BT.709, sRGB, Identity, Full Range (1, 13, 0, 1) 2. BT.709, BT709, Identity, Full Range (1, 1, 0, 1) If CICP didn't exist, option 1 would replicate the default wouldn't it? A transfer function of 13 is defined: IEC 61966-2-1 sRGB (when MatrixCoefficients equal to 0)

…

-Chris

[ProgramMax]

You mean two reasonable defaults?

I think if a user provides only one of [primaries/transfer function], I should default the other value to something reasonable, too.
I think that is what @svgeesus was pointing out.
So if someone specifies the transfer function 14 but doesn't specify primaries, we have a matching preset "bt.2020-10-bit" which has primaries of 9. I could default to primaries of 1. But it would be more reasonable with this information to go with 9.

There are also times this doesn't fully work.
If a user specifies primaries of 9, we could go with a transfer function of 14 (BT.2020 10-bit), 15 (BT.2020 12-bit), 16 (BT.2100 PQ), or 17 (BT.2100 HLG). Still, choosing any of those is probably better than sticking with 1.

[ProgramMax]

We could also mix it up between default & warning vs. error.
If the user specifies only transfer function 14, we can reasonably default primaries to 9 and issue a warning.
If a user specifies primaries of 9, we can error saying we can't find a reasonable default and they should specify the primaries.

[digitaltvguy]

Maybe best to force them to enter the primaries and transfer function otherwise throw an error? ..and have a default value for Matrix (Identity) and signal range (Full) if no value is entered?

[ProgramMax]

I've been thinking about this and I'm a bit torn.
An old-school program would error on a missing command line parameter.
That method is tried and true. It doesn't result in any surprises.

But in the age of AI, I feel like going with a safe default when one is obvious enough (and then warning) is better.
But warning text gets ignored and what if a new CICP entry comes along and makes the default no longer obvious?

I think if the situation were more interactive, the safe default option is better.
But so many of us are used to noisy cli programs. It is too easy to miss the warning.

I guess I'm not torn, now that I type this out.
But if this program becomes more interactive, it is worth revisiting.