Support forum for DG Tools

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.