View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000659 | madVR | bug | public | 2021-01-31 07:01 | 2021-02-03 09:14 |
| Reporter | goraelec | Assigned To | |||
| Priority | high | Severity | major | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | Windows | OS | Windows 10 | OS Version | 2004 |
| Summary | 0000659: HDR Metadata is not sent when tone mapping with 3DLUT | ||||
| Description | HDR settings contain an option "tone map HDR using external 3DLUT", which has 3DLUT selectors for 3 different color spaces and a separate section that says "send the following HDR metadata to display", which allows to specify a color space and target peak nits. Even with a valid 3DLUT and valid parameters for the metadata, no metadata is actually sent to the display and display doesn't switch to HDR mode. When switched to "passthrough HDR to display", the display switches to HDR confirming that metadata is present. | ||||
| Steps To Reproduce | 1. Have an HDR display or another way to verify that metadata is passed to the display 2. Have a valid 3DLUT for HDR tonemapping 3. Set the 3DLUT in HDR settings 4. Fill in metadata and click apply 5. Enter full screen The display won't switch to HDR mode | ||||
| Additional Information | OS HDR is not engaged | ||||
| Tags | No tags attached. | ||||
| madVR Version | 0.92.17 | ||||
| Media Player (with version info) | MPC-HC 1.9.8.109 | ||||
| Splitter (with version info) | LAV Splitter 0.74.1.92-git | ||||
| Decoder (with version info) | LAV Decoder 0.74.1.92-git | ||||
| Decoding | DXVA2 Copyback | ||||
| Deinterlacing | none (progressive) | ||||
| DXVA2 Scaling Active | no | ||||
| Aero / Desktop Composition | Off | ||||
| Problem occurs with mode | fullscreen exclusive mode | ||||
| GPU Manufacturer | AMD | ||||
| GPU Model | Vega Frontier Edition | ||||
| GPU Driver Version | 20.Q4 | ||||
|
|
Does this also occur using the latest HDR test build? http://madshi.net/madVRhdrMeasure122.zip Btw, using a 3DLUT for HDR tone mapping is no longer recommended because it results in static tone mapping, while the latest HDR test builds do very high quality dynamic tone mapping. You will need a reasonably fast GPU to use those new algorithms, though. |
|
|
Yes, build 122 also has this issue. I'm using 3DLUT for HDR in order to correct some of its inaccuracies in the neutral axis. Is there any way to have dynamic tone mapping with 3DLUT in the future? |
|
|
You can let madVR do dynamic tone mapping and combine that with a BT.2020 or DCI-P3 SDR 3dlut. That should give you the best of both worlds. Actually doing calibration while sending the display HDR is rather questionable because the 3DLUT cannot really know what the display's tone mapping algorithm will do. Unless it's so simple and stupid that it's predictable for the 3DLUT, but if it is, then it must be really bad. |
|
|
It's simple and stupid in my case. It has FALD, and in each zone, it looks at the brightest pixel and sets the backlight brightness to that value, but it does not exceed the maximum content light level (at least, this is what I observe) |
|
|
It would be great if there was a way to determine how tonemapping works on a display precisely using madTPG and measurement software like ArgyllCMS and find ways to correct for that |
|
|
That's a job for the calibration software, not for madTPG. madTPG simply renders whatever test pattern the calibration software asks for. How to actually make use of the measured data is the job of the calibration software. |
|
|
Interestingly, I too have been thinking about HDR dynamic tone mapping via 3DLUTs. I think I should describe my idea: madVR's dynamic tone mapping has two attributes which are dynamic: 1. Dynamic max light and tone map target calculation: madVR dynamically calculates a rolling-average based max light for each frame/scene and also the dynamic target for tone mapping (if DTN is enabled) 2. Dynamic colorimetric processing: madVR dynamically adapts the tone mapping curve depending upon the max light and the dynamic target etc. For dynamic 3DLUT tone mapping, madVR should just expose the settings/functionality for 1. Even in that, it should just provide the settings for determining the max light (i.e. the optimized maxCLL per frame/scene) and expose the max light as a profile variable. The user can then set up profiles to use different HDR 3DLUTs for different max light ranges. So, when an HDR video is played, madVR will switch between different 3DLUTs depending upon the max light value of the frame/scene. Certainly, there may be brightness jumps in certain places (or maybe you can take care of them), but all in all it should be possible to have a good dynamic tone mapping experience with 3DLUTs taking care of tone mapping. What do you think? |
|
|
This is a bug report. I don't think it's the right place to discuss potentially adding support for dynamic tone mapping with 3DLUTs. Anyway. madVR adapts the tone mapping curve even within each scene, which would not be possible with a 3DLUT solution - unless madVR would load a number of 3DLUTs for different "maxCLL" values and then interpolate between them as needed. That would require a much smaller 3DLUT size, though, to make real-time interpolation reasonable. In any case, there's very very little interest from either madVR or Envy users for having tone mapping baked into the 3DLUT atm, so there's very little chance that I'll spend precious development resources on that, when so many other things are begging for attention. |
|
|
I understand that this may not be the right place to discuss this idea. So, I will not continue here. But I will just make some remarks. My comments are inline: "madVR adapts the tone mapping curve even within each scene, which would not be possible with a 3DLUT solution - unless madVR would load a number of 3DLUTs for different "maxCLL" values and then interpolate between them as needed. That would require a much smaller 3DLUT size, though, to make real-time interpolation reasonable." Yes, I understand that madVR adapts the tone mapping curve within scenes too. But that is the colorimetric aspect of madVR's implementation, which we are not concerned about for 3DLUT based tone mapping. A 3DLUT is always going to be a static tone map. I was referring to a very basic dynamic implementation, where on the basis of the range in which maxCLL lies, madVR gently switches between LUTs. And all that interpolation or any complex processing is not really needed. Nor we need a large number of LUTs. Typically, I and others (some projector owners who I provided HDR tone mapping+calibration LUTs) felt just the need for two 3DLUTs. One for very dark scenes and the other for all other scenes. Basically, people were quite satisfied with my LUTs except for one issue that the dark scenes were looking too dark. I believe with just 2 to 4 3DLUTs, the users can have a very good HDR experience with dynamic tone mapping. "there's very very little interest from either madVR or Envy users for having tone mapping baked into the 3DLUT atm, so there's very little chance that I'll spend precious development resources on that, when so many other things are begging for attention." Fair enough. Maybe I can bring this up again in future to hear your thoughts then. I will just share my perspective though: madVR's HDR tone mapping is quite resource intensive. I am sure you will optimize it, but still it is going to be heavy. 3DLUT based tone mapping can provide flexibility to some users to allocate more resources to scaling algorithms or other processing algos or use less powerful GPUs while still getting a good dynamic tone mapping experience. madVR already supports tone mapping HDR LUTs, so why not make that feature more useful? |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2021-01-31 07:01 | goraelec | New Issue | |
| 2021-01-31 08:48 | madshi | Note Added: 0002774 | |
| 2021-01-31 17:55 | goraelec | Note Added: 0002775 | |
| 2021-01-31 18:00 | madshi | Note Added: 0002776 | |
| 2021-01-31 18:08 | goraelec | Note Added: 0002777 | |
| 2021-02-01 00:46 | goraelec | Note Added: 0002778 | |
| 2021-02-01 00:54 | madshi | Note Added: 0002779 | |
| 2021-02-02 18:28 | omarank | Note Added: 0002782 | |
| 2021-02-02 18:58 | madshi | Note Added: 0002783 | |
| 2021-02-03 09:14 | omarank | Note Added: 0002784 |
