Gerhard Fürnkranz wrote:
so you believe that the "abbreviated calibration" is not just a limitation of NCE, but that even access to the hardware LUT is not yet implemented in the firmware?
I suppose it's rather a faulty interface to the LUT than no access at all -- but that's a wild guess. It might be that there's already a firmware update.
[I think there are no doubts whether there exists hardware LUTs in an XL20?]
I think so too.
But then I'm wondering, howNCE can load the TRC of emulated profiles into the monotor
There are several ways to define a LUT (gamma formula parameters, tables in different sizes and bit depths, ...), maybe some of them work for NCE and others don't?
And there's the I2C interface, which seems to be a little bit unsteady in general: While playing with the ookala framework (HP's open source solution to drive the DreamColor displays), I noticed that the code is designed to repeat I2C commands up to 5 times as there's no guaranty that a IC2 transaction succeeds at the first go (an indeed I actually saw several transactions which failed one or even two times on my system). The integrity of every transaction can be verified with a checksum -- but of cause the software *has* to validate it.
Btw, the ability to calibrate the XL20 coarsely with NCE before doing a dispcal calibration (-> graphics card LUTs) has at least the advantage that the graphics card LUTs only need to do minor adjustments and do not steal too many RGB levels.
of course. Klaus