HDRTools vs DitherTools vs ColorMatrix

[TheFluff]

Try replacing npl=100 with npl=1200. No idea if I'm on the right track or not, haven't dealt with HDR much, but I have a hunch.

[manolito]

I did that, the colors are different from the original npl=100, but still not usable.

Meanwhile I tested different lossless preprocessing options, and it turned out that it does not matter if the lossless file was made with a different frame size or frame rate. Even when the lossless X264 intermediate file kept all the source properties, it did convert flawlessly to SDR using the hable tonemapping.

Could it be that current FFmpeg versions have trouble decoding some HEVC source files?


//EDIT//
Almost forgot to mention that I am using 32-bit FFmpeg exclusively. Could this have anything to do with it?

[hello_hello]

Well, so basically you wanna go from BT2100 HDR PQ to BT2020nc SDR, is that right?
But... what for? I mean, if it's for TV compatibility, then it would make much more sense to go from PQ to HLG so that both SDR TVs and HDR ones will be able to play it without compromising the original HDR too much. If it's for FULL HD SDR TV compatibility, then they won't be able to interpret the new matrix anyway so it wouldn't make sense.

Yes, now I see it that way it makes sense.

Anyway, I can definitely make a LUT from BT2100 PQ to BT2020 SDR and from BT2020nc HLG to BT2020 SDR.
As to how to use my matrices of linear transformation, it's pretty easy:

Sorry, I didn't mean to put you to any trouble, the question was rather theoretical, but thanks for the info. I'll check out the video and make time to have a play later.

