Plugin HDRTools for Avisynth [Archive] - Page 2

FranceBB

14th August 2018, 03:58

As i've explained in post #42, i don't know if finaly it's working properly. So, users who have HDR display and stuff, can you provide feedback ? Are the formula i use/implement good ? Are things working properly ?

I tested them with their default values, so I didn't change parameters out of curiosity.

From the test results, it seems that HDR to SDR is working as expected, with Reinhard getting closest to the original compared to the others.

Source: 4K HDR 10bit BT2100 PQ
Scene: Sunset, a very dark scene, with a bit of contrast between the objects (dark) and the sky (not so bright, yet brighter than the objects).

- ConvertXYZ_Scale_HDRtoSDR

Grade: F

Insufficient, totally unreliable, colors completely messed up, out of range, unwatchable. On top of that, it turned a sunset into a sunrise.
It's a simple scalar function, so it's not expected to be reliable, but still, the output was completely wrong.

- ConvertXYZ_Hable_HDRtoSDR

Grade: C+

Way better than the scalar function, however, it was brighter than the original HDR version. I had the feeling that it tried to "exasperate" the colors, trying to reproduce a very strong fake HDR effect in SDR. Although some people might love very strong colors, it doesn't quite resemble the original HDR version which is way darker. As result, the colors that were already kinda "bright" in the HDR version, became too bright in the Hable SDR version, compromising details (like the edges of the clouds) with the white point set too high.
Still, I think that it's tweakable, you can play around with the settings to make it look better and some people might like it, even though this "colorful" tone-mapping approach is not my favorite.

- ConvertXYZ_Mobius_HDRtoSDR

Grade: B

This is more like it.
With the default settings it got close to the original and the content is actually watchable and many people wouldn't complain with the result, to be fair.
However... I'm not one of these people.
The result is actually slightly darker than the original HDR in some areas and slightly brighter in some other, which is interesting... Odd, but interesting.
The grass became slightly darker than the original as well as few other objects, while the sky became slightly brighter.
Almost no details were lost in the sky and in the clouds, but they were still slightly brighter. As to the grass and other objects, they indeed lost details because they were slightly too dark, but I'm pretty confident that playing around with the settings a good balance can be found.
Mobius has slightly too contrast because it tries to reproduce the HDR one in the best possible way; sometimes it gets it wrong, but it can be tweaked and the result is gonna look acceptable.

- ConvertXYZ_Reinhard_HDRtoSDR

Grade: A

With the default settings, Reinhard seems to be the best one.
I'm very impressed, it almost looks like the original HDR and it gives a really good, conservative feeling when you watch it on an SDR screen. I mean, if you are not an encoder and you don't deal with these stuff (like the normal user watching TV) you probably wouldn't even notice that the content was graded in PQ and then tone-mapped to SDR via Reinhard.
Compared to Mobius, the sky is slightly darker (closer to the original) and the grass and other objects are brighter (again, closer to the original). The sky looks pretty legit and natural and there are more details in the grass and other objects compared to Mobius, however, it's still not like the original, even though it's pretty close. It can be tweaked as well and I think it can be improved even more by fine-tuning parameters and I believe it has the potential to look really close to the original. I really like it and it's definitely gonna be my choice if I gotta make HDR to SDR conversion.

Screenshot:

I compared the SDR footages with the HDR one using my TV, because my computer is obviously SDR (a normal LCD 1920x1080 60Hz, nothing special).
Besides, trying to screenshot an HDR material doesn't really make much sense, but in order to give you something to compare the tone-mapped SDR versions, I'm gonna give you... well... "something".

