madshi bug tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000539madVRbugpublic2018-02-05 17:352018-02-06 13:46
Reporterfhoech 
Assigned Tomadshi 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
Platformx86_64OSWindows 10OS Version10.0.16299
Summary0000539: madVR_LoadHdr3dlutFile always writes "Output_Transfer_Function PQ", assigns "HDR to SDR"
DescriptionmadVR_LoadHdr3dlutFile seems to always write "Output_Transfer_Function PQ" into the header of the installed 3D LUT, irrespective of the sdrOutput parameter.

The 3D LUT is used and produces the correct result, but opening madVR's settings and clicking "OK" results in an error message if the 3D LUT was installed for the "convert HDR to SDR" slot.
Steps To Reproduce/*
  Expected: 3D LUT gets assigned to "convert HDR to SDR",
            header only contains "Input_Transfer_Function PQ"
  Actual: 3D LUT gets assigned to "convert HDR to SDR" (OK),
          but header also contains "Output_Transfer_Function PQ" (not OK)
*/
BOOL saveToSettings = 1;
int gamut = 3; // BT.2020
bool sdrOutput = 1;
madVR_LoadHdr3dlutFile("<lutFileName>", saveToSettings, gamut, sdrOutput);
TagsNo tags attached.
madVR Version0.92.11
Media Player (with version info)MPC-BE 1.5.2
Splitter (with version info)LAV 0.69.0
Decoder (with version info)LAV 0.69.0
DecodingDXVA2 Copyback
Deinterlacingauto mode
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modeall modes
GPU ManufacturerNVidia
GPU ModelGTX 1070
GPU Driver Version388.71
Attached Files

- Relationships

-  Notes
(0002224)
fhoech (reporter)
2018-02-05 17:56

0.92.11 -> 0.92.12
(0002225)
madshi (administrator)
2018-02-05 20:49

On a quick check, without actually having tried it, I can't seem to find the issue in my source code.

Hmmmm... I think with the API you're using, madVR decides on its own name of the 3DLUT file, is that correct? If so, what is that name? E.g. is it "BT.2020.HDR2SDR.3dlut" or "BT.2020.HDR.3dlut"?
(0002226)
fhoech (reporter)
2018-02-05 21:15

> I think with the API you're using, madVR decides on its own name of the 3DLUT file, is that correct?

Yes, looks like it. It chose the name "BT.2020.HDR.3dlut". Automatic assignment to the respective section "convert HDR to SDR" or "process HDR" works fine, just the header seems to be the issue, so it is not ignoring the sdrOutput parameter completely.
(0002227)
madshi (administrator)
2018-02-05 21:28

Oh, stupid me. A simple "not" was missing.

After triple checking the code and doubting my sanity, the code does it exactly the wrong way around: With "sdrOutput=true", "Output_Transfer_Function PQ" is added, while it should not be. With "sdrOutput=false", "Output_Transfer_Function PQ" is *not* added, while it should be. This will be fixed in the next build.

Do you need fixed madHcNet32/64.dll files, or can you wait for the next official madVR build?
(0002228)
fhoech (reporter)
2018-02-05 21:34

> A simple "not" was missing.

Happens easily :-)

> Do you need fixed madHcNet32/64.dll files, or can you wait for the next official madVR build?

Would be nice to have for testing as I'm planning a DisplayCAL release (est. tomorrow, if all goes well), but if you're going to have a new build in the next days anyway, then I'll happily wait.
(0002229)
madshi (administrator)
2018-02-06 00:06

I think this one should work:

http://madshi.net/madHcNetDisplayCAL.rar [^]

Can you confirm?

BTW, just yesterday I tried creating a pure BT.2020 tone mapping HDR -> SDR 3dlut, but I got a floating point exception, using the latest DisplayCAL version. Could have been my fault, but I didn't find a way to make it work. Maybe you can double check it works, just to be safe, before releasing the new build.
(0002230)
fhoech (reporter)
2018-02-06 00:36

> I think this one should work:

Almost. The problem is now reversed (i.e. the installed HDR to SDR 3D LUT has the correct header, but the installed process HDR 3D LUT is missing the "Output_Transfer_Function PQ" bit). Both LUTs are still installed under the same name (BT.2020.HDR.3dlut).

> BTW, just yesterday I tried creating a pure BT.2020 tone mapping HDR -> SDR 3dlut, but I got a floating point exception

Yes, that's a known bug in 3.4 (previous version was fine) that I introduced when I added HLG :-( (already fixed in SVN). It only affects profiles with zero black level though (e.g. synthetic, or from an OLED). For a synthetic profile, you can set a black level slightly above zero as a work-around.

Time for a good night's sleep I'd say :-)
(0002231)
madshi (administrator)
2018-02-06 10:40

Argh, this time it was a BOOL vs bool mismatch between header and implementation. Ouch.

http://madshi.net/madHcNetDisplayCAL2.rar [^]

Please make sure you also update madTPG.h, just to be safe.
(0002232)
fhoech (reporter)
2018-02-06 13:07

Alright, working as intended now. Thanks!

- Issue History
Date Modified Username Field Change
2018-02-05 17:35 fhoech New Issue
2018-02-05 17:56 fhoech Note Added: 0002224
2018-02-05 20:49 madshi Note Added: 0002225
2018-02-05 20:49 madshi Assigned To => madshi
2018-02-05 20:49 madshi Status new => feedback
2018-02-05 21:15 fhoech Note Added: 0002226
2018-02-05 21:15 fhoech Status feedback => assigned
2018-02-05 21:28 madshi Note Added: 0002227
2018-02-05 21:28 madshi Status assigned => feedback
2018-02-05 21:34 fhoech Note Added: 0002228
2018-02-05 21:34 fhoech Status feedback => assigned
2018-02-06 00:06 madshi Note Added: 0002229
2018-02-06 00:06 madshi Status assigned => feedback
2018-02-06 00:36 fhoech Note Added: 0002230
2018-02-06 00:36 fhoech Status feedback => assigned
2018-02-06 10:40 madshi Note Added: 0002231
2018-02-06 10:41 madshi Status assigned => feedback
2018-02-06 13:07 fhoech Note Added: 0002232
2018-02-06 13:07 fhoech Status feedback => assigned
2018-02-06 13:46 madshi Status assigned => closed
2018-02-06 13:46 madshi Resolution open => fixed


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker