HDRTools vs DitherTools vs ColorMatrix

[FranceBB]

Originally Posted by JoyBell

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.

Originally Posted by JoyBell

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.

Originally Posted by JoyBell

Much duller.

Originally Posted by JoyBell

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.

Originally Posted by JoyBell

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]

Originally Posted by JoyBell

Looks like the bright setting in DGHDRtoSDR around 150 produces results that looks like SDR Blu-ray but with better colors.

DGHDRtoSDR does not have a 'bright' parameter. Do you have the latest version 1.13?

[JoyBell]

Originally Posted by videoh

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]

Originally Posted by 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?

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 , 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")




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.




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




HDRTools 470bg-709




ColorMatrix 601-709




DitherTools 601-709



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]

Originally Posted by hello_hello

There's a 709 to 2020 up-conversion here. https://forum.doom9.org/showthread.p...24#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 and the replies that follow. Keep an eye on that thread. I'm still learning....

https://forum.doom9.org/showthread.p...19#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.