OBS: Broadcast Levels from Camera

[chris319]

I have a camera feeding OBS Studio via HDMI. The camera (Canon XF-100) has an internal color-bar generator. The camera puts whites at 8-bit 255 and blacks at 8-bit 0. With a little tweaking I was able to bring these to broadcast (BT.709) levels: white = 235, black =16.

Using the camera's color-bar generator and the OBS "color correction" filter for the video capture device, I set "brightness" to 0.0052 and "contrast" to -0.21. Voila! On OBS Studio, "brightness" acts like a pedestal (lift) control and "contrast" acts like a gain control.

OS is Windows 10. My display is set to 720 x 1280. To access the video filters it was necessary to move the Windows task bar away from the bottom of the display.

Hope this helps.

[Sharc]

I have a camera feeding OBS Studio via HDMI. The camera (Canon XF-100) has an internal color-bar generator. The camera puts whites at 8-bit 255 and blacks at 8-bit 0. With a little tweaking I was able to bring these to broadcast (BT.709) levels: white = 235, black =16.

In Avisynt this would be

ColorYUV(levels="PC->TV")

Using the camera's color-bar generator and the OBS "color correction" filter for the video capture device, I set "brightness" to 0.0052 and "contrast" to -0.21. Voila! On OBS Studio, "brightness" acts like a pedestal (lift) control and "contrast" acts like a gain control.

I don't know OBS in detail. 'Brightness' usually shifts the levels up or down, 'contrast' stretches (expands) or shrinks the levels (changing the slope of Y_out vs Y_in). But details depend on the particular software.

[pandy]

But general rule stays same (algorithmically). All this means re-quantization and lost quantization levels - isn't better just mark stream as full scale? (eventually loosing level 0 and 255)

[Sharc]

All this means re-quantization and lost quantization levels - isn't better just mark stream as full scale? (eventually loosing level 0 and 255)

Yes, 8 bit levels manipulations with integer maths introduce spikes (squashing the level range) and gaps (expanding the levels range) in the histogram which favour banding and posterization, unless one applies dithering. Actually, gaps (=unused levels) are no losses as no data are lost. All data can be recovered. Spikes means losses which can usually not be correctly recovered as there is no information as to how the spikes got accumulated.
I don't know how OBS processes internally. Maybe it uses an intermediate 10 bit format and converts back to 8 bits for exporting, or using floating point maths? No idea.
Marking as full is ok when one is sure that the flag is respected by the subsequent processing and player, and one wants to do without a sefety margin for over- and undershoots (e.g. filter ringing etc.). Consumer video (DVD, Blu-Ray, Broadcast etc.) are all limited YUV with Y 16....235 and Cb,Cr 16 ....240. Also, x264 encoder defaults to limited.

Edit:
Attached an extreme case when shifting the original luma from 16 ....235 to 0....15 or 236....255 (picture in the middle) and shifting it back to the regular 16....235 range. (bottom picture). See the change in the histogram (accumulations and gaps).

[pandy]

Yes, 8 bit levels manipulations with integer maths introduce spikes (squashing the level range) and gaps (expanding the levels range) in the histogram which favour banding and posterization, unless one applies dithering. Actually, gaps (=unused levels) are no losses as no data are lost. All data can be recovered. Spikes means losses which can usually not be correctly recovered as there is no information as to how the spikes got accumulated.
I don't know how OBS processes internally. Maybe it uses an intermediate 10 bit format and converts back to 8 bits for exporting, or using floating point maths? No idea.
Marking as full is ok when one is sure that the flag is respected by the subsequent processing and player, and one wants to do without a sefety margin for over- and undershoots (e.g. filter ringing etc.). Consumer video (DVD, Blu-Ray, Broadcast etc.) are all limited YUV with Y 16....235 and Cb,Cr 16 ....240. Also, x264 encoder defaults to limited.

Yes, level manipulation in digital domain introduce re-quantization problems - higher bitdepth allow to minimize problem proportionally to quantization step so quantization noise have lower level for higher bitdepth. Dithering is common way to deal with quantization noise but probably it will be suboptimal for further video processing and encoding.

Yes, flag may be not honored but usually it is honored so not doing re-quantization is probably still best option unless special requirements.

Yes, we don't know how camera produce video and how OBS produce it - assuming that camera produce video with level from 0 to 255 then in theory we should in first step perform sample scaling i.e. multiply each signal sample by 219/255 (0.8588235294117647) then add 16 so overall signal values will be from 16 to 235.

No, in broadcast levels beyond usual range for Y and for Cx are allowed (so called undershoot and overshoot), only levels 0 and 255 are reserved for control so any sample is clipped between 1 and 254. So it is still OK when you have limited quantization range flag active and video with less than 16 and more than 235/240 values.

Edit:
Attached an extreme case when shifting the original luma from 16 ....235 to 0....15 or 236....255 (picture in the middle) and shifting it back to the regular 16....235 range. (bottom picture). See the change in the histogram (accumulations and gaps).

Yes, this is expected. To restore 'normal' histogram look you need to apply some lowpass filtering on samples.

[Sharc]

No, in broadcast levels beyond usual range for Y and for Cx are allowed (so called undershoot and overshoot), only levels 0 and 255 are reserved for control so any sample is clipped between 1 and 254. So it is still OK when you have limited quantization range flag active and video with less than 16 and more than 235/240 values.

Agree, allowed as head- and footroom for TV broadcast, but nominal range is still 16....235.
Attached a document from the EBU which adresses exactly this subject for digital TV. See Table 1 and Figure 1.
(Btw. my TV goes a few steps above 235 and a few steps below 16 before it fades to all white or all black, with its current adjustments.)

[chris319]

The way OBS appears to work is the "contrast" control multiplies the digital values and "brightness" adds an offset. I'm assuming the user needs to keep luma values between 16 and 235; otherwise just leave everything at unity.

Yes, there will be rounding error when multiplying. I don't know for sure but it is possible that OBS makes these adjustments in the RGB domain.

This leaves no headroom or footroom but those can be added by altering the values I have given. Ideally this processing would be done ahead of the camera's color-bar generator but this is not possible with this camera.

[pandy]

@chris319 - To be honest i have no clue about internal way of OBS working - just wanted to point that if possible probably it is best to avoid any level manipulation but of course everything depends on goals.

Btw going for RGB may be useful in case of CG (overlays with subtitles etc) but as in OBS target is one of commonly popular encoders then they probably avoid not necessary YCbCr>RGB>YCbCr conversion.

@Sharc - yes, nominal range is 16..235 (240 for chrominance) and whenever it is possible probably best option is to follow recommendations but even recommendation says that going over limited quantization range is not a crime - it may happen under some circumstances - it is simply not recommended.

[chris319]

I don't know OBS in detail. 'Brightness' usually shifts the levels up or down, 'contrast' stretches (expands) or shrinks the levels (changing the slope of Y_out vs Y_in). But details depend on the particular software.

"Contrast" is multiplicative. In professional video it is galled "gain" or "white level".

"Brightness" is additive. In professional video it is called variously "lift", "pedestal", "setup", "black level".

In professional video, "brightness" and "contrast" are monitor controls.