Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warning for AVIF file with no colr box and non-default CICP in Sequence Header OBU #36

Open
leo-barnes opened this issue Sep 21, 2022 · 12 comments

Comments

@leo-barnes
Copy link

We recently came across some AVIF files that rendered incorrectly on macOS/iOS. The reason turned out to be that the files were encoded as video-range, but had no colr box.

Per MIAF, an image item without colr box shall default to NCLX 1,13,5/6 full-range, no matter what is in the bitstream. So files like these should be rendered as if encoded as full range.

It would be great if the compliance warden could detect this and warn about it since the file creator does most likely not intend for that to happen. Both CICP and full/video-range mismatches would be good to detect.

@rbouqueau
Copy link
Member

rbouqueau commented Sep 21, 2022

The container indeed takes precedence over the bitstream. However in this case you'd like a warning when parameters are inconsistent across layers.

I think the whole color management is actually error-prone and not well understood (as also show #37 and #38). Do you know if there exist a dump tool for such parameters in AVIF/MIAF?

We could add a fake rule in CW but we need to clearly identify what we want to check.

@cconcolato
Copy link
Member

A warning would be good, associated to the following sentence in ISOBMFF:

If colour information is supplied in both this box, and also in the video bitstream, this box takes
precedence, and over-rides the information in the bitstream.

It should check all the values from nclx: CP/TC/MC/Range.

@leo-barnes
Copy link
Author

Yeah, I agree that the color management part is a bit messy.
But there is now at least a way to fully specify it in such a way as to leave out any possibility of undefined behaviour: By having both an ICC profile and an NCLX box.

So if we detect that there is a mismatch between whatever ends up happening at the container level and the video bitstream, we should ideally warn about it and mention that two colr boxes could be used to remove the ambiguity.

@rbouqueau
Copy link
Member

What do we do from here? Should we compare the color management information given at different layers and report inconsistencies?

@leo-barnes
Copy link
Author

What do we do from here? Should we compare the color management information given at different layers and report inconsistencies?

I think that would make sense.

@cconcolato
Copy link
Member

I think ComplianceWarden should not implement rules that do not correspond to "shall"s/"should"s in the spec. If there is a need for ComplianceWarden to emit a warning (I think the need is valid here), then we should modify the spec to add a "should". In this case, I would suggest modifying the sentence in ISOBMFF that says:

If colour information is supplied in both this box, and also in the video bitstream, this box takes
precedence, and over-rides the information in the bitstream.

to:

The colour information supplied in both this box and in the video bitstream SHOULD match. If it is not the case, this box takes precedence, and over-rides the information in the bitstream.

But even then the above change in ISOBMFF uses "this", assuming that there is only one such box but in HEIF we may have more than one. So we may need to update HEIF as well, again ...

@rbouqueau
Copy link
Member

Couldn't a side tool that analyzes color management inconsistencies help? It could not be cw.exe but a side executable - or may more pragmatically a mediainfo dump of the container versus the extracted bitstream.

Opinion?

@leo-barnes
Copy link
Author

@rbouqueau

Couldn't a side tool that analyzes color management inconsistencies help?

It could, I just doubt people would actually run it.

Could we add a "color" section to the CW output that warns about these issues? Not necessarily errors, but warnings that the file is underspecified (or in the case of completely missing colr box and video range content) most likely will render differently in various implementations.

@rbouqueau
Copy link
Member

CW could implement it if you write a normative document that list such cases. Would that make sense?

@podborski
Copy link
Contributor

CW could implement it if you write a normative document that list such cases. Would that make sense?

I believe we could do it in AVIF spec using bikeshed asserts. Similar to how we are trying to do it in HDR10+ spec at the moment. AOMediaCodec/av1-hdr10plus#26

@rbouqueau
Copy link
Member

Is there any news here?

@rbouqueau
Copy link
Member

Any news here? This also blocks #37.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants