SafeColorLimiter

[FranceBB]

Hi there folks,
the idea is to automatize clipping to get a broadcast safe output in Limited TV Range (0.0-0.7V).

8bit sources will be limited to 16 - 235 luma and 16 - 240 chroma
10bit sources will be limited to 64 - 940 luma and 64 - 960 chroma
12bit sources will be limited to 256 - 3760 luma and 256 - 3840 chroma
14bit sources will be limited to 1024 - 15040 luma and 1024 - 15360 chroma
16bit sources will be limited to 4096 - 60160 luma and 4096 - 61440 chroma
32bit sources will be limited to 16/255.0 - 235/255.0 luma and -112/255.0 - -112/255.0 - 112/255.0 chroma

It supports y8, y10, y12, y14, y16, y32, yv12, YUY2, yv16, yv24 and YUV 4:2:0 planar, YUV 4:1:1 planar, YUV 4:2:2 planar, YUV 4:4:4 planar 10-12-14-16-32bit, including those with alpha channel.
If the input is in RGB, it will just return the input untouched.


Script: https://github.com/FranceBB/SafeColorLimiter

[Alexkral]

passthrough ? out=my_catched_out : out=my_out

[FranceBB]

passthrough ? out=my_catched_out : out=my_out

Ok, so "?" already evaluates if it's true, but there's still the problem with the line above and the 32bit float individuation.
Besides, I was trying something like:

ColorBars(848, 480, pixel_type="YV24")

ConvertBits(32)

Limiter(min_luma=0.0625, max_luma=0.91796875, min_chroma=0.0625, max_chroma=0.91796875)

but I get a completely wrong result:

https://i.imgur.com/e9rXqL3.png

which is weird, considering that in 32bit float min_luma is supposed to be 16/256 which is 0.0625 and max_luma is supposed to be 235/256 which is 0.91796875

[Alexkral]

