Linear canvas vs non-linear pixels.

Thanks to Chris for drafting a concrete proposal [0]. Below is a
potential challenge when handling PQ HDR content.

Starting from mastering, video pixels are coded as non-linear integer
code values, e.g. HLG, PQ, etc..

These pixels ideally remain unmodified until they are rendered to the
display since each conversion carries a risk that fidelity will be
lost. This is the case even in the case where the color space and the
pixel encoded remain the same.

The strawman currently requires that PQ pixels be converted to linear
values when written to Canvas:

   PQ CV ----F----> linear value -----G-----> PQ CV

This is non-trivial and computationally expensive since F is highly
non-linear and covers many orders of magnitude. It also requires G to
be the exact inverse of F, which is not always simple if F and G are
provided by different implementations.

How do we provide a means of avoiding this complexity and potential
loss of fidelity?

Could one approach be to add optional support for non-linear pixel
encodings, e.g. add 'rec2100--pq' to [1]. In other words,
implementation would need to support 'rec2020-linear' but could also
support 'rec2100--pq'.

Hope this makes sense. Looking forward to the feedback, as always.

Best,

-- Pierre

P.S.: I would have filed an issue on github but the strawman is, for
now, only a PR.

[0] https://github.com/ccameron-chromium/ColorWeb-CG/blob/add_hdr/hdr_html_canvas_element.md
[1] https://github.com/ccameron-chromium/ColorWeb-CG/blob/add_hdr/hdr_html_canvas_element.md#color-spaces

Received on Tuesday, 16 March 2021 20:49:50 UTC