Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 19th August 2019, 14:30   #101  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by jpsdr View Post
What is exactly your issue ?
If it's difference between dither and ConvertXYZ, it's expected, as dither is only doing matrix convertion.
My only issue was expecting that when I do the same color conversion with programs X, Y & Z (pun intended), the result should be the same. I'm not sure that's unexpected.

Even when using the same program, I don't think many people would expect completely different results from the same kind of conversion. ie XYZtoYUV vs LinearRGBtoYUV.
Don't get me wrong, I finally understand why they're so different.

So rec.2020 conversions with DitherTools are effectively wrong?

As a side question, do you know how the average TV handles rec.2020? Amongst all the reading I did yesterday I stumbled on some posts in another forum somewhere, and they were discussing how at the moment the rec.2020 colorspace is something of a "future proof" colorspace, in that no TVs today are capable of displaying much more than the rec.709 range of colors. If that's true, I guess I'm asking if I upscale a HD video to UHD and convert the colors, for it to display correctly in an UHD TV's media player, should I be using the "matrix only" method or do it "properly" with the XYZ method. I don't have a UHD TV so I have no idea, but it seems silly to be up-converting the colors with a "matrix only" method if it won't display correctly.

Edit: It also makes me wonder what the point of ConvertToRGB(matrix="Rec2020") would be if it's only doing a matrix conversion which is technically wrong.

Just trying to get this whole thing straight in my head.

Cheers.

Last edited by hello_hello; 19th August 2019 at 14:50.
hello_hello is offline   Reply With Quote
Old 19th August 2019, 15:39   #102  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
ConvertToRGB(matrix="Rec2020") is not technicaly wrong, you have RGB, but with colorimetry of BT.2020.
After, if you made all your process in RGB, and finalise with
ConvertToYV12(matrix="Rec2020"), you have nothing wrong.
(According of course your input is YUV BT.2020).

What is technicaly wrong, according R-REC-BT.2087 it's that :
ConvertToRGB(matrix="Rec2020")
ConvertToYV12(matrix="Rec709")
This also apply to dither_tools, so, also, they are not wrong.
While you stay within the same colorimetry space (all your data and your video are on the same colorimtry space), nothing is wrong with only matrix.

But when you have different colorimetry spaces :
- Either you convert everyone to the same colorimetry if you're working with datas affected by colorimetry space (or are inside a colorimetry space) (RGB, YUV).
- Either you work with datas which are unafected (or make abstraction or are outside a colorimetry space) by colorimetry (XYZ and probably others i don't know).

According your question :
Quote:
If that's true, I guess I'm asking if I upscale a HD video to UHD and convert the colors, for it to display correctly in an UHD TV's media player, should I be using the "matrix only" method or do it "properly" with the XYZ method.
I must said that i have no knowledge of broadcast or professional environment, and i'm sorry, but i don't know what to answer.
Just that, personnaly, i would follow the R-REC-BT.2087, so with XYZ method, which should, theoricaly, be the proper way.

Unfortunately, this is not helping the mess.
Quote:
Originally Posted by poisondeathray View Post
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.
__________________
My github.

Last edited by jpsdr; 19th August 2019 at 15:49.
jpsdr is offline   Reply With Quote
Old 19th August 2019, 15:55   #103  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by StvG View Post
zimg uses those values from wikipedia - https://github.com/sekrit-twc/zimg/b...ce_param.h#L28 REC_470_BG (625 lines) and SMPTE_C (525 lines/170m/240m).
My bad; I got confused by hello_hello's chart reproduction . The headings are shifted in his post

They are aligned here
https://en.wikipedia.org/wiki/Rec._6...chromaticities

And they match the ITU HEVC document and wikipedia, so false alarm




Quote:
Originally Posted by jpsdr View Post
Quote:
Originally Posted by poisondeathray View Post

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.
Unfortunately, this is not helping the mess.



Primaries aren't usually adjusted for in the 709/601 case, or you get shifted colors . The underlying premise is you should get the same colors in HD as SD when viewing

I verified this with a bunch of things, software players, NLE's, professional tools, hardware players - DVD, BD, both authored discs connected to TV , and as files, devices phones, set top media players . Also retail discs (BD and the DVD from the same studio; the same "movie" but released by different studio can have different colors), and TV broadcasts . It's entirely possible that I messed up some observations or made a mistake somewhere, but the findings are 99.9% consistent - really only the matrix is used in practice.

Note I didn't check 2020 or UHD equipment for this - it has to be rechecked
poisondeathray is offline   Reply With Quote
Old 19th August 2019, 16:44   #104  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
For 709<->601 i understand primaries are not adjusted, values are close enough to consider not necessary, and indeed, "everyone" does only matrix convertion, me also.
I though your comment was for 2020 <->709/601. Apparently i was wrong. So, for now, according the informations i have, my answer for 2020 <-> 709 is to adjust primaries.
__________________
My github.

Last edited by jpsdr; 19th August 2019 at 22:49.
jpsdr is offline   Reply With Quote
Old 19th August 2019, 18:11   #105  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Thanks jpsdr and everyone else for the answers and the help.

I think I have something approaching an understanding now.

Thanks again.
hello_hello is offline   Reply With Quote
Old 16th September 2019, 08:42   #106  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
New version, see first post.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 16th September 2019, 09:28   #107  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by jpsdr View Post
New version, see first post.
Thank you!

Quote:
Crosstalk -
Coeff for the crosstalk R,G,B matrix (for Method C of BT2446). Value 0.0 to 0.33.
Will apply a crosstalk matrix on RGB before XYZ matrix convertion.
Avoid value over 0.3 in 8 bits mode. 0.0 means no crosstalk between R,G,B.
Very useful!
I'm gonna post the link here to the relative documentation so that others can see what this is for: https://www.itu.int/dms_pub/itu-r/op...2019-PDF-E.pdf (go to page 19 if you are curious).

In particular, the crosstalk matrix is applied such that saturations of linear signals are reduced to achromatic to avoid hue changes caused by clipping of compressed highlight parts.
FranceBB is online now   Reply With Quote
Old 22nd September 2019, 10:22   #108  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
Does anyone know where i can get some kind of "reference" video in HLG mode at 1000 cd/mē ?
__________________
My github.
jpsdr is offline   Reply With Quote
Old 22nd September 2019, 16:15   #109  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by jpsdr View Post
Does anyone know where i can get some kind of "reference" video in HLG mode at 1000 cd/mē ?
You mean a sample?
Can you send me your email in PM? I could set up an FTP account for you and send you a tiny chunks original of our productions but of course you don't have to share it with anyone for whatever reason.
FranceBB is online now   Reply With Quote
Old 19th October 2019, 07:53   #110  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Could somebody please show me how to do a simple color conversion with HDRTools, minus the banding extravaganza?
The source is blocky and on the edge of banding already, so it makes the problem hard to miss.

Spline36Resize(1280,720)


ConvertToYV24().ConvertYUVtoXYZ(Color=3).ConvertXYZtoYUV(Color=2, PColor=3).ConvertToYV12()
Spline36Resize(1280,720)


source.mkv (382kB)

Thanks.
hello_hello is offline   Reply With Quote
Old 19th October 2019, 10:36   #111  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
For simple REC601 to REC709 no need to use HDRTools, the simple integrated avs functions are enough.
Otherwise, this is the proper script line.
Maybe you can try to add Output=1 in ConvertYUVtoXYZ, or, convert to 16 bits before ConvertYUVtoXYZ (and after convert down to 8 bits).
__________________
My github.

Last edited by jpsdr; 19th October 2019 at 10:38.
jpsdr is offline   Reply With Quote
Old 21st October 2019, 07:27   #112  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by jpsdr View Post
For simple REC601 to REC709 no need to use HDRTools, the simple integrated avs functions are enough.
Otherwise, this is the proper script line.
Maybe you can try to add Output=1 in ConvertYUVtoXYZ, or, convert to 16 bits before ConvertYUVtoXYZ (and after convert down to 8 bits).
I'll confess I don't understand why it's such a disaster in 8 bit. A 601 to 2020 conversion is the same (just as a test).

If there is a problem it must be the conversion from XYZ to YUV, because when the input is 8 bit, OutputMode=1 produces a fairly similar result to converting to 16 bit first. I used Tweak(Bright=25) after the conversion to make things easier to see.

Cheers.

ConvertToYV24()
ConvertYUVtoXYZ(Color=4)
ConvertXYZtoYUV(Color=1, PColor=4)
ConvertToYV12()


ConvertToYV24()
ConvertYUVtoXYZ(Color=4, OutputMode=1)
ConvertXYZtoYUV(Color=1, PColor=4)
ConvertBits(8)
ConvertToYV12()


ConvertToYUV444()
ConvertBits(16)
ConvertYUVtoXYZ(Color=4)
ConvertXYZtoYUV(Color=1, PColor=4)
ConvertBits(8)
ConvertToYV12()

Last edited by hello_hello; 21st October 2019 at 08:27.
hello_hello is offline   Reply With Quote
Old 21st October 2019, 09:12   #113  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
You have a resolution loss because of the non-linear to linear (and back after) transfert function.
Basicaly, with 8 bit, if you have something like this.
(YUV) 0 -> 0 (XYZ)
(YUV) 1 -> 0 (XYZ)
(YUV) 2 -> 1 (XYZ)
(YUV) 3 -> 1 (XYZ)
(YUV) 4 -> 1 (XYZ)
(YUV) 5 -> 2 (XYZ)
....
When you convert back XYZ to YUV, you'll have
(XYZ) 0 -> 0 (YUV)
(XYZ) 1 -> 4 (YUV)
etc...
You loose (1,2,3). Nothing can't be done, except... increase the output (XYZ here) bitdepth, to keep 8 bit resolution for the input (YUV here). But if you stay in 8 bits for all the process, you'll loose resolution, and have less than 8 bit in final result.

And effect is even worse with HDR.
__________________
My github.

Last edited by jpsdr; 21st October 2019 at 09:15.
jpsdr is offline   Reply With Quote
Old 21st October 2019, 14:20   #114  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Ahhhh.... I get it now.

Would it be a good idea for HDRTools to automatically convert to 16 bit for the conversion process and then convert back to 8 bit if required?
I guess it'd break compatibility with Avisynth 2.6, but that's probably better than "bad" conversions.

Thinking about it, DitherTools does a similar thing, only using the legacy stacked 16 bit format. I'm not suggesting you should support that, but I think it'd be better to make Avisynth+ a requirement for HDRTools than for it to appear to be doing crappy color conversions for 8 bit video. Just a thought...

Thanks.
hello_hello is offline   Reply With Quote
Old 21st October 2019, 19:23   #115  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
I'd rather keep actual status, allowing avs 2.6 to use it, but i'll had more warning in the readme (hope i'll dont forget) on next release.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 15th December 2019, 00:29   #116  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
New version (see first post), add BT2446 A and C methods for HDR to SDR.

I didn't optimize the A method because, honestly, results are bad. Maybe i didn't understood properly the method/formula or there is something wrong in my code, but i've checked and re-checked a lot of times without finding anything wrong.

The C method provide on the other hand interesting results. For those who made experiments, i suggest to first play with the "normal" adjustable parameters Crosstalk and Whiteshift, before playing with the others parameters, like pct white/skintone and others i've made avaible and adjustable, but not 100% sure they were intended to be.

If you want to use it, reading BT2446 is... mandatory if you want to understand how things works and are related to.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 22nd December 2019, 20:37   #117  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
I can't figure out why i'm getting that nasty banding and harsh cut-off in dark colors.

mediainfo
Quote:
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 10 min 0 s
Bit rate : 43.2 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.217
Stream size : 3.02 GiB (86%)
Writing library : ATEME Titan File 3.9.0 (4.9.0.0)
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0000 cd/m2, max: 1000 cd/m2
Code:
video=ConvertYUVtoXYZ(video,Color=0,HDRMode=0,OOTF=false,Crosstalk=0.0,threads=1)
video=ConverXYZ_BT2446_C_HDRtoSDR(video,PQMode=true,Lhdr=30000.0,Lsdr=100.0,pColor=0,threads=1)
video=ConvertXYZtoYUV(video,Color=2,pColor=0,OOTF=false,Crosstalk=0.0,threads=1)


for comparison DGHable
Code:
video=z_ConvertFormat(video,pixel_type="RGBPS",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:l", dither_type="none").DGHable(exposure=1.0)
video=z_ConvertFormat(video,pixel_type="YV12",colorspace_op="rgb:linear:2020:l=>709:709:709:l",dither_type="ordered")


BTW ConvertXYZ_Hable_HDRtoSDR and others have the same problem.


DGHable

Last edited by Atak_Snajpera; 22nd December 2019 at 20:43.
Atak_Snajpera is offline   Reply With Quote
Old 22nd December 2019, 21:35   #118  |  Link
quietvoid
Registered User
 
Join Date: Jan 2019
Location: Canada
Posts: 570
Looks like the same issue I came across at the very beginning: https://github.com/jpsdr/HDRTools/issues/1
Might have to rearrange to use LinearRGB instead of XYZ though. Or just add OutputMode=2 in the ConvertYUVtoXYZ() call

Last edited by quietvoid; 22nd December 2019 at 21:39.
quietvoid is offline   Reply With Quote
Old 23rd December 2019, 10:31   #119  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
Lhdr=30000.0 ???????? According your mediainfo it should be 1000.0. Max is 10000 anyway.
Same advice, add OutputMode=2 to ConvertYUVtoXYZ(), didn't expect 16 bit workflow still produce resolution loss.

Before adding OutputMode=2, for experiment, add Convertbits(16) before ConvertYUVtoXYZ(). I don't know if your source filter provide 10 or 16 bits data, and even if it provides 10 bits data it shouldn't change things, but, if there is something i've missed, it will show it.
__________________
My github.

Last edited by jpsdr; 23rd December 2019 at 10:41.
jpsdr is offline   Reply With Quote
Old 23rd December 2019, 10:37   #120  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Quote:
Originally Posted by jpsdr View Post
Lhdr=30000.0 ???????? According your mediainfo it should be 1000.0. Max is 10000 anyway.
With lower value image is totally overexposed!
Atak_Snajpera is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:18.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.