Add #image-png-hdr-pq feature (#695). #816
Conversation
|
@nigelmegitt @palemieux I suggest we go ahead and approve this, but mark as risk for CR2. That way, we can pull it out if we find out we can't normatively reference the WG Note. |
| of content type <code>image/png</code> as defined by <bibref ref="png-hdr-pq"/>.</p> | ||
| <p>A TTML <loc href="#terms-presentation-processor">presentation processor</loc> supports the <code>#image-png-hdr-pq</code> | ||
| feature if it implements presentation semantic support for <loc href="#terms-image-resource">image resources</loc> | ||
| of content type <code>image/png</code> as defined by <bibref ref="png-hdr-pq"/>.</p> |
There was a problem hiding this comment.
Concerns have been raised that the approach taken in the PQ HDR in PNG WG Note is brittle because it uses a "magic string" to identify the ICC profile. The idea is that there should be a better or more standard way to make PQ values from a PNG in the future. I propose that we extend this feature to cover any PNG constructed to generate PQ pixel values and revert the reference to being normative, of the form "Note that [REF] defines a mechanism for storing images that use the Reference PQ EOTF specified in [BT2100-1] in the Portable Network Graphics (PNG) format" and that we add a normative reference to BT2100 as the definition of PQ.
There was a problem hiding this comment.
As far as I'm concerned, that is a veto of adding any #image-png-hdr-pq at this time. The intent of defining an HDR image feature is to point at a concrete (and not any) format. If there is none, then we can't proceed at all with defining a related feature.
There was a problem hiding this comment.
@skynavga we can indeed point at one, but the definition of PQ HDR is not in the image format but in BT2100. We do not need a normative reference to an image format to define an image feature that relates to the output pixels generated when processing an image. An informative example to a single example is acceptable in my view.
There was a problem hiding this comment.
@nigelmegitt I cannot agree.
There was a problem hiding this comment.
@skynavga I don't really understand which part of this you're not agreeing with, so a bit more information would be helpful. In the meantime, closing this is likely to push us to creating an extension in IMSC 1.1 that does the same thing as I'm proposing above.
|
Based on @nigelmegitt veto of this proposal, I am closing this PR, and recommend that #695 be closed and marked with |
Closes #695.