Over-red display profiles

[Richard Hughes]

Last night I was hunting the overly-red-crazy-temperature VCGT bug. I
think the error is in two parts. First, the way I 'm calculating the
factory calibration matrix isn't optimal (for the details, I'm finding
the 4-color method is quicker and more accurate than ASTM-96) and
there's also something screwy when you tell argyllcms you want a D65
whitepoint.

By selecting "Native whitepoint" on the configuration wizard I'm
getting a much better D65 profile without the super red tint. Tonight
I'm going to try to figure out what's changed in argyllcms between 1.2
and 1.4 that could affect this in such a bad way. The code is very
complex, so it might take a bit of time to work out. I'd be interested
to hear if native calibration fixes the tint for other people too.

I'll also try to regenerate the device calibration files when the
difference between the least-error and 4color values is so large. I've
kept all the .ti3 files for all the devices already "in the wild" so
it should be an easy process to recreate them. I'll let you all know
how I get on.

Richard

[George Sedov]

Hi,

Just tried with "native" (at least I think it was "native", because in
russian gnome they used the word which is translated as "custom"), and
yes, it looks much better. Feels reddish, but this time it looks like a
correct flavor of reddish, the one you expect when calibrating the
laptop screen.

Have a question about argyllcms-1.4: it have this piece of code
/spectro/insttypes.c

if (idVendor == 0x04d8) { /* Microchip */
if (idProduct == 0xf8da) { /* Hughski ColorHug */
#ifndef ENABLE_COLORHUG
if (getenv("ENABLE_COLORHUG") == NULL)
return instUnknown;
else
#endif
return instColorHug;
}
}

because of which I couldn't start validation for an hour. Whose idea was
it? What is the purpose of this? If you're including colorhug support by
default, do it properly, or at least tell the user why it's not working.
Something like "if you want to use colorhug, export ENABLE_COLORHUG=1"
in stdout, although I really can't imagine how it can be, that someone
inserted colorhug device, launched calibration software, but STILL don't
want to use it.

Cheers,
George

[Derek Holdaway]

Yeah I just did a native white point calibration and the results are much better. White is no longer red :)

I have attached the .ICC files. The 15-06-53 was from selecting D65, the 17-21-28 was selecting D50, and the 09-47-13, was after selecting Native.

[Graeme Gill]

Richard Hughes wrote:
> By selecting "Native whitepoint" on the configuration wizard I'm
> getting a much better D65 profile without the super red tint. Tonight

I would suspect that's just because the instrument isn't accurate. If
the default display white point is close to the daylight or black body
curve and the instrument is way out, then the native white point
will look better.

[If you have a specific bug scenario that you can reproduce with a known
accurate instrument like the i1pro, ColorMunki or i1d3, then please report it
and I will investigate.]

Graeme Gill.

[Graeme Gill]

George Sedov wrote:

> Have a question about argyllcms-1.4: it have this piece of code
> /spectro/insttypes.c
>
> if (idVendor == 0x04d8) { /* Microchip */
> if (idProduct == 0xf8da) { /* Hughski ColorHug */
> #ifndef ENABLE_COLORHUG
> if (getenv("ENABLE_COLORHUG") == NULL)
> return instUnknown;
> else
> #endif
> return instColorHug;
> }
> }
>
> because of which I couldn't start validation for an hour. Whose idea was
> it? What is the purpose of this? If you're including colorhug support by
> default, do it properly, or at least tell the user why it's not working.

It's not enabled by default because the ColorHug doesn't work on all
the platforms that ArgllCMS supports. As such, it would be wrong to claim
that the ColorHug is a supported device in Argyll, and you will note
that it is not listed in the "supported instruments" list. It is instead
"experimental", as was noted in the V1.3 release announcement, and nothing
has changed since then. [ It was an oversight that some mention is not
made in the documentation, and I have now corrected the online version.]

If/when it proves to run reliably on MSWin, OS X and Linux, I'll remove
the experimental status, and enable it by default.

Graeme Gill

[Richard Hughes]

On 10 May 2012 04:28, Graeme Gill <gra...@argyllcms.com> wrote:
> [If you have a specific bug scenario that you can reproduce with a known
> accurate instrument like the i1pro, ColorMunki or i1d3, then please report it
> and I will investigate.]

I've seen the crazy pink bug with my Huey, and Ross has experienced a
*very* pink screen when using a Spyder 2. Should I should restrict the
color temperature selection screen to the i1pro, ColorMunki and i1d3
only, and force all the other instruments to native?

Thanks,

Richard.

[Graeme Gill]

Richard Hughes wrote:
> I've seen the crazy pink bug with my Huey, and Ross has experienced a
> *very* pink screen when using a Spyder 2. Should I should restrict the
> color temperature selection screen to the i1pro, ColorMunki and i1d3
> only, and force all the other instruments to native?

Hi,
that doesn't make clear whether it's a software bug or
problems with the accuracy of the meters (It's not uncommon to
see reports of tints after calibrating with the Huey, i1d2, Spyder
when using the instrument vendors SW. Typically this comes down
to the filters aging. That's what you get with plastic filters...)
If it's a software bug, then making such a change merely covers it up,
which will just mean it takes longer to eventually track down and fix.

I personally think that defaulting to native white point is probably
a reasonable thing, with the user having to take some positive action
to select something else. Presumably they will do this because they
have some idea of what they are doing, and why they are doing it.

Graeme Gill.

[George Sedov]

В Чтв, 10/05/2012 в 13:42 +1000, Graeme Gill пишет:

Still, I can't imagine how it can be useful.
Someone inserted colorhug into his computer. Then this someone launched
argyllCMS. Question: why did he do it? What he expects to get? I
suggest, that he wants to calibrate his screen, NOT to see "device can't
be initialized" message. You want the user to provide the env variable
in order to use the device. But he just provided the device itself (by
inserting it), isn't it proof enough that he wants to use it?
There are plenty of ways to tell the user that the support is
experimental, although I really can't imagine how can someone get
colorhug device without knowing that it's in beta state.

[Richard Hughes]

On 10 May 2012 10:25, George Sedov <radist...@gmail.com> wrote:
> Still, I can't imagine how it can be useful.
> Someone inserted colorhug into his computer. Then this someone launched
> argyllCMS. Question: why did he do it? What he expects to get?

In newer versions of gnome-color-manager, I'm explicitly setting
ENABLE_COLORHUG=1 before launching the argllcms commands. I don't
agree that it's the right thing to do, but I can respect it's Graemes
choice. What we need to do is fix the OS X and Microsoft Windows HID
problems and then it can be a proper-supported device in Argll.

Richard.

[Graeme Gill]

George Sedov wrote:

> Still, I can't imagine how it can be useful.

It's quite useful in avoiding a stream of "why doesn't my
ColorHug work on MSWin or OS X, when you claim it does"
complaints and queries.

> Someone inserted colorhug into his computer. Then this someone launched
> argyllCMS. Question: why did he do it? What he expects to get? I

The same as plugging any other non-supported instrument in - it doesn't
appear in the list of instruments, because it's not supported as a
fully functioning device.

> suggest, that he wants to calibrate his screen, NOT to see "device can't
> be initialized" message. You want the user to provide the env variable
> in order to use the device. But he just provided the device itself (by
> inserting it), isn't it proof enough that he wants to use it?

The user can wish all they want, that doesn't make it magically work.
Someone has to write the code, debug it, test it and continue to support it.

Graeme Gill.

[Pascal de Bruijn]

Exactly. We are quite grateful you included the code into argyll at
this stage. So at least argyll doesn't need to be manually patched
before the ColorHug can be used.

Thanks,
Pascal de Bruijn

[Richard Hughes]

On 10 May 2012 10:49, Pascal de Bruijn <pmjde...@pcode.nl> wrote:
> Exactly. We are quite grateful you included the code into argyll at
> this stage. So at least argyll doesn't need to be manually patched
> before the ColorHug can be used.

More than quite grateful, *very* grateful :)

Richard.

[Matthias Welwarsky]

On Thursday 10 May 2012 17:40:17 Graeme Gill wrote:
> I personally think that defaulting to native white point is probably
> a reasonable thing, with the user having to take some positive action
> to select something else. Presumably they will do this because they
> have some idea of what they are doing, and why they are doing it.

