Some more progress on decoding the measurements packets. Klaus Karcher suggested that bytes 5-7, 56-58, 59-61, …, 77-79 (counting from 0), can be decoded as “nibble-swapped”. For example “9C 37 10″ decodes to 0×0173C9 or 95,177. He plotted these bytes and saw exponentially increasing curves. I was hoping that some of these curves would be the raw RGB measurements. Unfortunately, we know that the first three measurements are the red, green, and blue measurements independently, and therefore doesn’t fit the graph. Once we figure out the USB protocol, we can draw our own colored patches on the screen and get ground-truth measurements. That should help in figuring out the measurement packets.
Did you also count the black spot measurement at the beginning?
Measurement the black level doesn’t happen until the fourth measurement in this trace.
How are things coming along? what sort of help do you need ?
would a code svn set-up be helpfull? if so drop me email and i can set one up.
cheers!
Yan,
Looks like you’ve made some decent progress! The only thing I can suggest is try running Windows and the official driver under virtualization, and then using Linux as the host OS and capture packets that way.
I remember reading an article about reverse engineering USB wireless network card drivers that way; apparently involved a “reasonably simple hack” to libusb (for certain definitions of “reasonably simple” most likely). I could try to find it. it was presented at one of the black hat conferences a while back.
It would definitely give you a good amount of insight on what’s going on, and give you a second method of measuring packets (to root out bugs or missing data from your existing tools.)
–Brian
Yan,
Have you tried to use Spyder2Pro software?
It can take direct readings of sampled color even with colorimeter which came with Spyder2express. I think colorimeters are the same (only firmware is different).
You can access this function from “Tools>Colorimeter”
Come on guys, keep going! We really need this - developing an open source Spyder driver and open source tools would greatly help Linux adoption amongst graphic designers.
I’m not sure I can help on the driver front, but once the driver is working I’d love to help develop the calibration software.
I’m interested in what you’re doing… does this need an old Spyder colorimeter or does it work with the new ones too?
No news yet? Or did you run into legal actions?
Anyway, if you enter a serial number of Spyder2express in Spyder2Pro, you’ll get Spyder2express.
Guys - if you will develop open source Spyder driver I will seriously consider drinking myself to death.
That would be the most fantastic linux news of this century - hardware colour calibration… I can’t wait!
I am crossing my fingers.
Some hometheater enthusiasts have written color calibration software for their purposes. The software looks rather impressive and it can use Spyder II, DTP94 and Gretag EyeOne sensors as well as their own DIY sensor.
The software is licensed under GPL thus the source code is available, although only at request, from the developers. It is Windows only so I wonder if they are using some drivers from sensor manufacturers or have they written all of the code themselves. It might be worth asking!
http://www.homecinema-fr.com/colorimetre/index_en.php
Hey, cool work! I made similar tests than you did and came to the same conclusion: The real data is somewhere hidden in these (was it 80?) bytes. However, there’s calibration involved and I will probably do some tests without calibration (maybe it’s done in the driver!?).
If you want full control over the spyder under Win32, see http://colorhacks.blogspot.com where I published the API.
In fact the Spyder II has 7 sensors with different short wavelength cut-off filters, as a look inside the unit quickly indicates. The light sensors are TAOS TSL237’s, which are a light to frequency converter, so the readings are in fact integrated counts of the number of transitions of their output. There are a total of 3 x 8 x 24 bit values (72 bytes) for each reading, allowing for 8 sensors, the first of which isn’t populated. The three numbers for each sensor are the 1MHz clock start count, end count, and integrated frequency transitions since the last reset. For
doing a CRT reading the refresh frequency of the display needs to be established using the c2 and c3 commands.
Converting to XYZ entails scaling according to the integration time, and then applying the 3×9 floating point calibration factors read from the Serial EEPRom during the initialization sequence. There is also an additional 3×9 calibration factors that allow for non-linearity. And of course, the Xilinx XCS05XL PLD needs it’s pattern loaded before you can do anything. If you want any other details, I can send you the source to the driver I’ve just completed
GWG, that’s fantastic news! I’m glad you’ve made progress!