Actually it is "value/255.0 for Y (luma) channel and (value-128)/255.0 for U/V chroma channels" according to this (http://avisynth.nl/index.php/Limiter) when using autoscale = true

[FranceBB]

Actually it is "value/255.0 for Y (luma) channel and (value-128)/255.0 for U/V chroma channels"

Ah, I see, I'm an idiot, so these are the correct values:

Limiter(min_luma=0.0627450980392157, max_luma=0.9215686274509804, min_chroma=-0.4392156862745098, max_chroma=0.4196078431372549)

In fact I get the right output:

https://i.imgur.com/npFWdqv.png

however that's an approximation; when I try to use the right float values through mathematical operations in Avisynth I get a completely black output:


ColorBars(848, 480, pixel_type="YV12")
ConvertBits(32)

min_luma_float=16/255
max_luma_float=235/255
min_chroma_float=-112/255
max_chroma_float=107/255


Limiter(min_luma=min_luma_float, max_luma=max_luma_float, min_chroma=min_chroma_float, max_chroma=max_chroma_float)

[StvG]

ColorBars(848, 480, pixel_type="yuv420ps")

min_luma_float=16/255.0
max_luma_float=235/255.0
min_chroma_float=-112/255.0
max_chroma_float=112/255.0


Limiter(min_luma=min_luma_float, max_luma=max_luma_float, min_chroma=min_chroma_float, max_chroma=max_chroma_float)

Or you can just do:
ColorBars(848, 480, pixel_type="yuv420ps")

Limiter(paramscale=true)
There is error in the wiki (http://avisynth.nl/index.php/Limiter). The last parameter is paramscale not autoscale.

[FranceBB]

Ah! Ok, thanks, I edited it.
I'll edit the wiki later as well, thanks.
So that's why the autoscale wasn't working, it's actually called paramscale.

EDIT: Fixed error in the wiki by swapping "autoscale" with "paramscale"

Thanks!

[StvG]

Btw here (https://github.com/FranceBB/FranceBB_Sample-Avisynth-Script/blob/master/TvRange%20Limiter%20Luma-Chroma.avs#L20) should be 112/255.0 ((240-128)/255.0).

[poisondeathray]

The >8bit chroma values for limited range should not be the same as Y
10bit CbCr 64-960
12bit CbCr 256-3840
14bit CbCr 1024-15360
16bit CbCr 4096-61440
32bit CbCr 0.0625-0.9375

[StvG]

Right, max_chroma=240d.
I didn't take a look at the other bit depths than float.

Edit:
...
32bit CbCr 0.0625-0.9375
0.0627-0.9412 (for chroma range 0..1)

[Cary Knoop]

Almost all software treats the visible range for floats between 0.0 and 1.0. Both limited and full range gets mapped onto this interval.
WTW and BTB are not clipped but exist outside those values.

[FranceBB]

The >8bit chroma values for limited range should not be the same as Y
10bit CbCr 64-960
12bit CbCr 256-3840
14bit CbCr 1024-15360
16bit CbCr 4096-61440
32bit CbCr 0.0625-0.9375

Got it. I changed them, thanks.

[feisty2]

there's no such thing as fp32 safe color, same as there's no limited range RGB.
YCbCr is always defined on [0.0, 1.0] for Y and [-1.0, 1.0] for CbCr for fp32
it is conceptually incorrect to assume there's a "hard" range for floating point samples

[StainlessS]

...
YCbCr is always defined on [0.0, 1.0] for Y and [-1.0, 1.0] for CbCr for fp32
...
Is that a mistake feisty ?

https://forum.doom9.org/showthread.php?p=1843058#post1843058
By Pinterf - release of AviSynthPlus-MT-r2693.exe, (Quoting from Locked thread dont work any more [if it ever did])

- Changed (finally): 32bit float YUV colorspaces: zero centered chroma channels.
U and V channels are now -0.5..+0.5 (if converted to full scale before) instead of 0..1
Note: filters that relied on having the U and V channel center as 0.5 will fail.
Why: the old UV 0..1 range was a very-very early decision in the high-bitdepth transition project. Also it is now
compatible with z_XXXXX resizers (zimg image library, external plugin at the moment).
- New function: bool IsFloatUvZeroBased()
For plugin or script writers who want to be compatible with pre r2672 Avisynth+ float YUV format:
Check function availablity with FunctionExists("IsFloatUvZeroBased").
When the function does not exists, the center value of 32 bit float U and V channel is 0.5
When IsFloatUvZeroBased function exists, it will return true (always for official releases) if U and V is 0 based (+/-0.5)
- Fix: RGB64 Turnleft/Turnright (which are also used in RGB64 Resizers)
- Fix: Rare crash in FrameRegistry
- Enhanced: Allow ConvertToRGB24-32-48-64 functions for any source bit depths
- Enhanced: ConvertBits: allow fulls-fulld combinations when either clip is 32bits
E.g. after a 8->32 bit fulls=false fulld=true:
Y: 16..235 -> 0..1
U/V: 16..240 -> -0.5..+0.5

[feisty2]

Is that a mistake feisty ?

https://forum.doom9.org/showthread.php?p=1843058#post1843058
By Pinterf - release of AviSynthPlus-MT-r2693.exe, (Quoting from Locked thread dont work any more [if it ever did])

- Changed (finally): 32bit float YUV colorspaces: zero centered chroma channels.
U and V channels are now -0.5..+0.5 (if converted to full scale before) instead of 0..1
Note: filters that relied on having the U and V channel center as 0.5 will fail.
Why: the old UV 0..1 range was a very-very early decision in the high-bitdepth transition project. Also it is now
compatible with z_XXXXX resizers (zimg image library, external plugin at the moment).
- New function: bool IsFloatUvZeroBased()
For plugin or script writers who want to be compatible with pre r2672 Avisynth+ float YUV format:
Check function availablity with FunctionExists("IsFloatUvZeroBased").
When the function does not exists, the center value of 32 bit float U and V channel is 0.5
When IsFloatUvZeroBased function exists, it will return true (always for official releases) if U and V is 0 based (+/-0.5)
- Fix: RGB64 Turnleft/Turnright (which are also used in RGB64 Resizers)
- Fix: Rare crash in FrameRegistry
- Enhanced: Allow ConvertToRGB24-32-48-64 functions for any source bit depths
- Enhanced: ConvertBits: allow fulls-fulld combinations when either clip is 32bits
E.g. after a 8->32 bit fulls=false fulld=true:
Y: 16..235 -> 0..1
U/V: 16..240 -> -0.5..+0.5


that kinda depends on how the conversion (to RGB) formula is defined.
for this particular formula listed on avisynth.nl (http://avisynth.nl/index.php/Colorimetry)

R = Y + Cr*(1-Kr)
G = Y - Cb*(1-Kb)*Kb/Kg - Cr*(1-Kr)*Kr/Kg
B = Y + Cb*(1-Kb)

Cb and Cr are defined on [-1, 1], you would need to scale some coefficients in the above formula for [-0.5, 0.5] chroma

[StainlessS]

OK, thanks, F2.

[FranceBB]

New version, see first post or: https://github.com/FranceBB/SafeColorLimiter

Update:

- Code cleanup.
- Moved project to Github.
- Introduced support to Y8, Y10, Y12, Y14, Y16, Y32 and YUV411
- Fixed a bug that would prevent the script from returning a clip when the input had an Alpha Channel

[feisty2]

You should really remove all that fp32 safe color nonsense before someone stupid had the chance to actually use this incorrect "feature"

[Cary Knoop]

You should really remove all that fp32 safe color nonsense before someone stupid had the chance to actually use this incorrect "feature"
^This.

Floats are levels agnostic!

[poisondeathray]

there's no limited range RGB.

There is such a thing as "limited range RGB" . It's also known as "studio range RGB" . In 8bit RGB , 16-235 is black to white (sRGB or "computer RGB" is 0-255 black to white in 8bit, it's far more common) . Limited range RGB is used in r103 compliance checks for broadcast, and some NLE's like vegas use studio range RGB .

But it usually makes more sense to limit at the end , not intermediate float processing; and you usually don't deliver a float format in the first place. (common exception would be intermediate stages for production, such as EXR for VFX ). I don't see a usage case where it would be used in float, so it probably is a good idea to remove it


For this filter - limiting the min/max limits does not make something necessarily "broadcast safe" . Many YUV values "map" to illegal broadcast values that lie in the middle of the Y,U,V ranges . So the name for the filter is a bit of a misnomer. But typically you're allowed <1% illegal values in scenarios like r103

[feisty2]

I'm 99.9% sure that the so called studio range RGB is nothing but a mistake made by unprofessional engineers in the earlier days, because:
a) no television system transmits video in RGB space, so it makes no sense to preserve some "headroom" from the 8-bit range for some metadata that does not exist in the first place.
b) YUV<->RGB conversions are ALWAYS defined on full range RGB, this limited range RGB could not be properly displayed (without some non-standard scaling applied first), or properly converted to YUV by any standard. it's an abomination

[poisondeathray]

I'm 99.9% sure that the so called studio range RGB is nothing but a mistake made by unprofessional engineers in the earlier days, because:
a) no television system transmits video in RGB space, so it makes no sense to preserve some "headroom" from the 8-bit range for some metadata that does not exist in the first place.
b) YUV<->RGB conversions are ALWAYS defined on full range RGB, this limited range RGB could not be properly displayed (without some non-standard scaling applied first), or properly converted to YUV by any standard. it's an abomination

Maybe - but these standards exist, you should be aware of them, and we have to live with it because it's still used today. A lot of it is historical, where they had to deal with broadcast compromises with bandwidth and equipment issues

For broadcast, the transmission is not in YUV, but the display is not in YUV either. A normal HDTV in your living room uses limited range RGB by default. A comptuer display/montior uses sRGB, no surprise, so computer range YUV<=>RGB equations are typically used in the latter. But not in the former

YUV<=> RGB conversions have a "full" and "limited" parameter, correct ?

When you use "full" range equations, that produces limited range RGB - that is (almost) studio range RGB (there is a slight offset to actual "studio RGB" , they are not exactly equivalent), but range is the same.

Pros/cons - there is no range contrast expansion in the full range equations - it's 1:1 mapping 0-255 to 0-255. So in some ways it's better, in others it's worse. (Any range scaling is technically worse)

This is how broadcast checks are done for r103 ; they specify using full range equations for the RGB check (where <1% illegal is ok) , and that is "limited range RGB"

[feisty2]

For broadcast, the transmission is not in YUV, but the display is not in YUV either.

I'm not sure what you meant by "transmissions not in YUV", display is always in RGB, it's the only colorspace (or should I say type of colorspaces) that directly corresponds to how display devices work in the physical world


YUV<=> RGB conversions have a "full" and "limited" parameter, correct ?

there is no mentioning of limited range RGB anywhere in Rec.601 (https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.601-7-201103-I!!PDF-E.pdf). In fact, the quantization equations on page 4 already suggest that RGB must be full range, so E'y, E'cb and E'cr would also be range full as appeared in the equations. If certain programs support conversions between limited range RGB and YUV, it's a non-standard support for an illegal format.

A normal HDTV in your living room uses limited range RGB by default.
I don't know about this and I don't care, no one of my generation watches TV anyways

[poisondeathray]

I'm not sure what you meant by "transmissions not in YUV", display is always in RGB, it's the only colorspace (or should I say type of colorspaces) that directly corresponds how display devices work in the physical world


Sorry typo

That's correct. Transmission in YUV, display in RGB. That's the reason for the limited range RGB check

Your TV (if you had one...) uses limited range RGB.

Your graphics card should have a toggle for limited and full range RGB output - why ? Because a TV uses limited range RGB



there is no mentioning of limited range RGB anywhere in Rec.601 (https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.601-7-201103-I!!PDF-E.pdf). In fact, the quantization equations on page 4 already suggest that RGB must be full range, so E'y, E'cb and E'cr would also be range full as appeared in the equations. If certain programs support conversions between limited range RGB and YUV, it's a non-standard support for an illegal format.


r103 specifies limits for Y,R,G,B as 16-235

The full range equations are used for the YUV=>RGB portion of the check





I don't know about this and I don't care, no one of my generation watches TV anyways

Sure, that's why you weren't aware - but some people still do

That's what this thread is supposed to be about - "broadcast safe", at least what the 1st post mentioned

[feisty2]

also regarding fp32 YCbCr, it is obvious that this format corresponds directly to E'y, E'cb and E'cr defined on page 3 of Rec601 (https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.601-7-201103-I!!PDF-E.pdf), so the range should be [0, 1] and [-0.5, 0.5] accordingly. There is no definition of limited range E'y, E'cb and E'cr.

[poisondeathray]

also regarding fp32 YCbCr, it is obvious that this format corresponds directly to E'y, E'cb and E'cr defined on page 3 of Rec601 (https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.601-7-201103-I!!PDF-E.pdf), so the range should be [0, 1] and [-0.5, 0.5] accordingly. There is no definition of limited range E'y, E'cb and E'cr.

f2 - maybe some confusion over terminology over what "range" refers to. It does not refer to absolute range. It refers to black and white point

1) "Limited range RGB" means 16-235 black to white (in 8bit). It does not mean that you cannot have RGB code value of 1. It describes the black to white range only . When you apply full range equations, with broadcast range input (legal range) YUV video Y 16-235 - You get limited range RGB 16-235. If you had a Y'CbCr overshoot of 236,128,128 the resulting RGB value would be 236,236,236 . It's still called "limited range RGB", because the black to white point is RGB 16-235. The 236 value doesn't get clipped

A large part of why we have "legal range video" in the first place is for historical broadcast reasons - 0,255 are reserved for sync , and the equipment/ bandwidth issues mentioned earlier



2)
"Full range RGB" means 0-255 black to white. This is what you're used to. Computer RGB. Y 16-235 => RGB 0-255. This is limited range equation application . Range expansion


But of you started with full range video (Y 0-255) , you would get clipping of Y <16, Y>235 values when limited range equation to RGB is applied. In this case, that same YCbCr 236,128,128 value does get clipped in the RGB conversion



If you look at BT.709 If you look under 4.6 - R,G,B,Y (not just Y) black level and nominal peak are listed as 16, 235 (and 64, 940 for 10bit) . Both full and limited range equations are valid for BT.709, but only the full range equation results in RGB 16-235 from legal range Y input . That's the default BT709 specification. Not surprisingly, r103 guidelines mirror that range for R,G,B,Y

https://i.postimg.cc/2jtZk1Nc/BT709-4-6.png



Hypothetically, you had unlimited bandwidth and if fp32 was a transmission format, and you still had restrictions (pretty stupid if you had unlimited bandwidth, that's the main reason for the existence of full vs. limited ranges in the first place. We'd just use RGB for everything) , then the concept of full and limited Y range would still be valid . But as mentioned earlier limiting in fp32 never exists in a real scenario. It's always done at the end

[feisty2]

I know exactly what range means. if you're talking about 8-bit limited range, any behavior on (236,128,128) is undefined because it is not in the (definition) domain.

If you had a Y'CbCr overshoot of 236,128,128 the resulting RGB value would be 236,236,236 . It's still called "limited range RGB", because the black to white point is RGB 16-235. The 236 value doesn't get clipped

this is called analytic continuation, basically you have extended the domain of the original definition, and whatever happens in the extended domain has nothing to do with the original definition. do you know that the sum of all natural numbers converges to -1/12?

[poisondeathray]

I know exactly what range means. if you're talking about 8-bit limited range, any behavior on (236,128,128) is undefined because it is not in the (definition) domain.

this is called analytic continuation, basically you have extended the domain of the original definition, and whatever happens in the extended domain has nothing to do with the original definition. do you know that the sum of all natural numbers converges to -1/12?


You can call it undefined, but it happens, and those code values can exist.

Do you see why limited range RGB exists, and why limiting functions are sometimes used ? It's to conform to 709 specs , and r103

But the problem is many of those "illegal" broadcast values are illegal combinations of Y,Cb,Cr that result in negative or >1 values in RGB in the [0,1] definition (they lie outside the RGB color cube) . They lie in the middle of the range and cannot be addressed by simple min/max compression or clipping adjustments

Simple manipluations like resizing, chroma subsampling can result in those illegal values.

[feisty2]

You can call it undefined, but it happens, and those code values can exist.



you know I had a hard time convincing my 10-year-old cousin that 1+2+3+... = -1/12

[Cary Knoop]

this is called analytic continuation, basically you have extended the domain of the original definition, and whatever happens in the extended domain has nothing to do with the original definition.
A good example of this is when you convert a linear video to log and there are negative code values (due to the noise floor being set to zero).
Without extending the domain to the (principal) complex plane you will get errors that can no longer be corrected by subsequent operations.

[DTL]

"the idea is to automatize clipping to get a broadcast safe output in Limited TV Range (0.0-0.7mV).

8bit sources will be limited to 16 - 235 luma and 16 - 240 chroma"

That is not great idea and looks like misunderstanding the Rec.601. Rec.601 warning about possible walking restored RGB 'out of gamut' if even YUV is in valid (1..254) range. So Rec.601 recommends to check YUV (actually Y Cr Cb) if additional limits required to keep RGB-restored 'gamut in range'. And to distort image data as low as possible if actual limiting will be applied it recommends to distort saturation in the first place.

So limiting may be applied after analysing of YUV triad data (being checked in RGB-space for gamut limits) - not by simple checking every luma and chroma data channel separately. Because simple checking and applying to each channel separately it introduce many more unnecessary distortions. And clipping to nominal YUV levels may be even not guaranteed results to be actually RGB-gamut limited.

So the actual limiter may be best to work internally in HSB color system to have ability for Saturation degrading in the first.

Also all these additional limits requirements may be just 'shadows of the past' where real data receivers where very cheap and poor 8bit integer processors and can not handle 'out of 601 gamut' RGB properly.

there's no limited range RGB.


Limited range RGB is exact 4:4:4 member of Rec.601.

It looks like misunderstanding of system RGB data encoding and physical display RGB data encoding.

System RGB must be always in limited data range (in integer encoding) to handle over/under shoots (negative under the 'black'). It is valid in numbers (math), not physics of positive-only brightness.

Physical display RGB is the end of system and for data_to_brightness operation conversion negative under_the_black levels are not valid and consumes some useful data range of low-bit encodings. So display YUV to RGB conversion is usually done to 'full' range with zero black. Also it is correctly done after scaling data to actual display size. It is final system conversion and it is not required to be 'math safe' for processing signals with limited spectrum. So only at the End of System we have right to cut-out under_the_black undershoots in RGB without degrading. Also display RGB with 'full range' is no more valid for correct signal data processing in between samples in space.

And system RGB data is just one form of describing data of limited spectrum and may be any times later scaled and other processed so it must be in math safe bipolar range against 'black' for keeping undershoots under black and also must have some headroom above nominal and better even above highest objects levels for keeping overshoots.

Same as the processing of edges of actual physical display have special workarounds against Gibbs ringing because typical moving image data is usually not conditioned against Gibbs ringing at the edges nowdays. It is applied to thread https://forum.doom9.org/showthread.php?t=182276 where it is recommended to use Avisynth AddBorders() to expand 4:3 to 16:9. Because special display workarounds applied only to actual image data buffer edges - adding 'unconditioned' borders with AddBorders() will cause Gibbs-ringing at the transition to added borders if data levels of old frame edge and new border do not match. For 'broadcast safe' levels transition operation the Avisynth's filter AddBorders() need to be fixed too. For example based on ITU-R-BT.1212 idea of using Blackman impulse response for simple conditioning for channel or any other conditioning for channel with Gibbs-distortion depressed. But still no hero to do this and core developers are busy with other things. I read some user-defined scripts exist for workaround.

>there is no mentioning of limited range RGB anywhere in Rec.601.

https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.601-7-201103-I!!PDF-E.pdf
4:4:4 member of system - TABLE 4:

8) Correspondence between
video signal levels and
quantization level for each
sample:
– scale - 0.00d to 255.75d

– R, G, B or luminance
signal(1) - 220 (8-bit) or 877 (10-bit) quantization levels with the black level
corresponding to level 16.00d and the peak white level corresponding
to level 235.00d. The signal level may occasionally excurse beyond
level 235.00d or below level 16.00d

>Without extending the domain to the (principal) complex plane

Negative is simple real number. Not yet higher magic like complex numbers. Any video signal code value below 16 limited is actually 'negative' without any processing difficulties. In fp32 with correctly designed filters as was mentioned here there must be no difference in processing if data have some 'constant level shift'. And this shift may move all or part of data range to negative numbers too.

[DTL]

Some example what is going wrong when hardlimiting undershoots to 16 applied:

Giving some 'sharpness corrected' 1 video detail with local (blacker than black) undershoot samples sequence (16), 16, 7, 3, 120, 235, 3, 7, 16, (16):
https://i6.imageban.ru/out/2021/02/16/11cd7e6145968ff2bfd2be0175a8e422.png
It have good enough depressed Gibbs ringing and T-size in physical display RGB positive-only brightness about 3.1T at 0.1 level above physical zero brightness.

After hard-limiting under16 samples to 16:
https://i3.imageban.ru/out/2021/02/16/db265b898c622c9409f9e4da2c3acbf6.png
It have increased 0.1-level T-size to 3.2T (less sharp) and some far Gibbs ringing brought in (if using signal restoration DAC with large enough kernel taps value) near black level having positive (visible) values.

[Emulgator]

Applause, DTL.

[DTL]

http://downloads.bbc.co.uk/rd/pubs/reports/1987-22.pdf - the publication of Devereux, 1987 mentioned at ITU-Rep BT.629-4-1990 page 7 about possible implementation of YUV limiter keeping most of hue and luminance unchanged. I think in 2021 it may be easy enough designed as good speed Avisynth plugin but as a script it is hard and slow.

Also I see it (may not) do not try to keep the spatial spectrum of non-linearly limited YUV to be Nyquist-limited and anti-Gibbs conditioned. So the new implementation in 2021 and later may be even a bit better.

[FranceBB]

So Rec.601 recommends to check YUV (actually Y Cr Cb) if additional limits required to keep RGB-restored 'gamut in range'. And to distort image data as low as possible if actual limiting will be applied it recommends to distort saturation in the first place.

So limiting may be applied after analysing of YUV triad data (being checked in RGB-space for gamut limits) - not by simple checking every luma and chroma data channel separately. And clipping to nominal YUV levels may be even not guaranteed results to be actually RGB-gamut limited.

So the actual limiter may be best to work internally in HSB color system to have ability for Saturation degrading in the first.


You're actually right, in fact although clipping the out of range values makes luma legal, it's not the same for chroma.
For instance, it's entirely possible to have 16-240 chroma, which is made of legal values, but it's represented as out of range in the scope.
The reason for this is relative to the intensity and not the code values in which the signal spans, in fact if you take this 12bit input: https://i.imgur.com/lhdv3Ag.png we can see that luma is slightly lower than 256, sitting at around 210, so, it's slightly out of range, and chroma slightly above 3935, so it's out of range as it's supposed to be 3840, however, if I limit the values to Limiter(min_luma=256, max_luma=3760, min_chroma=256, max_chroma=3840) the luma is gonna be in range but the chroma is still gonna be out of range, especially in the green component and it takes a tweak(sat=0.90) to bring it in range. https://i.imgur.com/pc3Nu0G.png The fact is that, technically speaking, there's nothing wrong with the current Avisynth implementation of clipping, I mean, Limiter does what is supposed to do, namely limit the range to the correct values (in this case Limited TV Range), however, that is not enough for chroma as it not only has to be in that range in terms of values in which the signal is spanning, but it also has to be inside the 75% relative intensity as per standard, so it's still out of range despite being limited to span the correct values. I agree with you that a much better implementation is needed for chroma which should also be able to de-saturate the input signal by a certain percentage according to the specs instead of just getting rid of the illegal values and hope for the best.


Also all these additional limits requirements may be just 'shadows of the past' where real data receivers where very cheap and poor 8bit integer processors and can not handle 'out of 601 gamut' RGB properly.


Sadly no, they're not from the past as they affect very much what we perceive today. Although it's true that the effect of airing out of range stuff is way less catastrophic today than how it was years ago with CRT TV, it's also true that the TV is supposed to convert the input signal to RGB and most of them blindly trust the flag, which means that if it's flagged as Limited, it will convert to RGB (which is always full, as feisty said before and we agreed to) assuming that the black is 16 and the peak white is 235. What this means is that nothing below 16 or above 235 is displayed. What I've seen most of the times, is cameras being out of range, not in the sense of being Full Range, no no, their black was starting correctly, at 16, but their peak white exceeds 235. This is bad as anything above 235 will NOT be displayed by the TV which performs the conversion and a soft highlights rollback is therefore needed. Besides, some watchdogs are more permissive, some other are less permissive and may be prone to make a complaint to broadcasters airing out of range stuff, depending on the nation you're airing in. As to chroma, the same thing applies, however from my experience watchdogs tend to be far more permissive on chroma than on luma (don't ask me why), but it's very much an issue today as it was in the past and it's something that we can't ignore and that we MUST get right.


Physical display RGB is the end of system and for data_to_brightness operation conversion negative under_the_black levels are not valid and consumes some useful data range of low-bit encodings. So display YUV to RGB conversion is usually done to 'full' range with zero black.


Precisely, from Limited TV Range YUV the TV converts to Full Range RGB, but if there's something below 16 and above 235 for luma and 240 for chroma, the TV will almost certainly not display it as it would return a math error. As you said, if 16 is mapped to 0, 15 can't be mapped to -1 which is not valid.


And system RGB data is just one form of describing data of limited spectrum and may be any times later scaled and other processed so it must be in math safe bipolar range against 'black' for keeping undershoots under black and also must have some headroom above nominal and better even above highest objects levels for keeping overshoots.


Correct.


For 'broadcast safe' levels transition operation the Avisynth's filter AddBorders() need to be fixed too. For example based on ITU-R-BT.1212 idea of using Blackman impulse response for simple conditioning for channel or any other conditioning for channel with Gibbs-distortion depressed. But still no hero to do this and core developers are busy with other things. I read some user-defined scripts exist for workaround.


I didn't know about AddBorders(), but I too believe that we should have those broadcast safe values respected right in the core, probably with a better implementation of Limiter, but for now I'm just thinking about a way to implement it as a plugin. It shouldn't be too hard to do, after all we "only" need to de-saturate accordingly, but I have no idea of how much I have to desaturate according to the detected value, nor how I should detect that value. I'm pretty sure that there are some ways to detect it, just like what Histogram("color2") uses to display these things, but I have to think about it and write some logic around it.


Applause, DTL.

Yep. I always said that Russian guys are good at this and he's no exception! Well done for pointing it out, DTL ;)

[DTL]

this means is that nothing below 16 or above 235 is displayed.

I do not know where do you take about limiting max brightness display value to 235 Y code value. My poor-people 4k TV set from about 2015 branded 'philips' do display Y code levels up to 254. Do not as good as I think math with gamma 2.4 says like 20% brighter in compare with 235 code level, but about 16% brighter. May be because of poor driving of LCD panel at extreme code values.
https://i3.imageban.ru/out/2021/02/23/c47332398ab976d13c938345b1af85d0.jpg


I understand there may be at the consumer's side badly designed displays clipping brightness values to 235 or even upscaling 234+ code values to 236+ and with truncating high bits without saturation to 8bit ends up with 0..1+ code values and display black dots instead of 'superwhite'. But it is still badly designed examples of digital display devices. For CRT with no error any bit data processing inside tube it is also no problem do display some over-normal brightness values. As I remember at time of analog TV the 'superbright' still non-clipped value was about 130%, not 109% as currently with digital coding.

[FranceBB]

I mean they physically represent the whole range, even if they're TVs, if the stream is flagged as full but they won't if it's flagged as limited and since everything is flagged as limited in broadcast, you see my point... :(
As to full range streams properly flagged as full range, it's not mandatory for manufacturers to be able to display those values so it's honestly a lottery as the TV may or may not support it. In your case, your TV correctly decodes Full Range YUV to Full Range RGB, so you're lucky, but that doesn't solve the problem with streams flagged as limited but with luma out of range I'm afraid... :(

[Sharc]

You may find this interesting. They introduce "preferred min./max. values".
https://tech.ebu.ch/docs/r/r103.pdf

[vcmohan]

I am looking for a color conversion code using template for all uint and float formats. Something like
template <typename T>
void RGB_YUV( T*YUV, T* RGB)
and
template <typename T>
void YUV_RGB(T* RGB, T* YUV)

can you guide me? I tried to code but became messy and needed more inputs like nbits, min, max, int/float

[pinterf]

I am looking for a color conversion code using template for all uint and float formats. Something like
template <typename T>
void RGB_YUV( T*YUV, T* RGB)
and
template <typename T>
void YUV_RGB(T* RGB, T* YUV)

can you guide me? I tried to code but became messy and needed more inputs like nbits, min, max, int/float
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

[vcmohan]

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/AviSynthPlus/blob/master/avs_core/convert/intel/convert_planar_sse.cpp#L616

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

Exactly 8 bits (RGB24): https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/intel/convert_planar_sse.cpp#L1432
Exacly 16 bits (RGB48): https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/intel/convert_planar_sse.cpp#L1459
All bit depths: https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/intel/convert_planar_sse.cpp#L1459

8-16 bits (C version): https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/intel/convert_planar_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/AviSynthPlus/blob/master/avs_core/convert/intel/convert_planar_sse.cpp#L1490

32 bit float: https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/intel/convert_planar_sse.cpp#L1344
calling this: https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/intel/convert_planar_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/AviSynthPlus/blob/master/avs_core/convert/intel/convert_planar_sse.cpp#L1593

Exact 8 bit:
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/intel/convert_planar_sse.cpp#L2498
Exact 16 bit:
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/intel/convert_planar_sse.cpp#L2539
10-16 bits
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/intel/convert_planar_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]

