[argyllcms] Re: How do I force dispcal to always map R0 B0 G0 -> R0 B0 G0 on the calibrated video LUT?

  • From: Alexander <adfirestone@xxxxxxxxx>
  • To: argyllcms <argyllcms@xxxxxxxxxxxxx>
  • Date: Wed, 13 Jan 2010 05:32:14 -0800

>
> After calibration is finished, dispcal scales and then applies the
>> VideoLUT values it generated.
>>
>
> I think there may be a misunderstanding. Dispcal does not apply the
> calibration it generates. It resets (to linear) any video LUT curves that
> might be present before starting measurements, and thereafter, it restores
> them. So when invoking dispread, to actually use the calibration you
> created, you have to provide the -k parameter with the cal file as argument
> (or invoke dispwin file.cal first, but using the -k parameter is clearer).
> Otherwise dispread measures the display in whatever state it happens to be
> in. All mentioned in the Argyll docs btw :)
>
> Regards,
>
> Florian Höch
>
>
Oh, you're right. Looking closely, what I thought was actually a scaled
VideoLUT was actually my previous profile's VideoLUT which means dispcal
does do exactly what you just described.

This was my first time going through the entire calibration process using
the CLI only instead of dispcalGUI. With dispcalGUI it does automatically
apply the VideoLUT for when finished, so when I saw the display get
brighter, I just wrongly assumed it was the default dispcal behavior.

Thank you for pointing out my mistake, I wouldn't have easily noticed it
otherwise.

__________

Now that the above is cleared up, this is even better news since it means
that RC3/RC4 completely resolves this issue with the EyeOne Pro when
calibrating a display with a blackpoint nearly 0.00cd/m2. I've only tested
it with the -V parameter so far. I still have to get around to testing RC4
without the -V parameter to see if the 'High/Low gain fix' by itself
improves on this issue at all.

Graeme, I'll post back in the RC4 thread with my full impressions once I
find time to do a bit more testing.
As expected, using -V -qh is very slow with my first trial run taking ~90
minutes with an average of ~7 seconds per measurement over 761 total
measurements (initial 86 + first iteration 22 + second iteration 45 + third
iteration 146 + forth iteration 462 = 761 total).

Other related posts: