Support forum for DG Tools

DGHDRtoSDR alone doesn't match DGNV HDR preview. I have to convert the matrix from 2020 to 709 to make it the same as what I saw from DGNV GUI.

From what I learned, it converted the "colorimetry" from 2020 to 709, but not the "matrix" from 2020 to 709. So a matrix conversion without a colorimetry conversion is needed.

Is this an expected behavior?

EDIT:

Comparing to a non-HDR 2020
Converting between YUV and XYZ changes both colorimetry and matrix. I initially used this to convert the above result, and obviously went wrong. Took me a long while to notice the difference between the two conversions.

I'll look into it. First I have to complete the THD demuxing and HEVC seeking issues. Thank you for your report, MeteorRain.

They are theoretically using the same code so this should be interesting.

Just a reminder: I could be wrong though. I'm very new to the 4K/8K/2020/HLG world, so I'm still exploring and trial and error.

MeteorRain wrote: ↑

Sun Mar 15, 2020 8:19 pm

I'm very new to the 4K/8K/2020/HLG world, so I'm still exploring and trial and error.

You and me both!

https://www.youtube.com/watch?v=QKA7N2vMtcw

Colorimetry consists of three things:

* matrix
* transfer function
* color primaries

DGHDRtoSDR() is coded to properly convert all three. You claim:

"DGHDRtoSDR alone doesn't match DGNV HDR preview."

Please provide a stream and describe all steps to demonstrate this, including scripts, and specify used applications.

Note that for display in DGIndexNV, the output is converted to RGB for GDI display using either 601 or 709, depending on the source stream (typically 709 for HD). So if it looks OK in DGIndexNV, then it must have been 709 going into the RGB conversion. DGHDRtoSDR uses the same HDR->SDR code, so I argue that it is outputting 709.

Uploaded a sample file.

Steps for DGIndexNV
1) Load hevc file
2) Video - HDR to SDR
3) Enable HDR to SDR
4) Enable HLG
5) Set params to 7000, 0, 0.42, 1.00, 1.00, 1.00, 0.70, 0.70
6) F8 copy frame

Steps for DGHDRtoSDR
1) Create index file
2) Create AVS file as
dgsource("HLG-7600241771-7663549204.dgi")
DGHDRtoSDR(mode="hlg",white=7000, black=0, gamma=0.42, r=1.0, g=1.0, b=1.0, tm=0.7, roll=0.7, fulldepth=true)
ConvertToRGB(matrix="Rec709")
3) Load file into VirtualDub2 or any other tool
4) Copy frame

Compare colors on pink circle board people hold or top right pink 人shape logo.

I'm reading FC97C7 from DGNV and FFA4C8 from AVS, for the center of the pink board holding by a girl in front row.

As a side note, a manual conversion as I wrote in OP didn't give me the same color either, so I might have done it wrong.

I peeked at the code, nyuk nyuk!

So in DGIndexNV the HLG P16 to RGB P8 uses limited range. OK, that matches 'RecXXX'. But the conversion routine lacks the 601/709 parameter that gets used for normal 8-bit stuff. And it appears to be coded for 601. To verify that this is the case use ConvertToRGB(matrix="Rec601"). Then everything seems to match. So Rockstar, ya gotta use 709 equations for this.

I think you're right, Curly! Thanks.

Fortunately it's only a display issue in DGIndexNV GUI. The DGHDRtoSDR() output is correct; it outputs YUV (no RGB conversion).

Curly has no nuts.

I resemble that remark.

Shaddap!
Tashie, don't feed the trolls.

Rocky wrote: ↑

Sun Mar 29, 2020 8:44 pm

Fortunately it's only a display issue in DGIndexNV GUI.

However, it's unfortunate to the extent that using DGIndexNV to find good DGHDRtoSDR() parameters is now problematic.

I'm not blind!

Mr. Peabody, could this be the girl for you?

https://www.youtube.com/watch?time_cont ... u3HN-MmJc4

Checked the code and the conversion is coded for 709 so Curly's theory appears incorrect. Still looking for the source of the discrepancy.

The kid did pretty good on the PVBob() issue. Why don't we assign him this one?

Thanks, Bullwinkle. I'll get right on it.

I'm not seeing a problem here. First off, the ConvertToRGB() in the script is not needed and just complicates things. So I removed that. Also there's no need for doing F8 and all that. I used ColorPic to look at the pixels for 2 cases:

1. Directly in DGIndexNV display (not via F8).

2. Script loaded in VirtualDub2.

Below I show the results. You can see that the results are the same (allowing for different pixels and possible small algorithmic differences in the two display chains. On the left is DGIndexNV and on the right is Avisynth+VirtualDub2.



I also confirmed that there are no relevant code differences for the two conversions. I recommend closing this if MeteorRain is OK with that.

You're right, boy, but the hullabaloo? In the debugger, directly compare the YUV values entering the RGB conversions.

Don't we need an end-to-end test? Otherwise someone could say fine, the YUVs are the same, but the RGB conversion in DGIndexNV is messed up. It would be a useful double-check, I agree.

I think everything is just fine. Rocky

Gonna close it then. Thank you, Sherman.

Thanks, I'll double check the colors.