I think for "blueish" laptop screens "native whitepoint" is essentially
useless.

br,
matthias

[k2]

I'm just tried to calibrate Benq GL2450 with new firmware/livecd. The result is still quite reddish. But it is less than before, IMHO. And there is no whitepoint selector in the calibration wizard (is this feature?).

---
Best regards,
Kirill Kozlovkiy

10.05.2012 13:51 пользователь "Richard Hughes" <hugh...@gmail.com> написал:

[Richard Hughes]

On 11 May 2012 09:01, k2 <kiri...@gmail.com> wrote:
> I'm just tried to calibrate Benq GL2450 with new firmware/livecd. The result
> is still quite reddish.

Right, D65 is a lot warmer than most laptop displays. Ever time I go
past a "blue" Lenovo screen I cry :)

> But it is less than before, IMHO. And there is no
> whitepoint selector in the calibration wizard (is this feature?).

Yes, that's a bugfix, as we've found the colorimeter devices (even
spyder, huey, etc) are not accurate enough to use anything other than
native.

Richard.

[Matthias Welwarsky]

I'm pretty sad about losing the whitepoint selector. Actually, calibration
towards a D65 white point worked rather well on my Lenovo T520 LCD. I found it
very yellow-ish for a week, now it is fine and I regard all other LCDs I work
with too cold. On the contrary, the native white point of the display is in my
opinion way too cold for any kind of photography related tasks. Why not go
with "native" as the default and leave the final choice to the user?

br,
matthias

[Peter D'Hoye]

I'm also having overly red results (compared with a white paper next to it), and I was wondering more stuff:

With the live CD I'm using a different graphics driver than with my normal distro (ubuntu 10.10 for now, probably LMDE soonish) using AMD catalyst driver. And when checking gamma via http://www.lagom.nl/lcd-test/gamma_calibration.php I see the results are off (red being at 2.55, green and blue 2.4).

I was assuming the whole calibration via a detector would have been much simpler than fiddling with sliders while watching charts :/

[Pascal de Bruijn]

On Mon, May 21, 2012 at 3:19 PM, Peter D'Hoye <peter...@gmail.com> wrote:
> I'm also having overly red results (compared with a white paper next to it),
> and I was wondering more stuff:

I'm not trying to refute if the display is too red or not... (it very
well may be)

But using a white piece of paper to compare is a rubbish test at best.
As paper often isn't really neutral white (most have fluorescents in
them) and your lighting probably isn't near daylight (I'm sure mine
isn't :D).

> With the live CD I'm using a different graphics driver than with my normal
> distro (ubuntu 10.10 for now, probably LMDE soonish) using AMD catalyst
> driver.

I have nice packages available for Ubuntu Precise on my PPA, where you
aren't dependent on the LiveCD anymore.

> And when checking gamma via
> http://www.lagom.nl/lcd-test/gamma_calibration.php I see the results are off
> (red being at 2.55, green and blue 2.4).

Argyll defaults to gamma 2.4, so that's expected:

http://www.argyllcms.com/doc/gamma.html

Eyeballing these things usually isn't a great way to verify these
things. It's only good for detecting huge problems.

> I was assuming the whole calibration via a detector would have been much
> simpler than fiddling with sliders while watching charts :/

Regards,
Pascal de Bruijn

[Peter D'Hoye]

I'm not trying to refute if the display is too red or not... (it very
well may be)

But using a white piece of paper to compare is a rubbish test at best.
As paper often isn't really neutral white (most have fluorescents in
them) and your lighting probably isn't near daylight (I'm sure mine
isn't :D).

I'm not discussing subtle tones, the color is way off. And I'm actually near daylight, no artificial light on.

> With the live CD I'm using a different graphics driver than with my normal
> distro (ubuntu 10.10 for now, probably LMDE soonish) using AMD catalyst
> driver.

I have nice packages available for Ubuntu Precise on my PPA, where you
aren't dependent on the LiveCD anymore.

except that I'm on 10.10 since I do not want to touch unity of gnome3, even with a very long stick, for now.
 

Argyll defaults to gamma 2.4, so that's expected:

http://www.argyllcms.com/doc/gamma.html

Eyeballing these things usually isn't a great way to verify these
things. It's only good for detecting huge problems.

 Thanks for the link. Actually, the value is off enough to be a huge problem :/

Peter

[Richard Hughes]

On 21 May 2012 15:29, Peter D'Hoye <peter...@gmail.com> wrote:
>  Thanks for the link. Actually, the value is off enough to be a huge problem

Are you calibrating to a native whitepoint? If your using the LiveCD
you shouldn't have the option to choose any more. If so, can you tell
us what kind of screen you're trying to calibrate? Thanks,

Richard.

[Peter D'Hoye]

> Are you calibrating to a native whitepoint? If your using the LiveCD
> you shouldn't have the option to choose any more. If so, can you tell
> us what kind of screen you're trying to calibrate? Thanks,

I'm using the live cd that came with it (today), the display is a dell
2001FP.

And forget about my musing about graphicsdrivers, it's already off while
using the live cd...

Peter

[Richard Hughes]

On 21 May 2012 15:41, Peter D'Hoye <peter...@telenet.be> wrote:
> I'm using the live cd that came with it (today), the display is a dell
> 2001FP.

Does anybody on the list have a 2001FP and a ColorMunki? It seems to
be quite a popular monitor and I think this is the second person on
the list with a 2001FP needing a CCMX. If needs be, I can buy a used
2001FP quite cheap and create a CCMX myself, but would obviously
prefer not to.

Richard

[Chris Lilley]

On Sunday, May 13, 2012, 12:58:24 PM, Richard wrote:

RH> On 11 May 2012 09:01, k2 <kiri...@gmail.com> wrote:
>> And there is no
>> whitepoint selector in the calibration wizard (is this feature?).

RH> Yes, that's a bugfix, as we've found the colorimeter devices (even
RH> spyder, huey, etc) are not accurate enough to use anything other than
RH> native.

*Some* colorimeter devices (spyder 2 and 3, huey, colorhug) are not accurate enough out of the box. Thus they may be ok to read luminance and create a LUT ramp, but not to read chromaticity and thus correct the WB in that ramp.

Others (i1D3) are reasonably accurate out of the box.

Some (spyder 3, colorhug) improve a lot when a suitable calibration matrix is available.

Some (i1D3) improve a bit with a calibration matrix, too.

--
Chris Lilley Technical Director, Interaction Domain
W3C Graphics Activity Lead, Fonts Activity Lead
Co-Chair, W3C Hypertext CG
Member, CSS, WebFonts, SVG Working Groups

[Richard Hughes]

On 21 May 2012 17:29, Chris Lilley <ch...@w3.org> wrote:
> Some (spyder 3, colorhug) improve a lot when a suitable calibration matrix is available.

I'd agree with this summary. Does anybody know of a list of popular
external monitors used nowadays? I've tried to use Smolt[1] but that
just returns the video card used, not the monitor as supplied by the
EDID data. I'm not super comfortable asking the user to upload the
EDID for statistics purposes when calibrating, although that might
indicate what monitors are worth buying for testing.

Richard.

[1] http://smolt.fedoraproject.org/static/stats/by_class_VIDEO.html

[Yan-Fa Li]

I'm more than happy to upload EDID data for the all the monitors I
have access to. I have access to at least 6 or 7 different models of
LCD monitor. I calibrated my Lenovo x120e and a late 2011 macbook pro
15" and the macbook running OSX turned out much better, but I get a
noticeable ghosting effect while scrolling now.

As an early adopter I feel I'm expected to help, so please let us know
what we can do. I don't really have 500USD to spend on a colormunki
though :)

Unfortunately the kde install, running arch linux, I have on the
lenovo isn't cooperating with colord-kde (git head) and gives me
errors when loading the profile. I looked at the code and it looked
like it was a copy error. I'm guessing it just doesn't handle the case
where the file already exists and needs to prompt to overwrite. I
haven't had time to figure out what the right way to report issues to
Daniel's project is.

Yan

--
"We do not learn so much by our successes as we learn by failures --
our own and others'.  Especially if we see the failures properly
corrected."
-- Frank Lloyd Wright

[peter merhaut]

Hi,

after calibration i've got a pretty red tone, white doesn't seem white
any more. i've used the latest livecd (10.05). I've got an Iiyama
ProLite E2403WS.

[Dirk Beck]

Hi,
I have the same problem. I have an Iiyama ProLite B2409HDS on Ubuntu 12.04 and an iMac 21.5 ".
I have received on Saturday my Colorhug. Everything is going great just a bit too red.

[Alexander Wright]

I also have a calibration that is off by a country mile!

I'm using a Benq E2220HD

profile attached, if that's any help!

Alex.

[Richard Hughes]

On 21 May 2012 18:39, Alexander Wright <alex...@wright-family.me.uk> wrote:
> I'm using a Benq  E2220HD

I've attached a screenshot of your profile. The VCGT is pretty crazy.
Graeme, I thought the VCGT for all channels was supposed to go through
display white (i.e. join at rgb 255,255,255) for a native calibration?

Richard.

[Chris Lilley]

On Monday, May 21, 2012, 7:39:20 PM, Alexander wrote:

AW> On Monday 21 May 2012 15:33:34 Richard Hughes wrote:
>> On 21 May 2012 15:29, Peter D'Hoye <peter...@gmail.com> wrote:
>> > Thanks for the link. Actually, the value is off enough to be a huge
>> > problem
>> Are you calibrating to a native whitepoint? If your using the LiveCD
>> you shouldn't have the option to choose any more. If so, can you tell
>> us what kind of screen you're trying to calibrate? Thanks,

>> Richard.

AW> I also have a calibration that is off by a country mile!

AW> I'm using a Benq E2220HD

AW> profile attached, if that's any help!

It is. The profile shows the red colourant to be at x=0.691, y=0.348 which is outside the spectral locus (so, more saturated than even a pure single wavelength source could be. not physically possible).

The green looks more saturated than I would have expected, but is easily physically possible.

[Richard Hughes]

On 21 May 2012 18:52, Chris Lilley <ch...@w3.org> wrote:
> It is. The profile shows the red colourant to be at x=0.691, y=0.348 which is outside the spectral locus

I guess we should do something more sane when this happens (i.e.
because we need a CCMX to do a decent job). Ideas welcome...

Richard.

[Alexander Wright]

So what has caused this? How do I get a better result?

Incidentally, the calibration process also produced this file, from I assume
the EDID (attached).

Does this help in any way?

Alexander

[Jarl Arntzen]

I'd just like to add my data-point and say that my display on a Dell
Precision M4400 laptop, turned out nearly perfect for me when I used the
native white-point. Colors are strong and neutral; very similar to the
profile created by my Spyder 3 Express. The main difference is that the
darkest 5% of the gray scale test titles all look black.

However, like Matthias and many others, I too think that removing the
white point selector altogether is taking it a little too far.
Keep the selector but simply set it to "Native" as default.

Kind regs,

Jarl Arntzen

On Sun, 13 May 2012 22:08:05 +0200, Matthias Welwarsky
<matt...@welwarsky.de> wrote:
> I'm pretty sad about losing the whitepoint selector. Actually,
> calibration
> towards a D65 white point worked rather well on my Lenovo T520 LCD. I
> found it very yellow-ish for a week, now it is fine and I regard all
> other LCDs I work with too cold. On the contrary, the native white point
> of the display is in my opinion way too cold for any kind of photography
> related tasks. Why not go with "native" as the default and leave the
> final choice to the user?
>
> br,
> matthias

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

[Graeme Gill]

Richard Hughes wrote:
> I've attached a screenshot of your profile. The VCGT is pretty crazy.
> Graeme, I thought the VCGT for all channels was supposed to go through
> display white (i.e. join at rgb 255,255,255) for a native calibration?

Yes it should. But what were the dispcal options used, and what does the
verbose output look like ?
(ie. a simple "dispcal test" doesn't seem to show such a problem).

Graeme.

[Yan-Fa Li]

Here are the icc files I've generated using the livecd so far.
Thanks
Yan

[thilo.a...@googlemail.com]

Hello Richard,

got my colorhug yesterday. Unfortunately all the color profiles generated have a massive pink tint.

I'm on Ubuntu 12.04 and am using Pascal's PPA repositories (great work btw!). My system is a Sony Vaio VPCSA; I'm using the integrated Intel graphics and try to calibrate my laptop screen.

By selecting "Native whitepoint" on the configuration wizard I'm
getting a much better D65 profile without the super red tint. Tonight
I'm going to try to figure out what's changed in argyllcms between 1.2
and 1.4 that could affect this in such a bad way. The code is very
complex, so it might take a bit of time to work out. I'd be interested
to hear if native calibration fixes the tint for other people too.

Nope, it only had a slight influence on the outcome. I tried calibrating with gnome-color-manager and with dispcalGUI; no difference. I did choose a "blank" initial matrix for the colorhug in LCD mode, though.
 

I'll also try to regenerate the device calibration files when the
difference between the least-error and 4color values is so large. I've
kept all the .ti3 files for all the devices already "in the wild" so
it should be an easy process to recreate them. I'll let you all know
how I get on.

I did not attach my profiles to this mail as I don't see much added value in them for debugging since several have been posted by users already. If you still think they're useful please let me know and I'll re-run the tests and attach the profiles.

Is there anything else I can do? Experiments, logfiles, anything? I'm not afraid of hacking and am quite experienced with C and embedded systems.

Regards,
Thilo

[Richard Hughes]

On 22 May 2012 10:37, <thilo.a...@googlemail.com> wrote:
> Nope, it only had a slight influence on the outcome. I tried calibrating
> with gnome-color-manager and with dispcalGUI; no difference. I did choose a
> "blank" initial matrix for the colorhug in LCD mode, though.

Trying a different CCMX using colorhug-ccmx might be worthwhile,
although I think there's something else fishy going on.

> Is there anything else I can do? Experiments, logfiles, anything? I'm not
> afraid of hacking and am quite experienced with C and embedded systems.

Right, that sounds really good. I guess a great thing would be to try
to use http://www.argyllcms.com/doc/dispcal.html to try and work out
why native measurements are not native at all, e.g. R:255,G:255,B:255
should always be R:255,G:255,B:255

For native calibration of an LCD on display 0, GCM runs "dispcal -v
-ql -m -d0 -yl -P 0.5,0.5,1.2 basename"-- maybe using -ql is a
mistake... I'd appreciate if somebody could sanity check that.

Richard.

[Chris Lilley]

On Monday, May 21, 2012, 7:58:50 PM, Richard wrote:

RH> On 21 May 2012 18:52, Chris Lilley <ch...@w3.org> wrote:
>> It is. The profile shows the red colourant to be at x=0.691, y=0.348 which is outside the spectral locus

RH> I guess we should do something more sane when this happens (i.e.
RH> because we need a CCMX to do a decent job). Ideas welcome...

Perhaps this falls into the class of "you are better using no profile/using a generic profile, than this profile".

I guess one could

- advise the user that this profile does not accurately represent the monitor, and should not be used except for testing

- suggest that they look for a suitable ccmx (maybe pop up the gui for the ccmx loader)

- suggest that if they have a spectrophotometer, they generate a ccmx
(link to the calibration instructions) and then upload it so others can benefit

[Chris Lilley]

On Monday, May 21, 2012, 9:04:34 PM, Alexander wrote:

AW> On Monday 21 May 2012 18:58:50 Richard Hughes wrote:
>> On 21 May 2012 18:52, Chris Lilley <ch...@w3.org> wrote:
>> > It is. The profile shows the red colourant to be at x=0.691, y=0.348 which
>> > is outside the spectral locus
>> I guess we should do something more sane when this happens (i.e.
>> because we need a CCMX to do a decent job). Ideas welcome...

AW> So what has caused this?

Sorry if this response is longer than you might have wished :)

The colorhug is a class of instrument called a tristimulus colorimeter [1]; it measures the intensity of incoming light through three different filters and, from those three measurements and knowing the spectral responses of the filters and the light sensor, it approximates CIE XYZ values.

This is in contrast to much more complex and expensive devices called spectrophotometers, which split the incoming light into a spectrum and then sample the intensity at a large number (50 to 500) of wavelength intervals. These values are weighted and added to give a close approximation to the CIE XYZ values.

What has caused the error?

Firstly, the spectral responses of the filters in the colorhug[2] are not a linear combination of the CIE XYZ color matching functions[3]. (This is true of all colorimeters, but some[4] match better than others). This means that an adjustment is needed to convert what the colorhug sees to a better approximation to the XYZ values.

Secondly, the emission spectrum of the device used to calibrate the colorhug and your device differ. This is true of any pair of devices, but it is particularly true of they use different backlight technologies and especially true if one of them has a spiky, discontinuous spectrum rather than a smooth one. Red LEDs and the red phosphor in a CRT[5] are two examples of a spiky response.

In fact in the colorhug there are two adjustment matrices - one is the factory calibration, and there can be a second supplemental one to increase the accuracy for a specific display type (which then decreases the accuracy for different display types). Not all colorimeters have this capability. The Spyder 4, and the X-Rite i1D3 are examples of other colorimeters that can do this.

AW> How do I get a better result?

Use a supplemental correction matrix (CCMX file) which you, or someone else, has created[6] by measuring the same display with a colorhug and with a spectrophotometer and then getting ArgyllCMS to create the matrix[7].

AW> Incidentally, the calibration process also produced this file, from I assume
AW> the EDID (attached).

AW> Does this help in any way?

A bit. The EDID includes chromaticity values for red, green, blue and native white that the manufacturer considers representative of the device. These values may not be especially accurate, and are averages rather than being measurements of your specific display.

The profile you attached was automaticaly generated from the EDID. It can be used to sanity check the measured profile. In this case, it looks like the colorhug measured values for green are also off, as I suspected earlier.



[1] http://en.wikipedia.org/wiki/Tristimulus_colorimeter
[2] http://www.hughsie.com/img/frequency-response-large.png
[3] http://en.wikipedia.org/wiki/File:CIE_1931_XYZ_Color_Matching_Functions.svg
[4] http://www.pro-lite.co.uk/File/brontes.php
[5] http://en.wikipedia.org/wiki/File:CRT_phosphors.png
[6] http://www.hughsie.com/calibrate.html
[7] http://www.argyllcms.com/doc/ccxxmake.html

[Chris Lilley]

On Tuesday, May 22, 2012, 12:13:47 PM, Richard wrote:

RH> On 22 May 2012 10:37, <thilo.a...@googlemail.com> wrote:
>> Nope, it only had a slight influence on the outcome. I tried calibrating
>> with gnome-color-manager and with dispcalGUI; no difference. I did choose a
>> "blank" initial matrix for the colorhug in LCD mode, though.

RH> For native calibration of an LCD on display 0, GCM runs "dispcal -v
RH> -ql -m -d0 -yl -P 0.5,0.5,1.2 basename"-- maybe using -ql is a
RH> mistake... I'd appreciate if somebody could sanity check that.

The only difference between -ql and -qm (which is the default) seems to be the amount of effort expended on the intermediate values. -qm tries 16 samples from black to white, then 32, then 64 with increasingly strict target deltaE.

But that should only affect the shape of the curve between min and max, not (very much) the end points. I say "not very much" since I do see some mention of 'fixing up white point to remain in gamut' and adjustments to the black value, in the verbose output. But those adjustments, from memory, are small.

Graeme can of course comment much more authoritatively on that, this is just my observations because I always use the -qm setting myself.

[Graeme Gill]

Richard Hughes wrote:
> For native calibration of an LCD on display 0, GCM runs "dispcal -v
> -ql -m -d0 -yl -P 0.5,0.5,1.2 basename"-- maybe using -ql is a
> mistake... I'd appreciate if somebody could sanity check that.

There's nothing odd there. I've run a few checks using the ColorHug,
and the resulting .cal file has white values of 1,1,1 as expected
(a native white target forces this to be so).

Graeme Gill.

[rok....@gmail.com]

I have liveCD 20120510, however this problem is still there. I calibrated DELL IPS 2412M and laptop's probook 4510s screen. Both awfully red.

I also tried it on Arch linux, using colord 0.1.21. All the same.

By selecting "Native whitepoint" on the configuration wizard

Which configuration wizard?

Dne sreda, 09. maj 2012 14:29:41 UTC+2 je oseba Richard Hughes napisala:

Last night I was hunting the overly-red-crazy-temperature VCGT bug. I
think the error is in two parts. First, the way I 'm calculating the
factory calibration matrix isn't optimal (for the details, I'm finding
the 4-color method is quicker and more accurate than ASTM-96) and
there's also something screwy when you tell argyllcms you want a D65
whitepoint.

By selecting "Native whitepoint" on the configuration wizard I'm
getting a much better D65 profile without the super red tint. Tonight
I'm going to try to figure out what's changed in argyllcms between 1.2
and 1.4 that could affect this in such a bad way. The code is very
complex, so it might take a bit of time to work out. I'd be interested
to hear if native calibration fixes the tint for other people too.

I'll also try to regenerate the device calibration files when the
difference between the least-error and 4color values is so large. I've
kept all the .ti3 files for all the devices already "in the wild" so
it should be an easy process to recreate them. I'll let you all know
how I get on.

Richard

[Heinz Horstinger]

I tried to calibrate my display with the newly arrived colorhug
yesterday and unfortunately now everything seems to be very red, too. I
used the packages colorhug-clien 0.1.8-1pmjdebr in the ubuntu-ppa of
pmjdebruijn on ubuntu 12.04. My Monitor is a ASUS VE278. I have no
photospectrometre so I hope somebody can provide a correction-matrix or
there is another solution. I attached the icc file and a screenshot of
the curves in case that will help.

[Graeme Gill]

What does the verbose output of dispcal look like ?

Graeme Gill.

[Heinz Horstinger]

Am 25.05.2012 10:09, schrieb Graeme Gill:
> What does the verbose output of dispcal look like ? Graeme Gill.

I didn't use dispcal since yet. I will try it and send the verbose
output as soon as possible (which is propably after the weekend).
Thanks!

heinz horstinger

[Robert Swain]

Hello,

I've just tested on an LG W2486 24" LED-backlit (as far as I recall) monitor which I have had trouble setting up before getting a ColorHUG. I ended up giving up on it as I can either have what appears to be good contrast for text and greys or I can have reasonable colour reproduction (i.e. not totally crap) but not both. Long story short, it's not a good monitor but I thought perhaps calibration could help it.

I'm not sure how best to go about configuring the monitor before conducting calibration. I noted that my Lenovo T520 internal screen has its backlight set to maximum brightness before calibration commences and so I have set the brightness and contrast on the LG monitor to max.

I tried using the D65 whitepoint and the result was very pink. During that D65 whitepoint calibration attempt, dispcal would report at some point that the Jacobian could not be inverted. A quick Google suggested that this happens when encountering a dead spot in some colour adjustments, usually due to clipping. So, I tried the native whitepoint in case that would help after seeing this thread and that looks much better.

Any tips for how to set up manual controls of a monitor before calibration in case they are the cause of the pinkness would be welcome.

Best regards,

Rob

[mattybalaam]

I'm a Mac user trying to get a profile with the LiveCD, but they subjectively always look very red - especially towards the white end of the scale.  Today I ran Ubuntu in VirtualBox, turned off OS X colour correction, and attempted to create a profile which - again, subjectively - looks far better to my eyes.

I've attached an image attempting to show the differences on my BenQ 241 which uses a P-MVA panel. I have used the old ole no moire image, and a print of it produced by a printing company to assist in colour calibration. I have included the original images and have used the Photoshop colour-picker to adjust to the print-outs white, black and mid-points.

Obviously the screen doesn't photograph very well with the iPad I used, and the print out looks slightly washed out, so this isn't a hugely scientific method, but it illustrates the range of the difference between the two profiles. To my eyes the monitors look far less blue using either profile than this photo shows.

I have also attached the profiles.

I hope this helps and isn't just noise.

Matthew

[joh...@gmail.com]

I just got my colorhug, and both my screens (Benq G2420HDBL and Samsung Synchmaster 960BG) turn out pink/red using the factory defaults and 20 min calibration.

[Markus Jung]

Have you tried calibrating to the native whitepoint? The results using
native whitepoint appear to be reasonable (my display has some crazy
whitepoint of 8400K).
Other whitepoints produce extreme red results for me.

Regards,
Markus