- "Original" HDR (well, sort of):
Link (https://i.imgur.com/yel0v1a.jpg)

- Simple Scalar Function:
Link (https://i.imgur.com/dEZVCaR.jpg)

- Hable:
Link (https://i.imgur.com/hx5Kf1J.jpg)

- Mobius:
Link (https://i.imgur.com/Qt6d2x5.jpg)

- Reinhard:
Link (https://i.imgur.com/9u95DjI.jpg)

I don't see anything wrong in the implementation of Jean-Philippe: it works and I find it very useful.
I didn't try SDR to HDR, PQ to HLG and HLG to PQ, though.

It would be interesting to test PQ to HLG and vice-versa using HDRTools and Davinci Resolve, then compare the results and check whether there are differences or not, but I don't have time for this right now.

Anyway, a big fat thank you to Jean-Philippe for this amazing plugin, once again.

On a very side note: I got this error the very first time I tried to run Hable, when I was seeking the video, but after seeking frame-by-frame without jumping "frenetically", it disappeared.

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

jpsdr

14th August 2018, 09:17

Scale seems to provide "appropriate" results with a coeff between 35 - 40. On the other side, as i've said, it was just "out of curiosity" to see what a simple scalar can do on XYZ colorspace, i never expect great result from it. If it was so simple, it would have been done a long time ago ;)

About detail loss, out of curiosity : Does it change if you use OutputMode=2 on the first ConvertYUVtoXYZ (or similar) ?

I'll take a look on Hable just in case, can you provide the exact script ? But, the 3 tonemap are all "indetical". I mean, the code is just a copy/paste on all 3, just the formula on the lookup table creation on the constructor changes.

I'll integrate it on the "all" plugins package version.

After, i don't know what you're seeking with, but i've noticed that according the tool used, there is 2 working ways :
- Constructor is run only once, and when seeking, only getframe is called (this is what you have in Virtualdub).
- Constructor/destructor is called each time a new frame is required. As filter has a "long" setup time (creating lookups), if you freneticaly seek, it's not impossible that you hit a "time out" issue, requesting 5 frames when the 1rst is still not out. This is how tools like avspmod seems to work. My guess is that you are in this case.

Otherwise, thanks for your post.

Now, i'll slowly work on my original idea, and the real "why" i've created these tools : Try a neural network approch on HDR to SDR. No idea if it will even work, but without trying, who knows...
To bad tritical is not here anymore, i would have asked some question about neural network. I've made my neural network class, i think i have the learning retropropagation algorithm correct, but i need convergence tweaking and feedback from neural networl expert. Well, i'll see later.

StainlessS

14th August 2018, 10:42

To bad tritical is not here anymore, i would have asked some question about neural network.

V.C.Mohan still visits quite regularly, and wrote NeuralNet plugin, no idea if he can assist.
http://www.avisynth.nl/users/vcmohan/NeuralNet/NeuralNet.html

jpsdr

14th August 2018, 17:50

New version, minor change, see first post.

jpsdr

14th August 2018, 18:56

For Scale tonemap, the following is not too bad, at least on my small video part of Dark Crystal :
Coeff_X=37,Coeff_Y=36,Coeff_Z=36

FranceBB

15th August 2018, 14:21

I don't know what you're seeking with, but i've noticed that according the tool used, there is 2 working ways :
- Constructor is run only once, and when seeking, only getframe is called (this is what you have in Virtualdub).
- Constructor/destructor is called each time a new frame is required. As filter has a "long" setup time (creating lookups), if you freneticaly seek, it's not impossible that you hit a "time out" issue, requesting 5 frames when the 1rst is still not out. This is how tools like avspmod seems to work. My guess is that you are in this case.

Yes, you are right, it was AVSPmod.
I'm downloading the new version of plugin_JPSDR, so thank you for including this new filter there.
As to the other tests, I'll eventually make a few more when I'll have time, but right now I'm really focused on something else due to work-related problems.

jpsdr

16th August 2018, 09:36

HLG mode can have a very long (like in seconds) setup time according the input/ouput and configuration. Warning, it will be a nightmare with tools working calling constructor/destructor each time you seek a frame.

FranceBB

30th September 2018, 05:12

New test and new comparisons! :D

Original HDR Source: Link (https://i.imgur.com/trL32ka.jpg)
Normal HDR to SDR: Link (https://i.imgur.com/L4AxbWn.jpg)
Scale default: Link (https://i.imgur.com/DpgmMWX.jpg)

Hable: Link (https://i.imgur.com/V2xLkwU.jpg)

ConvertBits(16)

ConvertYUVtoXYZ(Color=0, OutputMode=1, HDRMode=0, fullrange=false)

ConvertXYZ_Hable_HDRtoSDR(exposure_X=7.0)

ConvertXYZtoYUV(pColor=0)

Not bad at all, very close to the original.
Too bad for the object that Loki is holding: I got it too bright and details are lost.
I tried to play a bit with the white point, but I didn't manage to get it correct:

Hable v2: Link (https://i.imgur.com/PxF1AsE.jpg)

ConvertBits(16)

ConvertYUVtoXYZ(Color=0, OutputMode=1, HDRMode=0, fullrange=false)

ConvertXYZ_Hable_HDRtoSDR(exposure_X=7.0, whitescale_X=8.0)

ConvertXYZtoYUV(pColor=0)

Mobius: https://i.imgur.com/tg8V3iF.jpg

ConvertBits(16)

ConvertYUVtoXYZ(Color=0, OutputMode=1, HDRMode=0, fullrange=false)

ConvertXYZ_Mobius_HDRtoSDR(exposure_X=17.0, peak_X=1.1)

ConvertXYZtoYUV(pColor=0)

Close, but I've got the same problem: the object is too bright and therefore I lose details...

And... here comes the star... here comes the good one... here comes the one that keeps details... here comes my favorite one:
Reinhard: Link (https://i.imgur.com/yXJkcjo.jpg)

ConvertBits(16)

ConvertYUVtoXYZ(Color=0, OutputMode=1, HDRMode=0, fullrange=false)

ConvertXYZ_Reinhard_HDRtoSDR(exposure_X=2.5, contrast_X=0.9)

ConvertXYZtoYUV(pColor=0)

Just perfect, as I expected from Reinhard.
The exposure is exactly the same that I have on the HDR content and details of the object are not lost as I'm able to adjust the contrast accordingly. In my former chart I gave Reinhard an "A" and I'm gonna confirm my grade again.

Updated chart:

- ConvertXYZ_Scale_HDRtoSDR:

Grade: F

I gave it an F before because it didn't give me the correct values at all and I still gotta say that it's not fit for the job. Yes, it can be useful to test values and see how much you can scale down, but the result will be unwatchable anyway.

- ConvertXYZ_Hable_HDRtoSDR

Grade: C+

It's better than the "Scale" function, but I still think that it tries to "exasperate" the colors and give a sort of explosive fake HDR effect to the viewer at the expense of details which, for me, it's an absolute "no go".

- ConvertXYZ_Mobius_HDRtoSDR

Grade: B

It still tries to accentuate the "fake HDR feeling" by bringing colours a bit too saturated, but some people may like it. Overall, it's watchable for many people, but unfortunately, it loses some highlights. The kind of people that like these kind of grading probably doesn't care and actually prefers something like this, but it's simply not me.

- ConvertXYZ_Reinhard_HDRtoSDR

Grade: A

Reinhard gets the job done and it does it well, period.
It was my favorite one and it still is as today confirmed my thoughts once again.
Thanks to the contrast parameter and the exposure parameter it's possible to tweak it to get a very good result.
Yes, it's not gonna have extremely saturated colors and they will be perfectly legit for the BT709 range, the black level is gonna be pretty much perfect, details are gonna be kept and highlights are gonna be preserved.
Overall, it's my recommended way to do HDR to SDR.

jpsdr

30th September 2018, 09:50

In the readme :

pColor -
Color mode used in YUV/RGBtoXYZ.
0 : BT2100
1 : BT2020
2 : BT709
3 : BT601_525
4 : BT601_625

Default: 2 if Color=0, 0 otherwise.

So, as you've used :

ConvertYUVtoXYZ(Color=0, OutputMode=1, HDRMode=0, fullrange=false)

You have to use :

ConvertXYZtoYUV(pColor=0)

Otherwise, thanks for your tests and report.

FranceBB

30th September 2018, 16:57

@jpsdr... yes, of course. Tests are legit with pColor=0, but I forgot to include the script while I was testing, so I did it later while I was already writing the post here and I pasted the wrong one. xD

jpsdr

1st October 2018, 08:46

You can eventualy try/test to be more accurate if you have the SEI mastering parameters of your HDR stream. You don't have them by any chance ?

Soulnight

13th October 2018, 20:16

Hello!

thank you for creating this tool. :)

I am trying to do a small experiment with hdr rec2020 content to display in a certain color the pixels having colors outside REC709 colorspace.

I thought I would have to:

1) first convert from YUV to RGB.
2) Then convert non linear RGB to Linear RGB
3) Multiply by the matrix to go from REC2020 to REC709 colorspace

At 3), I though, I should then tell what to do with RGB values outsides the legal range and specify their value.

Like:

= decodeTransferFunction(sourcePixel); float3 rgb709 = mul(rgb2020, float3x3(...)); float3 result; if ((rgb709.r < 0.0) || (rgb709.r > 1.0) || (rgb709.g < 0.0) || (rgb709.g > 1.0) || (rgb709.b < 0.0) || (rgb709.b > 1.0)) result = 1.0; else result = 0.0;

But I don't know how to do that in Avisynth.

I currently have that code:

loadplugin("C:\Users\flole\Downloads\ManualColorMatrix\ManualColorMatrix_26.dll")
loadplugin("C:\Users\flole\Videos\AviSynth\HDRTools\x86\Release_W7\HDRTools.dll")
Directshowsource("F:\Kodi\Demo 4k HDR\The World In HDR 4K Demo.mkv")
ConvertYUVtoLinearRGB(Color=1)
#isRGB()
ManualColorMatrix(1, 1.66049, -0.58764, -0.07285, -0.12455, 1.13290, -0.00835, -0.01815, -0.10058, 1.11873)

Does the function you have written directly combined step 1 and 2?
ConvertYUVtoLinearRGB(Color=1)

Thank you, Merci beaucoup.
Florian

ps:
Final goal will be to visualize what color are "extended" and outside the REC709 color space.
And then analyse a full movie to get a % of pixels and frames showing colors outside the REC709 range.
And then if possible, even say how far and saturated are those colors for different Hue (RED, green, etc).

jpsdr

14th October 2018, 09:29

If you check the some example code provided in the first post (and/or in the Readme), you'll see exactly the script needed for what you want to do.
Indeed it's possible to do this from linear RGB step with a transformation matrix combining the two RGB -> XYZ / XYZ -> RGB matrix, but as you can see in the examples, you can directly do that with my tools, but going by the XYZ step, and not the LinearRGB step.
Also, read the pdf document i've provided with the plugin, i've tried to explain things, so maybe it will help you to understand exactly what you have in each step of the process of transformation signal from the natural real world light to the YUV data we are working on on our PC.

Soulnight

14th October 2018, 11:24

Thanks for the answer.
I did did read and I tried to understand the examples as well.

The thing is, I need to sort the "good" from the "bad" pixels afterwards.

And I understand how to define what is an illegal pixel in RGB (in 8bits, bigger than 256 or smaller than 0). With XTZ, it seems more complicated.

Can you confirm that:

ConvertYUVtoLinearRGB(Color=1)

not only convert YUV to RGB but then also convert non linear RGB to linear RGB?:thanks:

jpsdr

15th October 2018, 10:12

My bad, i didn't notice your PS. I thought you wanted to make convertion, didn't see you wanted to make some analysis...
Yes, i confirm.
All the functions are indeed made to not produce bad pixels, so any value outside range will be clipped, so the functions for the second conversion step can't be used for your analysis.

Soulnight

15th October 2018, 10:22

Thanks! I want to preserve the illegal values for the color outside rec709 so I can color them to black or white for example (using something like a if statement. If pixel r or g or b value outside the 0 to 255 range, then r=g=b=0)

Do you know how to do that?

jpsdr

15th October 2018, 10:40

Unfortunately, not.
But for sure, you'll need filters working on float values to do this.
So, first, set OutputMode=2 on the ConvertYUVtoLinearRGB.
If ManualColorMatrix worked on float values, it would have been exactly what you need just after.
Your coeff matrix on your previous post, you get them reverting the following 709 -> 2020 matrix provided in rec2087 ?
0.6274 0.3293 0.0433
0.0691 0.9195 0.0114
0.0164 0.0880 0.8956

Soulnight

15th October 2018, 10:57

Ok. Too bad.

I will attach this evening my excel spreadsheet where I gave I came up with all the conversion matrix.

It's a multi step process and you have to know your colorspace coordinates.

In the future, I will also do those studies for specific "triangle gamut " that I will have measured for display measuring like 90% dci.

Goal is to see how often do we have information outside of the rec709 colorspace, or outside the real colorspace covered by a tv/projector.

Any idea to do matrix multiplication in float?

-QfG-

20th October 2018, 10:58

First, this an awesome filter for avisynth, and second , sorry for my bad english, i'm German :stupid: . Ok i have a small Problem, i will show it here. I post the previe pictures in previemode, click for fullsize...

Beginning, this is the picture with MPC-BE madVR 150 Nits. I will this result in my target file:

Original 4K with madVR 150 Nits @1080p
http://fs1.directupload.net/images/181020/temp/5u88sgd7.jpg (http://www.directupload.net/file/d/5246/5u88sgd7_jpg.htm)

Try with HLG
Exposure=2
Whitescale=11.2
ConvertYUVtoXYZ(Color=0, OutputMode=0, HDRMode=2, fullrange=false)
ConvertXYZ_Hable_HDRtoSDR(exposure_X=Exposure, exposure_Y=Exposure, exposure_Z=Exposure, whitescale_X=Whitescale, whitescale_Y=Whitescale, whitescale_Z=Whitescale)
ConvertXYZtoYUV(pColor=0, OutputMode=2)
http://fs1.directupload.net/images/181020/temp/iebp2nqv.jpg (http://www.directupload.net/file/d/5246/iebp2nqv_jpg.htm)

Ok i like the Details of the HLG , but the problem is, where are my Colors? I need more Colors...

Try with PQ
Exposure=2
Whitescale=66
ConvertYUVtoXYZ(Color=0, OutputMode=0, HDRMode=0, fullrange=false)
ConvertXYZ_Hable_HDRtoSDR(exposure_X=Exposure, exposure_Y=Exposure, exposure_Z=Exposure, whitescale_X=Whitescale, whitescale_Y=Whitescale, whitescale_Z=Whitescale)
ConvertXYZtoYUV(pColor=0, OutputMode=2)
http://fs1.directupload.net/images/181020/temp/wb5mahse.jpg (http://www.directupload.net/file/d/5246/wb5mahse_jpg.htm)

The result with the standard whitescale=11.2 to dark. With Whitescale=66 the brightness and colors perfect, but too much white (show the skyline in the upper left corner).

Conclusion:

I need more colors in HLG, because i love this detailed picture. For PQ conversion i can use DGTonemap, this is ok. Is there any Solution for more colors and fewer brightness in HLG mode?

jpsdr

20th October 2018, 12:37

First, you have to use the proper mode. If your file is HDR PQ, use PQ, if your file is HDR HLG, use HLG, so, my first question would be : what mode is your file ? Can you post mediainfo result of it ?
According tests made by FranceBB (post #61), for him reinhard produde the best results. Have you tried it ?

-QfG-

20th October 2018, 13:21

thanks for response, file transfer is PQ.

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format_Commercial_IfAny : HDR10
Format-Profil : Main 10@L5.1@High
Codec-ID : V_MPEGH/ISO/HEVC
Dauer : 2 h 2 min
Bitrate : 35,0 Mb/s
Breite : 3 840 Pixel
Höhe : 2 160 Pixel
Bildseitenverhältnis : 16:9
Modus der Bildwiederholungsrate : konstant
Bildwiederholungsrate : 23,976 (24000/1001) FPS
ColorSpace : YUV
ChromaSubsampling/String : 4:2:0 (Type 2)
BitDepth/String : 10 bits
Bits/(Pixel*Frame) : 0.176
Stream-Größe : 29,8 GiB (79%)
verwendete Encoder-Bibliothek : ATEME Titan File 3.8.3 (4.8.3.0)
Default : Nein
Forced : Nein
colour_range : Limited
colour_primaries : BT.2020
transfer_characteristics : PQ
matrix_coefficients : BT.2020 non-constant
MasteringDisplay_ColorPrimaries : Display P3
MasteringDisplay_Luminance : min: 0.0050 cd/m2, max: 1000 cd/m2

I tried Reinhard, but Reinhard has "warmer" colors as Hable. Hable is perfect, without this white Bloom effect. But now, it's looks much better then before, playing with the switches :) ...

http://fs1.directupload.net/images/181020/temp/cc7hf3i7.jpg (http://www.directupload.net/file/d/5246/cc7hf3i7_jpg.htm)

jpsdr

21st October 2018, 10:11

... "Display P3" is not of big help, i need the values (not your fault)... :(
Do you use DGIndexNV by any chance ? If yes, what are the SEI parameters value ?

sneaker_ger

21st October 2018, 10:25

MasteringDisplay_ColorPrimaries : Display P3
is the same as
Mastering display color primar : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000

Also called "P3 D65".
https://en.wikipedia.org/wiki/DCI-P3#System_colorimetry

jpsdr

21st October 2018, 11:52

-QfG-

21st October 2018, 12:34

Thanks.
In that case, to have correct result, you should do :

ConvertYUVtoXYZ(Color=0,Rx=0.680,Ry=0.320,Gx=0.265,Gy=0.690,Bx=0.150,By=0.060)
#Whatever XYZ HDR to SDR (pColor=0,pRx=0.680,pRy=0.320,pGx=0.265,pGy=0.690,pBx=0.150,pBy=0.060)
ConvertXYZtoYUV(Color=2,pColor=0,pRx=0.680,pRy=0.320,pGx=0.265,pGy=0.690,pBx=0.150,pBy=0.060)

thx, i will try it :). Here my DGIndex Log:

DGHEVCIndexFileNV20 DGIndexNV 2053.0.0.159 X64

DEVICE 0
DECODE_MODES 0,0,0,0,0
STREAM 2 0
CLIP 0 0 0 0
RANGE 0 0 18446744073709551615 0
DEMUX 2,3,4,5,6,7
DEPTH 10
ASPECT 16 9
COLORIMETRY 9 16 9

MASTERING 13250 34500 7500 3000 34000 16000 15635 16450 10000000 50

But i'm to stupid to check, how i must calculate the MASTERING values for HDRTools :(.

jpsdr

21st October 2018, 12:53

It's explained in the ReadMe :

Another way to get them, it's if you're using DGIndexNV, on HEVC HDR stream.
In that case, you'll have in the DGI file this line (for exemple) :

MASTERING 13250 34500 7500 3000 34000 16000 15635 16450 40000000 50

The values are the following:

MASTERING GreenX GreenY BlueX BlueY RedX RedY WhiteX WhiteY MaxMasteringLevel MinMasteringLevel

The GreenX GreenY BlueX BlueY RedX RedY WhiteX WhiteY are by 0.00002 steps.
The MaxMasteringLevel MinMasteringLevel are by 0.0001 steps.

In our exemple, it will result :
Gx: 0.265
Gy: 0.690
Bx: 0.150
By: 0.060
Rx: 0.680
Ry: 0.320
Wx: 0.3127
Wy: 0.3290
Max: 4000
Min: 0.05

-QfG-

21st October 2018, 13:40

Yes i have seen it, but don't understand.

But know i think i find my mistake:

GreenX in DGIndex = 13250. Steps = 0.00002

So 13250/0.00002 = 662500000 :stupid::stupid::stupid:

I must: 13250x0.00002 = 0,265 :readfaq::readfaq::thanks:

Now, i check it ;)

EDIT:

So i'm happy and i like it :) Changed PQ to HLG
http://screenshotcomparison.com/comparison/122892

thx for this awasome plugin :)

SpasV

10th December 2018, 21:35

This is a plugin with functions made to work on HDR videos, but can also eventualy work to do some color conversions.

Note: ConvertXYZ_Scale_HDRtoSDR is a simple scalar function, i've made just to see what result it produces. Don't have expectations on this plugin, but if by luck it works for you...

Hi, I think you have succeeded. Great.
I haven't tried your work. I have some interest in programming video filters and I could do some work for you if you need.

Actually, I'm interesting in formal evaluating of color space transformations. In particularly, I've tried a simple transformation - truncating the color codes' two LSB, maybe analogous to ConvertXYZ_Scale_HDRtoSDR with this script:

DGSource("F:\Gladiator-2160p\Gladiator.hevc.dgi",i420=true,fulldepth=true)
z_ConvertFormat(width=1920,height=1080,pixel_type="YV12",dither_type="none"

to get an 2160p HDR (10-bit color) BluRay video conveted to 1080p SDR (8-bit) color retaining the Rec.2020/PQ color space.
Using Sony Catalyst Browse I've seen
Source: Rec.2020/PQ, Working Rec.709, Preview: Rec.709.
and video in the working space visually undistinguished from the source with waveform under 67 %.

So, I'm interested in programming a waveform/histogram generating Avisynth function.

jpsdr

1st June 2019, 12:03

New version, see first post.

jpsdr

7th June 2019, 11:44

New version, see first post.

StvG

16th August 2019, 00:39

Conversion 2020->709:
ConvertYUVtoXYZ(Color=1).ConvertXYZtoYUV(Color=2, pColor=1, OutputMode=2)
ConvertYUVtoXYZ(Color=1).ConvertXYZtoYUV(Color=2, pColor=2, OutputMode=2)
Both conversions give identical result. Is it expected? Is it not wrong for the pColor=2 variant? avsresize gives different results - https://forum.doom9.org/showthread.php?p=1881971#post1881971

jpsdr

16th August 2019, 22:06

pColor and also pRx,pRy,pGx,pGy,pBx,pBy,pWx,pWy are used only to compute the Min/Max values of XYZ, which are not a stable [0,1] in all situations like RGB, but are White Point and R,G,B point chromaticity dependent.

With this, with integer format, 16 bit for exemple, i can affect [0]=Min(X,Y,Z) [65535]=Max(X,Y,Z) in the inputs. These previous parameters have no effect in float format. The parameter is here for optimal theorical performance, but i don't know if it will produce real visible effect between the standard BT. It will if you use different White Point (his has the biggest effect), or realy very different R,G,B point.

Roughly, range is Y [0,1.00], X[0,0.96], Z[0,1.10]. Didn't check more decimal, but maybe for BT.709 max Z is 1.1001 and for BT.2020, max Z is 1.002. I think it's something like that, realy no more.
Well, the previous parameters are here to be sure you have input proper range value used in integer mode.

And again, of course, no effect in float mode because no needs.

Described also in the Warning page 3 of ColorConversion.pdf document i've provided within the binaries package.

hello_hello

17th August 2019, 00:56

jpsdr,
I'm still not clear as to why I'm getting such bizarre results for XYZ conversions here (https://forum.doom9.org/showthread.php?p=1881952#post1881952). Am I doing something wrong?

I read your reply in the other thread and looked at the PDF, and I can see rec.601_525 line and rec.601_625 line are different, but the question I'm trying to get a simple answer to is... why do other programs such as ColorMatrix & DitherTools only have/require one version of rec.601?
I assume my understanding is wrong, but I thought once analogue PAL and NTSC are converted to digital, the colorimetry is the same, and therefore there's only one flavour of rec.601 required for colorimetry conversions. When I play an NTSC DVD encode, is the same colorimetry being used by MPC-HC to convert to RGB on playback as for a PAL DVD encode?

StvG said in the other thread I should be using rec.601_625 to convert between HD and SD etc in digital-land, and I don't doubt him, but once again I'm just after a simple explanation as to why.

Cheers.

jpsdr

17th August 2019, 02:14

Neither my dictionnary, google trad or me understand "borked"...

There is no XYZ colorspace in avisynth, so, it's tagged RGB. So, the system (avs, Windows, Video card drivers, monitor) diplays (linear) XYZ data, thinking it's non-linear RGB. Not so suprise result is odd... But basicaly, you'll see darker colors than original. Effect even worse (a lot darker) with HDR data.
If you haven't, read the pdf document i've put with the filter, i've tried to explain how things work (at least, what i've understood). ;)
Maybe it will help you.

I've put the two rec.601 because there was two in the spec, so, i made them both avaible.
After, colorimetry is not realy my best field, so, i would suggest you to follow StvG advice.

After, i'm not sure there is realy need to go through XYZ (neither Linear RGB) for 601 <-> 709. Colorimetry parameters are almost identical, this is why people always do the convertion staying in the standard non-linear space, so, just by a simple matrix translation.
After, if you want perfect accuracy...

For 2020 <-> 709/601, you need to go through XYZ, because colorimetry parameters are different, and so it's only through XYZ that you can do it. Only Linear RGB is not enough and will produce improper results. Described in R-REC-BT.2087-0-201510-I!!PDF-E.

So, it's 3 am for me, time to bed...

poisondeathray

17th August 2019, 03:24

I read your reply in the other thread and looked at the PDF, and I can see rec.601_525 line and rec.601_625 line are different, but the question I'm trying to get a simple answer to is... why do other programs such as ColorMatrix & DitherTools only have/require one version of rec.601?
I assume my understanding is wrong, but I thought once analogue PAL and NTSC are converted to digital, the colorimetry is the same, and therefore there's only one flavour of rec.601 required for colorimetry conversions. When I play an NTSC DVD encode, is the same colorimetry being used by MPC-HC to convert to RGB on playback as for a PAL DVD encode?

StvG said in the other thread I should be using rec.601_625 to convert between HD and SD etc in digital-land, and I don't doubt him, but once again I'm just after a simple explanation as to why.

Cheers.

Simple answer is convention. It's the way everyone does it

1) Matrix for bt470bg (pal, or 601-6_625), smpte170m (ntsc, or 601-6_525) are the same, 709 different
2) Transfer for bt470bg, smpte170m, and 709 are the same
3) Primaries are different for all 3, but look at footnote 2

It is recognized that a practice is now sometimes used by which, when programs produced in HDTV are
release in SDTV, their HDTV pixel map is re-mapped onto the SDTV pixel map without changing the
colorimetry of the original program.

In practice, only matrix is usually accounted for, not primaries. You see this in professional HD to SD conversions, broadcast NLE's too . Technically you should adjust for the primaries too, but it's rarely done.

ie. So technically it's a HD => SD conversion with uncorrected 709 primaries .

But you can do whatever you want - you control matrix, transfer, or primaries for source/destination with tools like zimg/zlib (resize in vapoursynth, avsresize in avisynth)

dither tools' "newer brother" fron the same author, the vapoursynth's fmtc also give you control over these

hello_hello

17th August 2019, 04:03

poisondeathray,
Thanks for the reply.
Maybe I'm being thick, but I'm still not 100% clear on this.

Even the section you quoted only refers to HD and SD colorimetry, implying SD is a single colorimetry.
The pdf appears to me to explain the method for converting analogue to digital. Below figure 2.6 it says:

Chromaticity coordinates specified are those currently used by 625-line and 525-line conventional
systems.

I doubt any of us are using 625 or 525 line displays any more, and it seems the colorimetry co-ordinates convert "from" those systems. Even if they're different in analogue form, it seems bizarre to use two formulas to convert them to different digital SD colorimetries rather than them ending up the same. If they're not intended to convert to the same colorimetry, why use different formulas?

I must be missing the obvious here, and I won't get a chance till tomorrow, but I'll do some more reading to see if I can work out what I'm missing. In the mean time though, if there's two rec.601 colorimetries in digital form, which one do programs with only a single rec.601 option normally use?

Cheers.

PS. I've had the table in the ColorMatrix help file in my head, which is one reason I'm confused about it now. To me it implies there's only a single rec.601 in digital form but maybe I've been mis-interpreting it.

This is a list of all possibilities according to the MPEG-2 specs and DGDecode.
0 forbidden
1 ITU-R BT.709
2 Unspecified Video (unknown)
3 reserved
4 FCC
5 ITU-R BT.470-2 (exactly the same as ITU-R BT.601)
6 SMPTE 170M (exactly the same as ITU-R BT.601)
7 SMPTE 240M
8-255 reserved

poisondeathray

17th August 2019, 04:40

Even the section you quoted only refers to HD and SD colorimetry, implying SD is a single colorimetry.
The pdf appears to me to explain the method for converting analogue to digital. Below figure 2.6 it says:

Chromaticity coordinates specified are those currently used by 625-line and 525-line conventional
systems.

I doubt any of us are using 625 or 525 line displays any more, and it seems the colorimetry co-ordinates convert "from" those systems. Even if they're different in analogue form, it seems bizarre to use two formulas to convert them to different digital SD colorimetries rather than them ending up the same. If they're not intended to convert to the same colorimetry, why use different formulas?

There is a 625 and 525 chart. Notice their primaries for Red, Green, Blue are different

As mentioned earlier, in practice, the primaries are not adjusted for HD to SD conversion. You ignore it

You need to define matrix, transfer , primaries when converting from something to another. Input and output. Thats 6 values in and out. It becomes more important when you have other formats used in production like linear exr , then the transfer becomes important . The HD <=> SD case is covered by by 1,2,3 in my post above. 1) matrix is used 2) Transfer is cancelled out 3) primaries are usually ignored

I must be missing the obvious here, and I won't get a chance till tomorrow, but I'll do some more reading to see if I can work out what I'm missing. In the mean time though, if there's two rec.601 colorimetries in digital form, which one do programs with only a single rec.601 option normally use?

Use in what way ?

If you mean "primaries" it's usually unspecified or ignored. But some do specify it in metadata, even if it's actually ignored in conversions. (and you can verify these things , since you have control over matrix, transfer and primaries with vapoursynth resize or fmtc, or avsresize in avisynth)

The way you test it, is take known colors and values such as colorbars, run it through your HD conversions to SD (or SD to HD if you want)

You can specify the matrix/transfer/primaries in/out .

Keep in mind - the way you or whatever program converts back to RGB is important if you are "viewing" it

Keep in mind that sometimes there are conversions done in the GPU, sometimes in the renderer

You can do this for different programs, editors, media players to check behaviour

It takes alot of time to do these tests, but I did this a while back and my findings were primaries are mostly ignored in most programs. If you corrected for primaries (709 primaries in, 601-6_625 or 601-6_525 out) the conversion looked different than the known values you started out with in HD .

The exception is vapoursynth. It reads metadata, and that metadata affects conversions. Often, you have to override the "props" or various properties if you want it to behave like other programs, very tricky if you forget (e.g. something might be flagged interlaced, though progressive content, like a PAL DVD, but vapoursynth will treat it interlaced for all operations unless you override the props)

