Whitepoint mismatch and color managed application differences.

[Tamas Toth (ebola)]

Dear Florian!

Firstly I would like to thanks a very-very lot for your fantastic application. I have 2 Spyder3 devices at my home and at my office and used them a lot in the last some years. Your DispCAL/DisplayCAL application is simply the heaven of color management and love it while I know them so really lot of thanks for your efforts.

In the other end I have 2 problem what is simply not understandable for me and I would like to ask you about. The first one is an old problem but the second is came to my eyes just in the last some weeks/months and because I would not like to disturb you in 2 different topic I will compress them into this one:)

1. and old.
   • I have a lot of problems with different whitepoint results produced by DisplayCAL on different displays what is for me a very annoying result. I know that in the following post: https://hub.displaycal.net/forums/topic/frequently-asked-questions/#visual-mismatch you try to explain it’s background but for me is not enough clean yet. Me as a layman from the hardware aspect of the colorimeters/spectrometers I think that one main target of the devices to meter the exact color and light intensity of the measured device. In this case the measurement device can accurately measure the white point of it as it can drive the monitor with full white signal (255,255,255 in 8 bit/color area) and can compare to an absolute position of the desired WB/WP. If the 255,255,255  driven signal makes a little warmer as it should be on eg. D65 (6504K) that the metering exactly know what is the problem (a little bit more green light that we would like to see). In this case the resulted color profile  could compensate the difference and make a WB perfect image. Of course this is just the brief background as the desired WB need to be correctly aligned through the whole grey scale. If colorimeters could not meter accurately the white balance and compensate it the whole result will be misleading. Of course the human eye can compensate the differences and will hold as reference the actually identified white point but this is far from the result of perfect measurements based on clear math and physics. Some people can see totally different whites as the same while for example my eyes could easily notice any type of warm or cold white compared to natural and almost colorless one. Of course this is subjective and this is my biggest problem. I would think that we need such measurement devices to make a consistent and absolutely reliable result to lock out these subjective spiceings. If I need to visually set my device to a correct white point in this case I simply rely on my eyes instead of the more accurate colorimeter what in theory should correct the errors of my eyes.
   • I have 2-3 Samsung/LG LED backlight LCD monitors (with ~sRGB color gamut) what with 6500K desired white point will be aggressively warm. The white will be very yellowish perceived simply by anybody who check them. But meanwhile I have a very old not LED backlighted SONY monitor what is a little bit off in uncalibrated state and could become very nice and natural result with DisplayCAL with 6500K target.
   • For example one of problematic monitors have the following uncalibrated WB results:
     • 17:54:18,812 White Correlated Color Temperature = 7543K, DE 2K to locus = 15.6
       17:54:18,812 White Correlated Daylight Temperature = 7529K, DE 2K to locus = 13.4
       17:54:18,813 White Visual Color Temperature = 6677K, DE 2K to locus = 15.1
       17:54:18,815 White Visual Daylight Temperature = 6826K, DE 2K to locus = 12.9
     • The monitor in uncalibrated state is a little bit colder as need (from D65 aspect) but not horrible (perceived by my eyes).
   • And the same monitor with 6500K 2.2 gamma calibration has the following WB results:
     • 17:35:10,822 White Correlated Color Temperature = 6496K, DE 2K to locus = 4.6
       17:35:10,823 White Correlated Daylight Temperature = 6499K, DE 2K to locus = 0.1
       17:35:10,823 White Visual Color Temperature = 6332K, DE 2K to locus = 4.4
       17:35:10,823 White Visual Daylight Temperature = 6502K, DE 2K to locus = 0.1
   • I also attached 1-1 gamut view of the WB calibrated and WB non-calibrated device where we need to know that the native white point is far better than the measured one what makes overcompensated warm look at the and of the calibration.
   • So at the and could you please help me what I see wrong in the whole process? It is absolutely sure that the example monitor has not 7500K native WB/WP. Maybe a little bit colder as we need but with the calibrated result the monitor is totally redish/yellowish (in one word globally pinkish and this could perceived by anyone who has eyes:)). For me the the whole calibration as a result over on a perfect gamma definition and corrected RGB levels should handle the precise WB/WP value as without it warmer displays could show us a little bit less blues while colder displays could show us a little bit less oranges.
   • The measured WB/display’s native give a little bit better result as I said the display looks like a little colder as it should but just a little bit and with the above explained background my goal would be the better result not the wronger.
   • (The relevant monitors were (Samsung/LG) usually cheap and old types while the other SONY was one of the most expensive one. But over on the price difference all of them cover approximately the same color gamut.)
   • (The color levels and the gamut usually not problematic if not perfect then manageable but the totally off WP simply makes me crazy:) The solution were always the usage of the measured one but I would like better results from this aspect also not just from the gamut and levels. So here is the point when I would like to ask you for some help.)
   • Sorry for the long explanation but maybe now (with my words) you could help me why I’m not understanding this aspect of the calibration.
2. and relatively new.
   1. Some weeks ago I just realised one interesting thing. Google Chrome 64/65 and Gimp (latest stable 2.8 but ‘beta’ 2.10 also) show me smaller gamma as Darktable and XnView with calibrated monitor profiles. On Darktable and XnView I get deeper darks as on Chrome or Gimp. On XnView and Gimp I explicitly set up the color profile what my system uses, but Chrome and Darktable  with default settings should use  the same without any custom settings. The results are however very rhapsodic as I wrote it. Did you met with it? Have you got any ideas about them? Directly color managed Gimp and default Chrome gave me the same not so deep darks while default Darktable and directly color managed XnView gave me the exactly same but deep darks. The gammas of the 2-2 applications are simply not the same.
   2. (The global environment is Ubuntu 17.10 on 2 different machines with the same results. On both device the calibrated profile made by DisplayCAL.)

And as my last sentence: sorry for anything if I was lame or undereducated in this question circle (and for my English:)).

Very lot of thanks in advance!

Tamas

Attachments:

You must be logged in to view attached files.

[Florian Höch]

Hi,

I would think that we need such measurement devices to make a consistent and absolutely reliable result to lock out these subjective spiceings

It’s physically impossible though – even if you had the “perfect” color measurement instrument whose sensor response exactly matches that of the CIE 1931 2° (or any other) standard observer (which is an average of how humans see color, and notwithstanding the possibility of finding a better average), you still have the variance in the human visual system. In addition to the human variance, instruments are also not all created equal. The most accurate device you can get is a lab-grade spectrometer like the Jeti specbos with a high spectral resolution and pair that with a good quality colorimeter, but short of that your options are very limited. There’s basically only one affordable consumer colorimeter with relatively good accuracy (due to reasonable match to the CIE 1931 2° observer), which is the i1D3.

Google Chrome 64/65 and Gimp

Chrome’s color management is not up to snuff currently and should not be relied upon (test) – use Firefox with gfx.color_management.enablev4 (to enable cLUT profile support) and gfx.color_management.mode 1 (to enable color managing untagged content) if you want correct color management. Gimp on the other hand is fine and produces the same result as other applications using littleCMS as color management module (when identical color management settings are used across applications).

Calibrite Display Pro HL on Amazon  
Disclosure: As an Amazon Associate I earn from qualifying purchases.

[Tamas Toth (ebola)]

Hi Florian!

First of all thanks for your reply! I love DisplayCAL and my questions was of course not appeared because the functionality of its but just for theory for correct my thoughts. Over on it there were some small mistakes (the referred monitor (with DisplayCAL reports in my post) in it’s factory state is not slightly blueish but yellowish) in my first post but at the end they are unimportant.

1) So about the color cast problem you say that what I would like to reach is available just in theory as in the real life instruments usually not enough accurate for my goals. So at the end I need to accept that could be incorrect metering. But also you suggest to use a new colorimeter what is ‘i1 Pro’ isn’t it? For me it is a good and acceptable answer as this is point on that there is no problem with my results and also no problem with my theory but in practice the results are different. For my real problem I found some relevant informations for what I simply could ‘hit’ my head because not searched for them before:) There are a lot of forum topics about Spyder3 whitepoint problems with LED backlight monitors. Usually referred as magenta color cast as the result of calibration. This is exactly what I got on the corresponding monitors and where I got correct results all of them are older not LED backlight monitors. In my wider environment there are some old not LED BL monitors and on them usually the calibration is enough good for me. But when I use it on the others with LED BL the result is I think in all case has magenta color cast so wrong measured WB. Maybe using fix WB offset could help if I measure the difference but the difference could be other and other on the different monitors so this is not so reliable for me. At the end if you could confirm me as this could be the case I simply need to use my Spyder3 in the same way as I used in such situations (with measured native WB of the monitors or maybe with some hardware color corrections on them referenced to my eyes what will be never and absolute reference point and what is my main problem). I hope that maybe ‘i1 Pro’ could give me a better result so I’m thinking about buying of it also.

2) The other problem is not such simply but I need to make some test images for you to check it so I need to ask some patience for make them. In short my last stable Firefox (with default settings) and also the last stable Chrome give me same results and that result is also the same what I get from Gimp (also Gnome default image viewer give me the same result). My problem is that with XnView (what is the smaller problem) and Darktable (what is my primary and loved photo post processing workspace) give me same (compared to each other) but different dark tones as all the others. Seems like gamma problem or black point compensation problem or something like this as the result is a little bit darker and more contrasting visuals. Some details in the dark tone areas are simply seems to be cutted or so. For me basically is disinterested which one is the good but as my main photo workspace is Darktable what uses system monitor profile for rendering what is the same what used by Gimp, Gnome image viewer, Chrome, and Firefox in this case the difference is deeply problematic as the images what I prepare on Darktable is different from visual aspect as every other users will see. The most important and interesting side of it that XnView (with explicitly defined monitor profile for rendering) give the same dark results as Darktable give.

I will make some test images to show you the real situation but simply don’t know what is the background of it.

Thanks again!

[Florian Höch]

So about the color cast problem you say that what I would like to reach is available just in theory as in the real life instruments usually not enough accurate for my goals.

Basically, yes. I would also advise not to focus too much on absolute white accuracy. The latter is only useful to the extent when it helps you match different monitors to one another. But the highest quality match (visually, i.e. whites look the same, not necessarily whites measure the same) usually is obtained by either using high accuracy instrumentation, or doing a visual match.

I hope that maybe ‘i1 Pro’ could give me a better result so I’m thinking about buying of it also.

Note that the i1 Pro is a spectrometer. I was referring to the i1 Display Pro / ColorMunki Display (both colorimeters out of the i1D3 family, basically the same instrument, the latter is just a tad slower).

My problem is that with XnView (what is the smaller problem) and Darktable (what is my primary and loved photo post processing workspace) give me same (compared to each other) but different dark tones as all the others.

You can use these test images to check each application’s color management.

[jenzi]

Hi Florian,

the test images are really helpful for browser and application testing. I think you should set a link to the to the test image website on the Wiki page.

[Florian Höch]

That’s planned and will likely happen as part of publishing my curated color managed applications list (still to be done).

[Author]

Posts