#12848 (Enhancement) Allow selection of .3dl sample points
+1 0
Closed as Implemented
Component: DisplayCAL | Milestone: 3.6.1
Created by jasminetroll
Last modified
When generating an n-by-n 3D LUT in .3dl format with m-bit input, the sample points are obtained by evenly diving the interval [0, 2^m – 1] into n-1 subintervals, then rounding the endpoints of the subintervals to the nearest integer. So, for example, a 17-by-17 LUT with 10-bit input has samples at points
0, 64, 128, 192, 256, 320, 384, 448, 512, 575, 639, 703, 767, 831, 895, 959, 1023
However, I’m working with an application that requires samples at
0, 64, 128, 192, 256, 320, 384, 448, 512, 576, 640, 704, 768, 832, 896, 960, 1023
in this case (henceforth “ceiling points”, because these points can be obtained by taking the smallest integer >= each endpoint instead of rounding). It would therefore be useful to be able to somehow specify these points as an alternative.
My specific application is using CalMAN to install a DisplayCAL-generated LUT in a 2018 LG TV, and the specific 3D LUT sizes supported are 17-by-17 (for IPS and B-series OLED TVs) and 33-by-33 (for higher-end OLED models), both using 10-bit input and 12-bit output, but only accepts .3dl files with ceiling points.
As an aside, the Lustre manual cited by the DisplayCAL uses the above set of ceiling points as an example on page 8, so this doesn’t appear to be a particular quirk of LG TVs and/or CalMAN.
I’d attach a patch, but I can’t think of a simple UI for this feature that doesn’t involve knowing what applications require or prefer one or the other sets of sample points.
Finally, note that, for practical purposes, this problem can be solved by hacking one line of the DisplayCAL source to output ceiling points instead of rounded points in the .3dl header; the main reason I’m requesting this enhancement is so I can explain how to use DisplayCAL to generate LG 3D LUTs to others without requiring either code changes or edits to the resulting .3dl file.
As a distant second reason, output values should also be calculated from input values at the input points implied by the header, rather than at the actual (floating-point) endpoints or the rounded points, though I imagine this would only lead to visible differences in pathological cases.
Reports (application/zip | 2018-07-19 18:50:31)
I don’t think UI is needed. I’ll just change from rounding to nearest integer to rounding up always for 3dl format.
That certainly works for my application!
See attached for a proof-of-concept, bearing in mind that the 3D LUT sending the white balance off the rails near the black point as backlight bleed starts to dominate appears so far to be a non-issue in actual use — though if there’s an obvious way to fix it, I’m all ears — and that the “pre” state is the result of a full reset followed by 42-point white balance calibration to D65 with (CalMAN’s definition of) 2.2 gamma.
Finally, it’s potentially worth pointing out that this test was carried out
more than 24 hours after calibration
under wildly different ambient lighting conditions
using a different HDMI port on the TV
on a Mac (vs a Windows 10 PC used for calibration)
with an AMD video card (vs Intel graphics on the calibration PC)
at 2160p60 (vs calibration at 1080p120, because my meter appears to work marginally better at the higher refresh rate)
as is my habit, to avoid misleadingly good post-calibration results that don’t accurately reflect actual use.
Once this change makes it into a release, (my) time permitting, I’ll do a write-up of my procedure for hybrid CalMAN/DisplayCAL calibration of 2018 LG TVs (CalMAN is currently the only software that can calibrate white balance and install 3D LUTs on these displays).