HDRTools vs DitherTools vs ColorMatrix

[TheFluff]

The helpfile should have a huge warning that says "don't use colormatrix", instead.

[manolito]

Originally Posted by hello_hello

Looking back at the original ColorMatrix 2.6 thread it seems it was only intended to support conversions to/from rec.2020 and rec.709,

Couldn't one chain two ColorMatrix calls so it first converts REC.2020 to REC.709, then the second call converts from REC.709 to REC.601 ?

And a general question:
For converting a REC.2020 UHD clip to DVD, is it really enough to change the colorimetry to REC.601? Or is some additional tone mapping required?

[hello_hello]

Originally Posted by manolito

Couldn't one chain two ColorMatrix calls so it first converts REC.2020 to REC.709, then the second call converts from REC.709 to REC.601 ?

I guess so, but it still should produce an error when trying to convert between rec.2020 and rec.601 and I'm pretty sure the rec.2020 to rec.709 conversion is wrong anyway. It's different to DitherTools and HDRTools (when HDRTools is doing a linearRGB conversion).

Originally Posted by manolito

And a general question:
For converting a REC.2020 UHD clip to DVD, is it really enough to change the colorimetry to REC.601? Or is some additional tone mapping required?

Sorry if some of this is stuff you already know. I imagine it is, but just to be thorough....

Have a look at the samples attached to my previous post and the color difference between the ColorMatrix/DitherTools matrix-only conversions, and HDRTools converting both the matrix and the color primaries.
The HDRTools conversions look wrong because I used a rec.709 source and it's being displayed using rec.601, but the author of HDRTools says that's the correct way to convert to/from rec.2020, although HDRTools will do a matrix-only conversion too.

I don't have anything that understands the rec.2020 primaries to do a real comparison, but you can maybe get away with a matrix-only conversion when upscaling HD content and encoding with something like x264 while specifying rec.709 as the color primaries and rec.2020 for the color matrix in the command line, and if a player pays attention to that sort of thing it'd probably display correctly, but then again you could just upscale without converting anything while specifying rec.709 for both the primaries and the matrix, and it should display correctly if a player pays attention, much like you can specify rec.709 for both when downscaling HD to SD.

When downscaling from UHD though, if the source is rec.2020 and you didn't convert anything, but just specified rec.2020 for the primaries and matrix, you'd have to be using a player/TV that understands them for it to display correctly. Likewise if you did a matrix only conversion from rec.2020 to rec.709, you'd have to specify rec.709 for the color matrix and rec.2020 for the primaries and once again the player/TV would have to understand the rec.2020 primaries and use the rec.709 matrix on playback.

When downscaling UHD to HD/SD and encoding with a codec or using a player that's oblivious to rec.2020, I don't know how it could display correctly unless you converted both the matrix and color primaries, as the rec.2020 primaries are vastly different to rec.709/rec.601.

Even rec.709 and rec.601 NTSC and rec.601 PAL all use slightly different color primaries, but they're so similar you can get away with a matrix-only conversion. Rec.709 and rec.601 PAL use the same red and blue primaries, while green is a little different. From memory rec.601 NTSC uses different color primaries for each, but red and blue are pretty close to rec.601 PAL/rec.709. Rec.709 was some sort of compromise between PAL and NTSC. It's green color primary sits halfway between the PAL and NTSC green color primaries.

Technically I should be referring to 525 line and 625 line, not PAL or NTSC.

Try doing a color conversion with CropResize. The options are:

ColorCorrect=1 - ColorMatrix to/from rec.709/rec.601, matrix only.
ColorCorrect=2 - DitherTools to/from rec.709/rec.601, matrix only.
ColorCorrect=3 - HDRTools converting the primaries and matrix. 525 line for the rec.601 primaries.
ColorCorrect=4 - HDRTools converting the primaries and matrix, 625 line for the rec.601 primaries.

HDRTools conversions require AVisynth+ so they can be done in 16 bit, otherwise the output can show color banding.

A matrix-only conversion using DitherTools would look like this:
CropResize(ColorCorrect=2, ColorMode="709-601")

The same conversion converting the primaries too:
CropResize(ColorCorrect=3, ColorMode="709-601")
or
CropResize(ColorCorrect=4, ColorMode="709-601")

You'll sometimes see a slight difference between the methods, so naturally it'd be huge for rec.2020 conversions because the green and red rec.2020 primaries are outside the sRGB color gamut used by rec.709 and rec.601, if memory serves me correctly.
https://upload.wikimedia.org/wikiped...1_Rec_2020.svg
https://upload.wikimedia.org/wikiped...31_Rec_709.svg

The one thing I'm not sure of is what happens when a rec.2020 source is actually using a wider color gamut than is supported by rec.709/601 and you convert between them (given that was the whole point of rec.2020). I assume the out of range colors must be clipped. I guess that's what happens when you watch rec.2020 video on a rec.2020 display that can only produce RGB colors anyway (probably most of them as most displays are RGB), or maybe the display would try to do some sort of clever color adjustment.

I think if you're using a player/codec that understands rec.2020 and will obey the specified color primaries and matrix, you'd possibly be better off downscaling without converting anything.

[manolito]

Thanks hello_hello for this detailed explanation.

I did know a few things you mentioned already, but since I am not interested in this UHD stuff personally I do not intend to dig into it too deeply. The reason I got into it is that a friend had an UHD clip that he wanted to watch on his notebook and on his TV, and on both the colors looked unacceptable. AFAIK his TV is a Full HD capable LCD, but no UHD, no 4k, no HDR. He asked me if I could convert the clip to SD resolution, either MPEG2 or AVC, and fix the colors in the process.

So I downloaded a few demo clips from 4kmedia.org, for testing I used the LG New York demo.

Just converting the matrix from BT.2020 to BT.601 did not do much, so I started reading. I ended up using the DGHDRtoSDR tool because it seemed pretty easy to use, and it got very good reviews. The conversion looked pretty good to me (after reducing the blue satuaration a little), but I have a few questions. I used this script:

Audio = LWLibavAudioSource("MySourceFile", stream_index=-1)
Video = LWLibavVideoSource("MySourceFile", stream_index=-1, format="YUV420P16", seek_mode=0).ChangeFPS(25)

Video = Video.Spline36Resize(720,576)
Video = Video.DGHDRtoSDR(mode="pq")
Video = Video.ConvertToYV12(matrix="rec601")

AudioDub(Video, Audio)

Does DGHDRtoSDR do any matrix conversion by itself? The readme does not mention anything about this. If not, is it enough to use the matrix="rec601" parameter in the ConvertToYV12 call? Or do I need to use a different tool for converting the matrix?

I doubt that I could convince my friend to learn AviSynth or VapourSynth, but he may bite if I can give him a working FFmpeg command line which he could easily edit for his needs. I found some examples on the Web, I will have to do more tests tonight and compare the FFmpeg results to DGHDRtoSDR.

[hello_hello]

I'd not heard of DGHDRtoSDR until now. Probably because I have no real interest in 4K or UHD or HDR myself.

I had a play, but I think those questions are really for videoh to answer. Best as I can tell it's purpose is purely to convert HDR to SDR, so I guess it's also designed to work with rec.2100 sources. It's not clear to me if it also converts the colorimatery in the process.
My guess is it doesn't, because rec.2100 supports a 1920x1080 resolution (the resolution mentioned in the help file) and there's no mention of coloriimtery in the help file, so after using it you'd probably have to do an additional rec.2020 to rec.709/601 conversion if that's where you want to end up, and I'd imagine you'd need to be able to display rec.2020 correctly so as to get the HDR to SDR conversion right first, or at least follow it with a conversion to rec.709/601 in the script if you can't display rec.2020 correctly.

For ConvertToYV12(matrix="rec601"), the matrix option only works when the source is RGB (as far as I know) so for a YUV source, to do a matrix-only conversion with Avisynth+ it'd be:

ConvertToRGB(matrix="rec2020")
ConvertToYV12(matrix="rec601")

You'd probably want to do it in 16 bit or there'll be a good chance of banding. That's the advantage of ColorMatix.dll. It converts the YUV colors without going through an RGB conversion first, so it doesn't produce much/any banding. DitherTools does it by converting to RGB first, but in stacked 16 bit. HDRTools can do it in 8 bit but it converts to RGB first for a matrix-only conversion, or to XYZ first in order to convert the primaries too, so it tends to result in lots'o'banding unless you convert to 16 bit first.

Using Avisynth to convert the matrix is obviously a matrix only conversion. I suspect for the correct colors if you want to convert to rec.601 you should convert the color primaries too, but that's really just my guesses.

I'll try to find and download the source you mentioned previously and play around later on to see if I can convert it to look satisfactory using rec.709 for playback on my PC and I'll let you know if I discover anything interesting.

[manolito]

Did a few more AVS based tests using AVStoDVD.

All tests were done with my previous script with the exception that I added the "b=1.0" parameter to the DGHDRtoSDR call (with the default the blue was way too much "in your face" for my taste).

Using the ConvertToYV12(matrix="rec601") command did make a difference compared to leaving out the matrix parameter. File size and encoding speed were different, I just could not see any visual difference. With two ColorMatrix calls there was a slight visual difference, but nothing where I could say that one or the other looked better.

I uploaded the results here:
https://www.sendspace.com/file/nqeh05

Maybe you got better eyes or a better monitor than I do.

Anyways, next thing I will do is testing some FFmpeg parameters for HDR to SDR conversions...

[videoh]

Of course DGHDRtoSDR converts from 2020 to 709! Tempted to add "duh".

Will look at the rest of the thread and answer any other questions I see.

[videoh]

Originally Posted by hello_hello

It's not clear to me if it also converts the colorimetry in the process. My guess is it doesn't...

Wrong.

[manolito]

Originally Posted by videoh

Of course DGHDRtoSDR converts from 2020 to 709! Tempted to add "duh".

But my target format is DVD, so I need 601 instead of 709. So I need to do this manually after the DGHDRtoSDR call?

[hello_hello]

Thanks manolito, you helped me find a problem with the CropResize script. I'd added a line for testing and forgotten to remove it, causing HDRTools to throw an error when converting the colors if the source bitdepth was greater than 8.

Here's what I tried with the sample you mentioned. The first encode converted the HDR to SDR and the the colors from rec.2020 to rec.601 including the primaries. I'm not claiming the HDR to SDR conversion is perfect because I just went with the example in the help file.

FFVideoSource("E:\LG New York HDR UHD 4K Demo.mkv", threads=1)
CropResize(720,576, OutDAR=16.0/9.0)
ConvertBits(16)
DGHDRtoSDR(mode="pq",white=1800, impl="sw")
CropResize(NoResize=true, InDAR=16.0/9.0, ColorCorrect=4, ColorMode="2020-601")
ConvertBits(8)

New York HDR to SDR 2020 to 601.mkv

Same again, minus the color conversion.

FFVideoSource("E:\LG New York HDR UHD 4K Demo.mkv", threads=1)
CropResize(720,576, OutDAR=16.0/9.0)
ConvertBits(16)
DGHDRtoSDR(mode="pq",white=1800, impl="sw")
ConvertBits(8)

New York HDR to SDR.mkv

The version without the rec.2020 to rec.601 color conversion looks better to me, so now I'm just annoyed and confused. Maybe being a demo, the colors are intentionally crap, as in-store demos tend to be, and not converting the colors has functioned as an un-crapper. I don't know.... I expected the result to be effectively the opposite. I double checked the color conversion in the script and I'm sure it's okay. Tomorrow, when I'm less annoyed and confused I might try again using a different source.

Edit: The samples above will download with the names "New York HD to SD 2020 to 601" and "New York HD to SD" when I should have named them "New York HDR to SDR 2020 to 601" and "New York HDR to SDR". Doh!

[hello_hello]

Originally Posted by videoh

Wrong.

I'm so unbelievably glad to be wrong. Now I'm no longer annoyed and confused, although I'm not sure how it's even remotely obvious that it does a conversion to rec.709. I don't recall seeing colorimetry get a mention in the help file.

[hello_hello]

Originally Posted by manolito

Using the ConvertToYV12(matrix="rec601") command did make a difference compared to leaving out the matrix parameter. File size and encoding speed were different, I just could not see any visual difference.

That seems odd.
http://avisynth.nl/index.php/Convert

string matrix = "Rec601"
Controls the colour coefficients and scaling factors used in RGB↔YUV conversions.

Downloading your samples for a look-see now.

[hello_hello]

Trying again.

FFVideoSource("E:\LG New York HDR UHD 4K Demo.mkv", threads=1)
CropResize(720,576, OutDAR=16.0/9.0)
ConvertBits(16)
DGHDRtoSDR(mode="pq",white=1800, impl="sw")
CropResize(NoResize=true, InDAR=16.0/9.0, ColorCorrect=1, ColorMode="709-601")
ConvertBits(8)

New York HDR to SDR 709 to 601.mkv

manolito,
Your conversion labelled ColorMatrix(source=4,dest=0).ColorMatrix(source=0,dest=2).mpeg looks a bit odd. I guess I led you astray there. I blame it on the lack of information in the help file.
The other two do look exactly the same. I don't know why encoding speed would have been different.

PS I'm still dubious about using Colormatrix for a rec.2020 to Rec.709 conversion anyway, but if you compare that encode to mine labelled "New York HDR to SDR 2020 to 601.mkv", even though they both tuned out to be wrong in respect to converting the colors unnecessarily, I guess they're something of an example of the difference between converting the color primaries and not converting them.

Ignoring the fact we now know it's an unnecessary color conversion, here's the difference between Colormatix and DitherTools (both matrix only conversions).

No Conversion



ColorMatrix(mode="rec.2020->rec.709")