PS. I've had the table in the ColorMatrix help file in my head, which is one reason I'm confused about it now. To me it implies there's only a single rec.601 in digital form but maybe I've been mis-interpreting it.

That Colormatrix table you posted only specifies matrix, not the transfer or primaries.

The matrix values for 601-6_525 and 601-6_625 end up being the same - KR = 0.299; KB = 0.114 . But 709 is different. That's why we use matrix=blah when doing those conversions HD<=>SD conversions . But no matrix conversion between "PAL" and "NTSC" because they are the same

Better tables are in the more modern Rec. ITU-T H.265 standards document, which include 2020 and a bunch others along with their values and equations

E3 Color Primaries
E4 Transfer Characteristics
E5 Matrix Coefficients

Common tools like popular media players, only use matrix when converting back to RGB for display. The primaries are are not accounted for. You will get different colors than expected if you start adjusting primaries in that HD to SD or SD to HD case. Same with video editors and other tools

hello_hello

18th August 2019, 20:46

poisondeathray,
Thanks for the info. I also did some more reading and I think I'm now closer to an understanding.

First we have this table showing the difference between NTSC and PAL color primaries (from Wikipedia).

RGB color space parameters for Rec. 601 Color space White point (D65) Primary color
xW yW xR yR xG yG xB yB
625 line 0.3127 0.3290 0.640 0.330 0.290 0.600 0.150 0.060
525 line 0.3127 0.3290 0.630 0.340 0.310 0.595 0.155 0.070

