[Openicc] monitor profiling

[Hal V. Engel]

On Wednesday 07 March 2007 08:55, edmund ronald wrote:
> The open source issue is marginal to most companies' business, and
> many of them do not offer open source support not because of active
> opposition to the idea but mainly because they don't have the time to
> "waste" to think it over.
>
> Maybe politely indicating to Xrite that not fulfilling a customer
> request for support offers an niche and entry point for a competitor
> who does offer the requested support would provide some (slight)
> economic motivation for them, superior to the 1% of business that they
> would actually gain from the Linux community.

In late 2004 the number of end user Linux machines (the installed base 
excluding servers) had exceeded the number of MacIntosh machines (these are 
world wide numbers) at about 2.8% of the installed base.  In addition 
projections at that time were that the number of end user Linux machines 
would be 6% of the installed base by the end of 2006 and about 10% by 2010.  
A far as I know these projections have so far been close to what has 
happened.  So the potential is for this to be significantly more than a 1% 
kind of thing.

You can't sell hardware to users if your hardware does not work on their 
platforms and Linux is just now getting to the point where monitor profiling 
and calibration make sense for many users.  A year ago there was effectively 
no linux market demand for these devices because the underlying systems did 
not have good enough support for color management for this to be viable for 
most Linux/Unix/BSD (*nix) users. But today and going forward I think that 
the percent of *nix users who would purchase this type of device is going to 
start growing and will reach Windows like levels in two to three years.  That 
is in a few years the use of these devices will be nearly as common on Linux 
machines as on Windows machines.  

One of the interesting things about this is that the Mac, because of it 
history of use in the pre-press and graphics industries, uses these devices 
all out of proportion to the overall size of it's user base.  In fact 
GretagMacbeth started out only producing software that supported the Mac 
because at that time they didn't think there was a market for these devices 
on Windows.  I think this is the same mistake they are making with the *nix 
markets.  IE. thinking it is a 1% thing when it is likely to be a 10% thing 
when this matures in a few years. 

>
> I think a stronger argument is that Xrite is dominant in the color
> measurement business, and that a standardisation of interfaces to
> instruments always consolidates the advantage of the player who
> defines the interface.
>
> In practice, I think one only gets open source support in companies
> where there is an internal open-source advocate - maybe some senior
> scientist at Xrite would wish to act as such an advocate ?
>
> Surely, Xrite are seeing the practical benefits of open source, as the
> most solid color-managed platform is the Mac, and all the compilers
> and most of the Mac OS base layers and utilities are open-source.
>
> IBM is doing very well out of open source, thank you :)

X-Rite before the merger had good support for platforms that were not 
supported in their high level interface libraries in that they released 
documentation of the device protocol to registered developers and placed no 
restrictions on how that information could be used other than stipulating 
that those developers and not X-Rite were responsible for supporting any 
systems based on that information.  IE. the information could be used to 
build open source interfaces to the devices.  At one point this was also true 
of GretagMacbeth but they started to move away from this approach a few years 
ago.  X-Rite by withdrawing from the market all of the devices for which this 
information was available and not making the low level device interface 
information available for the remaining devices have effectively stopped 
supporting our platforms when they have traditionally provided that support 
in the past.   And they have done this right at the time when we most needed 
it.  Not a good way to build trust with this market segment.

GMBs SDK license for the EyeOne and the Huey is so restrictive that it 
actually precludes the use of this library in open source projects although 
the head of X-Rites software devision has told me that this was not what they 
had intended even though he acknowledges that this is in fact what it does.   
Post merger we see X-Rite adopting much if not all of the GMB approach to 
this.  

From my talks with GMB and X-Rite they appear to actually believe that having 
a closed interface gives them a market advantage.  I think this may be true 
on the software side of things but I also think that it actually hurts their 
efforts at marketing the hardware.  Of course, as soon as some *nix developer 
reverse engineers the low level interface that advantage, if there actually 
is one, is gone. 

Graeme is in the process of adding EyeOne Display and Pro support to ArgyllCMS 
and I think this will be available in the next release.  I have done some 
testing of the development ArgyllCMS code with my EyeOne Display* and it 
works nicely at this point if I ignore the nvidia twinview driver related 
issues with setting gamma curves (another issue that we need to start dealing 
with is the video card driver support for features needed for CM).  So it 
will not be too much longer and there will be open source drivers for the 
EyeOne line of devices.  So the other shoe is about to drop.

Hal

* All of my testing has been "blackbox" in that I didn't look at the code for 
the ArgyllCMS drivers and I avoided providing Graeme with any feed back 
beyond what a normal user would/could provide.  I did this because I have 
signed the EyeOne SDK license agreement and also an NDA with GMB and I want 
to make sure that I don't do anything that even has the appearance of 
violating either of those agreements.