[Openicc] Drop size calibration

[Hal V. Engel]

On Monday 04 February 2008 12:13:42 edmund ronald wrote:
> It would appear that Barbieri see themselves as a pure manufacturer of
> hardware -not software- and would like to set open interface
> specifications and export measurements a L*a*b* values, but
> unfortunately some of their "firmware" runs on the host platform and
> they cannot expose the source to this code  for a reason which I
> haven't been told. 

Much of the hardware that is out there now (not just these measurement 
devices) have significant functionality implemented in software on the host 
machine.  This is true for the EyeOne devices and it appears to be the case 
with the Barbieri hardware.  These bits of code are the "secrets" that the 
vendors are trying to hide and protect in the device interface 
libraries/drivers and this functionality is probably only about 5% to 10% of 
the code in the library.  In the past hardware vendors would have implemented 
this same functionality directly in the hardware.  By moving this to the host 
computer they reduce the cost of producing the hardware significantly and 
they gain the flexibility of being able to improve the "firmware" by simply 
creating new versions of the interface library/driver that have improved code 
for this functionality.

The underlaying issue that we are dealing with is that none of these vendors 
have figured out how to hide these details in an open environment and this is 
something that we need to work with them to resolve.  Either there is some 
way that will allow them to continue to hide these details without being too 
expensive or they need to come to grips with working out in the open.

We have seen this same issue with other vendors for other classes of hardware 
in the past.   A number of these vendors have decided to work in the open and 
none have suffered any ill effects from doing so.   If anything exactly the 
opposite has been true since the open source community embraces any company 
that takes this route.   But most hardware companies have an initial mind set 
that prevents them from embracing working out in the open because they have 
convinced themselves that they will be harmed by doing this even if there is 
no evidence that this is in fact the case.

> As we clearly have a device manufacturer 
> sympathetic to the needs of the open source community here, and who
> even says good things about argyll, I think we shouldn't scare them
> off,  and rather help them actively pursue a solution that would help 
> the userbase.

I agree 100%.

>
> As for my virtual box solution, I don't think communicating with the
> outside world is hard - if you go to the VMware site you will see a
> lot of virtual appliances that implement things like Apache, MySQL or
> LAMP and communicate very nicely with the nearby world via TCP/IP,
> while guaranteeing the user a stable, tested and preconfigured version
> of the target software. I don't think that exposing a port and an HTTP
> server that can be sent a request, maybe upload a target definition
> file,  and sends back a file with measurements is that hard in 2008.
>
> Edmund
>
> On Feb 4, 2008 8:35 PM, Hal V. Engel <hvengel at astound.net> wrote:
> > I have yet to see any well known open source advocate asking any hardware
> > vendor to open* the source code for their drivers.  What we want from the
> > vendors is open hardware interface specifications.  This is a very
> > different thing and is in no way comparable to requesting that the
> > vendors open their driver source code.
> >
> > On the other hand any hardware vendor that actually works with the open
> > source community on open source drivers gets extra points.  There are
> > major hardware vendors that are currently doing this.  This includes
> > Intel and AMD which are clearly the two largest hardware vendors in the
> > world.  In both cases the vendors supply specifications for both CPU and
> > GPU hardware to the open source community and both vendors are currently
> > providing funding and internal staff to provide these specifications and
> > to do some of the open source coding activity.