Which I compared with the pic below showing how they correspond to RGB. Now I properly understand what those numbers mean.
Red and blue for NTSC and PAL are so close they can probably be considered the same, while green is a little different. For Rec.709 the red and blue primaries are exactly the same as 625 line Rec.601, while green is roughly halfway between the two Rec.601 versions.

https://www.image-engineering.de/content/library/technotes/2012_06_16/xy-Locus.jpg

Maybe now I understand why I've seen PAL DVDs that appear to have a slight green tinge. I assume they were encoded using NTSC primaries, or something....
I posted an example of that (https://forum.videohelp.com/threads/379383-QTGMC-with-interlaced-PAL#post2452886) during a discussion quite a while back.

Transfer Characteristics = gamma, which is the same for rec.601 and rec.709.

Color Matrix is the formula for converting YUV back to RGB (or more correctly converting YCbCr to RGB).
From what I understand now, there's only one formula for each, but there's constant(s) in each formula that are different for 525 line, 625 line (and rec.709) to account for the different primaries. If the wrong "constants" are used you don't convert back to exactly the same RGB you started with. Is that a correct assumption?

So the formula for converting between the rec.601 and rec.709 matrices is a standard formula used by most programs, that should take into account the different "constants" for red, blue and green, but doesn't because that makes stuff-all difference compared to using the wrong matrix, and I assume in many cases the original RGB primaries might be unknown anyway. I think I finally understand what "ignoring the primaries" means....

I assume HDRTools does account for those primaries... hence the two flavours of rec.601.... so to be technically accurate, assuming I'm encoding with x264 for example, if I converted HD to SD using the rec.601_625 formula, I should specify bt470bg for the color primaries and for the color matrix (rather than rec.709 for primaries and bt470bg for matrix), and if I'm upscaling from PAL to HD it'd be bt709 for the primaries and matrix (rather than bt470bg and rec.709)? Not that I've bothered setting the color primaries for a long time, just the matrix.

How am I doing?

Thanks again!

hello_hello

18th August 2019, 21:32

Neither my dictionnary, google trad or me understand "borked"...

There is no XYZ colorspace in avisynth, so, it's tagged RGB. So, the system (avs, Windows, Video card drivers, monitor) diplays (linear) XYZ data, thinking it's non-linear RGB. Not so suprise result is odd... But basicaly, you'll see darker colors than original. Effect even worse (a lot darker) with HDR data.
If you haven't, read the pdf document i've put with the filter, i've tried to explain how things work (at least, what i've understood). ;)
Maybe it will help you.

