[Openicc] monitor profiling

[Hal V. Engel]

On Monday 26 February 2007 06:32, Stefan Döhla wrote:
> Hi,
>
> > Jordi Canton wrote:
> >> I was just surfing looking for information about this specific device
> >> when I Found the following GPL licensed software called HCFR Colormeter
> >> that already supports Spyder2.
> >
> > I think you'll find that it supports the Spyder2 by using Datacolor's
> > MSWindows SDK for their instrument, therefore even though the
> > HCFR Colormeter software is GPL, the support for the Spyder2 is not.
>
> 1: The software doesn't use the "SDK" but simply loads the native
> user-space driver,
> which comes with some variants of Datacolor's products. This native
> driver is called "cvspyder.dll" and at least the function names are
> readable. It may not be that hard to extract the API from it - but
> this will probably be part of the ColorHCFR software.

This is hair splitting.  Graeme's point was that they are using the vendors 
library and the same calls to that library that are documented in the SDK.   
After all for these vendors the SDK is nothing but a document that describes 
the API, a header file and perhaps a few example programs.  So it really does 
not matter if they actually have a copy of the SDK or managed to figure out 
the API by digging around in the library binary.  The result is the same in 
the end.

The real issue is that the "user-space driver" is a closed source Windows and 
Mac only binary.  That is unless Datacolor also has this available for *nix 
systems (I was not able to find anything like this on their web site).  I 
have also asked them in the past if the interface library was available for 
Linux and they didn't even bother to respond to my request for information.

>
> 2: There's another software, called S2Fly, which was the first one using
> that API (at least as far as I know). The author may give you the
> reverse-engineered API as well.

Again if S2Fly is using the vendors interface library it simply does not 
matter unless the interface library is available for the platforms we need.  

As a side note the SDK information for the EyeOne library can be found on the 
net if you dig around enough.  Having that information would be comparable to 
having " reverse-engineered" the SDK APIs.  The problem is that the 
information is useless if X-Rite will not release the interface library for 
the platforms we use.  And so far at least they have not even though they 
have had linux versions of the library internally since at least 2004.  So we 
have exactly the same issue with X-Rite. 

>
> Starting from using cvspyder.dll - maybe one can issue the native USB
> commands as well - but that's not my expertise and I will stop
> issuing ideas at that point.

Now we are down to the meat of the issue.  Using a port sniffer to figure out 
how to interact with this type of device is a significant effort.  Even for 
someone who is very experienced at this, such as Graeme, it could take 100 to 
200 (possibly more) hours of effort to get an interface to the device that is 
good enough to consider a user test version and even more effort to have a 
production quality interface.  If the vendors would release interface 
protocol information for these devices a person who has worked on this type 
of thing could have a working interface in a few days effort.  This is an 
order of magnitude difference in the amount of effort required. 

Hal