SafeColorLimiter

[FranceBB]

Hi there folks,
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
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]

Originally Posted by Alexkral

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:



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 when using autoscale = true

[FranceBB]

Originally Posted by Alexkral

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:



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

Originally Posted by poisondeathray

...
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]

Originally Posted by 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

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]

Originally Posted by feisty2

...
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.p...58#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]

Originally Posted by StainlessS

Is that a mistake feisty ?

https://forum.doom9.org/showthread.p...58#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

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]

Originally Posted by feisty2

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]

Originally Posted by feisty2

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