View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000539 | madVR | bug | public | 2018-02-05 17:35 | 2018-02-06 13:46 |
| Reporter | fhoech | Assigned To | madshi | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | x86_64 | OS | Windows 10 | OS Version | 10.0.16299 |
| Summary | 0000539: madVR_LoadHdr3dlutFile always writes "Output_Transfer_Function PQ", assigns "HDR to SDR" | ||||
| Description | madVR_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); | ||||
| Tags | No tags attached. | ||||
| madVR Version | 0.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 | ||||
| Decoding | DXVA2 Copyback | ||||
| Deinterlacing | auto mode | ||||
| DXVA2 Scaling Active | no | ||||
| Aero / Desktop Composition | On | ||||
| Problem occurs with mode | all modes | ||||
| GPU Manufacturer | NVidia | ||||
| GPU Model | GTX 1070 | ||||
| GPU Driver Version | 388.71 | ||||
|
|
0.92.11 -> 0.92.12 |
|
|
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"? |
|
|
> 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. |
|
|
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? |
|
|
> 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. |
|
|
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. |
|
|
> 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 :-) |
|
|
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. |
|
|
Alright, working as intended now. Thanks! |
| 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 |
