Plugin HDRTools for Avisynth

[hello_hello]

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.

[jpsdr]

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 :

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.

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.

[poisondeathray]

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).


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._601#Primary_chromaticities

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







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

[jpsdr]

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.

[hello_hello]

Thanks jpsdr and everyone else for the answers and the help.

I think I have something approaching an understanding now.

Thanks again.

[jpsdr]

New version, see first post.

[FranceBB]

New version, see first post.

Thank you!

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! :D
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/opb/rep/R-REP-BT.2446-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.

[jpsdr]

Does anyone know where i can get some kind of "reference" video in HLG mode at 1000 cd/m² ?

[FranceBB]

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.

[hello_hello]

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)
https://i.postimg.cc/64psxdnG/upscale-only.png (https://postimg.cc/64psxdnG)

ConvertToYV24().ConvertYUVtoXYZ(Color=3).ConvertXYZtoYUV(Color=2, PColor=3).ConvertToYV12()
Spline36Resize(1280,720)
https://i.postimg.cc/G4sWR38z/colorconvert.png (https://postimg.cc/G4sWR38z)

source.mkv (https://ufile.io/h3sswnxx) (382kB)

Thanks.

[jpsdr]

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).

[hello_hello]

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()
https://i.postimg.cc/8JwDVzjj/8.png (https://postimg.cc/8JwDVzjj)

ConvertToYV24()
ConvertYUVtoXYZ(Color=4, OutputMode=1)
ConvertXYZtoYUV(Color=1, PColor=4)
ConvertBits(8)
ConvertToYV12()
https://i.postimg.cc/hJLcprn8/1.png (https://postimg.cc/hJLcprn8)

ConvertToYUV444()
ConvertBits(16)
ConvertYUVtoXYZ(Color=4)
ConvertXYZtoYUV(Color=1, PColor=4)
ConvertBits(8)
ConvertToYV12()
https://i.postimg.cc/5jn9hnCn/16.png (https://postimg.cc/5jn9hnCn)

[jpsdr]

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.

[hello_hello]

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.

[jpsdr]

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.

[jpsdr]

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.

[Atak_Snajpera]

I can't figure out why i'm getting that nasty banding and harsh cut-off in dark colors.

mediainfo
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


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)
https://i.postimg.cc/xC8fmXQp/job2-preview-avs-snapshot-05-00-2019-12-22-20-09-14.png

for comparison DGHable
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")

https://i.postimg.cc/G3ZDcCJn/job2-preview-avs-snapshot-05-00-2019-12-22-20-08-38.png

BTW ConvertXYZ_Hable_HDRtoSDR and others have the same problem.
https://i.postimg.cc/WtLTxSkx/Convert-XYZ-Hable-HDRto-SDR-exposure-x8.png

DGHable
https://i.postimg.cc/tR1PQT6z/DGHable.png

[quietvoid]

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

[jpsdr]

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.

[Atak_Snajpera]

Lhdr=30000.0 ???????? According your mediainfo it should be 1000.0. Max is 10000 anyway.

With lower value image is totally overexposed!

[jpsdr]

In that case, i think it's with others parameters you should first play/adjust (crosstalk,whiteshift, pct values), instead of putting a parameter totaly out of range/spec, but... Afterall, if it produces results you like.

I've edited my other post.

[Atak_Snajpera]

Here how frame looks with value=1000
https://i.postimg.cc/Mp132qBH/job2-preview-avs-snapshot-05-00-2019-12-23-10-48-47.png

Before adding OutputMode=2, for experiment, add Convertbits(16)
No difference. Btw. I'm using l-smash as decoder + latest avisynth+ and video is detected as YUV420p10.

UPDATE: Only outputmode=2 fixes this issue.

[jpsdr]

If no difference, at least, it means there is "no error". I didn't expect resolution loss at 16 bits... :(
In that case, add OutputMode=2 to ConvertYUVtoZXY().
You shouldn't have resolution loss in that case.

[Atak_Snajpera]

Has anybode managed to emulate madvr look using this plugin?

sample -> https://4kmedia.org/sony-camping-in-nature-4k-demo/
No matter which method I use I get either opaque white or oversaturated 4k logo

reference from madvr
https://i.postimg.cc/DZnqZXYt/a-madvr.png

BT2446 30000 (BTW. WhiteShift does nothing)
https://i.postimg.cc/Vv792kg2/a-bt2446-30000.png

Reinhard exposure=12
https://i.postimg.cc/1Xzw0ZSB/a-reinhard12.png

