[argyllcms] Re: Display calibration with Eye-One Display 2

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Tue, 15 May 2007 18:03:38 +1000

Tilo Nitzsche wrote:

I tried to calibrate my monitor using an Eye-One Display 2 using 0.70 beta 3.

Under Linux (Ubuntu 6.10 running in VMware server), the dispread timing is
totally screwed up, it cycles through something like 10 or 20 patches per
second. Turning on debugging, it seems to be able to talk to the Eye-One
display. The debug output looks like this:

-----------------------------------------------------------------
patch 996 of 1000i1disp: Sending cmd 14 args '00 01 00' response '4c 4f 43 4b
00' ICOM err 0x0
i1disp: Sending cmd 14 args '00 01 01' response '4c 4f 43 4b 00' ICOM err 0x0
i1disp: Sending cmd 14 args '00 01 02' response '4c 4f 43 4b 00' ICOM err 0x0
i1disp: Sending cmd 16 args '4c 4f 43 4b 00' response '4c 4f 43 4b 00' ICOM
err 0x0
i1disp: Sending cmd 02 args '4c 4f 43 4b 00' response '4c 4f 43 4b 00' ICOM
err 0x0
i1disp: Sending cmd 03 args '4c 4f 43 4b 00' response '4c 4f 43 4b 00' ICOM
err 0x0
------------------------------------------------------------------

This results in junk and profile fails:
./profile: Error - 2, Failed to find high clip target for Lab space

The above indicates a problem unlocking the device. I haven't seen
the above responses before, so the code doesn't recognize them and
assumes everything is working, hence the high rate of apparent readings.
It would help if you could capture the debugging output right from
the start (by redirecting stderr) so I can see what led up to this.

Under Windows XP, dispread can profile the laptop display fine. However when
trying to calibrate a Dell 1905FP (19" TFT, Samsung PVA panel), it hangs for
maybe 30s when trying to read dark patches and then times out. (dispread -v
-yl -K -p 0.5,0.5,2.0 dell1905)

Hmm. It uses some sort of integrator A/D converter, so the less
light there is, the longer the reading takes. I'll look into
how extremely low light levels can be handled without ending
in a timeout. Maybe I've overlooked something in how the Gretag driver
handles this.

When I set the display type to CRT (dispread -v -yc -K -p 0.5,0.5,2.0
dell1905), dispread runs through but this results in a profile with a strong
green cast in dark tones and a peak error of 93, avg. error of 5.4.

The CRT reading mode is a little different, so it deals with very low light
levels differently.

How long is dispread supposed to wait to start measuring after displaying a
patch? A lot of newer TFTs seem to have a latency of 2-3 frames (30-45ms). It
might be nice to have a command line option to add some delay.

The display calls are meant to flush the color change to the display,
and there has not been any indication of any issues caused by the instrument
being too fast in taking a reading. I have added a slight delay in any case
to my current code, to give displays a chance to refresh.

Graeme Gill.


Other related posts: