AviSynth+ thread Vol.2

[DTL]

What was the reason for such strange matrix ? Wiki says PC-matrix keep range unchanged. But ColorBarsHD already create levels in standard (industry ITU-R/ARIB) narrow range. Additional Levels of 0,255 to 16,235 looks like compress range even more ? Also aditional Levels() make precision and performance lower - may be add one more single-filter 'matrix' to ConvertToRGB() to create 16..235 RGB from 16..235 standard YUV ?

Also using Levels() for >8bit create additional nightmare for users to compute correct params because it is not autoscale.

Also it is good to add into documentation (wiki ?) about PC-matrix only in Convert() do not keep range in 16..235 (as input) but create some distorted RGB decode (above possible compute errors for 8bit in/out) in narrow-like levels if input standard narrow range not additionally compressed with Levels() processing.

"First time for 32 bit"

I see avspmod still release 32bit builds and require 32bit .dll for it. But I think at AVX2 chips users mostly running x64 OS so 32bit builds a not very required. With intrinsics-based SIMD program 32bit builds are easily possible (mostly all instructions have 32bit versions) but may have somehow lower performance because in 32bit mode addressable by instructions register file space is 1/2 of total.

[Rob105]

When opening Avisynth script is there command to get windows open file window to populate variable with the video.

Purpose is i have script that do not change at all, but file i apply script to changes a a lot, i don't want to type file name in script, i want to use windows open file dialog to populate it.

How i apply Avisynth script to all video files in folder, batch?

[FranceBB]

Originally Posted by Rob105

How i apply Avisynth script to all video files in folder, batch?

Let me introduce you to the fantastic world of FFAStrans: https://forum.doom9.org/showthread.php?t=176655
It does exactly what you want in terms of automation.
Just add a watchfolder -> A/V Decoder -> Custom Avisynth Script (doing whatever you want) -> Encoder -> Delivery
works every time.

[DTL]

Originally Posted by poisondeathray

Note that "PC matrices" are not quite the same thing as "Studio RGB", or "limited range RGB" used in broadcast or some NLE's

The equivalent way in avisynth as what's used a Studio RGB NLE (like vegas) for 8bit for that example above would be

ColorBarsHD(640, 480, pixel_type="YV24")
ConvertToYV12()
Levels(0,1,255,16,235)
ConvertToRGB32(chromaresample="point", matrix="rec709")

Y 180,179,16
C 16,181,179
G 16,179,14
M 179,16,181
R 180,16,17
B 15,16,180

There was an old dedicated "studio RGB" function by "trevlac" for avisynth

I tried 2 more plugins for convert: avsresize and fmtc - they both output equal RGB in narrow range and can accept feed from ColorBarsHD directly:

Y 180, 180, 16
C 16, 180, 179
G 16, 180, 15
M 180, 16, 181
R 180, 16, 17
B 16, 16, 180

So it looks only AVS internal 'narrow' matrix is something special and of lowest precision if even feed by 'double-narrow' 8bit YV24.

[poisondeathray]

Originally Posted by DTL

What was the reason for such strange matrix ?

Not sure what the "PC matrix" was originally for. Back then, people didn't know what "studio RGB"/"limited range RGB" was.

Originally Posted by DTL

I tried 2 more plugins for convert: avsresize and fmtc - they both output equal RGB in narrow range and can accept feed from ColorBarsHD directly:

Y 180, 180, 16
C 16, 180, 179
G 16, 180, 15
M 180, 16, 181
R 180, 16, 17
B 16, 16, 180

zimg/avsresize seems better/faster for just about everything in terms of pixel format conversions than internal functions.

[Rob105]

Subtitle() problem.

Subtitle("Hello World!", font="Arial", size=34, text_color=color_gold, halo_color=color_black, align=1, x=20)

Shows text in bottom left corner, if i add y=-20 to move text 20 pixels up from bottom left corner, text disappears.

I have to use frame height 1080 minus 20 = 1060 in y value.

Subtitle("Hello World!", font="Arial", size=34, text_color=color_gold, halo_color=color_black, align=1, x=20, y 1060)

this is major annoyance that whenever i set y value for Subtitle() function it starts to move text from top rather than its current position, am i doing something wrong or its a bug? I use AviSynthPlus_3.7.2_20220317_vcredist.exe

Originally Posted by FranceBB

Let me introduce you to the fantastic world of FFAStrans: https://forum.doom9.org/showthread.php?t=176655
It does exactly what you want in terms of automation.
Just add a watchfolder -> A/V Decoder -> Custom Avisynth Script (doing whatever you want) -> Encoder -> Delivery
works every time.

Thanks will give it a try.

Originally Posted by FranceBB

Easy peasy lemon squeezy: a simple Converttoyv12() after you index the images will do it.

Explanation:

when you stack together different clips, they must all be the same, so you need to convert either the original video file you're indexing to reflect the two jpg you're trying to add on OR the other way around. In the example, I've done the opposite, so I've converted the two images to yv12 (4:2:0 planar 8bit).

Thx for explaining.

[StainlessS]

Originally Posted by Rob105

When opening Avisynth script is there command to get windows open file window to populate variable with the video.

Purpose is i have script that do not change at all, but file i apply script to changes a a lot, i don't want to type file name in script, i want to use windows open file dialog to populate it.

How i apply Avisynth script to all video files in folder, batch?

1) Not exactly what you want but might like to know if its existence.
From RT_Stats plugin. https://forum.doom9.org/showthread.php?t=165479

RT_FSelOpen(string "title"="Open",string "dir"="",string  "filt",string "fn="",bool "multi"=false,bool "debug"=false)

 Function to select EXISTING filename using GUI FileSelector.

 Title = Title bar text.
 Dir   = Directory, "" = Current
 Filt  = Lots, eg "All Files (*.*)|*.*"
         [Displayed text | wildcard] [| more pairs of Displayed text and wildcard, in pairs ONLY].
         first one is default.
 fn    = Initially presented filename (if any).
 multi = Multiply Select filenames. Allows selection of more than one filename at once.
 debug = Send error info to DebugView window.

 Returns
   int, 0, user CANCELLED.
   int, non zero is error (error sent to DebugView window).
   String, Filename selected, Chr(10) separated multiline string if MULTI==true (and multiple files selected).

   Example, to prompt for an AVI file and play it.
    avi=RT_FSelOpen("I MUST have an AVI",filt="Avi files|*.avi")
    Assert(avi.IsString,"RT_FSelOpen: Error="+String(avi))
    AviSource(avi)

***
***
***

Function RT_FSelSaveAs(string "title"="Open",string "dir"="",string  "filt",string "fn="",bool "debug"=false)

 Function to select filename for Save using GUI.

 Title = Title bar text.
 Dir   = Directory, "" = Current
 Filt  = Lots, eg "All Files (*.*)|*.*"
         [Displayed text | wildcard] [| more pairs of Displayed text and wildcard, in pairs ONLY].
         first one is default.
 fn    = Initially presented filename (if any).
 debug = send errors to DebugView window.

 Returns
   int, 0, user CANCELLED.
   int, non zero is error (error sent to DebugView window).
   String, Filename selected.
 Will prompt to overwrite if file already exists.

***
***
***

Function RT_FSelFolder(string "title"="",string "dir"=".",bool "debug"=false)

 Function to select Folder using GUI.

 Title = UNDERNEATH the title bar text, for instructions.
 Dir   = Directory, Default "." = Current, ""=Root.
 debug = Send errors to DebugView window.

 Returns
   int, 0, user CANCELLED.
   int, non zero is error (ie -1, error sent to DebugView window, usually selecting non Folder object eg 'My Computer').
   String, Folder selected (minus trailing BackSlash).

2) Avisynthesizer_Mod
A SendTo App that allows Windows Explorer selection of video files and fills in a user supplied Template with the filenames.
Can concatenate (join/splice) selected files (default as original non mod version) and create a single output AVS file OR,
batch create multiple AVS files, one for each input source file (MOD version only).
Has a GUI to select required template and sort input files if multiple input files selected.

https://forum.doom9.org/showthread.php?t=166820

Also, This thread is Avisynth Development thread, not really for asking questions on Usage, Avisynth Usage forum appropriate place for that.

Do not reply in this thread to this post, thanx.

[Rob105]

Originally Posted by StainlessS

Do not reply in this thread to this post, thanx.

Do not tell others what to do, thanks.

[kedautinh12]

Originally Posted by Rob105

Do not tell others what to do, thanks.

StainlessS right, you ask wrong thread, you need create a thread in avisynth usage

[gispos]

Originally Posted by DTL

Made new version of converter to RGB32 - https://github.com/DTL2020/ConvertYU...ases/tag/0.4.0

It is finally more correct processing in 16bit intermediates and in narrow range the resudual error only about +1LSB. After gained to Full range - at some colours may reach error of 2LSB.

Yes, the colors are even better (more accurate) and I am glad that there is also a 32bit dll.
Thanks again for your work. I hope you don't mind because I deliver the dll with AvsPmod.

Edit:
I think you have something mixed up

Full range - gain=74, offset=0,
narrow range - gain=64, offset=16,
zero black and non-clipping superwhited - gain=69, offset=0.

should be

Full range - gain=64, offset=16
narrow range - gain=74, offset=0

[DTL]

"should be

Full range - gain=64, offset=16
narrow range - gain=74, offset=0"

No. In latest version the computing of R,G,B changed significantly (the 16 is subtracted from Y at first). So in old versions (not correct) the computing make R,G,B in 16..235 range, and in latest version it is in 0..219 range (with signed integer 16bit format so underblacks are negative).

0..219 range with negative underblacks is not standard to either narrow or full range in 8bit output. So to make it narrow - addition of 16 only required and to make it full - multiplication to (255/219)*64=74.5 only. So to output narrrow range it is now required gain=64 (no gain), offset=16. So to output full range - gain=74, offset=0 (no offset). To make computing a bit faster I even thing about templating main processing function even more so it can skip multiplication and addition of rounder and shifting if only addition of offset of 16 is required or skip addition if only range scaling is required. But it still not implemented because may not make significant difference in performance and make program text even more complex. And I think multiplication to 64 with addition of rounder of 32 and integer shift to 6 bits to the right (/64) not make precision lower in compare with skipping this operation (may be I not correct here because addition of rounder 32 may somehow change output in worse precision ?) in case of outputting narrow range with gain=64 and offset=16. So currently 'proc-amp' of gain+offset always full active. Also it may be some research if the sequence of operations of multiplication (range scale) and addition may make residual errors less - may be it is more better to make addition of offset first and next is scale. The total performance may be not any depend of the sequence of operations but residual error over all RGB range may change somehow. So current version have some internal features not completely optimized for case of gain only (no offset) and offset only (no gain) operations. Also the non-clipping superwhites monitoring setting of gain=69, offset=0 also required no offset so do-nothing addition of 0 may be skipped with some very small performance gain. Though most of expected operations with output full-RGB and non-superwhites clipping RGB both require full scale operation (of 3 stages - integer multiplication, addition of rounder and div-shifting). So only may be currently rare-needed narrow-RGB output may possibly benefit a bit in precision and performance if the scale/gain 3 operations may be skipped in completely template-based if-then new version. But it require even more complex selector of processing function (if gain=64 - select no-gain proc function version and if gain !=64 - select gain-proc function version). It may finally require redesign all large number of combinations params selector to 'tuple-type' like was implemented in mvtools by pinterf and not large and very complex set of if-else statements (they can also eat some performance and make program text harder to design and understand). May be will try it in some next versions.

Also about possible precision optimizations: Current computing of RGB performed not with 3x3 matrix multiplication and additions but with 'classic' RGB equations and with 16bit signed immediates:

R = (Y-16) + (Kr * (V-128) + 32) >> 6;
B = (Y-16) + (Kb * (U-128) + 32) >> 6;
G = (Y-16) - (Kgu * (U-128) + 32) >> 6 - (Kgv * (V-128) + 32)>>6;

this produce RGB in 0..219 range.

and proc-amp to make required range mapping
Val = ((Val * gain) + 32) >> 6) + offset;

So it have internally 16, 128 and 32 lots of hidden constants and matrix-dependent Kr, Kb, Kgu, Kgv coefficients and may be using some optimizing software (like zopti ?) there constants and coefficients may be tweaked so the absolute mean error over possible RGB output values may be reduced to minimum (in both or separate narrow-range RGB output mode and/or full-range RGB). But it require to run optimizer software with about 18 input variables (of 16bit signed short each) to optimize - may be long to run and I still not know this ready to use optimizer software (with brute-force search for example in +-defined range for each variable). May be some simple C-program may be designed to make this optimizing search.

16bit immediate computing allow to about double performance of AVX-engine in compare with 32bit immediate but not allow to accumulate several multiplication results before addition of rounder and div-shifting.
With 32bit immediate the possible computing is like

R = (R (Y, Kr, V, gain, offset) + rounder(4096)) >> 13; so it possibly have less rounder addition operations and div-shifts but total compute performance in 32bit IOPS is only 1/2 of 16bit IOPS for AVX-engine. Also the total workunit size for 32bit immediate only 1/2 of 16bit immediate computing (32 or 64 RGB triplets per 1 SIMD pass for AVX2). So the 32bit immediate computing mode can be also checked for performance in 3x3-matrix way of computing (as in AVS core now). The simple redesign of non-matrix computing to 32bit immediate shows it is about 2+x times slower.

[gispos]

Originally Posted by DTL

"should be

Full range - gain=64, offset=16
narrow range - gain=74, offset=0"

No. In latest version the computing of R,G,B changed significantly (the 16 is subtracted from Y at first). So in old versions (not correct) the computing make R,G,B in 16..235 range, and in latest version it is in 0..219 range (with signed integer 16bit format so underblacks are negative).

Then I'll probably mess something up. I asezoate 'narrow range' with TV-levels 16-235 and 'full range' with PC-levels 0-255

Is that correct?
But I just saw that if I look at a YV12 with PC-levels I get only 235 as white value and with TV-levels 255 (RGB value).

I am completely confused now, where is my thinking error?

AvsPmod Display setting TV-Levels:
ConvertToRGB32("Rec709") and DecodeYUVtoRGB(matrix=1, gain=74, offset=0) are the same (I thought this is narrow range)

AvsPmod Display setting PC-Levels:
ConvertToRGB32("PC709") and DecodeYUVtoRGB(matrix=1, gain=64, offset=16) are equal (I thought this is full range)

[StainlessS]

Then I'll probably mess something up. I asezoate 'narrow range' with TV-levels 16-235 and 'full range' with PC-levels 0-255

Google guesses that you mean "associate" there. [better than my guess which did not exist]

[DTL]

"'narrow range' with TV-levels 16-235 and 'full range' with PC-levels 0-255"

Yes - in EBU terms narrow range is 16..235. And PC is not limited to any range mapping but widely used at PCs sRGB uses 0 black and 255 max (and nominal ?) white.

"AvsPmod Display setting TV-Levels:
DecodeYUVtoRGB(matrix=1, gain=74, offset=0) are the same (I thought this is narrow range)"

In latest version with 0..219 computing it is not correct. The 'narrow' integer range mapping is also 'shifted/offsetted range' - its black is offsetted to code value 16 in 8bit words to have some footroom for underblacks in same 8bit unsigned words. Underblacks (and superwhites) typically not exist in PC-sRGB so sRGB (named also full) not require such shift and compression of nominal white to under-255 area.

Also PC-users like to map nominal 'moving pictures' white of 235 to max sRGB 255 white (so possible valid superwhites of 'motion pictures' become clipped). It is just one of widely used practice - other users may like to monitor up to at least 254 'moving pictures' Y/RGB non-clipped or even route RGB datastream to 'video/motion pictures/professional' display device (not sRGB PC monitor) - so that device will handle all levels in 0..255 code words in 'narrow mapping' as it should (with both scaler and displaying of superwhites).

So to convert computed in 0..219 RGB signed 16bit integer to narrow/shifted unsigned integer it is required to add only offset of 16. After adding offset of 16 it will map to 16..235 (it not mean 0..15 and 236..255 code values are not used - they may be populated with underblacks and superwhites).

" DecodeYUVtoRGB(matrix=1, gain=64, offset=16) are equal (I thought this is full range)"

To convert 0..219 into full-sRGB range only gain/scale with 255/219 ratio required so it is DecodeYUVtoRGB(matrix=1, gain=74, offset=0). Negative underblacks below 0 in signed 16bit integers are auto-cut-off by saturated 16bit signed to 8bit unsigned SIMD conversion at 8bit RGB producing so not require additional handling.

[gispos]

Originally Posted by DTL

"'narrow range' with TV-levels 16-235 and 'full range' with PC-levels 0-255"

Yes - in EBU terms narrow range is 16..235. And PC is not limited to any range mapping but widely used at PCs sRGB uses 0 black and 255 max (and nominal ?) white.

Described the other way:

ConvertToRGB32("Rec709") visually looks like DecodeYUV(matrix=1, gain=74, offset=0).
And "Rec709" is called TV-levels, so narrow range

ConvertToRGB32("PC709") visually looks like DecodeYUV(matrix=1, gain=64, offset=16).
And "PC709" is called PC-levels, so full range

But you write:
narrow range = gain=64, offset=16
full range = gain=74, offset=0

But it doesn't matter, I use it in a way that it matches the other settings.

[DTL]

First you need to download latest ver 0.4.0 (all previous uses different RGB computing and require different output proc-amp settings for levels mapping).

Test script for both levels and performance is

LoadPlugin("DecodeYUVtoRGB.dll")

ColorBarsHD(640, 480)
ConvertToYV12()

// make caching of YV12 to skip ConvertToYV12 compute at each frame for performance check
Trim(1,1)
Loop(1000000)

DecodeYUVtoRGB(matrix=1, gain=64, offset=16)

I open it in the VirtualDub and Ctrl+1 frame to buffer and paste into MS Paint to check levels in code values with colour pick tool (not simply look into image) -
Its Yellow patch RGB is in the narrow range of 180 and 16. 180 is computed to 180-16=164 164/219=~0.75 and it looks correct for 75% colour bars (in transfer-domain, not linear).

Also in VirtualDub monitor window it is visible all black level setup patches are visible (using PC sRGB monitor mode) - so black is shifted/offsetted to higher levels from normal display. If user have PC or other display with switching to limited/narrow/16-235 levels display - it may be switched to that mode and black will be placed to nominal.

For full range -
DecodeYUVtoRGB(matrix=1, gain=74, offset=0)

Now Yellow patch RGB is in range 190 and 0 - it is full (sRGB) range mapping with zero black for sRGB black display.

ConvertToRGB32(matrix="Rec709") - output Yellow RGB in 191 and 0 range - so it is equal to full/sRGB.

ConvertToRGB32(matrix="PC.709") - output Yellow RGB in 181/180/12 - it is somehow 'broken' narrow/limited range.

Also some info on YUV to RGB computing:
The simple equations of
R,B = Y + (Kb, Kr) * (U, V)
G = Y - Kgu * U - Kgv * V

Looks only work for YUV in 0.0f..1.0f range and produce RGB in 0.0..1.0f range. It was designed for some abstract YUV also may be analog range 0 to 0.7V , bipolar voltage with negative underblacks.

Digital YUV with unsigned integers code values have scaled and biased range, also not equal Y and UV scale:
Digital Y is Y*219 + 16
Digital UV is UV*224 + 128
(looks like equal for all commonly used standards of 601/709/2020)

So before start computing of RGB it is required both subtraction of bias of 16 and 128 from Y and UV and also make scale of UV and Y equal (for example division of UV to 224/219=1.02283). The additional division may be included into Kr,Kb, Kgu, Kgv coefficients of computing to make processing faster.

So version of DecodeYUVtoRGB from 0.4.0 have both Y-16 added and division of UV to 1.02283 included - so total compute errors in RGB expected to be lower. But it also cause range shift to 0..219. Also it adds some performance penalty over versions before 0.4.0 but I hope not very visible.

[poisondeathray]

Originally Posted by DTL

What was the reason for such strange matrix ? Wiki says PC-matrix keep range unchanged.

PC matrix still has usage scenario - for full range video. Y=0 black , Y=255 white . Many videos are full range out of the camera (e.g. gopro, many consumer cameras, some phones), gameplay recordings

If you take a perfect full range ramp Y 0-255 from a 256 width video. The pc matrix returns RGB 0-255. Each x-coordiante produces perfect RGB value. (e.g. x position 96 would equal RGB 96,96,96)

BlankClip(length=1, width=256, height=256, pixel_type="Y8")
mt_lutspa(mode="relative closed", expr="x 255 *")

Neither of the DecodeYUVtoRGB variants produce the 1:1 mapping desired result in this case, there are values repeated and missing

For 'Full' levels mapping: DecodeYUVtoRGB(matrix=0, threads=1, gain=74, offset=0)

For non-clippig superwhites monitoring or other processing with zero black: DecodeYUVtoRGB(matrix=0, threads=1, gain=69, offset=0)

[DTL]

So we have different YUV->RGB conversion tools for different use cases. My version designed to better decode colour bars from some (Japan/Asian ?) ARIB standard YUV implemented in AVS ColorBarsHD() source. I not test extreme 'full YUV' values.

"If you take a perfect full range ramp Y 0-255 from a 256 width video. The pc matrix returns RGB 0-255. Each x-coordiante produces perfect RGB value. (e.g. x position 96 would equal RGB 96,96,96)"

But to decode output of ColorBarsHD with better low/high RGB mapping to 16 and 180 it require additional Levels() processing ?

"Neither of the DecodeYUVtoRGB variants produce the 1:1 mapping desired result in this case, there are values repeated and missing"

Hmm - the initial design of DecodeYUVtoRGB is to decode 'always narrow/limited' YUV to either narrow/limited or 'full' or other RGB. I not test it with 'full YUV' input. I even not shure how awful nightmare may be full-YUV in 8bit if our 'normal YUV narrow/limited' already produce out-of-range RGB triplets. Though if this 'full YUV' is encoded from game capture with RGB full-range initially it will simply not have some extreme YUV triplets ?

As I read the PC-matrix is 'not change range'. So if you provide 'full YUV' and want 'full RGB' (unchanged range) it probably will be with
DecodeYUVtoRGB(matrix=0, threads=1, gain=64, offset=16) (no gain, offset 16 to compensate for input Y-16).

So gain=64, offset=16 proc-amp setting should work as 'not change range' - if narrow/limited input - it will also output narrow/limited. Also if full input - it will also output full. And gain=74, offset=0 is 'expand from narrow/limited to full' range setting.

Also if user want full YUV to narrow/limited RGB conversion it may be gain=55 ((219/255)*64) and offset=16 (may be someone need such conversion too).

[poisondeathray]

Originally Posted by DTL

But to decode output of ColorBarsHD with better low/high RGB mapping to 16 and 180 it require additional Levels() processing ?

Yes for PC matrix. That was demonstrated earlier. PC matrix is not the same thing as "Studio RGB"

Though if this 'full YUV' is encoded from game capture with RGB full-range initially it will simply not have some extreme YUV triplets ?

Probably - Game captures begin as RGB (and some people capture as RGB for higher quality, eg. Fraps) ,but many people capture as full range YUV. The conversion is 8bit RGB to 8bit YUV full range using something similar to PC matrix

But full range YUV camera recordings are internally raw, debayered to RGB and processed at higher bitdepths, then converted to usually 8bit 4:2:0 full range for the recording format. Some recording formats are 10bit 4:2:0 now, 10bit is becoming more commonplace in consumer world

As I read the PC-matrix is 'not change range'. So if you provide 'full YUV' and want 'full RGB' (unchanged range) it probably will be with
DecodeYUVtoRGB(matrix=0, threads=1, gain=64, offset=16) (no gain, offset 16 to compensate for input Y-16).

Not change min,max range, or intermediate ranges ? For Y values on the grey ramp , none of the values are changed . Y = R = G = B

Yes that's equivalent to pc matrix for Y values on the ramp . Not sure about colors. But it is a valid usage case, I suggest you add that example to the documentation examples.

[DTL]

"PC matrix is not the same thing as "Studio RGB"

As practice show the YUV to RGB decoder may have its own Transfer Function. Even if it is linear it can do range remapping. So for AVS core the rec709 is range expanding Transfer Function embedded in transform. For PC.709 it is range no change ? So if narrow/limited at input - it will also output narrow/limited (but looks not completely and not match other plugins).

"Not change min,max range, or intermediate ranges ?"

As Transfer Function of typical YUV to RGB conversion expected to be linear - so all immediate code values should follow general range remapping. Only compute/rounding quantization errors may make some additional digital-noise.

I not sure if fixed Y-16 internal will make best RGB for full-YUV input. So it looks the YUV to RGB need to have adjustable proc-amps at input and at output. I will add Ybias and UVbias as new params in next builds. So Ybias will be -16 and UVbias -128 default. For full-YUV input it may be better to set Ybias=0 (and output offset to 0) ? The gains (for Y and UV) may be also important - but most easier to use without performance lost is UVgain only (it is additional multiplier to all UV coefficients). So may be UVgain (float) of 1.0 default better to add too.

Some full-YUV may use not 224 gain and not 128 offset for Digital UVs ?