Mobius exposure=15
https://i.postimg.cc/sXm5Zgk1/a-mobius15.png

[Atak_Snajpera]

Ok. Mission accomplished! I've managed to emulate madvr tonemapping almost perfectly. Logo however is still slightly oversaturated. Sky gradient is also slightly different.

Emulated using Bt2446
video=ConvertYUVtoXYZ(video,Color=0,HDRMode=0,OOTF=false,OutputMode=2,Crosstalk=0.0,threads=1)
video=ConverXYZ_BT2446_C_HDRtoSDR(video,PQMode=true,Lhdr=50000.0,Lsdr=100.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,threads=1)
video=ConvertXYZtoYUV(video,Color=2,pColor=0,OOTF=false,Crosstalk=0.0,threads=1)
https://i.postimg.cc/MHBSmQrt/a-bt2446-50000-044-06-06-1-1.png

MadVR
https://i.postimg.cc/DZnqZXYt/a-madvr.png


I have also noticed that emulated method gives more realistic sky color than madvr's tonemapping
emulated
https://i.postimg.cc/05Gf4QRB/Samsung-Wonderland-Demo-ts-snapshot-01-19-944-emulated.png

Madvr
https://i.postimg.cc/KYdN638d/Samsung-Wonderland-Demo-ts-snapshot-01-19-944.png

[r4dius]

Hi, I've looking for ways to get hdr to sdr done right but still can't find how .. I'd like to get the hdr converted footage to match the existing sdr version but there's always a mismatch,
when bright colors look ok then dark stuff looks way darker and vice versa, madvr and mpv tonemapping look good but there's no method to export their tonemapped output as I understand it,
the only way I found is to exporting frame by frame (with command line options) with mpv but this thing will take ages, so I was wandering would there be a way to use the hdrtools tools to match the mpv output ?
I mean a reproducible way that would always produce the same result (or close to it) as mpv ?

[FranceBB]

Hi, I've looking for ways to get hdr to sdr done right but still can't find how .. I'd like to get the hdr converted footage to match the existing sdr version but there's always a mismatch

Of course there is! Movies are shot in log and then graded from the raw masterfile to either SDR BT709 or HDR PQ BT2100, so there's always going to be a mismatch as you will be starting from the graded HDR version whereas the SDR bluray disk were made from the original log footage. Anyway, with HDRTools you can use tonemapping algorithms which can give you pretty good results. The one that has always been working for me as a good compromise is Reinhard so you may wanna check it out from my previous posts.
Also please read the documentation and the PDF wrote by Jean-Philippe included in the plugin download which are gonna explain how this plugin works and what it does.




Totally unrelated:

Question for Jean-Philippe: is it different from the last build you sent me via email? 'cause if it isn't, I'm gonna share the images of the last test results, otherwise I'm gonna repeat those tests.

[jpsdr]

The difference is the implementation of the whiteshift, which wasn't in the version i've send you for pre-test. So, it's different in this way, but, in what was allready implemented, as far i remember there is no change.

[r4dius]

Of course there is! Movies are shot in log and then graded from the raw masterfile to either SDR BT709 or HDR PQ BT2100, so there's always going to be a mismatch as you will be starting from the graded HDR version whereas the SDR bluray disk were made from the original log footage. Anyway, with HDRTools you can use tonemapping algorithms which can give you pretty good results. The one that has always been working for me as a good compromise is Reinhard so you may wanna check it out from my previous posts.
Also please read the documentation and the PDF wrote by Jean-Philippe included in the plugin download which are gonna explain how this plugin works and what it does.




Totally unrelated:

Question for Jean-Philippe: is it different from the last build you sent me via email? 'cause if it isn't, I'm gonna share the images of the last test results, otherwise I'm gonna repeat those tests.

Merci, I've been testing a bit with your examples on this post, it's getting better but cant seem to find a perfect match yet, I'll be testing some more,
still I wonder is it not possible to extract the required values used from let's say mpv, as its result looks really good for me, and reuse them on the hdrtools ?
I mean such thing would allow more than easy conversion rather than hand picking values for each movie.

[-QfG-]

A little Test of Tonemapping from me. HDRTools is better then DGTonemap (both curves), the new ripbot x264 have good standard settings in the script. A few pictures from me, but i think DGHDRtoSDR is still the best tonemapper of Avisynth base (the best choice for me is Blackmagic DaVinci Resolve for tonemapping, via ACES). Also you con minimize the "Black Crush" Problems, if you set "fullrange=true" in the ConvertYUVtoXYZ Line.

madVR 100 Nits:
https://s19.directupload.net/images/200108/zrca7z7a.png

madVR 150 Nits:
https://s19.directupload.net/images/200108/3ykxxejb.png

madVR 200 Nits:
https://s19.directupload.net/images/200108/hjez7x52.png

HDRTools Ripbot Settings:
https://s19.directupload.net/images/200108/qqaypbaf.png

HDRTools (QfG Settings ~100 Nits):
https://s19.directupload.net/images/200108/cvvcm3l8.png

DGHDRtoSDR (QfG Setting ~100 Nits)
https://s19.directupload.net/images/200108/a3gixlys.png

DGTonemap (Hable Curve Untouched ~ 100 Nits)
https://s19.directupload.net/images/200108/9ertrccy.png

*The pictures are from a 4K HDR Upscale from me from Star Wars VII

** I Miss the spoiler function here :scared:

[jpsdr]

New version, see first post.

[hellgauss]

Thank you for this tool, I used your first example to convert BT.2020 to BT.709, with nice results.

I have some questions

Consider a video with these parameters from mediainfo

Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color pri : 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
Mastering display luminance : min: 0.0050 cd/m2, max: 4000.0000 cd/m2

From what I understand, when using ConvertYUVto***, I should set Color=1, HDRMode=0. Mastering d. color is the default one.

1) How matrix coefficients enters in the conversion? Is it important?

2) How mastering display luminance is handled in HDRmode=PQ? It seems that these value can be set only in HLG. According to https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-3-2017-PDF-E.pdf the EETF function should enter in the process?

3) I'm trying to understand how the maxcll and maxfall parameters can be calculated. In https://www.smpte.org/sites/default/files/Study%20Group%20On%20High-Dynamic-Range-HDR-Ecosystem.pdf , pag 44, the "linear values (R,G,B)calibrated to cd/m2" are the values from ConvertYUVToLinearRGB() without OOTF-1 (i.e. linear displayed data)? Has EETF any role here?

Thanks
HG

[jpsdr]

No, you're PQ => HDR => BT.2100 => color=0. In the doc, it's said that HDRMode has effect only if color=0.
From what i've understood, you have BT2020, which is SDR, and you have BT2100, which is HDR version of BT2020.
So if "Transfer characteristics" is PQ or HLG => HDR => BT2100.
I suggest you to read the ColorConversion.pdf i've provided, which explain the path and what formulas/computation this plugin uses.

1)
Matrix coefficients are the one used to convert RGB to XYZ, they are more than important, it's them which defined the convertion matrix. Any change will change the output result.

2)
In PQ, mastering display luminance is not used, as it's always 1=10000.
I didn't implement any EETF function. This is very specific and used only for a display device when it wants to display a value wich is out of his range, from what i've understood. It's not a processing step i've implemented, and for now, didn't intend to.
If i implement it one day, it will be more in an external function (and not in an inside step of a ConvertXXXtoYYY) like the HDRtoSDR functions, because in a way, it's doing something similar.

3)
As there is not the keyword displayed (it says "linear values" and not "linear displayed values"), so from my point of view, they are the (Rs,Gs,Bs) i talk in my pdf, and not (Rd,Gd,Bb), but honestly, i'm not 100% sure.
But it's a value in cd/m², so if it's PQ, just multiply by 10000, but if it's HLG, you have to know the mastering level.

[Boulder]

I'm currently experimenting with downscaling HDR sources, otherwise keeping the HDR characteristics intact. I've understood from the x265 thread that processing should be done in linear light if possible.

Is this the proper way of doing things?
ConvertYUVtoLinearRGB(color=0, outputmode=0)
xxxxResize(xxxx, yyyy)
ConvertLinearRGBtoYUV(color=0, outputmode=2)

Is the difference between outputmode=0 and 2 in the first conversion just accuracy (and speed)? I tested a short encode with both values and outputmode=0 produces a slightly larger file. I cannot tell a difference in VDub2 when interleaving the two choices.

[jpsdr]

AS said in the ReadMe :
OutputMode -
Set the output data mode.
0: No change : Input 8 Bits -> Output : RGB32, Input > 8 Bits -> Output : RGB64
1: The ouput will be RGB64
2: The ouput will be RGBPS (Planar RGB float)

So, if your input is >8bits, outputmode=2 will force output to RGPBS instead of RGB64, better accuracy but slower (didn't make speed test, so can't tell "how much" slower).
There is no other difference.
Some people said that they have banding introduced even in 16 bits when converting from/back in PQ mode (especialy in dark area), but not in float mode. So, i'll suggest outputmode=2 in the first convertion.

[real.finder]

AS said in the ReadMe :
OutputMode -
Set the output data mode.
0: No change : Input 8 Bits -> Output : RGB32, Input > 8 Bits -> Output : RGB64
1: The ouput will be RGB64
2: The ouput will be RGBPS (Planar RGB float)

So, if your input is >8bits, outputmode=2 will force output to RGPBS instead of RGB64, better accuracy but slower (didn't make speed test, so can't tell "how much" slower).
There is no other difference.
Some people said that they have banding introduced even in 16 bits when converting from/back in PQ mode (especialy in dark area), but not in float mode. So, i'll suggest outputmode=2 in the first convertion.

btw why not accept RGBP! or even RGB48!

[jpsdr]

I don't see the need of others RGB outputmode, you can add a convertion after if you want something else, it will be lossles if you keep the same bit depth.
Also, it means i have to add input support of these formats in ConvertRGBtoXXX, i don't see the point to ouput something i don't support in input in the reverse convert. Don't want to.
From my point of view, supporting RGB, RGB64 and RGPS is enough to cover all the others cases, which can be easely be done by a simple convertion from the avs core.

[real.finder]

It's called ConvertYUVtoLinearRGB, so, i only acced YUV input.
As far as i know, there is no source material as float, we are for now, at maximum 12 bits. So, as i'm lazzy, i don't intend for now to add float YUV input support.

I mean ConvertXYZtorgb https://forum.doom9.org/showpost.php?p=1880289&postcount=2

also as the output, RGBP should be faster than RGB48, RGB64

and RGB48 (with no alpha) should be faster than RGB64

[jpsdr]

Ah...:(
You answered during my post change/edit, after correcting my misunderstanding of your question.

[real.finder]

Ah...:(
You answered during my post change/edit, after correcting my misunderstanding of your question.

I don't see the need of others RGB outputmode, you can add a convertion after if you want something else, it will be lossles if you keep the same bit depth.
Also, it means i have to add input support of these formats in ConvertRGBtoXXX, i don't see the point to ouput something i don't support in input in the reverse convert. Don't want to.
From my point of view, supporting RGB, RGB64 and RGPS is enough to cover all the others cases, which can be easely be done by a simple convertion from the avs core.

what about make it just RGBP, since RGB64 is slower

0: No change : Input 8 Bits -> Output : RGBPx, Input > 8 Bits -> Output : RGBPx
1: The ouput will be RGBP16
2: The ouput will be RGBPS (Planar RGB float)

[jpsdr]

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.

[Boulder]

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 :)

[FranceBB]

I'd like to convert an SDR video (rec709) to HDR (rec2020)?
I tried feeding this directly into x265:
ConvertYUVtoXYZ()
ConvertXYZtoYUV(Color=1, pColor=2)
Am I missing something?

I don't think that's what you're doing.
Simply using


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. (https://forum.doom9.org/showthread.php?t=176091) 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:

--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:

--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

[DTL]

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/opb/rep/R-REP-BT.2390-7-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 ?

[jpsdr]

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.

[DTL]

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.

[Dogway]

Couldn't find any tool to TM without issues.

madVR
http://i.imgur.com/wjNxXZFm.png (https://i.imgur.com/wjNxXZF.png)

HDRTools

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)
http://i.imgur.com/ZYu39JPm.png (https://i.imgur.com/ZYu39JP.png)
This is with Reinhard
# Reinhard has better TM, but the exposure value is a bit random
ConvertXYZ_Reinhard_HDRtoSDR(exposure_X=28.0)
http://i.imgur.com/3hjRPiPm.png (https://i.imgur.com/3hjRPiP.png)

DGHDRtoSDR

# White Point is too cool, maybe a chromatic adaptation issue
DGHDRtoSDR(mode="pq",white=48)
ConvertBits(bits=8, dither=1)
http://i.imgur.com/loadbbQm.png (https://i.imgur.com/loadbbQ.png)


There's also heavy banding with HDRTools (EDIT: nevermind fixed adding OutputMode=2):
http://i.imgur.com/dTd69M1m.png (https://i.imgur.com/dTd69M1.png)


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

[jpsdr]

New version, see first post.

[StainlessS]

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 :) )

[FranceBB]

(you've been a busy boy/girl :) )

I'm pretty sure Jean Philippe is a dude xD

And thanx for this one too

Yep, thank you, Jean ;)