First of all this limiter is not needed at all.


That's debatable.


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.



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.



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]

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]

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]

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]

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/commit/7ca71b79f2b3256a0eef1a099b857ac9e4017e36 (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/html/AK-UB300G(DVQP1279WA)_E/chapter04_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/trev_304-rec601_wood.pdf

[FranceBB]

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.


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)


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

Gotcha.



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.


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]

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.

[DTL]

Any comments?


+-1LSB error after processing is very great result. If you do not like errors level of 8bit systems you can freely use 10bit and more with current Avisynth+.

Also about issues with Y'CbCr systems - I hope in the future they will be discarded because it is just to make step to subsampled chroma that is not very good idea. It is shadows from the poor past with too poor MPEG codecs so they was supplemented with build-in distortions in the 2:1 compression rate R'G'B' 4:4:4 to Y'CbCr 4:2:0 system.

Now every generation of MPEG promise to provide close to x2 compression rate in compare with previous generation so using of more distortion-less R'G'B' 4:4:4 (bit-reduced or linear RGB full-bitdepth distortions-free) only equal to get previous -1 generation MPEG total compression rate. And (todays and future advanced) MPEG compression I hope introduces less distortions in compare with R'G'B' 4:4:4 to Y'CbCr 4:2:0 method.

With skipping RGB to R'G'B' compression stage increase MPEG loading to about 1.2:1 for SDR and abou 3:1 in HDR systems. But allow to get less distortions if even +-1LSB is important.
Ofcourse all mentioned systems must have headroom and footroom for transients encoding ('video-makeup look' especially) without additional distortions.

[Balling]

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... :(

There is a perfect float support in ffmpeg, ported from GIMP or GIMP's bable from 4 years ago.
As for quantising that float to integer and back, that is total garbage still, which makes it unusable, though this improved it https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200912090714.66582-3-mindmark@gmail.com/#58418 Still no tiff support though. https://trac.ffmpeg.org/ticket/5303#comment:11

But that is rgb.

[qyot27]

FranceBB is talking about libavutil/pixdesc.c and libavutil/pix_fmt.h not having I/O descriptors for AV_PIX_FMT_YUV(A)[420|422|444]F32[BE|LE], as those descriptors are the only thing the AviSynth demuxer in libavformat cares about (whether swscale can convert between them even passably doesn't enter into it).

AV_PIX_FMT_GBR(A)F32[BE|LE] and AV_PIX_FMT_GRAYF32 are the only ones defined in pixdesc.c/pix_fmt.h, so those are the only ones the AviSynth demuxer can open, even though AviSynth+ supports all those YUV(A) float formats (along with GBRAP14, YUVA420P12, and all of the YUVA*P14 formats, which also are missing in pixdesc.c/pix_fmt.h).

[FranceBB]

FranceBB is talking about libavutil/pixdesc.c and libavutil/pix_fmt.h not having I/O descriptors for AV_PIX_FMT_YUV(A)[420|422|444]F32[BE|LE].

Precisely.

[richardpl]

Balling is neither FFmpeg developer or contributor, so you knocking on wrong door.

[Balling]

Balling is neither FFmpeg developer or contributor, so you knocking on wrong door.

I am though. https://github.com/FFmpeg/FFmpeg/commits?author=ValZapod

And you are not Elon Mask either, like what is this?? https://trac.ffmpeg.org/timeline

[Balling]

Very cool commit, negate no longer clips: https://github.com/FFmpeg/FFmpeg/commit/97b5b9dbea2fd51861218416dafc46984e286826

BTW, chroma sample location in zimg (wrapper only) was wrong all along, ahahaha! Good I always used swscale. https://github.com/FFmpeg/FFmpeg/commit/27c0dd55609daf440a7744e96ac20c119bbeb80f

[DTL]

Very cool commit, negate no longer clips: chroma sample location in zimg (wrapper only) was wrong all along, ahahaha! Good I always used swscale. https://github.com/FFmpeg/FFmpeg/commit/27c0dd55609daf440a7744e96ac20c119bbeb80f

It is better do not use ffmpeg for serious processing at all. AVS+ + x264 + mp4box for muxing is good for everyday encodings.

[Balling]

It is better do not use ffmpeg for serious processing at all. AVS+ + x264 + mp4box for muxing is good for everyday encodings.

But we do not do everyday encoding. We need PQ and HLG and stuff.

[richardpl]

It is better do not use ffmpeg for serious processing at all. AVS+ + x264 + mp4box for muxing is good for everyday encodings.

You are not serious, AVS is crap.

[FranceBB]

AVS is crap.

Mind you, we use Avisynth everyday to handle every content encoded at Sky, including HDR PQ to HDR HLG conversion using custom made LUTs.

[cretindesalpes]

I think it was a sarcastic answer. FFmpeg is used by major video broadcast companies.

[DTL]

FFmpeg is used by major video broadcast companies'

May be in the very poor regions. Yes - our company also use it but only for proxy preview encodings where quality is not required at all. Only very small filesize and embedded timecode in the frame for the workers for create metadata (transcribing) before master editing at adobe nle.

[richardpl]

AVS is half-broken product used by incompetent people across the globe,
Proof is unlimited RAM usage as mentioned in one of this forums threads.
NLE are different thing and I'm rather not going into incompetent broadcast companies across the globe.

[FranceBB]

AVS is half-broken product used by incompetent people across the globe

Mind your language.
Not only this is not true, but it's also disrespectful towards the people who spent countless hours developing it and making it better and better, which Doom9 is full of.


Proof is unlimited RAM usage as mentioned in one of this forums threads.


That is ONE scenario I faced for a very PECULIAR use-case.


NLE are different thing and I'm rather not going into incompetent broadcast companies across the globe.

How funny. Avisynth is a frameserver, AVID Media Composer is a NLE, the two don't do the same freaking job! One is for post-processing, the other is for editing, is it too hard to understand? Besides, you said we're incompetent? Really? Do I have to remind you that literally the whole world is based on AVID Media Composer, which, mind you, IS a NLE? Not just broadcasters but the whole movie industry, just take a look at the logos at the end of a movie of your choice: the odds are that it has almost definitely been edited in AVID Media Composer and there's a reason for that. Not just as an editing product, but the whole environment AVID offers is second to none: AVID Nexis as RAID6 Storage, AVID Interplay Access to handle assets inside a MAM by abstracting the view and giving Media Managers lots of tool to handle it, the fact that you can have the Dynamic Relink to work on assets on different resolution and bitrate and only restore the original masterfile at export time and only in the bit you want, the integration with Spectralogic for LTO6 archive, AVID Airspeed Capture as hardware recording ports... Do I have to go on?

Yes I work in broadcast.
Yes I'm offended by your statement.

There are tons of broadcasting people who are very smart and skilled. The fact that you work in movie industry shouldn't put you above broadcasters.
There's no League A and League B workers, those working in broadcasting are just as skilled as those working in the cinema.
Besides, the concept that broadcasters are only those who receive readily available files and put them on air is totally wrong!
There are TONS of broadcasters who produce their own show, tv series and sometimes even movies, so this concept you have is totally wrong and misplaced!
You see lots of companies producing their own show despite not being a Hollywood company, so what? We have the people, we have the skills, we can do it.


This is gonna be my last reply.
This is a topic, my topic, about clipping to bring footage to legal range using an Avisynth Filter, so if you don't like Avisynth as frameserver and you don't use it and you don't have anything insightful to add to improve it, just don't reply any further.

[DTL]

"Proof is unlimited RAM usage "

It looks the feature of multi-threading multi-frame cache system. Yes - it sometime limit the complexity of the projects very fast and no way to free RAM memory for step by step processing. But for simple home projects like transcoding only it possibly may be faster and created with limited resources of freeware developers.

Really both ffmpeg and avisynth were created by 'personal computer pixel-based developers' not 'moving picture experts' and so were started and still loaded with lots of incorrect for broadcast industry processing algorithms. But with avisynth it looks like easier to avoid more or less destructive or errorneous processing of valuable data or put slow but working script workaround. Ffmpeg looks like much less controllable tool of what happens inside it. Also with every version and all in one patch the result of ffmpeg processing may become more buggy. The plugins-based structure of avisynth processing allow to keep the tested plugins separated with other parts.

[Boulder]

I think we've seen plenty of examples of the fact that just being in the movie industry doesn't mean a thing. We are often correcting their screw-ups here you know..

And being nasty towards fellow developers is something I consider very unprofessional and generally something that a person with a low self-esteem would do. You don't like it, do not use it or participate in the discussion as FranceBB said. In my almost 20 years of membership, I've found the place generally as a very supportive community and I would like it to stay so.

[Dogway]

If you work in the "movie industry" it's common knowledge software crashes every now and then, Maya, ZBrush, Substance, Mari... For me where people work means nothing if they don't show their competence

[FranceBB]

SafeColorLimiter v1.1 Released! (https://github.com/FranceBB/SafeColorLimiter/releases)

Changelog:

- Introduced Frame Properties Support as now the _ColorRange flag is correctly set to 1, namely Limited TV Range when filtering is applied on YUV (and Y only) at any bit depth, while RGB is passed through untouched.


SafeColorLimiter v1.2 Released! (https://github.com/FranceBB/SafeColorLimiter/releases)

Changelog:


- Adjusted chroma value scaling for higher bit depths
- Removed unnecessary chroma clipping in 32bit float when only luma is present