[argyllcms] Re: Untether or free run mode for display read

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Wed, 13 Jun 2018 11:05:05 +1000

Neil Woodall wrote:

Hi,

I’m trying to put together a system the allows a fairly automated way of 
characterizing
a display. I put together a script to use spotread to read the display 
continuously
while a video sample is playing, but it’s not designed to work at the maximum 
speed of
the instrument (I say this by comparing it to how fast display read works on 
the same
pattern set).

spotread is not currently intended for that kind of use.

display
read requires a connection to the device, so if we want to characterize 
something that
can’t connect to displayread (eg an iPhone) its not really possible...using 
the
webserver doesn’t work because it sees that as an sRGB file for device 
characterization
you want to send P3 or rec2020 colorspace.

Hmm. I'm not sure there's any way of tagging the window background color. Of 
course
for this purpose, I want to tag them as "native", but web color management is
a mess as it is, I suspect there is no such possibility :-(

(But for the purpose of creating a CCSS this is irrelevant. It doesn't matter
 much what colors are used, as long as the spectrometer measures them.)

chartread requires a ti2 file and it’s not
clear how you would use the output to generate a ccss file or whether it’s 
compatible
anyway.

I'm not sure what you mean. chartread has a lot of special logic in it to 
recognize
patch scans. This simply isn't applicable to measuring displays.

What would be useful is the ability to use the scanning type functionality 
that is in
chart read, but with a ti1 file instead of ti2 file.

You are really asking for a completely different utility, one that can
measure continuously and then parse up (i.e. "guess") the correct
patch boundaries.

Yes, DisplayCal has this functionality, but they are simply using spotread 
and whenever
the i1Pro2 returns any sort of error, it simply stops. It would be better for 
it to
continue and for the user to make the pattern slow enough that you can handle 
at least
one error response.

Easier to add an option to make spotread not error out. What sort of errors are 
you
talking about though ?

Cheers,
        Graeme Gill.

Other related posts: