[argyllcms] Re: A bit of fun with a Datacolor 1005
- From: Philip Pemberton <philpem@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Tue, 19 Mar 2013 09:53:08 +0000 (GMT)
On Tue, 19 Mar 2013, Graeme Gill wrote:
The command which handles measurements is code 0x0A. This returns a
15-byte (12 measurement bytes plus the header). After stripping the
header, there are three four-byte big-endian signed integers left.
Sounds not too bad then. I was assuming that all the "smarts" was
in the host software, not in the device.
It seems to be at least partly based on the Colorsavvy Color Mouse - and
indeed identifies itself as such (actually IDs as "Datacolor Color Mouse
III").
There is another version ("CM4") which has a somewhat different control
protocol. This is probably the new auto-scanning SpyderPrint.
Unfortunately (?) I just have the CM3 / 1005. That said, given annotated
USB traces or hardware I could probably write a driver...
There's a fairly lengthy setup and calibration procedure too, which I'm
still working on (it seems to muck about with the spectro's memory via a
memory read/write command pair). The calibration is performed by a
single "calibrate white level" command...
Hmm.
I doubt it's much -- the API calls it uses (from the SpyderPrint DLL which
very helpfully had debug info left in place!) describe it as "set
measurement mode". The SpyderPrint software always seems to use mode 0x10,
whatever that is. There are options in the software for measuring density
instead of Lab but they're greyed out in my version of SpyderPrint.
Quite how I'm going to convert the scan data into a TI3 file... well,
that's another problem :P
If you can provide an outline of the commands and responses, it wouldn't
take too long to write a minimal driver for Argyll. I think I have
an instrument here.
What I'll probably do is write a small app to talk to the spectro, then
put that and the command documentation on Github or Bitbucket. You may
feel free to write your own driver or crib parts of mine as needed to make
it work with Argyll.
The scan button is also fairly easy to support - try and read a single
byte from the spectro's IN endpoint with a short timeout. If you get a
timeout, the button isn't pressed. If it is pressed, you'll get a byte
(0xFD if memory serves) in response.
If you're polling for the button using a background thread, you'll want
to protect the USB I/O and poll thread I/O with a mutex (two threads
accessing the same USB device at once would at least cause data corruption
or possibly a libusb crash).
--
Phil.
philpem@xxxxxxxxxxxxx
http://www.philpem.me.uk/
Other related posts:
