Over-red display profiles

2522 views
Skip to first unread message

Richard Hughes

unread,
May 9, 2012, 8:29:41 AM5/9/12
to colorhu...@googlegroups.com
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

unread,
May 9, 2012, 2:30:10 PM5/9/12
to colorhu...@googlegroups.com
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

unread,
May 9, 2012, 2:35:19 PM5/9/12
to colorhu...@googlegroups.com
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.
GCM - Dell - DELL 2407WFP - CC30269S1G9S (2012-05-07) [15-06-53].icc
GCM - Dell - DELL 2407WFP - CC30269S1G9S (2012-05-07) [17-21-28].icc
GCM - Dell - DELL 2407WFP - CC30269S1G9S (2012-05-09) [09-47-13].icc

Graeme Gill

unread,
May 9, 2012, 11:28:19 PM5/9/12
to colorhu...@googlegroups.com
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

unread,
May 9, 2012, 11:42:24 PM5/9/12
to colorhu...@googlegroups.com
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

unread,
May 10, 2012, 2:53:21 AM5/10/12
to colorhu...@googlegroups.com, ro...@burtonini.com
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

unread,
May 10, 2012, 3:40:17 AM5/10/12
to colorhu...@googlegroups.com
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

unread,
May 10, 2012, 5:25:02 AM5/10/12
to colorhu...@googlegroups.com
В Чтв, 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

unread,
May 10, 2012, 5:27:58 AM5/10/12
to colorhu...@googlegroups.com
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

unread,
May 10, 2012, 5:35:40 AM5/10/12
to colorhu...@googlegroups.com
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

unread,
May 10, 2012, 5:49:17 AM5/10/12
to colorhu...@googlegroups.com
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

unread,
May 10, 2012, 5:51:15 AM5/10/12
to colorhu...@googlegroups.com
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

unread,
May 10, 2012, 11:16:40 AM5/10/12
to colorhu...@googlegroups.com
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

unread,
May 11, 2012, 4:01:26 AM5/11/12
to colorhu...@googlegroups.com

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

unread,
May 13, 2012, 6:58:24 AM5/13/12
to colorhu...@googlegroups.com
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

unread,
May 13, 2012, 4:08:05 PM5/13/12
to colorhu...@googlegroups.com
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

unread,
May 21, 2012, 9:19:46 AM5/21/12
to colorhu...@googlegroups.com
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

unread,
May 21, 2012, 10:19:28 AM5/21/12
to colorhu...@googlegroups.com
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

unread,
May 21, 2012, 10:29:49 AM5/21/12
to colorhu...@googlegroups.com

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

unread,
May 21, 2012, 10:33:34 AM5/21/12
to colorhu...@googlegroups.com
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

unread,
May 21, 2012, 10:41:03 AM5/21/12
to colorhu...@googlegroups.com
> 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

unread,
May 21, 2012, 12:06:36 PM5/21/12
to colorhu...@googlegroups.com
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

unread,
May 21, 2012, 12:29:33 PM5/21/12
to colorhu...@googlegroups.com
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

unread,
May 21, 2012, 12:37:26 PM5/21/12
to colorhu...@googlegroups.com
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

unread,
May 21, 2012, 12:56:43 PM5/21/12
to colorhu...@googlegroups.com
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

unread,
May 21, 2012, 1:03:48 PM5/21/12
to colorhug-users
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

unread,
May 21, 2012, 1:09:49 PM5/21/12
to colorhu...@googlegroups.com
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

unread,
May 21, 2012, 1:39:20 PM5/21/12
to colorhu...@googlegroups.com
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.
GCM - unknown - BENQ E2220HD - R8900286019 (2012-05-15) [06-36-38].icc

Richard Hughes

unread,
May 21, 2012, 1:47:59 PM5/21/12
to colorhu...@googlegroups.com
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.
Screenshot from 2012-05-21 18:43:58.png

Chris Lilley

unread,
May 21, 2012, 1:52:11 PM5/21/12
to Alexander Wright, colorhu...@googlegroups.com
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

unread,
May 21, 2012, 1:58:50 PM5/21/12
to colorhu...@googlegroups.com, Alexander Wright
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

unread,
May 21, 2012, 3:04:34 PM5/21/12
to colorhu...@googlegroups.com
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
edid-9b462a23a01a07d5c4f9065443fee605.icc

Jarl Arntzen

unread,
May 21, 2012, 4:37:15 PM5/21/12
to colorhu...@googlegroups.com
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

unread,
May 21, 2012, 8:17:43 PM5/21/12
to colorhu...@googlegroups.com
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

unread,
May 22, 2012, 12:34:46 AM5/22/12
to colorhu...@googlegroups.com
Here are the icc files I've generated using the livecd so far.
Thanks
Yan
GCM - Apple Inc_ - MacBookPro8,2 - unknown (2012-05-19) [02-12-02].icc
GCM - Lenovo - 0596CTO - unknown (2012-05-18) [16-59-18].icc

thilo.a...@googlemail.com

unread,
May 22, 2012, 5:37:58 AM5/22/12
to colorhu...@googlegroups.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

unread,
May 22, 2012, 6:13:47 AM5/22/12
to colorhu...@googlegroups.com
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

unread,
May 22, 2012, 8:49:50 AM5/22/12
to colorhu...@googlegroups.com
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

unread,
May 22, 2012, 9:37:52 AM5/22/12
to colorhu...@googlegroups.com
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

unread,
May 22, 2012, 9:51:30 AM5/22/12
to colorhu...@googlegroups.com
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

unread,
May 24, 2012, 9:35:29 AM5/24/12
to colorhu...@googlegroups.com
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

unread,
May 24, 2012, 3:10:07 PM5/24/12
to colorhu...@googlegroups.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

unread,
May 25, 2012, 2:17:21 AM5/25/12
to colorhu...@googlegroups.com
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.
GCM - Ancor Communications Inc - ASUS VE278 - BCLMTF114136 (2012-05-24) [19-04-10].icc
ASUS-VE278.jpg

Graeme Gill

unread,
May 25, 2012, 4:09:57 AM5/25/12
to colorhu...@googlegroups.com
What does the verbose output of dispcal look like ?

Graeme Gill.

Heinz Horstinger

unread,
May 25, 2012, 4:50:12 AM5/25/12
to colorhu...@googlegroups.com
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

unread,
May 27, 2012, 3:45:38 PM5/27/12
to colorhu...@googlegroups.com
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

unread,
May 29, 2012, 12:36:36 PM5/29/12
to colorhu...@googlegroups.com
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
GCM - BenQ - BenQ 241W - 3836 (2012-05-23) [15-28-42].icc
GCM - unknown - VBOX monitor - 78645120 (2012-05-29) [16-35-43].icc
colorhugtest.jpg

joh...@gmail.com

unread,
May 31, 2012, 2:41:16 PM5/31/12
to colorhu...@googlegroups.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

unread,
May 31, 2012, 3:00:02 PM5/31/12
to colorhu...@googlegroups.com
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

unread,
May 31, 2012, 3:55:30 PM5/31/12
to colorhu...@googlegroups.com, Markus Jung
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

unread,
May 31, 2012, 4:22:58 PM5/31/12
to colorhu...@googlegroups.com, Markus Jung
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

unread,
Jun 1, 2012, 10:54:28 AM6/1/12
to colorhug-users
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

unread,
Jun 1, 2012, 2:19:27 PM6/1/12
to colorhug-users

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

unread,
Jun 1, 2012, 8:49:55 PM6/1/12
to colorhug-users
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

unread,
Jun 1, 2012, 9:23:39 PM6/1/12
to colorhug-users
> 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

unread,
Jun 2, 2012, 7:27:13 AM6/2/12
to colorhu...@googlegroups.com
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

unread,
Jun 2, 2012, 7:34:35 AM6/2/12
to colorhu...@googlegroups.com
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

unread,
Jun 2, 2012, 8:05:57 AM6/2/12
to colorhu...@googlegroups.com
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

unread,
Jun 2, 2012, 8:29:04 AM6/2/12
to colorhu...@googlegroups.com
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

unread,
Jun 2, 2012, 9:53:22 AM6/2/12
to colorhug-users
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

unread,
Jun 2, 2012, 9:58:36 AM6/2/12
to colorhu...@googlegroups.com
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: