Home › Forums › Help and Support › Question about BT.2020 3D LUT generation
- This topic has 7 replies, 2 voices, and was last updated 6 years, 2 months ago by jasonwc.
-
AuthorPosts
-
2018-01-24 at 0:01 #10166
Hello,
I would like to generate a 3D LUT for UHD Blu-Ray content for viewing on a JVC RS600 projector using madvr to tone map HDR to SDR. UHD Blu-Rays use the BT.2020 colorspace as a container, but almost all UHD Blu-Rays are limited to the more limited DCI-P3 colorspace in terms of how the content is actually mastered. My RS600 is capable of displaying 98-99% of the DCI-P3 colorspace but certainly cannot display the entirety of BT.2020. However, the projector’s only WCG mode is BT.2020; there is no mode to directly target DCI-P3 as this is not a consumer standard.
The question is how to do I go about generating a 3D LUT for UHD Blu-Ray content which is essentially DCI-P3, but presented in a BT.2020 container. If I profile for DCI-P3, my understanding is that colors will be inaccurate. If I profile for BT.2020, anything beyond around 70% saturation (depends on the color) will not be achievable by the projector.
There’s already documentation for generating a 3D LUT for Rec.709 content but I haven’t been able to find any guidance for BT.2020. That isn’t all that surprising given that it only recently became possible to view UHD Blu-Ray content on a PC.
Jason
2018-01-24 at 16:05 #10177Hi,
the correct source colorspace for HDR is always BT.2020 as that is the container within which the content colorspace (which may be different and is DCI P3 for all currently available HDR material) is encoded. Using anything else will give incorrect results.
2018-01-24 at 16:34 #10183Will generating a 3D LUT for BT.2020 be accurate when my display is limited to displaying DCI-P3? Anything higher than approximately70% saturation, depending on the color, will not be reproducible.
For example, Calman addresses this issue for manual calibration by providing an option to limit saturation sweeps to DCI-P3, when calibrating BT.2020. Is there a similar option in DisplayCal, or even just the ability to limit samples to a maximum saturation level?
2018-01-24 at 16:36 #10184By samples, I mean the test color patches used to generate the 3D LUT.
2018-01-24 at 16:46 #10188Will generating a 3D LUT for BT.2020 be accurate when my display is limited to displaying DCI-P3? Anything higher than approximately70% saturation, depending on the color, will not be reproducible.
Yes. It should be of no real concern though (other than some of the patches being clipped to the same color by the display), as the profiler will figure out the limits of the display from the measurements anyway.
For example, Calman addresses this issue for manual calibration by providing an option to limit saturation sweeps to DCI-P3, when calibrating BT.2020.
For manual calibration, this may be needed because you need something to base your manual adjustments on, but not for profiling (it’s actually important that the profiler figures out which patches clip and which don’t, and the way to do that is to send even the ones that would clip and just let the profiler do its thing).
2018-01-24 at 16:57 #10192Thanks for the quick reply and clear explanation!
I just have one more question. You stated in another thread that DisplayCal only gives the option for TV Levels (16-235) when generating a MadVR 3DLUT as that is all that MadVR will accept.
I am confused by this as Calman allows selection of PC levels for MadVR 3DLUT generation and madshi himself recommends using PC Levels for both MadVR output and in GPU driver settings.
Will the DisplayCAL 3D LUT be accurate if I have my NVIDIA card, MadVR, and projector set to output PC Levels?
2018-01-24 at 17:07 #10193You’re confusing the 3D LUT encoding (which for madVR is always video levels) with the output levels (which you can choose in your graphics driver and madVR itself and needs to be configured correctly).
Will the DisplayCAL 3D LUT be accurate if I have my NVIDIA card, MadVR, and projector set to output PC Levels?
Yes.
2018-01-24 at 17:13 #10198Thanks for the explanation! It looks am good to go.
-
AuthorPosts