EDIT: I made such a matrix: Link (https://forum.doom9.org/showthread.php?p=1897834#post1897834)

Did you do all that because I asked a silly question??

I'll have to come back to it, but I'll have a read of that post too.

Thanks a lot!

[manolito]

Followup to this previous post:
https://forum.doom9.org/showthread.php?p=1897869#post1897869

I think I figured out why some HDR sources work and others don't when trying to apply a HDR to SDR conversion with FFmpeg. The difference is the chroma subsampling of the source. Sources where MediaInfo reports:
ChromaSubsampling/String : 4:2:0
work correctly. Other sources where:
ChromaSubsampling/String : 4:2:0 (Type 2)
is reported do not work when using the source file directly as the input for FFmpeg. This applies ony for "hable" and "reinhard" as the tonemap algorithm.

I have no idea what "Type 2" means for chroma subsampling, and I have not found any quick way to get rid of it in a HDR file. But there are 2 workarounds:

If AviSynth is installed, you can use an AVS script with just the source filter as the FFmpeg input. The filter line has to be the complex one posted by Atak (developed by dipje). The simpler line posted by Tebasuna will crash FFmpeg for an AVS input.

The second workaround requires to preconvert the source to a lossless intermediate file and use this intermediate file as the input for FFmpeg.

[StainlessS]

Mani, havin' a helluva prob loading D9 webpage[or any web page] in less than 2 mins.

But see here (can also have 4:2:2 type 2).
https://forum.doom9.org/showthread.php?t=165890&page=216

EDIT:
And "ChromaSubsampling_Position": "Type 2":- https://github.com/mdhiggins/sickbeard_mp4_automator/issues/968
"ColorSpace": "YUV",
"ChromaSubsampling": "4:2:0",
"ChromaSubsampling_Position": "Type 2",
"BitDepth": "10",

EDIT: Type 2 ChromaSubsampling, U,V swapped over ???
ChromaSubsampling_Position, MPEG1, MPEG2 ???

[FranceBB]

@manolito... FFmpeg can convert from classic 4:2:0 to 4:2:0 type 2 'cause it's what I use to encode with x265 after I fed ffmpeg with Avisynth.
Avisynth -> ffmpeg 4:2:0 to 4:2:0 type2 -> x265.
In other words, if FFmpeg can do it, I'm sure it can do the opposite as well.
Unfortunately I'm gonna be stuck with my mobile only and no access to my computer whatsoever otherwise I would have pasted what I use to convert from 4:2:0 to 4:2:0 type2 in FFmpeg so that you could invert it and do the opposite.


P.s if no one else replies (I doubt it) remind me to paste my bat here after February the 8th when I'll be sitting at my desk again (in front of my computer).

[StainlessS]

Could 4:2:0 Type 2, ChromaSubsampling_Position be Progressive chroma position (matched to vertically adjacent pairs of luma scanlines, not interlaced alternate luma scanlines).
or maybe that is the ChromaSubsampling type 2 whotsit.

[FranceBB]

Did you do all that because I asked a silly question??

Well, mostly because I realized that there are some scenarios in which it could actually be useful.


MediaInfo reports:
ChromaSubsampling/String : 4:2:0
work correctly. Other sources where:
ChromaSubsampling/String : 4:2:0 (Type 2)
is reported do not work when using the source file directly as the input for FFmpeg. This applies ony for "hable" and "reinhard" as the tonemap algorithm.

I have no idea what "Type 2" means for chroma subsampling, and I have not found any quick way to get rid of it in a HDR file.


This is how I go from normal 4:2:0 to 4:2:0 type 2 and encode with x265:

ffmpeg.exe -i "avs_script.avs" -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0 -pix_fmt yuv420p16le -strict -1 -an -f yuv4mpegpipe - | x265.exe --y4m -

You can use -vf scale in ffmpeg to do the opposite and go from type2 to normal 4:2:0 (MPEG2 position); try this for BT709 with MPEG2 standard 4:2:0 chroma position:


-vf 'scale=out_color_matrix=bt709:out_h_chr_pos=0:out_v_chr_pos=128'

[manolito]

Thanks FranceBB for your advice, but I could not get it to work... :o

I added your scale parameters at the front of my usual FFmpeg call:
zscale=s=704x396,zscale=tin=smpte2084:min=bt2020nc:pin=bt2020:rin=tv:t=smpte2084:m=bt2020nc:p=bt2020:r=tv,zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv420p,colormatrix=bt709:bt601

but it did not make any difference.

[JoyBell]

I have been trying to work with DGHDRtoSDR my self as our family TV does not do HDR at all and MadVR does not look correct either. We have an HDR 4K Laser Projector as well, but for (swear words) can not get it to do HDR in Windows. Just for now want my content 4K and SDR please.


z_ConvertFormat(pixel_type="YUV420P16",colorspace_op="2020ncl:2020:2020:l=>2020ncl:2020:2020:l", dither_type="None")
DGHDRtoSDR(hue=8.0, tm=0.9, r=1.00, g=1.00, b=1.15, roll=0.7, gamma=0.42, fulldepth=true)

This does not look correct. I loaded up the HDR sample which for some reason looks much much better than the shows and movies after conversion.

This is a screen grab from the Windows HDR player (noticed the laptop set the panel brightness to insane when this ran).
https://cdn.discordapp.com/attachments/644048199845412864/679082547249938465/Samsung_Wonderland_Two_HDR_UHD_4K_Demo_HDR_Player.jpg

This is what the above code gave. Much duller.
https://cdn.discordapp.com/attachments/644048199845412864/679084119245717504/Samsung_Wonderland_Two_HDR_UHD_4K_Demo_Hable_only_612.jpg

It does tell that the DGHDRtoSDR needs an adjustment, but after months, have had no luck using Tweak or anything else in Avisynth. The HDR->SDR output always looks much darker and duller than the SDR native content.

Also adding any of the listed parameters to DGHDRtoSDR() causes an script error.

DGHDRtoSDR(mode="pq",white=1800)
gives
Script Error: DGHDRtoSDR does not have a named argument "mode"


I have no idea how to get LUTs or ColorLike or other things working.

Sorry, about the image, how to make them show reasonable size syntax would be welcome.

[FranceBB]

This does not look correct. I loaded up the HDR sample which for some reason looks much much better than the shows and movies after conversion.


It doesn't look bad though.


This is a screen grab from the Windows HDR player (noticed the laptop set the panel brightness to insane when this ran).


Of course it does, it's trying to get as many nits as possible out of your monitor. Since it's SDR (100 nits) but it's a computer, it's probably going to be around 150 nits.


Much duller.


It does tell that the DGHDRtoSDR needs an adjustment, but after months, have had no luck using Tweak or anything else in Avisynth. The HDR->SDR output always looks much darker and duller than the SDR native content.


If you want something much more bright you can try "Hable" from HDRTools as tonemapping algorithm. I don't personally like it as I think it's too strong, but again I understand that there are people who may like it.


I have no idea how to get LUTs or ColorLike or other things working.


For LUTs you can look here: https://forum.doom9.org/showthread.php?t=176091

[JoyBell]

Thanks FranceBB.
I think I managed to figure most of it out. Looks like the bright setting in DGHDRtoSDR around 150 produces results that looks like SDR Blu-ray but with better colors. This is very good. Makes sense as HDR assumes 1000 nits and that is why almost all conversions look way too dark when played on a regular monitor.

I have used the HDRTools Hable for years, and even with all the manual color tweaks always looked dull and a slight green tint that I could never correct. Thus giving up and trying to brute force with risky auto-levels functions.

Oh, my laptop is 400 nits HDR. 400 nits in my face hurts my eyes. Good times.

[videoh]

Looks like the bright setting in DGHDRtoSDR around 150 produces results that looks like SDR Blu-ray but with better colors. :confused: DGHDRtoSDR does not have a 'bright' parameter. Do you have the latest version 1.13?

[JoyBell]

:confused: DGHDRtoSDR does not have a 'bright' parameter.
It does in 1.12, which I accidently used. Can't replicate in 1.13.

[videoh]

Ah, yes. I see you have started a thread at my forum. I will follow up there.

Is there no text document in your 1.12 RAR file?

[JoyBell]

Ah, yes. I see you have started a thread at my forum. I will follow up there.

Is there no text document in your 1.12 RAR file?

I literally only have the .dll dropped into the stax apps folder. I had tried to use it last spring and gave up only to come back to it now.

[videoh]

Mr Stax could include documentation for included tools, imho.

Here is the 1.12 help file:

DGHDRtoSDR 1.12 by Donald A. Graft
---------------------------------

This Avisynth+/Vapoursynth filter converts HDR10 PQ from UHD blurays to 8-bit SDR YV12
or 10-bit SDR stored in YUV420P16. The input must be YUV420P16, e.g., from
DGSource(fulldepth=true). Support for HDR10 HLG will be added in a future version.

This filter runs on both CUDA and in software mode. If you try to run
in CUDA mode without an nVidia card and driver installed, you will get
an error. Use the parameter impl="sw" to run in software mode.

Here is a typical Avisynth+ script using default parameters:

loadplugin("dgdecodenv.dll")
loadplugin("dghdrtosdr.dll")
DGSource("hdr_sample.dgi",fulldepth=true)
DGHDRtoSDR()
prefetch(6)

Here is the Vapoursynth equivalent:

import vapoursynth as vs
core = vs.get_core()

core.std.LoadPlugin(path="DGHDRtoSDR.dll")
core.std.LoadPlugin(path="DGDecodeNV.dll")
video=core.dgdecodenv.DGSource("hdr_sample.dgi",fulldepth=True)
video=core.dghdrtosdr.DGHDRtoSDR(clip=video,fulldepth=True)
video.set_output()

The parameters are:

impl="sw" Software mode (very slow).
impl="255" Use CUDA, device is chosen automatically.
impl="0" Use CUDA on device 0 (use desired device number).
Default is "255".

fulldepth=false When set to false, 8-bit YV12 is output. When set to true,
10-bit stored in YUV420P16 is output. Use fulldepth=true if you intend to
make a 10-bit encoding. The default is false.

light=300.0 Target display brightness, lower values increase the resulting
output brightness. A good starting point is the maximum nits of your intended
display, although you may have to tweak it depending on the source mastering.
Default is 300.0.

gamma=0.42 Final gamma for the output. The default is 0.42, standard for Rec.709.

hue=0.0 Hue adjustment used to correct hue shift. Values above 0.0 shift toward red.
Values below 0.0 shift toward green. The default value is 0.0.

r=1.0 Saturation adjustment used to desaturate or resaturate red in the output.
Do not overdo it; 0.5 to 1.5 is probably the most you can get away with without
ruining colors. Values below 1.0 reduce saturation and values above 1.0
increase saturation. The default is 1.0.

g=1.0 Saturation adjustment used to desaturate or resaturate green in the output.
Do not overdo it; 0.5 to 1.5 is probably the most you can get away with without
ruining colors. Values below 1.0 reduce saturation and values above 1.0
increase saturation. The default is 1.0.

b=1.15 Saturation adjustment used to desaturate or resaturate blue in the output.
Do not overdo it; 0.5 to 1.5 is probably the most you can get away with without
ruining colors. Values below 1.0 reduce saturation and values above 1.0
increase saturation. The default is 1.15.

tm=0.9 Strength of tonemapping. Reduce this towards 0.0 to smoothly transition
to blowout (clipping) of highlights. This value controls a LERP between Reinhard
tonemapping and no tonemapping. Default is 0.9.

roll=0.7 Rolloff strength of the tonemapping. Increase this towards 1.0 to soften
and desaturate the result. The default value of 0.7 is effective at retaining
saturation and contrast. This parameter also affects overall brightness so you may
have to adjust the light parameter as needed when changing the rolloff.

Cropping and Resizing:

Often the goal is to convert to HD bluray with a size of 1920 x 1080.
And sometimes one wants to crop as well. The fastest way to do this is to
use DGSource() cropping and resizing. Following is a typical script:

loadplugin("dgdecodenv.dll")
loadplugin("dghdrtosdr.dll")
dgsource("hdr sample.dgi",crop_t=276,crop_b=276,resize_w=1920,resize_h=804,fulldepth=true)
dghdrtosdr()
prefetch(6)

Alternatively, the cropping and resizing can be done in Avisynth. Do it before
calling dghdrtosdr() for best performance. Here is a script corresponding
to the one above:

loadplugin("dgdecodenv.dll")
loadplugin("dghdrtosdr.dll")
dgsource("hdr sample.dgi",fulldepth=true)
crop(0,276,-0,-276)
spline36resize(1920,804)
dghdrtosdr()
prefetch(6)

Copyright (c) 2018 Donald A. Graft, All Rights Reserved

[JoyBell]

Thank you so much @videoh!

[real.finder]

z_ConvertFormat(colorspace_op="470bg:470bg:470bg:limited=>709:709:709:limited",dither_type="ordered")

this should be better than old

ColorMatrix(mode="Rec.601->Rec.709")

right?

[hello_hello]

real.finder,

ColorMatrix converts YV12 directly without converting to RGB and back (which is why it's not a plugin for creating color banding), and I assume z_ConvertFormat does it's thing in 16 bit otherwise it'd have banding issues. HDRTools causes lots of banding if you color convert at 8 bit.

It turns out that this is wrong:
z_ConvertFormat(colorspace_op="470bg:470bg:470bg:limited=>709:709:709:limited")

I've been experimenting with conversions via XYZ, but that shouldn't change 470bg being incorrect for transfer characteristics. The gamma is wrong.
TheFluff explained it in this post (https://forum.doom9.org/showthread.php?p=1897824#post1897824) , which I read at the time, but obviously didn't take enough in, so today I wasted lots of time trying to discover why AVSResize appeared to be messing with the luminance levels. When I eventually realised the problems all involved 470bg, aside from one caused by a typo to throw me off the track, the penny finally dropped.

For YUV, this seems to be close to having each conversion method agree. I haven't bypassed XYZ yet to see if it's better or worse. It probably doesn't matter unless a conversion to/from 2020 is involved, if at all.

AVSResize 170m-709
z_ConvertFormat(colorspace_op="170m:601:170m:l=>170m:601:xyz:l", dither_type="error_diffusion")
z_ConvertFormat(colorspace_op="170m:601:xyz:l=>709:709:709:l", dither_type="error_diffusion")

https://i.postimg.cc/pTsZJVhm/AVSResize-170m-709.png


HDRTools 170m-709
This picture is named "HDRTools-470bg-709.png" but it's really 170m-709. PostImg has been messing with the file names during uploading lately.

https://i.postimg.cc/4y90DF14/HDRTools-470bg-709.png


AVSResize 470bg-709
z_ConvertFormat(colorspace_op="470bg:601:470bg:l=>470bg:601:xyz:l", dither_type="error_diffusion")
z_ConvertFormat(colorspace_op="470bg:601:xyz:l=>709:709:709:l", dither_type="error_diffusion")

https://i.postimg.cc/x1ZtW1tM/AVSResize-470bg-709.png


HDRTools 470bg-709

https://i.postimg.cc/fbxBWKfR/HDRTools-470bg-709.png


ColorMatrix 601-709

https://i.postimg.cc/mDjjCgqx/Color-Matrix-601-709.png


DitherTools 601-709

https://i.postimg.cc/J0qWqk3b/Dither-Tools-601-709.png

If anyone's interested, there's also some 2020 conversion comparisons here.

https://postimg.cc/gallery/4Tr8RzC

[real.finder]

so for upscaling DVD (NTSC DVD) to HD

z_ConvertFormat(colorspace_op="470bg:601:170m:limited=>709:709:709:limited",dither_type="ordered")

should do it? now it's not dark like the previous one

BTW how one know the color info in DVD?

in dgindex it only has Colorimetry: BT.470-2 B,G*

[kedautinh12]

There's a 709 to 2020 up-conversion here. https://forum.doom9.org/showthread.php?p=1881624#post1881624
Everyone seems to get 601 <-> 709 right. I haven't gone back and redone any more tests to be sure, but I think the result between colorimetries was the same in both directions. If it's correct down-converting, up-converting is okay too.

The one exception was ColorMatrix converting between 709 and 2020. It appears to down-convert incorrectly but the up-conversion is okay. It might pay not to use the ColorMatrix 2020 build though. There's tried and tested 32 and 64 bit builds for HD and SD color conversions.

It appears HDTools XYZ is working correctly but I didn't know how to use it, or possible more accurately, why the results were different. There's info in this post (https://forum.doom9.org/showthread.php?p=1882350#post1882350) and the replies that follow. Keep an eye on that thread. I'm still learning....

https://forum.doom9.org/showthread.php?p=1907119#post1907119

[hello_hello]

Yeah, I'm sure ColorMatrix 709 to 2020 conversion are different to every other program (2020 to 709 seems okay). Just as bad, you can specify a conversion between 601 & 2020 (either direction) and instead of producing an error message, it does nothing.