Hello everyone, I've recently joined the QD-OLED world with several of the latest SmallHD Quantum monitors, and I'm struggling to get consistent calibration results. I'm working on two 32" and two 27" units, but despite following the SmallHD calibration guide (the guide doesn't mention that the Quantum calibration wizard actually requires a two-step characterisation) the results have been less than ideal. The core issue is that the white points never perceptually match between units, even though quick profiles show low delta-E values and everything appears correct in ColourSpace. This raises a question: even if the instrumented results look good, do I still need to perceptually match the white points? And if so, why would that be necessary when these monitors use the same panel? Are the narrow spectral peaks of the primaries causing increased unit-to-unit metameric differences? I assumed the metameric behaviour would be similar across panels with comparable narrow-band emissions. Before I commit to full volumetric calibrations—which will take quite some time across multiple units—I want to make sure I'm not overlooking anything fundamental. My workflow is as follows: · Warm up each monitor for 45–60 minutes. · Set patch size to custom 3%, full range, no stabilisation. · Run the 1000-patch pre-roll CSV (8-bit full range), at 1 second per patch (adding ~16 minutes of additional warmup). · Switch to 10-bit range and set stabilisation to 0.250s FW. (I'm not sure stabilisation is even needed on this panel type—thoughts?) · Set CR-100 exposure to 500 ms max integration time, multiplier 2, Intelligent Integration enabled below 0.100 nits. · Use probe sync to confirm a manual 48 Hz setting is valid for 24 fps patches, and run auto-delay. Although auto-delay typically gives 0.109 s, I extend it to 0.250 s for safety. · Create FCVM with the CR-250 as the reference probe (auto-exposure, low light averaging), matching the CR-100. Both probes warm up during pre-roll. · Use an AJA ColorBox as the pattern generator, bypassing everything. When sending unity bypass to the LUT box, ColourSpace throws an error at 10%. All eight of my ColorBoxes show the same behaviour, even after factory resets, so I suspect a ColourSpace integration bug. (I'll create a separate post on this once I confirm others haven't seen this issue.) In any case, this doesn't seem to affect measurements: using Resolve as the TPG yields the same suboptimal results, and the monitor's colour-picker returns the correct 10-bit values with both TPGs, so the signal path seems fine. · Run the characterisation using Grey Primary & Secondary Ramp + for the first step of the Quantum calibration wizard ("bright pass"). Save the profile and generate a LUT for DCI-P3, D65, gamma 2.4. (SmallHD recommends building a custom 2.4 gamma space rather than 2.6.) Peak Chroma, no gamut mapping, normal levels. · Load the generated LUT and verify with the same quick profile—looks good. · Continue with the wizard, which displays a white patch and asks for a manual luminance reading to set peak brightness. This is usually just under 1000 nits. I enter the value and proceed to the second characterisation step, targeting ~250 nits. · Repeat probe matching and quick profile at the lower peak luminance, build the LUT, load, and verify again. Then read the dimmer white patch, enter its value, and complete the wizard. My understanding is that the monitor derives its other colour spaces and brightness levels from these two P3 calibrations. When I test different colour pipes (Rec.709, P3, etc.) and run verification profiles—including probe matching—the results all come back excellent. Instrumentally, everything is "green." However, when placing multiple units side-by-side and feeding them content or colour bars, there is a clearly visible white-point mismatch. I didn't have time to check a wide range of colours perceptually, but the white point difference is immediately noticeable. Has anyone experienced similar behaviour or has insight into what might be causing this? Any ideas or suggestions would be hugely appreciated (especially from Steve) Many thanks in advance! |