SafeColorLimiter

[vcmohan]

Originally Posted by pinterf

It will be complex, plus you'll need the YUV-RGB conversion matrix as well (e.g. bt.601, bt.709 etc..)
edit: one can dig into avsresize which is not only a resizer but a most powerful format and color space converter as well.
It's parameter set is quite complex. http://avisynth.nl/index.php/Avsresize

Very nice of you. Many thanks. But for me it looks formidable. I will go by the old formula and make some functions for my work, as they are not required to be so accurate. My requirement is to depict seeing through a colored filter(glass). While RGB is understandable, YUV I am not able to figure out excepting by converting to RGB, filter, convert back to YUV. There must be a better method.

[pinterf]

I can only help with source code links

What you need is to convert from YUV to RGB, make your RGB-based overlay, then back to YUV.

In each case you have to generate two matrices, one for each conversion. On matrix creation you have to specify the used color matrix type. E.g. passing Rec.709 is good for HD/limited range conversions.

Then I link you examples on the conversion itself which is using the pre-generated matrix to do the calculation.
Unfortunately at least 8 bit, 10-16 bits and 32 bit float has to be coded differently.

As for integer scaled arithmetic: 13 or 15 bit internal precision is used for quick integer multiplication conversion. For 8 bits it's more than enough, in some cases over 10 bits it is better to use 32 bit float internally.

And now the sample link-cunami:

RGB to YUV

