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, 15:30   #101  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 3,978
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 15:50.
hello_hello is offline   Reply With Quote
Old 19th August 2019, 16:39   #102  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,758
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 16:49.
jpsdr is offline   Reply With Quote
Old 19th August 2019, 16:55   #103  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,975
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, 17:44   #104  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,758
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 23:49.
jpsdr is offline   Reply With Quote
Old 19th August 2019, 19:11   #105  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 3,978
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, 09:42   #106  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,758
New version, see first post.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 16th September 2019, 10:28   #107  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Germany
Posts: 669
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.
__________________
Broadcast Encoder
Avisynth memes: 1 - 2 - 3
Videotek - Audacity XP
FranceBB is offline   Reply With Quote
Old 22nd September 2019, 11:22   #108  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,758
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, 17:15   #109  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Germany
Posts: 669
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.
__________________
Broadcast Encoder
Avisynth memes: 1 - 2 - 3
Videotek - Audacity XP
FranceBB is offline   Reply With Quote
Old 19th October 2019, 08:53   #110  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 3,978
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, 11:36   #111  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,758
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 11:38.
jpsdr is offline   Reply With Quote
Old 21st October 2019, 08:27   #112  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 3,978
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 09:27.
hello_hello is offline   Reply With Quote
Old 21st October 2019, 10:12   #113  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,758
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 10:15.
jpsdr is offline   Reply With Quote
Old 21st October 2019, 15:20   #114  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 3,978
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, 20:23   #115  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,758
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
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 07:55.


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