Monitor calibration sensor evaluations

[Mark D Segal]

Unfortunately, the number of devices that these excellent software packages support will likely decrease in the near future, thanks to new policies from X-Rite.
.....................

Personally, I will not buy another X-Rite product until these policies change.

--Rich Wagner

Of course the policies are not that "new" - the die has been cast ever since the merger with GMB, gobbling-up of the market, killing of perfectly satisfactory, usable products and software, and the huge licensing debacle they got themselves into with i1Profiler. One can only hope that technically and economically superior competition will emerge to put this seriously mismanaged corporation in its place - and until then it would indeed be very nice, if feasible, to avoid buying ANYTHING from X-Rite until the level of greedy monopolistic behaviour declines and the levels of concern with product quality and customer interests increases.

[digitaldog]

Since Richard decided to post this to the ColorSync list, and Tom Lianza of X-rite replied, I figured it might be a useful data point to the debate to share Tom’s reply. FWIW, Tom is the Chair of the ICC and Director of Advanced Development R&D at X-rite

To all,

It's hard to respond to so many erroneous opinions at one time, but I will
make some general comments.

1. OEM products.  When an OEM purchases a product from us, it is their
product.  There may be manufacturing differences, there may be firmware
differences.  Most important, X-rite cannot make a change to the product
without specific agreement with the OEM.  We can, and often do, make changes
in the retail line of products.  OEMs make specific volume commitments and
often invest a significant amount of R&D and supply chain cost to implement
the product in their product line.  They also service the product.  Some
display vendors put the calibration software in the display.  They have
every right to insist on absolute customization. When I designed the Sony
Artisan hardware I had to use a completely different strategy for
suppression of static because their standards exceeded the FCC and European
standards of the time.  We also had to re-engineer the cable so that the
insulation could be physically consumed.  This required a change in the
production techniques of the cable and very specific testing for impurities.
OEM's invest heavily in their products and they need to protect that
investment.  They are not screwing the consumer.  Comments like that
indicate a total ignorance of the position that OEM's are in.

2. The small developer- Independent developers are an important part of our
business.  The question is: who supports the hardware product? A developer
like Graeme Gill "cracks" our products at "arm's length".  In the US, this
is completely legal and has been defended in court many times (the DOS BIOS
is a good example of how this worked).  He applies his technology to a
product that was legally purchased through retail channels.  What would be
illegal would be to make copies of our software and sell it using the
cracked technology or to ship our drivers, unlicensed, to the field. In the
life a given hardware product, independent software developers will make
many upgrades and not all of them will be free.  We make money on hardware
once, and that piece of hardware is an "enabler" for many other companies
over the course of its lifetime.

I believe that there  will be a mechanism for independent developers to use
the latest technology colorimeter, purchased through retail channels, but I
need to confirm that.  Understand that the latest technology products are
significantly different than the earlier products and do require a certain
amount of training to implement properly. It's not in anyone's best interest
to open the technology to everyone who thinks they are a developer until we
understand the support and training costs.  Not everyone is a Karl or
Graeme.  Is it in the consumers best interests to have poor software
implementations of new hardware technology?  Should we make exceptions for
certain developers who may have the knowledge and not allow other developers
into the fray?  How do we make sure that an iSV product doesn't kill a
retail product by overlaying different dll's or packages?   How do we cover
release of information that is currently under application for patent?  How
do we inform ISV's of changes that are warranted by changes in operating
systems.  How do we justify the costs of system support to the ISV community
given that we make money only on the sale of the hardware item? There is
nothing nefarious here, it just takes time and resources which are not
available at the moment.

Third hand comments about internal corporate policy (which, by the way is
probably covered by NDA)  such as those from Mr Wagner, should not generate
the frenzy of nonsense that we have seen on this list.  Snarky and
uninformed comments like those of Mr. Segal add nothing to a solution to the
issues of ISV support. I hope that you all have a better understanding of
the situation and we can end this mindless thread started with third hand
information taken out of the context of reality.....
Tom Lianza

[Mark D Segal]

Yes I saw that and responded to it:

"Reality" is perceived by different people in different ways depending on, amongst other things, at which end of the spectrum they happen to sit, what their interests are, and how these matters affect them personally. While some peoples' reality is other peoples' snark, we'll see over time which perspective prevails. And if there is really critical misinformation out here, maybe the company needs to do more to correct that. Over the years of corporate history, the demise of bigger fish than XRite started when they just couldn't truly and seriously see beyond themselves and their self-perceived immediate interests.
 
Mark

In the final analysis, my perceptions don't matter. What matters is the judgment of the market in which I am only one in a cast of many thousands. But that cast and other developers around the world will decide the future of colour management alternatives. Time and the market will tell how XRite fares. Of course it's a complex reality - they've made a spectrum of stuff from lower quality to very high quality, and we all know that every product embodies compromises. However, the issues at stake here go beyond that. I'll leave it at that.

[Mark D Segal]

Just after returning to my email Inbox, I received the following from the Colorsync List:

"Mailing list removal confirmation notice for mailing list
Colorsync-users

We have received a request for the removal of your email address,
"............" from the colorsync-users@lists.apple.com mailing
list.  To confirm that you want to be removed from this mailing list,
simply reply to this message, keeping the Subject: header intact.  Or
visit this web page........"

I have notified the List administrator that this is a malicious action, I did not request to be removed from the Colorsync List and the perpetrator should be investigated. Nuff said.

[shewhorn]

Rich, and Andrew,

Thanks for that additional information. It would appear to me that not all the facts are out there yet. While the information that Rich posted confirms what Jack Bingham at Integrated Color (Color Eyes Display Pro) had said about 3rd party support for a retail version of the i1 Display Pro, my email to BasICColor, and the announcement that Spectraview would support the i1 Display Pro (although I'm not sure if it was specified whether or not it would only support the model that they are going to sell, or if it would support retail versions as well) would seem to be in disagreement with the information Rich posted and suggest that X-Rite is indeed making exceptions. I'm not sure.  I think we're going to have to wait and see to find out how this pans out.

Cheers, Joe

[digitaldog]

... and the announcement that Spectraview would support the i1 Display Pro (although I'm not sure if it was specified whether or not it would only support the model that they are going to sell, or if it would support retail versions as well) would seem to be in disagreement with the information Rich posted and suggest that X-Rite is indeed making exceptions.

I don’t know either but I’m excited that there will be this new instrument available for use in SpectraView. I’m not really that concerned if it will only operate with that software package, especially if the hardware is better mated to the panels.

[shewhorn]

I don’t know either but I’m excited that there will be this new instrument available for use in SpectraView. I’m not really that concerned if it will only operate with that software package, especially if the hardware is better mated to the panels.

Agreed. I will get one as soon as Spectraview II or Spectraview Profiler releases a version that supports it.

[Alan Goldhammer]

Andrew, thanks for posting the response from Tom Lianza.  He makes a good point that there is nothing to prevent any third party developer from writing their own driver to make new instrumentation available.  As he noted, Graeme Gill has been doing this for some time (as a one man shop!) to provide hardware support for ArgyllCMS.  He already supports a bunch spectros and as users provide him with the funds to buy new instruments, he will continue this.  I know that I'm a bit of a contrarian and don't believe that there is any conspiracy by X-Rite here but believe that there are opportunities for developers to come out with both new hardware and software solutions.  I won't be surprised at all if NEC source some of the newer hardware and mate it to Spectraview.

[Mark D Segal]

Alan, just to be clear, I think its useful to draw a distinction between "conspiracy" and "questionable policies". All of my concerns and those I've seen expressed by quite a few others, whatever their factual basis, are in the latter area.

[digitaldog]

Andrew, thanks for posting the response from Tom Lianza

There’s more just in:

As the product manager for our Display Solutions at X-Rite, let me try to
clarify a few things regarding OEM and 3rd party developer support for our
new i1D3 based colorimeters.  There seems to be lot’s of confusion here.
First and foremost, X-Rite absolutely does allow OEMs and 3rd party
developers access to our i1Display Pro retail instruments.  Karl Koch
already mentioned it here on the ColorSync List that BasICColor will support
our retail product and I now have permission from EIZO to announce that a
soon to be released version of ColorNavigator software will also support our
retail i1Display Pro device.  In addition, while I cannot mention their
names, I can tell you that there are more OEMs & developers currently
working on integrating our channel device into their software solutions.
So, for any other OEMs or third party developers that wish to also support
our retail i1Display Pro device, please contact devsupport@xrite.com and ask
for our “i1Display Pro License Request Form”.  Second, regarding support of
OEM versions of i1D3, this is not an X-Rite issue at all.  Any software
developer who wishes to support an OEM version of the i1D3 device must
contact and obtain this ability from that OEM.  I hope this clarifies things
and I must say it’s nice to see such the demand for our new products.

Best regards,
Steve.

[WombatHorror]

SVII measures the native TRC of the display in 8, 16, 32, or 52 steps, and puts correction curves in high-bit LUT of the display. So poor dark readings of the i1Pro have obvious and noticable effect.

Are you sure about that, that it is actually calibrating at each measured step on the PA series? Because when I use say some random program with some other monitor then I may see weird tints in dark colors but I never see any weird tints in the grayscale with the SV II whether I use NEC i1D2 or i1Pro with it.

My feeling is that  with the PA series it just measures it and reports along the way in those steps but it doesn't use them to send anything to the LUT and that it just feeds the system the adjustments to set color temp at a fairly bright white and that is it.

[WombatHorror]

Rich, and Andrew,

Thanks for that additional information. It would appear to me that not all the facts are out there yet. While the information that Rich posted confirms what Jack Bingham at Integrated Color (Color Eyes Display Pro) had said about 3rd party support for a retail version of the i1 Display Pro, my email to BasICColor, and the announcement that Spectraview would support the i1 Display Pro (although I'm not sure if it was specified whether or not it would only support the model that they are going to sell, or if it would support retail versions as well) would seem to be in disagreement with the information Rich posted and suggest that X-Rite is indeed making exceptions. I'm not sure.  I think we're going to have to wait and see to find out how this pans out.

Cheers, Joe

And what about Argyll or Colorimetre HCFR or the independent coder? Locking things down like this, especially items of this nature usually ends up biting the company in the end (although Apple has managed OK I guess, but then again Apple is Apple).

[RichWagner]

Andrew, thanks for posting the response from Tom Lianza.  He makes a good point that there is nothing to prevent any third party developer from writing their own driver to make new instrumentation available.  As he noted, Graeme Gill has been doing this for some time (as a one man shop!) to provide hardware support for ArgyllCMS.  He already supports a bunch spectros and as users provide him with the funds to buy new instruments, he will continue this.

There is a huge difference in software development in using a SDK specific to a given device firmware vs. having the electrical engineering know-how to reverse-engineer the firmware.  Doing the latter requires sophisticated and expensive electronics benchwork and know-how. There are few in this field that have that expertise.  Graeme's background in electrical engineering gives him an uncommon advantage. Even so, it would require significant labor, and I'm sure Graeme has more interesting things to do that are of greater interest to the Argyll community.

Many software developers depend on the EyeOne SDK.  Their lack of access to a significant subset of EyeOne devices becomes particularly frustrating, as their expertise is in color science and software development, not reverse-engineering firmware.  The HP-XRite DreamColor colorimeter is a great example. I certainly never expected that the HP-XRite DreamColor colorimeter would only function with the HP-XRite software when I bought it, OR that the HP-XRite DreamColor software would be so poor and feature-deprived.  This expensive colorimeter is not supported by ANY other software - even XRite's Match, ProfileMaker 5, Profiler, etc.  Software support is non-existent.  HP tech support is clueless, and X-Rite says it's HP's problem - even though the software is downloaded from X-Rite's web site. Even searching for the software on X-Rite's web site is futile.  So who wins?  HP... in the short term.  Certainly not the DreamColor monitor owner.

--Rich

[bossanova808]

Eizo have announced support for the i1Display Pro in CN6.1, NEC have said they pan to support it in SV2 although not quite officially yet, I think, BasicColor have announced support and X-Rite have clearly and publicly, several times now, stated that they have anSDK availably for the X-Rite i1Display Pro to be accessed by other apps if that app is willing to license it.

Re-badged ones can not be used in other software (so you buy an NEC badged one and you won't be able to use it in i1Profiler, for example).

This would appear to be exactly the same scenario as with the i1Display 2 (and other calibrators for that matter too).

So seriously - what's the issue here?  It's pretty clear and it's just as it was...

[digitaldog]

I certainly never expected that the HP-XRite DreamColor colorimeter would only function with the HP-XRite software when I bought it, OR that the HP-XRite DreamColor software would be so poor and feature-deprived.  This expensive colorimeter is not supported by ANY other software - even XRite's Match, ProfileMaker 5, Profiler, etc.  Software support is non-existent.  HP tech support is clueless, and X-Rite says it's HP's problem - even though the software is downloaded from X-Rite's web site. Even searching for the software on X-Rite's web site is futile.  So who wins?  HP... in the short term.  Certainly not the DreamColor monitor owner.

Clearly X-rite is at fault here and HP as well as the buyer is immune.

Yet another reason I was glad I listened to DreamColor early adopters who knew about this technology (people like Lang and Murphy) and didn’t bite.

[digitaldog]

So seriously - what's the issue here? 

Good question!

[dchew]

I plan to purchase an NEC PA241W-BK.  I currently have only a 17” mbpro, along with the x-rite i1pro spectrophotometer.  As discussed ad nauseum, my recent upgrade to Lion renders iMatch useless.  So I wonder if my plan should be:
-Get the NEC with the SVII for monitor profiling.
-Use some other software along with the i1pro for printer-paper profiles.

Some questions:
1.   What software should I choose for running printer-paper profiles?

2.   I figure I will try the SVII on my laptop screen also.  Given the above reported tests, the SVII may not work to well for that.  If not, l will just go back to the legacy profile I created with i1Match just prior to the Lion upgrade.  Does that sound reasonable assuming the laptop will no longer be the critical monitor?

3.   Does my plan make sense or is there a better path forward?

Dave

[Alan Goldhammer]

I plan to purchase an NEC PA241W-BK.  I currently have only a 17” mbpro, along with the x-rite i1pro spectrophotometer.  As discussed ad nauseum, my recent upgrade to Lion renders iMatch useless.  So I wonder if my plan should be:
-Get the NEC with the SVII for monitor profiling.
-Use some other software along with the i1pro for printer-paper profiles.

Some questions:
1.   What software should I choose for running printer-paper profiles?

2.   I figure I will try the SVII on my laptop screen also.  Given the above reported tests, the SVII may not work to well for that.  If not, l will just go back to the legacy profile I created with i1Match just prior to the Lion upgrade.  Does that sound reasonable assuming the laptop will no longer be the critical monitor?

3.   Does my plan make sense or is there a better path forward?

Dave

I suspect that SVII won't run on your laptop screen since it is designed for stand alone NEC monitors that can be addressed by the software.  Since you are getting a NEC monitor don't even bother trying to do anything with your laptop screen as it's probably a waste of time.  Depending on how much time you want to invest ArgyllCMS can be used to profile both papers and your screen (and a lot of other things).  A number of us who regularly post here use this and it's free so the price is right.  I've profiled all my papers using an i1 Pro and ArgyllCMS and am currently running my NEC monitor off an Argyll generated profile (I also have SVII).

[Czornyj]

ArgyllCMS 1.3.4 is out there with i1display pro/ColorMunki display support. A couple of very interesting and highly informative insights from Graeme Gill:
http://www.freelists.org/post/argyllcms/Argyll-V134-released

> Could you comment on their quality compared to the old i1 Display II and
> the Spyder III all dall used with ArgyllCMS?

I haven't done any real comparisons with a spectrometer, but my impression is
that (at least on non-refreshed displays such as LCD's) that they are pretty
good.
The filters seem very close to the standard observer in shape, and the optical
arrangement captures lots of light, giving good resolution readings, and
(in the case of the i1 Display Pro), very fast readings if the patch is
not too dark. Their precision at low light levels is excellent, although they
slow down a bit.
The optics ensures a narrow acceptance angle, and therefore they seem good
at distant measurements, such as measuring a display including flair,
or measuring projectors.

For refreshed displays such as CRT's, then I think the DTP92 and DTP94
are still superior, since they synchronize properly to the refresh rate.

To get some idea about how close the filters are to the standard observer,
I did the following: For a set of display sample XYZ values of the primaries
+ white, for each pair of calibration matrices for the different display
types, I computed the CIEDE2000 between the values predicted by the two
matrices.
Over the 147 combinations, there was an average error of 0.798 DE, and a
maximum of 4.72. I think this hints that the instruments will perform very
well across different types of displays.

> To get some idea about how close the filters are to the standard observer, I
> thought one had to measure the whole 380 to 730 spectrum, using a 1nm (or
> not too larger) spectrograph, to break the spectrum into "lines", so that
> one can get the response of the colorimeter at that particular wavelength

This information is stored in the instrument.

> just wondering, do these gadgets now have the individually measured
> sensitivity curves stored in their eeprom?

Indeed they do.

[RichWagner]

Graeme also wrote:
 

Support for the X-Rite i1 Display Pro and ColorMunki Display colorimeters (i1d3).
 While these instruments seem to be quite good without specific display calibration,
 they can benefit from it, so a new type of Argyll colorimeter calibration file has
 been created (CCSS) to support the type of calibration these instruments use.
 ccmxmake has been renamed to ccxxmake and support added for creating CCCS calibration
 files using a spectrometer instrument. A new tool called i1d3ccss allows the calibration
 files that come with the instruments to be translated into CCSS files and installed.
 A CRT calibration is provided, something that is missing from the manufacturers set.
 Non-1931 2 degree observer support has been added for these instruments, taking advantage
 of the type of calibration they use.

///

Marco wrote:
I have not understood, it is possible load the correction directly into the instrument so that
it can be used with every software?

Which instrument do you mean ?

Most colorimeters use a 3x3 calibration matrix which is stored in the
instrument EEPRom.

The i1d3 uses a different approach, and instead uses spectral measurements
from display to optimize it's accuracy for that type of display. Typically
these measurements are stored in a file (.edr files for X-Rite, .ccss for
ArgyllCMS).

and

Florian Höch wrote:
Graeme, regarding the slower measurement speed of the ColorMunki
Display, do you think this a hardware difference or maybe a difference
in firmware? I'm just curious. I only know from one unofficial source
which previously stated that they should be about the same (in speed)
when used with the same software (ie. when using the ColorMunki with i1
Profiler), but it seems that was just a rumor?

My guess is that the firmware adds about a 1 second delay to each
reading (or maybe imposes a minimum of 1 second per reading). The
instruments otherwise seem to operate identically, including the
integration time set, which is a lot less than 1 second.

So in terms of differentiating the two products, X-Rite have been
smart in making it something that a different driver can't overcome.