This one is using 15 bit precision integer arithmetic.
Matrix creation (depending on bit depth and matrix definition (e.g. limited range Rec601, full range PC.601)
https://github.com/AviSynth/AviSynth...r_sse.cpp#L616

The conversion itself (their parameter is the above mentioned precalculated matrix)

Exactly 8 bits (RGB24): https://github.com/AviSynth/AviSynth..._sse.cpp#L1432
Exacly 16 bits (RGB48): https://github.com/AviSynth/AviSynth..._sse.cpp#L1459
All bit depths: https://github.com/AviSynth/AviSynth..._sse.cpp#L1459

8-16 bits (C version): https://github.com/AviSynth/AviSynth..._sse.cpp#L1318

Note that depending on the bit depth I am using int64_t for the internal calculation to avoid overflow at 16 bit videos.

Since some years - because of precision - only the 8 bit conversion is using integer arithmetic in SSE2/AVX2. More than 10 bit integer formats are internally use 32 bit float calculation.

Comment here: https://github.com/AviSynth/AviSynth..._sse.cpp#L1490

32 bit float: https://github.com/AviSynth/AviSynth..._sse.cpp#L1344
calling this: https://github.com/AviSynth/AviSynth..._sse.cpp#L1364

YUV to RGB

This one is using 13 bit scaled integer arithmetics, the matrix is pre-calculated here:
https://github.com/AviSynth/AviSynth..._sse.cpp#L1593

Exact 8 bit:
https://github.com/AviSynth/AviSynth..._sse.cpp#L2498
Exact 16 bit:
https://github.com/AviSynth/AviSynth..._sse.cpp#L2539
10-16 bits
https://github.com/AviSynth/AviSynth..._sse.cpp#L2676

I hope this helps a bit. Ask if you need further clarification.

[vcmohan]

Thanks again. As I mentioned, I am trying to show some parts of frame as if one looks through a colored glass. For YUV formats knowing filter yuv, is there a better way than what I am doing viz: convert to RGB, filter in RGB, convert back to YUV. My only concern is when I switch input from RGB to YUV the outputs should look reasonably similar.

[DTL]

Also about 'super-white' level 109% - EBU tech 3325 2.1.2 describes testing of (good enough) displays ensuring that super white can be correctly displayed (producing about 120% of brightness above 100% level as gamma-tracking obliges).

[Balling]

Okay, I just read the thread. Oogh. So much confusion. First of all this limiter is not needed at all. Not just because it will not fix a lot of YCbCr values (for example YCbCr BT.709 values 139, 151, 24 will be R'G'B' -21, 182, 181, thus out-of-gamut) but it is not needed, because LG C9 (reference TV) supports Superwhite (>235 Y' even if it is not white Cb, Cr 128, 128) even in internal player, not talking about YCbCr Blu-ray streams. And that is actually the case for most TVs, Superwhite is supported. As for limited range RGB and YCbCr the only real limitation is THAT IN ALL components 0 and 255 (for 10 bit 0, 1, 2, 3, 1020, 1021, 1022, 1023, for 12 even more) values are reserved and should be absent. That is coming from HDMI spec as it is used for synchronisation. For full range there is no such limitation.

Also, I will point out that BT.709 triplet I showed above is actually what is used in xvYCC (it is always limited range). Negative R'G'B' means more saturated colors when converted to XYZ. See this calculator. https://res18h39.netlify.app/color

As for limited range RGB, not only it is used in nvidia control panel but it is how SMPTE RP 219 pattern is defined.

Oh, and BTW, 1+2+3+4+... is not -1/12, series diverges by definition.

[FranceBB]

Originally Posted by Balling

First of all this limiter is not needed at all.

That's debatable.

Originally Posted by Balling

Not just because it will not fix a lot of YCbCr values (for example YCbCr BT.709 values 139, 151, 24 will be R'G'B' -21, 182, 181, thus out-of-gamut)

Out of gamut chroma won't be fixed, but luma will.

Originally Posted by Balling

but it is not needed, because LG C9 (reference TV) supports Superwhite (>235 Y' even if it is not white Cb, Cr 128, 128) even in internal player, not talking about YCbCr Blu-ray streams. And that is actually the case for most TVs, Superwhite is supported.

Well, it depends from what you mean by "Super White".
All displays are RGB and by standard RGB is always full (Studio RGB is a particular case, we'll talk about this later). So, if the stream is tagged as Limited TV Range, the TV expects 16-235, namely a signal raging from 0.0V, 0.7V, therefore it expands 16 to 0 and 235 to 255. What happens if something is above 235? Math error as it won't fit in 255, therefore it will be clipped out.
If a stream however is flagged as full range and the TV supports full range, 0 will be mapped to 0 and 255 will be mapped to 255.
That being said, values above 235 in a Limited TV Range stream should not be part of the video and only short time overshooting are permitted by the ITU standard.
Same goes for 10bit, which should be within 64-940.
Try to send an out of range content to any serious broadcasting company with a serious QC Department and it will be refused.
And I can tell you that if I send a content with luma and chroma out of range (particularly luma) here at Sky to our QC Department, I can be 100% sure that it will be reported not just by operators but also by automatic checks like Tektronix Cerify and Tektronix Aurora and the content will be refused as they'll send it back to me so that I can re-encode it with the right levels.

Originally Posted by Balling

As for limited range RGB, not only it is used in nvidia control panel but it is how SMPTE RP 219 pattern is defined.

Studio RGB is a particular thing and although it's used, open source software don't have a way to flag it, in fact it's mainly used between broadcasters and studios for masterfiles.
For instance, I've received plenty of Motion JPEG2000 Studio RGB 12bit (i.e Narrow Range / Limited TV Range, call it what you want) files in which I had to apply LUTs working in Limited TV Range as well and I had to use zlib in Avisynth.

That being said, those are never files that reach the end users and are used in a particular scenario in which both parties (whoever sends the file from the studio and whoever receives the file as broadcasting company) agreed to receive a Narrow Range RGB (aka Studio RGB) and they both know what they're dealing with.

[cretindesalpes]

Originally Posted by FranceBB

That being said, values above 235 in a Limited TV Range stream should not be part of the video and only short time overshooting are permitted by the ITU standard.

BT.709-6 (p. 5), BT.2020-2 (p. 6) and BT.2100-2 (p. 2) don’t define it this way. They define black level and nominal peak at 16*2^N and 235*2^N (where N depends on the coding resolution: 0 for 8 bits, 2 for 10 bits, etc. Math formulation is mine, recs give the real values for each coding), and define a “video data range” from 1*2^N to (255*2^N)-1 inclusive as well as a two “timing reference” ranges (0 to (1*2^N)-1 and 255*2^N to 256*2^N-1). I cannot find any indication that signals under black level or over nominal peak should be temporary (and how would you check that?) or anything. Other ITU recs (like BT.2087 or BT.2390-9) also mention that the signal may exceed the black and peak values.

Maybe broadcasting stations have their own, more restrictive standards and this is perfectly fine. But for the ITU, the full [1, 255) range is legit.

[DTL]

It looks here is attempt to make cheap quality control for broadcasters.

If source provide 1..254 y-range it may be error/distortion or it may be correct. But to determine it broadcaster need to pay to high-priced worker like color-correction master or at least high graded professional. And if source provide 16..235 range it may be less in quality but the probability of significant errors like direct mapping of PC 0..255 levels to tv-limited is lower. And broadcaster can pay to cheap worker or buy cheap auto-QC software to check simply is levels are in 16..235 range or out. And ask sources to provide content only in hard-limited to 16..235 range. In the quickly degrading world suffering from a series of crisises it may be typical solution. Different providers of software QC tools tried to simulate pro human work of determine if 1..254 content is allowed or make by error by calculating of weights of out of 16..235 range samples and many other ideas. Like check if there large areas hard clipped to 254 level, if it appear rarely in really hard lighting to real camera or it is really error of computer-graphics software operator etc. The QC jury for real high quality content with real range 1..254 need to be highly competent and so highly priced. To make decision if it was unavoidable error in real world of content production or just gross mistake of content producer (and content need to be returned for repair).
But the price of advanced software tools may be also higher.

[FranceBB]

I wouldn't really call software like Baton, Cerify and Aurora "cheap" as they come with a relatively high price.
That being said, if a content is hard clipped is almost always the case it was shot in broad daylight, with no control whatsoever on it and in BT709 SDR 100 nits straight from the camera, therefore there's little to do honestly.
I've seen plenty of clipped out, completely white skies, but there's no problem with that, you can't always shoot log with a camera that has enough stops and apply a knee to knee down everything to 100 nits and make it also sit within the 16-235 / 0.0 - 0.7V range, especially if it's about news that have to go out live.

Taking this into account, anything else that is not live and that is shot nowadays for documentaries etc it's always shot log and then brought to BT709 and you can be absolutely sure that it perfectly sits within the available limited TV range values without anything clipped out unless the camera didn't have enough stops to record it (which, let's be honest, it can happen).

Still, if I have to choose I would rather get an hard clipped video than an out of range one 'cause if you send it on air and it's flagged as limited people won't be able to see it anyway. Most cameras on live shows have their black sitting at 16 correctly, however luma can go above 235 unless it's clipped. When we get ready for the shots, of course we tell the camera operator when to "close" so that the picture gets a bit darker but the highlights are within the limited TV range, however I personally also put a hard clipping on 'cause if the picture changes out of the blue and another subject is quickly now in focus it might go out of range 'cause perhaps there was a lamp out there that we didn't take into account, so I always always always put hard clipping on during live events just to be safe.

For instance, sports events.
I would rather have the players perfectly visible on the pitch and the lights clipped out in BT709 than having a completely dark picture.

[FranceBB]

Originally Posted by cretindesalpes

B
Maybe broadcasting stations have their own, more restrictive standards and this is perfectly fine. But for the ITU, the full [1, 255) range is legit.

Well if it was a full range video recorded and flagged as such it would be fine (even though you couldn't air it for standard reason) but if you were to play it on a TV that supports full range stuff it will play fine.
The thing is though that when you have a camera connected via SDI or IP or whatever set to limited TV range by standard it will not set the peak white to 235.
It will make the black sit at 16 but it will leave the white unclipped, therefore, according to what you have in the shot, like a chair with a person and a lamp in the background, the values around the lamp might go above 235.
What happens then?
Well all this is happening in YUV, but our TV work in RGB and we know that RGB is always full range, so if we were to feed a full range video with the full range flag, the TV would just map each point correctly. In case the flag is limited TV range and the content is limited TV range but out of range, 16 will be mapped to 0 correctly, but 235 will be mapped to 255, so what happens to those values above it (that shouldn't be there)? Well they're just not displayed...
This is why nothing should be out of range.
About the short spikes I don't remember where I read it, but it was actually to take into account compression overshootings rather than other things, but maybe it wasn't an ITU standard but rather an EBU recommendation and I'm just confusing the two...

[poisondeathray]

Originally Posted by FranceBB

Well all this is happening in YUV, but our TV work in RGB and we know that RGB is always full range,

But it's not true... In general, "normal" TV's use limited range RGB. Computer monitors use full range RGB. (Of course newer TV's support both, and you can set GPU to output either, but I mean by default)

About the short spikes I don't remember where I read it, but it was actually to take into account compression overshootings rather than other things, but maybe it wasn't an ITU standard but rather an EBU recommendation and I'm just confusing the two...

EBU r103 is just a set of recommendations, like ITU documents, but all broadcasters, even in North America follow those r103 guidelines.

The RGB range in r103 is referring to limited range RGB (or studio range RGB). The R,G,B out of gamut check uses studio range equations, not the computer range equations that you typically see (ie. studio range RGB, RGB 16-235 black to white in 8bit, 64-940 in 10bit - NOT RGB 0-255, RGB 0-1023 )

In 8bit 0 and 255 code values are strictly reserved for SDI timing (for 10bit, code values 0 to 3, 1020 to 1023 for 10bit)

[cretindesalpes]

Originally Posted by FranceBB

In case the flag is limited TV range and the content is limited TV range but out of range, 16 will be mapped to 0 correctly, but 235 will be mapped to 255, so what happens to those values above it (that shouldn't be there)? Well they're just not displayed...

It depends. If the display contrast is not set to the maximum, “superwhite” values may be displayed correctly instead of being clipped. And after resizing (or trapezoidal stretch for projectors), these values may fall back in 16–235 range because of the interpolation. Or conversely, out-of-range values may be generated at this step with significant overshoots from perfectly limited values. It all depends if the display system clips at intermediate steps of the calculations or just at the end, when sending voltages to LCD controller (or whatever technology is used).

to take into account compression overshootings rather than other things, but maybe it wasn't an ITU standard but rather an EBU recommendation and I'm just confusing the two...

Maybe EBU R 128 for audio? They recommend a maximum of -1 dBFS true peak. This is not written in the rec, but the well-known reason is that data compression can slightly change the peak output level, compared to the lossless input. Anyway the level is measured true-peak (as per BS.1770), which is not even the case with video.

[Balling]

"That's debatable." You can use --gamut-warning of mpv to see that all movies have out-of-range chroma and Superwhite. You need to remember that not only 420 FIR for left or top-left chroma siting in by itself introduces out-of-gamut gamut, but unless you use lossless avc/hevc/vp9/av1 the YCbCr 4:4:4 will get superwhite and superblack introduced due to how lossy encoders work.

"All displays are RGB " LG C9 has white subpixel for every 3 4k subpixels, so no. It is not that simple at all. Yes, it cannot simultaniously do the white subpixel and all 3 color subpixels, but still. Also, it is not THE VERY SAME RGB that is defined by matrix. Remember: BT.601 matrix is actually BT.470 System M primaries, white point CIE C (not even CIE series D), while BT.709 and BT.2020-ncl use BT.2020 and BT.709 primaries.

"the TV expects 16-235, " No, it expects 1-254, where 0 and 255 are used for sync. Wrong.

"namely a signal raging from 0.0V, 0.7V, "

Just like IRE units, this mV stuff is not to be used, you know that, right?

"therefore it expands 16 to 0 and 235 to 255" Nobody does that, unless you output RGB.

"Math error as it won't fit in 255, therefore it will be clipped out."
There is no math error. The definition includes matrix to XYZ, which is used.

"If a stream however is flagged as full range and the TV supports full range, 0 will be mapped to 0 and 255 will be mapped to 255."

YCbCr full range is not supported except in sYCC digital format of HDMI or Adobe YCC. xvYCC601 and xvYCC709 are mandatery limited range. In particular it is very hard to get full range YCbCr in any digital format (that includes newly defined in January 2021 ICtCp) for nvidia.

"serious QC Department and it will be refused." That is their problem.

"software don't have a way to flag it" Yet ffmpeg since before a week ago was flagging x11grab content to libx264rgb as limited range. It was fixed. https://github.com/FFmpeg/FFmpeg/com...857ac9e4017e36 (We had full RGB tagged as limited, yet we have no support in swscale for RGB limited. Yeah.)

[DTL]

" you can be absolutely sure that it perfectly sits within the available limited TV range values without anything clipped out unless the camera didn't have enough stops to record it"

There may be another long-read about how real scenes dynamic range compressed in SDR video cameras (up to 600% typical for broadcast-graded and more in selected products) and encoded to output but today too few time to type.

Look at least at Knee function and for example https://pro-av.panasonic.net/manual/...er04_03_03.htm
[AUTO KNEE LEVEL]

Sets the maximum level of the auto knee.

[100%] - [109%]

Factory setting: [108%]

Panasonic also votes with factory defaults for >100% auto knee highest target level and in >235 in 8bit encoding.

[Balling]

"But for the ITU, the full [1, 255) range is legit."

Yes, it is 1, 254. 0 and 255 are reserved for sync. Bit levels used for sync “from 0 to 2^(N-8)-1” and “from 255 × 2^(N-8) to 2^N-1". See xvYCC standard, IEC 61966-2-4, it has those formulae.

[Balling]

And, BTW. Originally it was supposed to be level 72-252 not 16-240 to capture sync levels too. See: https://tech.ebu.ch/docs/techreview/...ec601_wood.pdf

[FranceBB]

Originally Posted by Balling

You can use --gamut-warning of mpv to see that all movies have out-of-range chroma and Superwhite. You need to remember that not only 420 FIR for left or top-left chroma siting in by itself introduces out-of-gamut gamut, but unless you use lossless avc/hevc/vp9/av1 the YCbCr 4:4:4 will get superwhite and superblack introduced due to how lossy encoders work.

I know that, lossy encoders can create overshooting, however those are minimal. On top of that, the master is perfectly within the limited tv range, I can tell you that.
Every masterfile I received, especially for movies, is perfectly within the limited tv range levels and I haven't seen any overshooting due to the high enough bitrate, let it be AVC Intra Class 100 or XAVC Intra Class 300 or any high bitrate flavor of Apple ProRes. Sure, they're still lossy, but due to the high enough bitrate, I don't see overshooting, so the masterfile is perfectly valid and that's what I'm concerned about. If then the live H.264 encoder creates some overshoots due to the relatively low bitrate at which it has to encode, it's none of my business and it's perfectly supported by TVs, but that's only 'cause it's generally minimal.

Originally Posted by Balling

Just like IRE units, this mV stuff is not to be used, you know that, right?

mV is still a perfectly valid unit in the Digital World as well as it's provided by an hardware Waveform Monitor from Tektronix taking the input from the playout port playing the TX Ready mezzanine file via SDI, so it's the most reliable way to measure that. Of course, people may argue that it's better to specify it as bits values, but nonetheless the millivolt map exactly to the bits values, so it's perfectly fine to use a perfectly valid working waveform monitor that uses volts as a scale. Just FYI AVID Media Composer and other NLE still support this kind of scale in their built-in waveform monitor.

https://i.imgur.com/HRLItw3.jpg

(check the waveform in the middle in the top-right quadrant SDI->FlatLumaChroma)

Originally Posted by poisondeathray

EBU r103 is just a set of recommendations, like ITU documents, but all broadcasters, even in North America follow those r103 guidelines.

Gotcha.

Originally Posted by poisondeathray

The RGB range in r103 is referring to limited range RGB (or studio range RGB). The R,G,B out of gamut check uses studio range equations, not the computer range equations that you typically see (ie. studio range RGB, RGB 16-235 black to white in 8bit, 64-940 in 10bit - NOT RGB 0-255, RGB 0-1023 )

Right.

Originally Posted by poisondeathray

In 8bit 0 and 255 code values are strictly reserved for SDI timing (for 10bit, code values 0 to 3, 1020 to 1023 for 10bit)

Yep, absolutely.

[Balling]

Okay, so there is this thing called VideoProcessorBlt in DirectX11. You can select Intel's or Nvidia's one if you have both GPUs. Intel does this: it first decodes 160, 160, 160 Y'Cb'Cr' to limited range R'G'B' (209.27, 139.49, 218.05), then rounds (209, 139, 218) and then converts to full range R'G'B' (225, 143, 235). That is a bad idea, of course. Y'Cb'Cr' is much bigger colorspace than R'G'B' and has less gradations in R'G'B' part of it, so by decoding to limited range R'G'B' you lose some possible precision.

And anyway you are supposed to operate on float and only quantise in the end (whether it is integer optimisation or not).

Nvidia does this correctly and gets to 225, 144, 235.

Intel may have done it because for some colors you will get not perfect full R'G'B' values (like 100% red).
Any comments?

This of course assumes that the display is BT.1886 already, so no change of transfer function happens...

[FranceBB]

Originally Posted by Balling

And anyway you are supposed to operate on float and only

speaking of 32bit float, you come from the FFMpeg community, right? Any plan of adding support for this kind of Avisynth input in yuv? So far we're limited to 16bit planar...

[DTL]

Rawsourceplus plugin can import YUV444PS, YUV422PS YUV420PS . Though it is mostly useful for working with linear RGB data after final discarding all awfull inheritance from the past like sub-sampled and transfer-compressed (sub-bitted) Y'CbCr formats.
Also GREYS may be used to input float32 separated planes and combine to whatever need inside Avisynth enviroment.