Screen: T520 HD+

[Michal Nazarewicz]

On Thu, 31 May 2012 21:00:02 +0200, Markus Jung <mr.ma...@googlemail.com> wrote:
> Have you tried calibrating to the native whitepoint? The results using
> native whitepoint appear to be reasonable (my display has some crazy
> whitepoint of 8400K).

I've tried the 20 minute and 4 minute calibration with one of my screens
having it reset to defaults beforehand and both produced red profiles.
I'm actually not seeing any “native whitepoint” option anywhere; changelog
for the LiveCD (“Do not allow the user to select a custom whitepoint unless
they are using a i1pro, ColorMunki or i1d3 calibration device.”) makes me
think that's desired.

--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +----<email/xmpp: m...@google.com>--------------ooO--(_)--Ooo--

[Pascal de Bruijn]

On Thu, May 31, 2012 at 9:55 PM, Michal Nazarewicz <min...@mina86.com> wrote:
> On Thu, 31 May 2012 21:00:02 +0200, Markus Jung <mr.ma...@googlemail.com>
> wrote:
>>
>> Have you tried calibrating to the native whitepoint? The results using
>> native whitepoint appear to be reasonable (my display has some crazy
>> whitepoint of 8400K).
>
> I've tried the 20 minute and 4 minute calibration with one of my screens
> having it reset to defaults beforehand and both produced red profiles.
> I'm actually not seeing any “native whitepoint” option anywhere; changelog
> for the LiveCD (“Do not allow the user to select a custom whitepoint unless
> they are using a i1pro, ColorMunki or i1d3 calibration device.”) makes me
> think that's desired.

New versions of GCM, auto-default to native whitepoint for lower end
colorimeters.

Regards,
Pascal de Bruijn

[rylleman]

I've calibrated 4 machines/monitors and they all turn out reddish at
various degrees. All using latest liveCD and latest firmware.

1. Samsung SyncMaster SA650 - GeForce GTX 480 - quite red
2. Philips 230W5 - same machine as 1. also quite red
3. Fujitsu Siemens T5010 tablet PC - a bit too red
4. LG Flatron L207WT (reported as Goldstar company Ltd. L207W) - Dell
Precision 490, Quadro FX 550 - A bit too red.
5. Philips 230W5 - HP wx6600, Nvidia Quadro FX1700 - quite red.

What to do?

[hifi]

Hi !

I have just received my colorhug.
I try it and I see the screen is reddish after calibration.
I have the last CD (20120510-->so with the whitepoint patch).
What can I do to correct that ? IS there any patch/clue about that
problem ?


Thanks a lot !

[Ian Tompkins]

Thanks to Pascal de Bruijn and his excellent ppa, I have the
calibration software up and running on two Ubuntu 12.04 machines.

My primary machine shows a very substantial red tint after calibration
on a Dell 2209WA. I'm currently running the 20 minute calibration on
an Asus ML228 as well and will update when it's through.

I'm a bit tech challenged in Linux, but I'm really good at following
instructions and not at all afraid of the command line. If there is
anything I can provide on either display, I would be happy to do so.
Sorry, I don't have access to a spectrophotometer. :/


> I'd agree with this summary. Does anybody know of a list of popular
> external monitors used nowadays? I've tried to use Smolt[1] but that
> just returns the video card used, not the monitor as supplied by the
> EDID data. I'm not super comfortable asking the user to upload the
> EDID for statistics purposes when calibrating, although that might
> indicate what monitors are worth buying for testing.

I wonder if we could set up a poll available to members of colorhug-
users that would allow you to see all the displays current owners are
trying to calibrate? I'm certainly not suggesting that you shouldn't
use a more mainstream selection of popular displays, but at least this
is data we could collect internally and would benefit people who are
definitely interested.

[Ian Tompkins]

> I'm currently running the 20 minute calibration on
> an Asus ML228 as well and will update when it's through.

Update: excessive red on the ML228 as well, at least to my eyes.

[Federico Bruni]

Many users are reporting over-red calibration with ColorHug.
IIUC, it is related on whitepoint settings. We have been recommended to
use a recent version of gcm which sets the native whitepoint.

The native whitepoint of LCD is usually 6500K, right?

I checked in gcm the whitepoint of some profiles I've created:

- default profile (edid): 5000K --> bluish
- colorhug profile: 6500K --> reddish (the profile generated with Live
CD is slightly reddish than the one generated using Debian testing packages)
- colormunki display profile: 5400K --> this looks good. I used
DispcalGUI and left the white point setting to native.
I'd be curious to check how gcm calibrates using colormunki, but gcm
can't detect the colormunki unfortunately. I'm trying to understand why.
Later I'll try the Fedora live cd, so I'll see if it's a bug in Debian
package.

[Pascal de Bruijn]

On Sat, Jun 2, 2012 at 1:27 PM, Federico Bruni <fede...@gmail.com> wrote:
> Il 02/06/2012 03:23, Ian Tompkins ha scritto:
>
>>> I'm currently running the 20 minute calibration on
>>> an Asus ML228 as well and will update when it's through.
>>
>>
>> Update: excessive red on the ML228 as well, at least to my eyes.
>
>
> Many users are reporting over-red calibration with ColorHug.
> IIUC, it is related on whitepoint settings. We have been recommended to use
> a recent version of gcm which sets the native whitepoint.
>
> The native whitepoint of LCD is usually 6500K, right?

No, absolutely not... 6500K is the desired whitepoint in most cases,
NOT the native whitepoint.

Native whitepoint are determine by a displays backlight, which is
usually a CCFL and white LED array.

For laptop it's common for displays to have a native whitepoint of 8000-10000K.

For desktop displays it can be anything. Though most affordable
desktop displays tend to have a whitepoint of > 6500K too.

> I checked in gcm the whitepoint of some profiles I've created:
>
> - default profile (edid): 5000K --> bluish
> - colorhug profile: 6500K --> reddish (the profile generated with Live CD is
> slightly reddish than the one generated using Debian testing packages)
> - colormunki display profile: 5400K --> this looks good. I used DispcalGUI
> and left the white point setting to native.

I'm guessing this is semi-accidental.

> I'd be curious to check how gcm calibrates using colormunki, but gcm can't
> detect the colormunki unfortunately. I'm trying to understand why. Later
> I'll try the Fedora live cd, so I'll see if it's a bug in Debian package.

I assume you are using GCM 3.4.2 and Argyll 1.4.0?

Regards,
Pascal de Bruijn

[Federico Bruni]

Il 02/06/2012 13:34, Pascal de Bruijn ha scritto:
> On Sat, Jun 2, 2012 at 1:27 PM, Federico Bruni<fede...@gmail.com> wrote:
>> Il 02/06/2012 03:23, Ian Tompkins ha scritto:
>>
>>>> I'm currently running the 20 minute calibration on
>>>> an Asus ML228 as well and will update when it's through.
>>>
>>>
>>> Update: excessive red on the ML228 as well, at least to my eyes.
>>
>>
>> Many users are reporting over-red calibration with ColorHug.
>> IIUC, it is related on whitepoint settings. We have been recommended to use
>> a recent version of gcm which sets the native whitepoint.
>>
>> The native whitepoint of LCD is usually 6500K, right?
>
> No, absolutely not... 6500K is the desired whitepoint in most cases,
> NOT the native whitepoint.
>

Ok.
It seems that in my case the desired whitepoint is not 6500K, but a
smaller value, around 5500K. Right?

IIUC, gcm (at least in the GUI) doesn't allow to set a different desired
whitepoint. Maybe there's a command-line tool for that? (man
gcm-calibrate currently doesn't help)

> Native whitepoint are determine by a displays backlight, which is
> usually a CCFL and white LED array.
>
> For laptop it's common for displays to have a native whitepoint of 8000-10000K.
>
> For desktop displays it can be anything. Though most affordable
> desktop displays tend to have a whitepoint of> 6500K too.
>

I see.
I guess this article is misleading:
http://support.datacolor.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=812

>> I checked in gcm the whitepoint of some profiles I've created:
>>
>> - default profile (edid): 5000K --> bluish
>> - colorhug profile: 6500K --> reddish (the profile generated with Live CD is
>> slightly reddish than the one generated using Debian testing packages)
>> - colormunki display profile: 5400K --> this looks good. I used DispcalGUI
>> and left the white point setting to native.
>
> I'm guessing this is semi-accidental.
>

Can you elaborate it please?

I'd like to try ColorHug with DispcalGUI, which since last version
(0.9.9.1) supports it:

"Experimental ColorHug support is enabled through Argyll CMS >= 1.3.6 if
the ENABLE_COLORHUG environment variable is set, but the ColorHug
currently doesn't work reliably across all platforms."

How can I set ENABLE_COLORHUG?
I've tried:
ENABLE_COLORHUG=1
./dispcalGUI.pyw

and

ENABLE_COLORHUG=True
./dispcalGUI.pyw

but none of them works: colorhug is not detected (I did click on the
refresh button)

>> I'd be curious to check how gcm calibrates using colormunki, but gcm can't
>> detect the colormunki unfortunately. I'm trying to understand why. Later
>> I'll try the Fedora live cd, so I'll see if it's a bug in Debian package.
>
> I assume you are using GCM 3.4.2 and Argyll 1.4.0?
>

yes

thanks for your help

[Pascal de Bruijn]

On Sat, Jun 2, 2012 at 2:05 PM, Federico Bruni <fede...@gmail.com> wrote:
> Il 02/06/2012 13:34, Pascal de Bruijn ha scritto:
>> On Sat, Jun 2, 2012 at 1:27 PM, Federico Bruni<fede...@gmail.com>  wrote:
>>> Il 02/06/2012 03:23, Ian Tompkins ha scritto:
>>>
>>>>> I'm currently running the 20 minute calibration on
>>>>> an Asus ML228 as well and will update when it's through.
>>>>
>>>> Update: excessive red on the ML228 as well, at least to my eyes.
>>>
>>> Many users are reporting over-red calibration with ColorHug.
>>> IIUC, it is related on whitepoint settings. We have been recommended to
>>> use
>>> a recent version of gcm which sets the native whitepoint.
>>>
>>> The native whitepoint of LCD is usually 6500K, right?
>>
>> No, absolutely not... 6500K is the desired whitepoint in most cases,
>> NOT the native whitepoint.
>
> Ok.
> It seems that in my case the desired whitepoint is not 6500K, but a smaller
> value, around 5500K. Right?

No, the desired whitepoint is pretty much always 6500K (well,
discarding some use-cases, please don't shoot :).

The fact that it seems to work for you with 5500K is probably just
coincidental. So this is at best a workaround, not a proper solution.

> IIUC, gcm (at least in the GUI) doesn't allow to set a different desired
> whitepoint. Maybe there's a command-line tool for that? (man gcm-calibrate
> currently doesn't help)
>
>> Native whitepoint are determine by a displays backlight, which is
>> usually a CCFL and white LED array.
>>
>> For laptop it's common for displays to have a native whitepoint of
>> 8000-10000K.
>>
>> For desktop displays it can be anything. Though most affordable
>> desktop displays tend to have a whitepoint of>  6500K too.
>
> I see.
> I guess this article is misleading:
> http://support.datacolor.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=812

Yes, to say to least.

It's true you can "adjust" the white point digitally using your
displays OSD, but this is done digitally. And the actual results
seldomly matches the claimed Kelvin value (usually not even within a
ballpark).

I usually keep my display at it's true native whitepoint (custom color
-> R=G=B=255 (or 100 or whatever scale your display uses)), and let
Argyll do all of the correction.

>>> I checked in gcm the whitepoint of some profiles I've created:
>>>
>>> - default profile (edid): 5000K -->  bluish
>>> - colorhug profile: 6500K -->  reddish (the profile generated with Live
>>> CD is
>>> slightly reddish than the one generated using Debian testing packages)
>>> - colormunki display profile: 5400K -->  this looks good. I used

Actually when you calibrate with the ColorMunki you should really
stick to a desired whitepoint of 6500K, as the ColorMunk is a
spectrophotometer, it will mostly likely properly correct your
displays whitepoint.

With my (el'cheapo) laptop with an el'crappo display calibrating with
a ColorMunki made a display seems a tad reddish at first too. But this
just because I was used to the insanely blue cast it had at first.

>>> DispcalGUI
>>> and left the white point setting to native.
>>
>> I'm guessing this is semi-accidental.
>
> Can you elaborate it please?
>
> I'd like to try ColorHug with DispcalGUI, which since last version (0.9.9.1)
> supports it:
>
> "Experimental ColorHug support is enabled through Argyll CMS >= 1.3.6 if the
> ENABLE_COLORHUG environment variable is set, but the ColorHug currently
> doesn't work reliably across all platforms."
>
> How can I set ENABLE_COLORHUG?
> I've tried:
> ENABLE_COLORHUG=1
> ./dispcalGUI.pyw
>
> and
>
> ENABLE_COLORHUG=True
> ./dispcalGUI.pyw
>
> but none of them works: colorhug is not detected (I did click on the refresh
> button)

I don't know about dispcalGUI...

GCM 3.4.0 and later automatically set ENABLE_COLORHUG, so you won't
need to worry about it.

>>> I'd be curious to check how gcm calibrates using colormunki, but gcm
>>> can't
>>> detect the colormunki unfortunately. I'm trying to understand why. Later
>>> I'll try the Fedora live cd, so I'll see if it's a bug in Debian package.
>>
>> I assume you are using GCM 3.4.2 and Argyll 1.4.0?
>
> yes
>
> thanks for your help

Regards,
Pascal de Bruijn

[Štěpán Roučka]

I also have problems with reddish screen after calibration. I have
Eizo EV2333W. I tried "factory calibration" and "HP LP2480zx (Adobe)"
CCMX with similar results. The VCGT of my profile looks similar like
the example posted by Richard Hughes in this thread previously. Should
I post the generated *.icc and *.til files?

Regards,
Stepan

[Andreas Helmcke]

Am 02.06.2012 14:05, schrieb Federico Bruni:
> I'd like to try ColorHug with DispcalGUI, which since last version (0.9.9.1) supports it:
>

> How can I set ENABLE_COLORHUG?
> I've tried:
> ENABLE_COLORHUG=1
> ./dispcalGUI.pyw

either:
ENABLE_COLORHUG=1 ./dispcalGUI.pyw

(Setting EXPORT_COLORHUG only for the following command)

or
export ENABLE_COLORHUG=1
./dispcalGUI.pyw

(Setting EXPORT_COLORHUG for the session (until exit /logout))

should work.

[Florian Höch]

Am 02.06.2012 15:58, schrieb Andreas Helmcke:
> Am 02.06.2012 14:05, schrieb Federico Bruni:
>> I'd like to try ColorHug with DispcalGUI, which since last version (0.9.9.1) supports it:
>

> either:
> ENABLE_COLORHUG=1 ./dispcalGUI.pyw
> [snip]

...or try the latest SVN (r1018 or newer) which enables the ColorHug by
default under Linux (only).

Florian

[Stijn van der Linden]

Samsung Syncmaster 245T
My first attempt with latest live cd (20120510) also gave a reddish
output.
White looked reasonably white, but greys were pretty pinkish.

After checking all settings on my monitor I increased brightness
slightly and re-ran the calibration.
Things now look a lot better imho.

Not sure if changing brightness should have this much influence?

Curious to see if the graphs (how do you make those?) show this
difference clearly.
And as soon as I figure out how to attach the .icc files I will.

[Stijn van der Linden]

Ah, switching to new google groups help, here are my icc files.

 

[Florian Höch]

Am 03.06.2012 11:24, schrieb Stijn van der Linden:>
> Ah, switching to new google groups help, here are my icc files.

What's interesting is that the "GCM - Samsung Syncmaster 245T
Better.icc" actually has the lower recorded brightness of the two
profiles (177.53 cd/m2 vs 184.96 cd/m2 of the other one), and the 'vcgt'
calibration curves also show this (they don't go up to display maximum).
The more 'normal' red in the profile may simply be an effect of the
reduced red channel in the calibration curves.

[Diego]

Hi Richard and all in the group!

I was using my brand new ColorHug to calibrate the LCD screen in my Acer Aspire 5610 laptop. I was using LiveCD and Ubuntu packages from Pascal de Bruijn's repositories, and both gave similar results. I notice just one difference, LiveCD (20120510) fit temperature always to 6500ºC, whereas Ubuntu packages fit to 6300, 6400 or 6500ºC depending on the run.

I was wondered if using the profile in some software would show also the same redish effect on the pictures. Then I unabled colorhug ICC profile in gnome-color-management (GCM) and opened some NEF files in UFRAW and setup the created profile as the display profile. Surprisingly it doesn't tint the pictures as it does GCM. Actually colors look much more naturals and I would say like I would expect. I'm pretty new to color profiling and so on, and may be I'm missing some important thing but ... Haven't they to show the same colors using the same profile to the whole system than using it just in the UFRAW?

Attached profile was made with "Normal" parameter.

[Beat Rubischon]

Hello!

On 02.06.12 15:53, Štěpán Roučka wrote:
> I also have problems with reddish screen after calibration.

Another "me too" posting. I was able to play with a ColorHug from a
friend on my Apple PowerBook 15". The display is a 1680x1050 one with
LED backlight, sadly I don't get the manufacturer out of the piece now.

Until now I worked with a ColorSync generated profile with a whitepoint
of D65. D50 would be probably a better option for my work. I was
expecting a "warmer" tone of the display, but the results generated by
ColorHug and the CD from Mai is much too warm. Comparing with a white
paper it delivers a tungsten like whitepoint of about 3000 Kelvin.

I also tried the CD from April. Using D65 as whitepoint is identical to
the calibration with the newer CD, using D50 results in a even warmer
display. Using the factory calibarion option results in a visual effect
of 10000 Kelvin which is fat too blue. Courves are OK, the visual
separation of different colors much better then the canned profiles
created by ColorSync.

As far as I understand a white background on the screen should have the
same tone as a piece of paper in sunlight. Sorry for my unprofessional
comparison :-)

Do we have to find a way to calibrate ColorHug? Or do we have a bug
inside of the software stack generating the profile?

Beat

--
\|/ Beat Rubischon <be...@0x1b.ch>
( 0-0 ) http://www.0x1b.ch/~beat/
oOO--(_)--OOo---------------------------------------------------
Meine Erlebnisse, Gedanken und Traeume: http://www.0x1b.ch/blog/

[Federico Bruni]

Il 02/06/2012 14:29, Pascal de Bruijn ha scritto:
> On Sat, Jun 2, 2012 at 2:05 PM, Federico Bruni<fede...@gmail.com> wrote:
>> It seems that in my case the desired whitepoint is not 6500K, but a smaller
>> value, around 5500K. Right?
>
> No, the desired whitepoint is pretty much always 6500K (well,
> discarding some use-cases, please don't shoot :).
>
> The fact that it seems to work for you with 5500K is probably just
> coincidental. So this is at best a workaround, not a proper solution.
>

I've uploaded the profiles I've created so far, along with shoots of the
screen:
http://ge.tt/9zHraaI

Best results to my eyes are:
1) colormunki, calibrated with dispcalgui using native whitepoint
2) colorhug, calibrated with dispcalgui using native whitepoint

Profile whitepoints (taken from gnome-color-manager):
the first has 5400K, the second 9300K

If I set the desired whitepoint to 6500K in DispcalGUI, the results are
not great: colorhug makes it too reddish, colormunki makes it greyish
(the white is not white enough).

Tips for judging if a profile is good or not?

>
> Actually when you calibrate with the ColorMunki you should really
> stick to a desired whitepoint of 6500K, as the ColorMunk is a
> spectrophotometer, it will mostly likely properly correct your
> displays whitepoint.
>

ColorMunki Display is not a spectrophotometer, is it?
http://www.argyllcms.com/doc/instruments.html#i1d3

> With my (el'cheapo) laptop with an el'crappo display calibrating with
> a ColorMunki made a display seems a tad reddish at first too. But this
> just because I was used to the insanely blue cast it had at first.
>

I'm not used anymore to the insanely blue cast. Profiles opened my eyes :)
But I still have to learn how to judge a profile.
I think it's time for me to buy a book on colour management...

>
>>>> I'd be curious to check how gcm calibrates using colormunki, but gcm
>>>> can't
>>>> detect the colormunki unfortunately. I'm trying to understand why. Later
>>>> I'll try the Fedora live cd, so I'll see if it's a bug in Debian package.
>>>
>>> I assume you are using GCM 3.4.2 and Argyll 1.4.0?
>>
>> yes
>>

even latest colorhug liveCD can't detect the ColorMunki

[Florian Höch]

Am 03.06.2012 12:20, schrieb Beat Rubischon:
> As far as I understand a white background on the screen should have the
> same tone as a piece of paper in sunlight. Sorry for my unprofessional
> comparison :-)

Because of optical brighteners in typical papers, a photographic
graycard may be the better choice. Also, sunlight differs quite wildly
during the day.

> Do we have to find a way to calibrate ColorHug?

My own experiences so far indicate the ColorHug can be quite accurate
with a custom-made CCMX, but you need a spectrometer to create one so
it's not an option for a lot of people. A better factory calibration
should be able to improve results, but that needs more contributed CCMX
matrices so they can be averaged for a new default calibration.

As the results with the current factory calibration are often (?) so far
off, I'm wondering if even calibrating the ColorHug towards the
chromaticity values from the individual user's display EDID may be an
improvement, but of course that would basically reduce the accuracy of
measurements to that of the EDID (which may be low or even bogus
especially for typical 'consumer' screens). It could still help though,
as it would presumably fix the 'red chromaticity too far out' problem in
profiles (I've actually briefly tested this, and the ColorHug
measurements with such a CCMX showed an peak and average whitepoint
normalized error of 4.81 and 1.43 DE 2000 respectively towards
measurements with the i1 Pro, which is better than I thought it would
be. The error of the factory calibration against the i1 Pro was a lot
higher with a peak of 19.53 and average of 5.27).

> Or do we have a bug
> inside of the software stack generating the profile?

I don't think so. The only real bug I ran across is on non-english
locale systems where the comma (,) is used as decimal separator instead
of the point (.) and loading of CCMX causes its values being misinterpreted.

[Jaroslav Škarvada]

Dne neděle, 3. června 2012 11:22:06 UTC+2 Stijn van der Linden napsal(a):

After checking all settings on my monitor I increased brightness
slightly and re-ran the calibration.
Things now look a lot better imho.

I have the same experience with my T500 laptop. I calibrated my ColorHug with ColorMunki at full backlight. Then the resulting profile was quite acceptable. When lowered the T500 backlight and re-created the profile the red-tint was back.

[Matthias Welwarsky]

Which hints towards a SNR problem if the illumination is not high enough.
Among other reasons, light spill into the ColorHug might be a factor. Then,
the black level should be off, as well.

I remember that I tried calibrating without the rubber grommit and that had a
similar effect.

[Graeme Gill]

Matthias Welwarsky wrote:
> Which hints towards a SNR problem if the illumination is not high enough.

Quantisation at lower light levels is also a possible explanation.

Graeme Gill.

[Enzo Cappa]

Hi!

After trying with different settings, I was able to complete a decent
(at least not reddish) calibration using dispcalGUI.
The differences from the original ones are:
- Selected Mode: Refresh
- Enabled White level drift compensation
- Enabled Black level drift compensation
- Selected Testchart file: Extended testchart for "curves + matrix"
profiles

Probably the most important change was selecting "Refresh" instead of
"LCD" for the mode.

What I couldn't do is using correction matrix from dispcalGUI DB. I
got an error message saying that the device doesn't supports that
functionality. Is that correct?

What do you think about this settings? Will they produce an accurate
profile?

Regards

Enzo

[Florian Höch]

Am 03.06.2012 19:34, schrieb Florian Höch:
> As the results with the current factory calibration are often (?) so far
> off, I'm wondering if even calibrating the ColorHug towards the
> chromaticity values from the individual user's display EDID may be an
> improvement, but of course that would basically reduce the accuracy of
> measurements to that of the EDID (which may be low or even bogus
> especially for typical 'consumer' screens). It could still help though,
> as it would presumably fix the 'red chromaticity too far out' problem in
> profiles (I've actually briefly tested this, and the ColorHug
> measurements with such a CCMX showed an peak and average whitepoint
> normalized error of 4.81 and 1.43 DE 2000 respectively towards
> measurements with the i1 Pro, which is better than I thought it would
> be. The error of the factory calibration against the i1 Pro was a lot
> higher with a peak of 19.53 and average of 5.27).