Dither_convert_8_to_16()
Dither_convert_yuv_to_rgb(matrix="2020", output="rgb48y", lsb_in=true)
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv(r, g, b, matrix="709", lsb=false, mode=0)

[videoh]

Originally Posted by hello_hello

I'm not sure how it's even remotely obvious that it does a conversion to rec.709.

When one is clueless it behooves one to do basic research, including reading the relevant threads for the tools:

https://forum.doom9.org/showthread.p...84#post1847484

[FranceBB]

Sorry if I jump into the topic, but...
Manolito, out of curiosity, would you like me to make an HDR HLG BT2020nc to BT601 SDR and HDR PQ BT2100 to BT601 SDR matrix of linear transformation to add to my LUT collection?
I actually never thought about it 'cause I didn't think it was useful, but if it is useful to someone, I can do it. After all, BT601 is pretty close to BT709 so it shouldn't be too hard...


As to the others, I've been using DGHDRtoSDR with good results when I had to tone-map the studio master of Riviera here: Link
And of course it converted from from BT2100 HDR PQ to BT709 SDR.
The only catch is that it only works in 4:2:0 planar. Since Donald is here reading the topic I take the chance to ask him: will you add 4:2:2 planar and 4:4:4 planar support in the future?

[videoh]

Originally Posted by FranceBB

The only catch is that it only works in 4:2:0 planar. Since Donald is here reading the topic I take the chance to ask him: will you add 4:2:2 planar and 4:4:4 planar support in the future?

It's certainly something I could do. May I ask what source filter you using to deliver 4:2:2 and 4:4:4? A sample script would be helpful.

[manolito]

@ FranceBB

Manolito, out of curiosity, would you like me to make an HDR HLG BT2020nc to BT601 SDR and HDR PQ BT2100 to BT601 SDR matrix of linear transformation to add to my LUT collection?

I'm sorry, but this would be way over my head.


@videoh
Thanks for the link to this old post, but such posts are not easy to find at Doom9. Neither me nor hello_hello found it, so it would be really nice if you could add this internal workflow to the readme...


@ all
I tested some FFmpeg parameters for this conversion. A complex version posted by Atak and a simpler one posted by Tebasuna. Easy to use, I just pasted it into the "more video filters" field in dmMediaConverter. My head is spinning from comparing the results. They all look a little different, but no idea which one is more correct or better...

You can download the results here:
https://www.sendspace.com/file/xjkl0j


Here are the scripts or parameters I used:

For AviSynth:

Audio = LWLibavAudioSource("MySourceFile", stream_index=-1)
Video = LWLibavVideoSource("MySourceFile", stream_index=-1, format="YUV420P16", seek_mode=0).ChangeFPS(fps)

Video = Video.Spline36Resize(720,576)
Video = Video.DGHDRtoSDR(mode="pq", b=1.0)
Video = Video.ColorMatrix(source=0,dest=2)
Video = Video.ConvertToYV12()

AudioDub(Video, Audio)

FFmpeg (Atak version)

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

FFmpeg (Tebasuna version):

zscale=s=704x396,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

These parameters are easy to modify for HD output. Edit the "zscale" parameter for the desired size and remove the "colormatrix" parameter.

//EDIT//
I forgot to mention that the FFmpeg parameters are meant to be inserted in dmMediaConverter. If you want to use them in an existing FFmpeg commandline you need to add them as a video filter and enclose the parameters in double quotes. like:
-vf "parameter list"


Cheers
manolito

[videoh]

Originally Posted by manolito

Thanks for the link to this old post, but such posts are not easy to find at Doom9. Neither me nor hello_hello found it, so it would be really nice if you could add this internal workflow to the readme...

Search for DGHDRtoSDR and the thread for it appears within the first 10 results. How much hand-holding do you need? Nevertheless, to indulge you and others unable to execute simple searches, I'll add it to the user manual.

[manolito]

[hello_hello]

Originally Posted by videoh

When one is clueless it behooves one to do basic research, including reading the relevant threads for the tools:

https://forum.doom9.org/showthread.p...84#post1847484

If I'd gone to the trouble of hunting through the thread and what I needed to know wasn't there you'd be telling me to read the help file, which is where you'd expect to find all the relevant info. Not everyone posts at doom9. Is the information about colorimetry available in a thread in your forum too?

To me, due to a lack of anything in the help file to the contrary, it seemed perfectly reasonable to assume DGHDRtoSDR simply converts HDR to SDR and you'd be left with rec.2020. Maybe if the plugin was named DGHDRto709SDR.....

Anyway, it's sorted now and we know what to expect. Thanks for the plugin by the way. I'm sure I'll use it eventually, even if I don't have a need for it now. Although what do you use if you want to convert HDR range to SDR and not reduce the color gamut to rec709?