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. |
19th August 2019, 14:30 | #101 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
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. |
|
19th August 2019, 15:39 | #102 | Link | |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
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:
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.
__________________
My github. Last edited by jpsdr; 19th August 2019 at 15:49. |
|
19th August 2019, 15:55 | #103 | Link | ||
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
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:
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 |
||
19th August 2019, 16:44 | #104 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
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. |
16th September 2019, 09:28 | #107 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
|
Thank you!
Quote:
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. |
|
22nd September 2019, 16:15 | #109 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
|
Quote:
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. |
|
19th October 2019, 07:53 | #110 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
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. |
19th October 2019, 10:36 | #111 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
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. |
21st October 2019, 07:27 | #112 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
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. |
|
21st October 2019, 09:12 | #113 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
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. |
21st October 2019, 14:20 | #114 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
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. |
15th December 2019, 00:29 | #116 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
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. |
22nd December 2019, 20:37 | #117 | Link | |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,816
|
I can't figure out why i'm getting that nasty banding and harsh cut-off in dark colors.
mediainfo Quote:
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
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper Last edited by Atak_Snajpera; 22nd December 2019 at 20:43. |
|
22nd December 2019, 21:35 | #118 | Link |
Registered User
Join Date: Jan 2019
Location: Canada
Posts: 574
|
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. |
23rd December 2019, 10:31 | #119 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
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. |
23rd December 2019, 10:37 | #120 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,816
|
With lower value image is totally overexposed!
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
|
|