"Borked" effectively means "broken". It's probably slang.
These definitions (https://www.urbandictionary.com/define.php?term=borked) possibly come across as being somewhat insulting, but that definitely wasn't my intention.

What I'm failing to understand (I seem to be doing a bit of that lately) is how the intermittent XYZ colorspace matters when I shouldn't be seeing it. The screenshots were taken from the output of a script using this (2020 to 601).

ConvertYUVtoXYZ(Color=1).ConvertXYZtoYUV(Color=3, pColor=1, OutputMode=2)

Shouldn't I be seeing a fairly similar result to this (the expected result)?

ConvertYUVtoLinearRGB(Color=1).ConvertLinearRGBtoYUV(Color=3, OutputMode=2)

Thanks.

poisondeathray

19th August 2019, 00:10

First we have this table showing the difference between NTSC and PAL color primaries (from Wikipedia).

A quick glance and it appears those values are different than the official specs, not sure what's up with that . I think the ones in wikipedia are older, I think it was revised again later. I'd probably trust the official ITU document - that's what zimg/zlib uses and I'm pretty sure jpsdr goes by it too. Anyways, the point is they have different primaries.

Color Matrix is the formula for converting YUV back to RGB (or more correctly converting YCbCr to RGB).
From what I understand now, there's only one formula for each, but there's constant(s) in each formula that are different for 525 line, 625 line (and rec.709) to account for the different primaries. If the wrong "constants" are used you don't convert back to exactly the same RGB you started with. Is that a correct assumption?

So the formula for converting between the rec.601 and rec.709 matrices is a standard formula used by most programs, that should take into account the different "constants" for red, blue and green, but doesn't because that makes stuff-all difference compared to using the wrong matrix, and I assume in many cases the original RGB primaries might be unknown anyway. I think I finally understand what "ignoring the primaries" means....

Yes, if you use the wrong assumption or value you get different colors than expected. Remember - 6 values total - for matrix, transfer, primaries. Input and output . Transfer cancels out for both 601(525 and 625) and 709 . Primaries are usually ignored for the 709/601 case (input and output are calculated as "unspecified" so there is no net effect of primaries) . So the only thing that affects the conversion is matrix in most software for the 709/601 case

I assume HDRTools does account for those primaries... hence the two flavours of rec.601.... so to be technically accurate, assuming I'm encoding with x264 for example, if I converted HD to SD using the rec.601_625 formula, I should specify bt470bg for the color primaries and for the color matrix (rather than rec.709 for primaries and bt470bg for matrix), and if I'm upscaling from PAL to HD it'd be bt709 for the primaries and matrix (rather than bt470bg and rec.709)? Not that I've bothered setting the color primaries for a long time, just the matrix.

I'm not sure what it does; I haven't really used it much. But if it accounts for the primaries difference (ie. primaries_input was 709, primaries_output is 601_625) - you'll usually get shifted colors in typical programs, because when they convert back to RGB for display, they usually only use the matrix the way most people have programs configured.

Note that in x264, those --colorprim xxx --transfer xxx --colormatrix xxx switches are just VUI metadata. They don't actually do anything. It's up to the other recieving software how it's handled . Some pay attention to that metadata. e.g vapoursynth. So if you do that actual primaries adjustment, and flag it accordingly, you end up getting the expected colors.

StvG

19th August 2019, 06:40

A quick glance and it appears those values are different than the official specs, not sure what's up with that . I think the ones in wikipedia are older, I think it was revised again later. I'd probably trust the official ITU document - that's what zimg/zlib uses and I'm pretty sure jpsdr goes by it too. Anyways, the point is they have different primaries.

zimg uses those values from wikipedia - https://github.com/sekrit-twc/zimg/blob/master/src/zimg/colorspace/colorspace_param.h#L28 REC_470_BG (625 lines) and SMPTE_C (525 lines/170m/240m).

Edit: I'm not sure what it does; I haven't really used it much. But if it accounts for the primaries difference (ie. primaries_input was 709, primaries_output is 601_625) - you'll usually get shifted colors in typical programs, because when they convert back to RGB for display, they usually only use the matrix the way most people have programs configured.

It seems that behavior is only when XYZ is used for 709<->601 (or 2020)? Using LinearRGB for those conversions doesn't touch primaries?

jpsdr

19th August 2019, 09:29

ConvertYUVtoXYZ(Color=1).ConvertXYZtoYUV(Color=3, pColor=1, OutputMode=2)
Shouldn't I be seeing a fairly similar result to this (the expected result)?
ConvertYUVtoLinearRGB(Color=1).ConvertLinearRGBtoYUV(Color=3, OutputMode=2)
Thanks.
No, because 2020 has significant primary colors differences than 709/601.
So, when going through XYZ, you adjust primary colors, you don't when going only through linear RGB, as linear RGB integrate the primary colors of the sensor. And primary colors are different enough to produce a noticeable different result.

According R-REC-BT.2087 the proper way is through XYZ for 2020 <-> 709.

As i describe in my pdf doc, you have for SDR :
[Scene] => [Camera sensor] => [Linear RGB] -> (Gama or OETF) -> [Non Linear RGB] -> (matrix) -> [YCbCr]

The primary colors are in the [Camera sensor], so, it's only on this step that 525/625 lines has effect, not in the (matrix).
Is my PDF provided with the tools so unclear ? I hoped it was clear enough to explain things, but unfortunately it seems not... :(

(R,G,B) 2020 : (0.708,0.292) (0.170,0.797) (0.131,0.046)
(R,G,B) 709 : (0.640,0.330) (0.300,0.600) (0.150,0.060)
(R,G,B) 601/625 : (0.640,0.330) (0.290,0.600) (0.150,0.060)
(R,G,B) 601/525 : (0.640,0.330) (0.310,0.595) (0.155,0.070)

Values for 709/601 even if not identicals, are close enough to assume that only doing the [Non Linear RGB] <-> (matrix) <-> [YCbCr] is enough.
OETF is identical for 2020 and 709, so, going to Linear RGB, or staying at non-linear RGB will produce the same result.

hello_hello

19th August 2019, 11:35

Is my PDF provided with the tools so unclear ? I hoped it was clear enough to explain things, but unfortunately it seems not... :(

I read the pdf and took some of it in, but ultimately I copied and pasted the example in your help file and expected the result to be what the help file said it'd be.

LOL. I used the PHP button instead of the Code button, but why not... it looks a bit pretty. :)

Some example use
================

BT.2020 to BT.709 conversion, do the following:
ConvertYUVtoXYZ(Color=1)
ConvertXYZtoYUV(pColor=1)

Had this been the example, I wouldn't have wandered so far off the main path (I assume it's correct given it appears to produce the same result as a DitherTools 2020 to 709 conversion).

ConvertToYV24()
ConvertYUVtoXYZ(Color=1, Rx=0.708,Ry=0.292,Gx=0.170,Gy=0.797,Bx=0.131,By=0.046,Wx=0.3127,Wy=0.3290)
ConvertXYZtoYUV(pColor=1, Rx=0.708,Ry=0.292,Gx=0.170,Gy=0.797,Bx=0.131,By=0.046,Wx=0.3127,Wy=0.3290)
ConvertToYV12()

Intuitively, and aided by the help file example, the Color and pColor options appear to be an automatic way of specifying the correct primaries, and to be honest, the one thing that's allowing me to not feel like a complete idiot just yet, is this topic has been discussed in two threads over several days now and I've posted examples in both, and so far nobody else has said "no, you do it like this". That's a lot of typing every time you want to do a rec.2020 conversion. ;)

Now back to reading Mr. Help File again to see if I can discover what "color mode of the data" means as I'm not clear on that now. :(
Does "color mode of the data" mean "matrix"?

** ConvertYUVtoLinearRGB **
Color -
Set the color mode of the data.
0: BT2100
1: BT2020
2: BT709
3: BT601_525
4: BT601_625

Oh well, at least I appear to be making some progress now.
Thanks for your help.

jpsdr

19th August 2019, 11:50

Something is wrong here :

ConvertToYV24()
ConvertYUVtoXYZ(Color=1, Rx=0.708,Ry=0.292,Gx=0.170,Gy=0.797,Bx=0.131,By=0.046,Wx=0.3127,Wy=0.3290)
ConvertXYZtoYUV(pColor=1, Rx=0.708,Ry=0.292,Gx=0.170,Gy=0.797,Bx=0.131,By=0.046,Wx=0.3127,Wy=0.3290)
ConvertToYV12()

You put the exact same colorimetry in both, meaning for the XYZ to Linear convertion in ConvertXYZtoYUV, meaning you've said : Color is 709 (default value 2 of Color), but colorimetry parameters are those of 2020.
I think it will produce the same result as

ConvertYUVtoLinearRGB(Color=1).ConvertLinearRGBtoYUV()

pColor is juste used to define the Min/Max(ZYZ) value in 8-16 bits modes (warning page 3 of pdf). It has no other effect.
I think i'll have to update the doc of the plugin, because it's clearly obvious that i didn't explain properly the effect of the "p"(previous) parameters, and people misunderstand the purpose of it.

hello_hello

19th August 2019, 12:21

hello_hello

19th August 2019, 13:16

Okay... time to accept that fact I'm just too stupid to use this program.....
I don't mind being an idiot. It's just frustrating when you're smart enough to know you're idiot. I'm off to drink alcohol until I'm too stupid to know...

This was my previous silly. Is it some sort of mathematical co-incidence it produces the same result as a DitherTools rec.2020 to 709 conversion (which is why I thought I finally had it right)?

Silly
ConvertToYV24()
ConvertYUVtoXYZ(Color=1, Rx=0.708,Ry=0.292,Gx=0.170,Gy=0.797,Bx=0.131,By=0.046,Wx=0.3127,Wy=0.3290)
ConvertXYZtoYUV(pColor=1, Rx=0.708,Ry=0.292,Gx=0.170,Gy=0.797,Bx=0.131,By=0.046,Wx=0.3127,Wy=0.3290)
ConvertToYV12()

https://i.ibb.co/NTDdWjh/Me-Silly.png (https://ibb.co/NTDdWjh)

2020 - 601

ConvertToYV24()
Dither_convert_yuv_to_rgb(matrix="2020", slice=false)
Dither_convert_rgb_to_yuv(matrix="601", output="YV12")
ConvertToYV12()

https://i.ibb.co/nsMScmp/DT-2020-601.png (https://ibb.co/nsMScmp)

ConvertToYV24()
ConvertYUVtoXYZ(Color=1, Rx=0.708,Ry=0.292,Gx=0.170,Gy=0.797,Bx=0.131,By=0.046,Wx=0.3127,Wy=0.3290)
ConvertXYZtoYUV(Color=4, pColor=1, Rx=0.640,Ry=0.330,Gx=0.290,Gy=0.600,Bx=0.150,By=0.060,Wx=0.3127,Wy=0.3290)
ConvertToYV12()

https://i.ibb.co/k8HdtmX/xyz-2020-601.png (https://ibb.co/k8HdtmX)

2020-709

ConvertToYV24()
Dither_convert_yuv_to_rgb(matrix="2020", slice=false)
Dither_convert_rgb_to_yuv(matrix="709", output="YV12")
ConvertToYV12()

https://i.ibb.co/wwyYQKB/DT-2020-709.png (https://ibb.co/wwyYQKB)

ConvertToYV24()
ConvertYUVtoXYZ(Color=1, Rx=0.708,Ry=0.292,Gx=0.170,Gy=0.797,Bx=0.131,By=0.046,Wx=0.3127,Wy=0.3290)
ConvertXYZtoYUV(Color=2, pColor=1, Rx=0.640,Ry=0.330,Gx=0.300,Gy=0.600,Bx=0.150,By=0.060,Wx=0.3127,Wy=0.3290)
ConvertToYV12()

https://i.ibb.co/QDHZPBb/xyz-2020-709.png (https://ibb.co/QDHZPBb)