I will see if I can get the errors again, but they were actually in the
DisplayCal log...which uses spotread for untethered mode.
Using spot read is not my first choice, but if you want to measure apple’s
display P3 mode, either the webserver code has to change to support additional
color spaces as you indicated, or play a media file and use spotread. It’s not
just for generating a ccss file. Using a media file might be easier as it will
also work for other displays such as HDR TV’s.
What would be better than suppressing the errors (my bash script ignores them)
would be to have a non-interactive mode for spotread. That is, do the read as
soon as the command is issued and don’t wait for a key press. Also nice would
be to still write to the output file if an error occurs, but return a negative
number for either the measurement number or the Y value so that you can detect
if an error occurred.
My plan was to make sure that you have at least three measurements that are
close, eg +/- 0.2 nits, and then average all the measurements that are close.
That way you can detect the change, detect if you did a measurement while the
pattern was changing (a single measurement that isn’t close to the one before
or after), and still allow for one measurement that has an error.
On Jun 12, 2018, at 6:05 PM, Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:
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.
