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 24th May 2020, 11:49   #141  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
Not sure RGB64 is slower, and i don't intend to start a huge work, because as i said, changing/adding output supported formats means also changing/adding supported formats input for the next filter.
This will be a long work, and i don't intend to spend time on something i think unecessary (again, you can convert lossless afterward).

Edit
Again i may have misunderstood... I mean for me not sure RGB64 is slower for the specific case of these plugins.
After, of course, for others plugins, it's another story.
__________________
My github.

Last edited by jpsdr; 24th May 2020 at 11:55.
jpsdr is offline   Reply With Quote
Old 24th May 2020, 11:49   #142  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
I just tested a 1000-frame encode,
outputmode = 0, 2.25 fps, 8825.11 kbps, avg QP 15.11
outputmode = 2, 2.26 fps, 8595.19 kbps, avg QP 14.76

Using outputmode = 2 was a tiny bit faster to encode but probably due to the lower avg bitrate. The difference in avg QP is quite big. But like I said, I cannot tell the difference in frame-by-frame comparison of the source, so it probably just stabilizes things.
What I found odd was that outputmode = 2 produces one keyframe more than outputmode = 0. I need to investigate where it is to see what's happening there
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 3rd September 2020, 13:48   #143  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
I'd like to convert an SDR video (rec709) to HDR (rec2020)?
I tried feeding this directly into x265:
Code:
ConvertYUVtoXYZ()
ConvertXYZtoYUV(Color=1, pColor=2)
Am I missing something?
I don't think that's what you're doing.
Simply using

Code:
ConvertYUVtoXYZ()
ConvertXYZtoYUV(Color=1, pColor=2)
will NOT give you any kind of HDR, you're essentially just converting from BT709 SDR to BT2020 SDR, that's it.
And of course, colors should be identical (if seen using an appropriate display) as it's SDR to SDR.
To properly encode it in x265 make sure you're setting: --colorprim bt2020 --transfer bt2020-10 --colormatrix bt2020nc and nothing else as it's not HDR, it's SDR, BT2020 SDR.

If you wanna go to "fake" HDR for any kind of reason and you wanna use HDRTools, the thing you're looking for is: ConvertXYZ_Scale_SDRtoHDR() with the appropriate parameters. Otherwise, there are always my matrices. I gotta say, though, that unlike SDR to SDR (like BT709 SDR to BT2020 SDR), if you go to HDR (namely BT2020 + a color curve) you're not gonna get an output that is identical to the input even if displayed with a proper display as you're essentially faking a color curve and HDR Metadata. This should be avoided unless you really need to. A common scenario is when you're producing something in HDR PQ or HDR HLG (like a Documentary) and you have some legacy footages to insert every now and then between interviews (and therefore you need to bring those BT709 SDR footages to HDR PQ or HLG).
Anyway, if this is NOT what you're doing, stick with BT2020 SDR.
if your final result is in PQ, make sure to specify:

Code:
--hdr-opt --hrd --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0.0050)" --max-cll 1000,400
(that's an example, you have to set master display and cll yourself according to your values)

for HDR HLG:

Code:
--hdr-opt --hrd --colorprim bt2020 --transfer arib-std-b67 --colormatrix bt2020nc --atc-sei 18 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0.0050)" --max-cll 1000,400

Last edited by FranceBB; 4th September 2020 at 10:34.
FranceBB is offline   Reply With Quote
Old 20th April 2021, 23:30   #144  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
A question about parameters for ConvertYUVtoLinearRGB : If I need to got inverse-OETF for given input system - which combination of EOTF and OOTF bools must be used ?

As I read from https://www.itu.int/dms_pub/itu-r/op...2019-PDF-E.pdf the EOTF even for old enough BT.709 is not complete inverse of OETF so resulting OOTF is not completely linear. Leaving System Gamma about 1.2.

Readme says about OOTF param:
OOTF -
Color = 0:

HDRMode = 0, 1, 2:
If set to false, the OOTF-1 step will be skipped during the linear convertion.

Color <> 0:
If EOTF is false, nothing is done whatever OOTF => Output will be standard RGB.
If OOTF is false and EOTF is true, the output will be the linear displayed data (Fd).

Default: true (bool)

For BT.709 input Color=2, so if EOTF=true and OOTF=true and Color=2 - what is output ?

Also for terms:
"Output will be standard RGB." - it mean RGB with OOTF not removed and target for displaying ?
"output will be the linear displayed data (Fd)." - it mean original true-linear RGB (inverse-OETF) ?

Or OOTF only applicable to BT.2100 (Color=0) and not applicable to BT.709 so it can not make real inverse-OETF for BT.709 to get initial true-linear data ?
DTL is offline   Reply With Quote
Old 21st April 2021, 18:03   #145  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
Don't make the same mistake than me at the begining, believing EOTF is the inverse of OETF. That's not it. Did you read the PDF i've provided with the plugin where i try to explain how it works and the paths with the functions name ?

Es = true original linear (directly from sensor)
E' = non lineard (what we are working with on our PCs).
Ed = linear displayed (what the screen displays/uses).
E' = OETF(Es)
Ed = EOTF(E')
Ed = OOTF(Es)
Again, read the PDF provided.

Standard RGB : Simple matrix conversion YUV <-> RGB, so E'.
It's not that's OOTF is not applicable, it's just that there is no one direct function. For BT.709 to have OOTF you do EOTF(OETF()).

BT.709 EOTF=true & OOTF=true you have inverse OETF, so Es.
BT.709 EOTF=true & OOTF=false you have inverse EOTF, so Ed.

From what i understood reading all the REC i list in the pdf.
__________________
My github.

Last edited by jpsdr; 21st April 2021 at 18:10.
jpsdr is offline   Reply With Quote
Old 21st April 2021, 19:01   #146  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
Oh - I found .pdf document only in the release .zip. The github files only have HDRTools - readme.txt. Now it is more sources to read. Thank you.
DTL is offline   Reply With Quote
Old 21st April 2021, 21:51   #147  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 2,352
Couldn't find any tool to TM without issues.

madVR


HDRTools

Code:
ConvertYUVtoXYZ(Color=0, OutputMode=2, HDRMode=0, fullrange=false, OOTF=false)
# Lhdr at 50000 otherwise overexposed output as pointed by someone before, Lsdr has no effect
ConverXYZ_BT2446_C_HDRtoSDR(PQMode=true,Lhdr=50000.0,Lsdr=200.0,pColor=0,pct_ref=0.6,pct_ip=0.6,pct_wp=1.0,pct_sdr_skin=1.0,pct_hdr_skin=0.44)
ConvertXYZtoYUV(Color=2,pColor=0,OOTF=false)
Converttoyuv420(interlaced=false, matrix="Rec.709")
ConvertBits(bits=8, dither=1)

This is with Reinhard
Code:
# Reinhard has better TM, but the exposure value is a bit random
ConvertXYZ_Reinhard_HDRtoSDR(exposure_X=28.0)


DGHDRtoSDR
Code:
# White Point is too cool, maybe a chromatic adaptation issue
DGHDRtoSDR(mode="pq",white=48)
ConvertBits(bits=8, dither=1)



There's also heavy banding with HDRTools (EDIT: nevermind fixed adding OutputMode=2):



By the way, it would be cool to support .measurement files made with madMeasureHDR so TM could be done dynamically.

Last edited by Dogway; 21st April 2021 at 22:02.
Dogway is offline   Reply With Quote
Old 30th April 2021, 15:32   #148  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
New version, see first post.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 30th April 2021, 16:23   #149  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
And thanx for this one too, and the other one [EDIT: two, EDIT: three] I aint comented on. (you've been a busy boy/girl )
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 30th April 2021 at 16:33.
StainlessS is offline   Reply With Quote
Old 30th April 2021, 19:06   #150  |  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 StainlessS View Post
(you've been a busy boy/girl )
I'm pretty sure Jean Philippe is a dude xD

Quote:
And thanx for this one too
Yep, thank you, Jean
FranceBB is offline   Reply With Quote
Old 30th April 2021, 20:05   #151  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
Yes, i'm a dude.

Almost everything was allready done, but i wanted to finish fixing the aWarp4 issue before releasing new builds.
I was waiting to have time to investigage it, and this is my first day of my holydays, so i finaly got the time, and also i wanted to "get rid of it", to be quiet for the rest of my holydays...
__________________
My github.
jpsdr is offline   Reply With Quote
Old 30th April 2021, 21:59   #152  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
OK dude, have a nice holiday.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline   Reply With Quote
Old 1st May 2021, 10:47   #153  |  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
i wanted to "get rid of it", to be quiet for the rest of my holydays...
Smart move. Enjoy your vacation
FranceBB is offline   Reply With Quote
Old 30th May 2021, 17:57   #154  |  Link
Hotte
Registered User
 
Join Date: Oct 2014
Posts: 209
I have some more general, simple questions concerning HDR.

My camera allows me to record in Rec.2020 (HLG) or Rec.709 while shooting in 10-bit modes. As far as I understood the idea of colorspaces, BT.2020 also covers colors outside 709 hence a larger visible colorspace if I have the right monitor. Although I have an sRGB-display I might be going for a HDR-Monitor in the near future to participate.

So I thought it is a good idea to start recording everything new in HLG rather than keep on shooting in 709.

But:

Isn't HDR only a mapping of colors rather than a quality push ? Could I e.g. remap rich 10-bit footage captured in 709 to become satifying HDR if needed (maybe using HDR-Tools) ?

Or is the chance for HDR gone if it was not recorded in BT.2020 right from the start ?

Generally I found it hard to get satisfying 709 results from HLG source: The colors, especially red spectrum ist somewhat out of balance and I have not found any approach yet to cure this.

What would you recommend ?

Last edited by Hotte; 30th May 2021 at 18:05.
Hotte is offline   Reply With Quote
Old 30th May 2021, 21:12   #155  |  Link
videoh
Useful n00b
 
Join Date: Jul 2014
Posts: 1,667
Quote:
Originally Posted by Hotte View Post
Isn't HDR only a mapping of colors rather than a quality push ? Could I e.g. remap rich 10-bit footage captured in 709 to become satifying HDR if needed (maybe using HDR-Tools)?
"quality push"? "rich"? "satisfying"?

Bit depth is independent from color space, but BT2020 is usually chosen for HBD.

Quote:
Generally I found it hard to get satisfying 709 results from HLG source: The colors, especially red spectrum ist somewhat out of balance and I have not found any approach yet to cure this.

What would you recommend ?
Post a link to the problematic HLG source video.
videoh is offline   Reply With Quote
Old 30th May 2021, 22:09   #156  |  Link
Hotte
Registered User
 
Join Date: Oct 2014
Posts: 209
Quote:
Originally Posted by videoh View Post
"quality push"? "rich"? "satisfying"?
Bit depth is independent from color space, but BT2020 is usually chosen for HBD.
I am clear about bit depth being independent from colour space.

The essence of my question was if I should always record my 10-bit modes in BT2020 to be future-proof.

Currently I am on Rec709 (monitor, projector...). Recording everything in BT2020 today would mean conversion down to 709 which probably comes with some compromise.

Also the HLG-setting in my cam does not allow me to use a flat log-profile. Or is a flat profile not needed anymore with HDR ?

Or is there a way up from recorded Rec709 to BT2020 ?

Sorry, maybe silly questions. I just want to make sure I am going into the right direction.

Last edited by Hotte; 30th May 2021 at 22:16.
Hotte is offline   Reply With Quote
Old 31st May 2021, 16:41   #157  |  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 Hotte View Post
The essence of my question was if I should always record my 10-bit modes in BT2020 to be future-proof.
Yes


Quote:
Originally Posted by Hotte View Post
Currently I am on Rec709 (monitor, projector...). Recording everything in BT2020 today would mean conversion down to 709 which probably comes with some compromise.
Yes, you would have to convert, but I would strongly suggest not to shoot in Linear BT709 SDR 100 nits in 2021 especially if the camera has far more stops than 6 stops which is 100 nits 'cause you would be wasting the sensor capacity otherwise... Also BT2020 alone won't achieve anything, it's just a color matrix, what's important is the color curve, in this case HLG which will allow you to record as many nits as the stops of the sensor.


Quote:
Originally Posted by Hotte View Post
Also the HLG-setting in my cam does not allow me to use a flat log-profile. Or is a flat profile not needed anymore with HDR ?
Ok, a bit of confusion.
BT709 and BT2020 are just matrices, those are color matrices and both are SDR 100 nits. Sure, BT2020 would give you a better result, but you're still gonna be limited to 6 stops, 100 nits SDR, so, if you shoot a subject with the sky behind and sunlight, either the subject will be lit and the sky clipped out and white averaged out at 940 or the sky is gonna be there and the subject is gonna be totally dark 'cause you still have only 6 stops, 100 nits.
Now, when it comes to color curve, those give you "HDR" aka "High Dynamic Range". Now, I don't know which camera you have and you didn't specify which log you're shooting in, so I'm gonna assume Slog3 for the sake of the argument.
If you compare Slog3 vs HLG, both have their pro and cons. You gotta remember that HLG is not a purely logarithmic color curve, therefore it starts just like a normal linear SDR curve and then it slowly curves and becomes logarithmic, which means that the blacks won't have many details and they're gonna be just like the SDR ones, but the more you "go up" the more logarithmic you get, so the highlights are gonna be preserved and you're gonna get more nits (up to 1000 nits, although I strongly doubt that your camera will reach that and it's gonna sit probably around 600-700). The reason why HLG is an "Hybrid Log Gamma" (emphasis on "hybrid") is that it allows backwards compatibility with SDR monitors and decoders who ignore the color curve and just interpret the color matrix. Of course, this "sacrifices" the details in the black 'cause you won't get anything more than shooting in SDR in the blacks. This is NOT true for Slog3, though. Just like other purely logarithmic curves like Clog3, Log-C, PQ etc, it starts logarithmic and continues as logarithmic, therefore you're gonna have many more nits available and you'll have many more details in the blacks as well. Cameras nowadays (assuming you're not using a Red Monstro or something insanely pricey and bleeding edge) sit around 700 nits anyway, so you won't have more details in the highlights using a purely logarithmic color curve anyway (even if they can go up to 10'000 nits) but you will get more details in the blacks as they start logarithmic and not linear. The "problem" with this is that this way you're literally getting as many frequencies as the sensor can get and many sensors do a fairly BAD JOB with dark/black areas, so the details you're gonna get are very likely going to be full of combing in the chroma and noise in the luma anyway. Nonetheless, if you ask me, from a purely mathematical point of view, it's better to shoot in a purely logarithmic color curve. That being said, I would suggest you to shoot in HLG for your use case and perform a linear transformation with a matrix like a custom made LUT in Davinci or any NLE to bring it to Linear BT709 SDR so that you can pick which frequencies are gonna be kept and which other are gonna be cut or kneed down to SDR. I also suggest you to archive the HDR HLG BT2020 master for future use. The reason why I'm suggesting you this is that *some* cameras that were produced in the middle of a "transition" only allow purely logarithmic curves with the BT709 matrix but not BT2020. This historically has a reason: when PQ and HLG were not yet invented camera manufacturers were already able to shoot with more than 6 stops 100 nits, so they invented their own color curves: Sony invented Slog, Canon invented Clog, Arri invented LogC, Fuji invented FLog etc and they did that with the only color matrix that was available at the time: BT709. Some manufacturers were quick to catch up and allow to record in Log with BT2020 (BT2100) as well, but some others were not, therefore:

- If your camera allows you to shoot log in BT2020 (BT2100), then do that and then apply a matrix to go to BT709 SDR and archive the original master. The SDR you're gonna get is gonna be far better than anything you can get by shooting in SDR directly from the camera.

- If your camera allows you ONLY to shoot log in BT709 but allows you to use BT2020 for HLG, then shoot in HLG BT2020 HDR, archive the original master and then use a matrix to bring it to Linear BT709 SDR. The SDR you're gonna get is STILL gonna be far better than anything you can get by shooting in SDR directly from the camera, at least in the highlights.


p.s also remember that purely logarithmic curves are NOT backwards compatible with SDR.


I hope this cleared the confusion a bit and helped you pick the correct profile.

Cheers,
Frank



Side note: Oh, I almost forgot: HDRTools from Jean Philippe currently only supports PQ and HLG but not other curves, so using it for Slog1, Slog2, Slog3, Clog1, Clog2, Clog3, LogC, FLog, DLog etc is out of question.
Side note 2: A personal appeal to Jean Philippe -> if you wanna introduce support for them as well and you need to work out how they work along with samples I can provide them to you via FTP, just like we've done back when we were testing BT2446 in 2019. You know, I'm always here, buddy

Last edited by FranceBB; 31st May 2021 at 17:11.
FranceBB is offline   Reply With Quote
Old 31st May 2021, 17:56   #158  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,308
So much................?????????????? Fleeing (with Benny Hill music)...
__________________
My github.
jpsdr is offline   Reply With Quote
Old 2nd June 2021, 01:04   #159  |  Link
videoh
Useful n00b
 
Join Date: Jul 2014
Posts: 1,667
Quote:
Originally Posted by jpsdr View Post
Fleeing (with Benny Hill music)
Me too.
videoh is offline   Reply With Quote
Old 2nd June 2021, 09:15   #160  |  Link
Hotte
Registered User
 
Join Date: Oct 2014
Posts: 209
very much, Frank. This makes me learn a lot.

(To be honest: I had seen you being active in this thread and I hoped, that you would contribute with your excellent knowledge and the ability to explain complicated things from scratch in a very understandable manner).

I would like to discuss this a bit further, but I saw too late this is the developer's chatroom (it is where the search engine sent me to), and maybe continuation is inappropriate here. If so, just say and I am happy to move elsewhere. However I think that a broader community benefits a lot more from sophisticated discussions here if some basics are being explained from time to time.

I`ve got a Panasonic G9 which can (latest firmware) record 10-bit YUV422 BT.2020 with HLG-profile available. My Edius-X shows the footage as BT.2020 explicitly with "BT.2100 HLG"-gamma curve. It is HEVC-coded. There is an ultraflat VLOG-L profile available for 100$ extra. They say it increases DR by 2 f-stops to 12 f-stops.

Question 1: As far as I understood you, there is no need to go for a VLOG-L profile: If I am doing it right, I will be able to squeeze all available shadow-DR out of the HLG master too if needed. Correct ?

Question 2: The "Primary Color Correction"-Filter in Edius allows me to apply LUTs and conversions. Leaving Input and Output in HLG results in this well described flat, colorless look on my calibrated Rec709-Monitor. The question is, why then HLG in some way is told to be "Rec709-compatible" if it looks so unnaturally washed out ?

Question 3: If I apply BT2020 / BT.2100 Input and Rec709 output in the PCC-Filter it looks much better. But still the greens and reds are not fully convincing and it is difficult to get the midtones into some harmonic balance. I`d say you achieve acceptable but not really good results. I thought BT2020/BT.2100 as well as rec709 are standard profiles so why are colors and tones getting messed up like this ?

Question 4: Is HDRTools something to improve this or do I have to take the hard track of trying out numerous LUTs until I find sth convincing ?

Last edited by Hotte; 2nd June 2021 at 10:30.
Hotte 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 12:42.


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