Re: cICP wording feedback

Hi John,

I’ve been through the H.273 standard this morning, there seems to be a typo in equation 4 which I’ll flag to the authors, but I think there’s a misunderstanding in your email on the clipping range.

Using 8bit as an example, with the VideoFullRangeFlag set to 0 (i.e. narrow range) and the MatrixCoefficients set to 0 (Identity matrix for RGB) the clipping in equations 27, 28 and 29 occurs at 0 and 255, Nominal peak white maps to 235 and Nominal black maps to 16.  There is however no clipping at 16 or 235.

This is consistent with ITU-R BT.709, BT.2020 and BT.2100 video – excursions outside the nominal range are allowed and are not clipped.

For detailed resoning as to why excursions are allowed, please see: https://tech.ebu.ch/docs/r/r103.pdf


I would certainly expect to see excursions below 16 and above 235 in a PNG created from a live video frame or a video test sequence.

What does seem to be missing is how to deal with the negative excursion – it is normal to mirror the equation about the nominal black level, but this hasn’t been explicitly stated.

I’m not sure I understand the changing base comment.  As the system is relative, the camera operator is free to change the camera settings such to ensure the image does not clip.

Hope that helps,

Simon



On Fri, Feb 2, 2024 at 1:40 AM Simon Thompson - NM
<Simon.Thompson2@bbc.co.uk> wrote:
> I think the range 0-1 is a target in live video production, not necessarily always possible, if you think of a sports game under natural lighting or an outdoor interview, then as the lighting changes, the camera operator will slowly adjust the iris to prevent any large shifts being visible.  Any still images exported from a live video will probably include values outside the 0-1 range.  The various regional production specifications prevent clipping to the range 0-1 as this would cause ringing when filtering and increase bitrate requirements in DCT based encoders.

My understanding is that you are a BBC employee and HLG is a BBC
invention.  I based my comments on the actual wording of the cICP text
and, indeed, the use of the magic numbers (16,235) by Kodak but now
that I have read the H.273 equations my comments were entirely wrong.
A "narrow band" image is called such because it really is only
transmitting a part of the encoding space; so, using 8-bit numbers, it
transmits encoded values in the range 16..235 by transmitting values
in the range 0..1.  Hence the equations 20 through 22 in the spec,
specifically the part:

> 219 * E′r + 16

That's from equation (20); E'r is a linear value that has been
obtained from the inverse of the transfer characteristics (EOTF; the
encoding function).  It typically (when the transfer characteristics
are not 11 or 12) is limited to a value in the range 0..1

So if a PNG contains a value '0' in RGB the equation evaluates to 16
and if it contains the maximum value the equation evaluates to 235
(the magic numbers).  This is then scaled back to the range 0..1 (or
at least that is the intent of equations 20..22; some equations are
more clearly wrong, such as that for Clip3.)

So they guys in the Beeb who did this knew what they were doing; the
transmitted signal can contain only a sub-range, specifically
0.063..0.922 (3dp) of the encoding range 0..1 and the transmission is
"narrow range".

This does depend on my correct interpretation of the direction of the
equations, which is why I would like you to go back and ask your
colleagues.  I've been troubled by the description "full range"
because, by the definition in the PNG specification, it was backwards.
The explanation above makes sense to me; only a subrange of the
encodable range is transmitted (so it is narrow) and out of range
values (still within the representable range of the encoding) are
clipped.  HLG is a relative encoding in contrast with PQ when "1.0"
means 10000cd/m^2, making it "absolute".  Because HLG is relative a
subsequent frame can, I assume, change the base (resulting in the
display upping the luminance across the whole screen) and accommodate
the previously clipped values.

Received on Tuesday, 6 February 2024 12:21:52 UTC