I've just made available a development version of dispcalGUI (1.0.5.7)
in my "testing" repository on opensuse buildservice (
https://build.opensuse.org/package/show?package=dispcalGUI&project=home%3Afhoech%3Atesting
) which enables the colorhug by default under Linux and all the
measurement modes supported by it. It has quite a list of other changes
and fixes too (see the changelog in the ReadMe).

It also makes my above crazy idea for using the EDID for CCMX creation
possible, which may atleast help to fix the "red problem" if no
spectrometer is available. Of course the caveats still apply (and may
render the whole idea useless), but I'm thinking it should be
interesting to see if this can be used as a intermediate workaround for
the "red problem" until more user contributed CCMX files become available.

If you want to try it:

1. Start up dispcalGUI, click the blue "Detect displays & instruments"
arrows, then select the colorhug under "Instrument" if it is not already
selected.
2. Select "Create profile from extended display identification data..."
from the "Options" menu. Save it anywhere you like, but don't install it.
3. Select "Create colorimeter correction..." from the "Tools" menu.
4. Reset the screen to factory defaults.
5. Attach the colorhug to the screen and click "Measure". After the
measurement, the CCMX creation window should pop up again.
6. Click "Create colorimeter correction..."
7. Choose the profile created in step 2. Then choose the measurement
file created in step 5 (should be automatically selected).
8. Set the correct display, backlight and panel type, then click OK.
9. The CCMX should be saved & automatically selected afterwards. Done.

The caveat is that a CCMX created in such a way basically sets the
primaries and whitepoint measured by the colorhug (with the screen at
factory defaults) to those reported by the EDID. If the EDID is
inaccurate, it makes the colorhug inaccurate. If the EDID is accurate,
it makes the colorhug accurate. The assumption is that in the colorhug's
current factory calibrated state, a CCMX created in the way outlined
above should atleast be more accurate than the factory calibration
alone, but YMMV.

[Steve Crawford]

Hi All,

I've been having trouble with overly-red calibration, which I believe I've solved.  Various comments within this thread lead me to a calibration that I'm happy with, so I thought I'd share my results (and profiles).

My monitor is an LG245WP - a pretty good CCFL lit panel from 2007, with either s-MVA or S-IPS panel (conflicting info from various sources).

Using the live-cd from may (which was provided with my colorhug) I get overly red profiles.  Whatever I do.  Turning up the brightness helped somewhat, but they grey was always really pink/red.  Not "that's a little bit warm", but "that can't be right".

Using the live-cd from april, I got a profile I was really happy with straight away, when using a native white point.

I've included one pink profile (filename starts with pink) and two good profiles (one with the monitor set at 6500K and the other with it set at sRGB, both using the on screen menu).

Steve

On Wednesday, 9 May 2012 14:29:41 UTC+2, Richard Hughes wrote:

Last night I was hunting the overly-red-crazy-temperature VCGT bug. I
think the error is in two parts. First, the way I 'm calculating the
factory calibration matrix isn't optimal (for the details, I'm finding
the 4-color method is quicker and more accurate than ASTM-96) and
there's also something screwy when you tell argyllcms you want a D65
whitepoint.

By selecting "Native whitepoint" on the configuration wizard I'm
getting a much better D65 profile without the super red tint. Tonight
I'm going to try to figure out what's changed in argyllcms between 1.2
and 1.4 that could affect this in such a bad way. The code is very
complex, so it might take a bit of time to work out. I'd be interested
to hear if native calibration fixes the tint for other people too.

I'll also try to regenerate the device calibration files when the
difference between the least-error and 4color values is so large. I've
kept all the .ti3 files for all the devices already "in the wild" so
it should be an easy process to recreate them. I'll let you all know
how I get on.

Richard

[Matthias Welwarsky]

Then, maybe the backlight should be set to maximum brightness always? How does
the color sensor work, can you influence the exposure time? Maybe it could be
extended when the light levels are too low? Should a black patch be shown in
between the colored patches to "reset" the sensor?

>
> Graeme Gill.

[Graeme Gill]

Matthias Welwarsky wrote:
> Then, maybe the backlight should be set to maximum brightness always? How does
> the color sensor work, can you influence the exposure time? Maybe it could be
> extended when the light levels are too low?

Since all the low level sensor reading stuff is in the ColorHug firmware,
these are all questions for Richard to answer. I think he made some
improvements in this area with one of the latest firmware updates.

> Should a black patch be shown in
> between the colored patches to "reset" the sensor?

I don't see how that would change anything. Each reading is (should be)
independent.

Graeme Gill.

[Jean-François Besançon]

I received my Colorhug yesterday and pug it in my computer, following the indications delivered by the software which automaticaly started. It took me an hour and 30 minutes to calibrate. The result is that the monitor - which is a recent Samsung - is magenta-red. What must I do?

Thanks for your help.

[Karol Babioch]

Hi,

Am 03.10.2013 19:30, schrieb Jean-François Besançon:
> What must I do?

You might want to take a look at the FAQ [1].

[1]: http://www.hughski.com/faq.html#red-shift

Best regards,
Karol Babioch

[David Wilson]

How I resolved my red cast problem.

When I initially started my first attempt at calibration and profiling my LG Flatron L1753T monitor, the problem appeared as soon as I started the first step of the whitepoint setting. The screen showed this: 

The white balance is quite good but the app and colorhug seem to think that the green level is much too high and the red and blue levels much too low. When I set 

these levels the the mid point, the screen looked like this.

When I tried to skip the whitepoint setting, the calibration and profiling set the screen to the same red tint.

So when all else fails read the manual. The  FAQ has a topic "Why is my screen "wrong" after calibrating?" but the link there, describes a solution that required a photospectrometer. However a work around is described in The p-Code Machine ColorHug red shift workaround. This method produced a 'simple' .icc profile that can be used and it looked correct - that is no red cast. My little contribution to this is write a little shell script do-icc.sh (attached) which save the user editing the complex commands for this method. To use it place the script in a directory where you wont mind some temporary files being created and enter

do-icc.sh 'monitor manufacturer name' monitor model'

example (do not use the quotes:)            

 do-icc.sh    LG   LI753T 

this creates a LG_L1753T.icc file in that directory.

An another work around is described by Florian Höch, on  03.06.2012 in this forum topic. This method was based in the idea

>  I'm wondering if even calibrating the ColorHug towards the 
> chromaticity values from the individual user's display EDID may be an 
> improvement, but of course that would basically reduce the accuracy of 
> measurements to that of the EDID

The method is simply stated:

1. Start up dispcalGUI, click the blue "Detect displays & instruments" 
arrows, then select the colorhug under "Instrument" if it is not already 
selected. 
2. Select "Create profile from extended display identification data..." 
from the "Options" menu. Save it anywhere you like, but don't install it. 
3. Select "Create colorimeter correction..." from the "Tools" menu. 
4. Reset the screen to factory defaults. 
5. Attach the colorhug to the screen and click "Measure". After the 
measurement, the CCMX creation window should pop up again. 
6. Click "Create colorimeter correction..." 
7. Choose the profile created in step 2. Then choose the measurement 
file created in step 5 (should be automatically selected). 
8. Set the correct display, backlight and panel type, then click OK. 
9. The CCMX should be saved & automatically selected afterwards. Done. 

IMPORTANT: You must add the following lines manually to the output .ccmx file:

KEYWORD "TYPE_LCD"
TYPE_LCD "YES"

and then load the correction file to colorhug using the colorhug-ccmx command.

This process enabled me to to use dipcalGUI to adjust the whitepoint correctly and to proceed to a full calibration and profiling.

[christian pellegrin]

Hi,

I followed the first link and got some calibration that looks right. I will try the second for dispcalGUI ASAP. But the fact that I had to follow a work around (and the fact that *many* people are having the same troubles) reduced my trust in the data I'm reading. :-( The primary reason I bought the colorhugh is to be sure (or at least non be too worried about) that the color I'm seeing on the monitor will be the same when I print the photo/brochure/etc.. I will double check with as many reference colors as I can get. Any suggestion for any sources I can use?