- This topic has 278 replies, 20 voices, and was last updated 2 years, 10 months ago by
.
-
Posts
-
Yes Calman and DeviceControl are reading the created 3d lut and encoding it appropriately to send to the TV.
Interesting, I didn’t know that.
Open to suggestions for which file format(s) are the most useful to support.
Then start with “AutoDesk/Kodak 3DLUT”, later you can add LG’s one. Thanks
Issues are enabled for the github repo now.
Thanks, I just created your first issue 🙂
Then start with “AutoDesk/Kodak 3DLUT”, later you can add LG’s one. Thanks
The most convenient format would be Iridas *.cube, not some integer format.
Alright thanks. Is it possible/foreseen to be able to export a 1d LUT from DisplayCal in cube format as well?
Alright thanks. Is it possible/foreseen to be able to export a 1d LUT from DisplayCal in cube format as well?
It’s probably redundant for SDR because the 3DLUT does a really good care of the grayscale inmy experiments.
I am not sure about HDR10/HLG unless you plan to convert the 1DLUT from dispcal results (the .cal 1DLUT file created by an iterative calibration process for the VGA LUT), otherwise the 3DLUT seems to be good enough (the results are not as great as they are for SDR). And even then it might not worth it for HDR due to the panel’s stability problems (what you gain from the more thorough iterative calibration, you might loose to the errors caused by the drift during longer measurements).
The only thing that really requires a 1DLUT is DolbyVision since that one doesn’t seem to have an active 3DLUT. (Or does it, by any chance? You might be able to figure this out. 🙂 ) But that must be pulled from the profile created for the HDR mode because I don’t think the ArgyllCMS/DisplayCAL developers would want to meddle with DolbyVison metadata injection (to display DV patterns for iterative calibration). Luckily, the HDR10 measurements should be valid for DV. Well, save for that “config file” but that seems trivial to construct from HDR10 measurements as well (it’s just a matrix profile).
I’ll take a closer look at the LUT behaviour in Dolby Vision mode next week.
On my nvidia shield 2017 I’m able to do HDR10 metadata injection by playing an HDR10 file in VLC and leaving it in the background using VLC’s PIP option. Then one can start generating patterns using the Chromecast option in DisplayCal/ArgyllCMS and it will continue sending HDR10 metadata. If someone has a 2019 Nvidia Shield they may try this with a Dolby Vision file. Otherwise I’m exploring a few options to do this using my Fire Tv Stick 4k. I agree that it should be possible to use profile information from HDR10 mode, but it would be nice to be able to verify properly at the end in Dolby Vision mode in any case.
The FireTV stick has a gui option to force HDR mode, in which case it will actually switch to Dolby Vision mode by default. No control over exactly what DV metadata is sent in this case, but one should be able to use ~any pattern generation solution in this case. I have a prototype for an RPC-controllable TPG running inside Kodi which I will push upstream if it turns out to be useful.
Other option I’m playing with is injecting test patterns into ffmpeg and sending them as an x265 stream (could be sent directly to the TV, or to VLC or other video players on the fire tv stick or other DV capable streaming device). I have a working prototype of this for SDR and HDR10. x265 in principle supports dolby vision encoding, but I don’t know how to generate the necessary metadata for the –dolby-vision-rpu option in x265 needed to use this. (Again I’ll package this up in a useful form together with patches for DisplayCal in case it turns out to be useful.)
Even in HDR10/HLG mode, sending the static HDR metadata (this can also be done by playing an HDR10 movie on a PC and putting the player to the background) is only half of the story. You also have put the TV into calibration mode where the tone-mapping is bypassed. And, of course, you also wish to fill the hardware LUT with neutral data before profiling.
DolbyVision pattern generation is even more complex because in DV mode everything goes through the Dolby CMU (usually a standalone chip in the TV or sometimes Dolby’s code running on the generic SoC), so the pattern generator has to send specific metadata for “bypass” (no color mapping) mode. CalMAN can do this after you put the TV into DV mode with a HDFury Integral or similar devices.
But fortunately, since this “bypass mode”, however you achieve it, is the same between HDR10 and DV modes (everything is bypassed after all), I don’t think anybody should be concerned about how to profile the display panel in DV mode. Even if you have the required software and hardware, you will want to reuse the HDR10 profile to save time. It’s stupid to repeat the same measurements, especially if it’s even more complicated to do so in DV than HDR10 mode.
However, you will need a way to put the TV into regular DV mode for the 1DLUT and matrix upload. But that can be done by playing a DV demo clip with the internal player…
Yes, agreed that it is not needed to profile in DV bypass mode, as opposed to just doing it in HDR10 bypass mode as you are suggesting. I was arguing rather that it would be useful to be able to send test patterns in standard DV mode to validate the calibration procedure at the end.
Yes, agreed that it is not needed to profile in DV bypass mode, as opposed to just doing it in HDR10 bypass mode as you are suggesting. I was arguing rather that it would be useful to be able to send test patterns in standard DV mode to validate the calibration procedure at the end.
Ah! Well, I guess it’s enough to validate a few patches (some grays and R,G,B) to see if the final LUTs were calculated and activated correctly after the upload (once you made sure the ICM profile was fine by validating that in bypass mode still). There should be some test patterns for that in video format (or should arrive soon, I have one for black clipping). Otherwise, one has to copy the CalMAN solution: the patches need to be encoded into DV’s YCC format in software and sent as RGB while the DV meatadata is injected with a hardware device.
Btw, access to DeviceControl no longer requires having a LightSpace license. Just contact Ted for access to the LG templates in DeviceControl using the “Request LG Templates for DeviceControl” form in the Contact section on his website: https://www.displaycalibrations.com
I have to retract this statement. DeviceControl access is available only to LS licensees. Ted contacted me to say he made an exception for a few people, but that was an exception.
I had a chance to take a closer look at the LUT behaviour in Dolby Vision mode on the C8.
Both the 1D LUT and 3D LUT can be used, but the 3D LUT data which is used is the one marked BT709_3D_LUT_DATA and NOT the one marked BT2020_3D_LUT_DATA as one might expect.
I had a chance to take a closer look at the LUT behaviour in Dolby Vision mode on the C8.
Both the 1D LUT and 3D LUT can be used, but the 3D LUT data which is used is the one marked BT709_3D_LUT_DATA and NOT the one marked BT2020_3D_LUT_DATA as one might expect.
That’s nice. 🙂
That DV 3DLUT shouldn’t necessarily target Rec2020 (even when used unofficially). I think the official (LG, CalMAN) way – if existed – would be creating the DV 3DLUT against a synthetic profile constructed with the actually measured R,G,B primaries, D65 white, gamma 2.2 and then crafting a DV config file with the measured R,G,B primaries and that LMS->display conversion matrix (which is not included in 2019 config files, so may be it’s never really used by 2018 models either). But, of course, the DV 3DLUT could target Rec2020 if the DV config is set to Rec2020 primaries as well (in this case, the Dolby chip/blob would theoretically do zero color saaturation conversion and handle the tone-map part only). This sounds easier and may be preferable to keep the HDR10 and DV modes as close to each other as possible (save for the optionally dynamic tone mapping).
I should warn you that I managed to brick my TV by uploading an invalid DV config file. There’s some discussion here but the consensus was that this was likely caused by the unreasonably low value of Tmax in the config I uploaded.
I ended up needing to replace the main board to get the TV working again. (Probably initialization failure of the dolby bits with no good error handling on the LG side)
So experimenting with the dolby config file should be done with some care…
Then start with “AutoDesk/Kodak 3DLUT”, later you can add LG’s one. Thanks
The most convenient format would be Iridas *.cube, not some integer format.
Ok, what I’ve implemented for the moment is Iridas .cube input for both 1d and 3d LUTs. (As far as I know DisplayCal/ArgyllCMS can only export this format for 3d luts though.)
For 1d LUTS I’ve also added the option to read in directly the .cal files from DisplayCal/ArgyllCMS. Since the 1D LUTs present here are with 256 entries, in this case linear interpolation is used to expand them up to 1024 entries as required by the display.
I don’t make any strong claim that this is useful or needed with respect to just including the calibration in the 3D lut, but now at least both options should be possible.
Ready for broader testing now:
Ready for broader testing now:
Amazing job, hopefully it will be fully working for me tonight!
