- This topic has 7 replies, 2 voices, and was last updated 3 years, 2 months ago by
.
-
Posts
-
Dear team, yesterday I made profiles with my ColorMunki Design for iMac 2010 (running 10.10 OS) and iMac 2019 (typical single curve + mtx + BPC for 6500K and 130cdm with some brightness reserve, X-Rite linear ICC has installed, auto brightness and night light were off), and also for MacBook Pro 2014. And I’d got unnecaptable different tints, especially between iMacs: while MacBook was something good, iMac 2010 had some green-yellow tint and iMac 2019 had magenta tint. All these showed good tests (MacBook had some dE>2 for dark saturated patches). The main difference between displays themselves is in spectrum: old one has “hills” for RGB channels (see attachment), new one has peaks (here I clip similar BenQ SW240 graph), MacBook also has “hills” and produces thinner gamut (95% sRGB only), iMac 2010 also has high-glare screen. Me and my colleague checked tints with 4000K WLED-lighted room and in total darkness from different angles: not a visual effect. As I used the same ColorMunki, I only suppose that there could be wrong conversion to L*a*b values for different IPS lighting. I have a couple of examples of profiling different paired displays, and I’d got similar tints there, but all those had modern LED lighting. Do you know this problem and how to resolve it?
i1DisplayPro +1nm WLED PFS spectral correction.
Munki Design is a 10nm spectrophotometer, at 10nm it cannot read properly newer WLED PFS backlight. At 3nm using ArgyllCMS it should improve.If you cannot afford a better device right now(i1displaypro), use visual whitepoint editor to match 2019 to 2010 (your visual “reference” for white)
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.Why do you think that ColorMunki has 10nm step? My Design edition supports -H flag and shows almost the same spectral graphs as my i1Pro 2 do, but starting at 410 or 420 nm instead of 376.7 (this is called UV filter, though it seems to be data reading start point). Xerox PhaserMatch is the same ColorMunki Design, but without X-Rite software license and this one works only with 10nm step (LowRes). I’ve tested it. However it makes display test with 3nm (HiRes mode) correctly except of zero brightness! – Cause relative values distances are correct and 3nm spectral graph too, but numbers power is wrong. And theres’s no real difference between using 3nm and 10nm mode for sharp LED spectrum, I compared them too. Cause spectral peak energy is almost the same at the same segment, and 10nm resolution is enough to make correct RGB weights for colorimeter correction.
By now I find two problems that are spectral issues:
- CCFL-lighted and old good LED-lighted display like one of iMac 2010 27″ show some light in violet segment that is blocked in ColorMunki, CCFL also produces UV light that can pass to colorimeter sensor.
- Display calibration model uses spectral correction at its first step only (XYZ weights of color channels are calculated). So, when spectral data is far away of normative RGB (like many GB-r LED have) visible color cast may appear, though DisplayCAL shows good test results.
Why do you think that ColorMunki has 10nm step? My Design edition supports -H flag and shows almost the same spectral graphs as my i1Pro 2 do, but starting at 410 or 420 nm instead of 376.7 (this is called UV filter, though it seems to be data reading start point). Xerox PhaserMatch is the same ColorMunki Design, but without X-Rite software license and this one works only with 10nm step (LowRes). I’ve tested it. However it makes display test with 3nm (HiRes mode) correctly except of zero brightness! – Cause relative values distances are correct and 3nm spectral graph too, but numbers power is wrong. And theres’s no real difference between using 3nm and 10nm mode for sharp LED spectrum, I compared them too. Cause spectral peak energy is almost the same at the same segment, and 10nm resolution is enough to make correct RGB weights for colorimeter correction.
It has 10nm (I mean Xrite driver for their tools and 3rd party licensed software provide it), Argyll driver grants 3nm which is cool. It’s a totally different picture from yours. Device as a product and tools licensed to use is 10nm, we can use 3nm thanks to argyll.
By now I find two problems that are spectral issues:
- CCFL-lighted and old good LED-lighted display like one of iMac 2010 27″ show some light in violet segment that is blocked in ColorMunki, CCFL also produces UV light that can pass to colorimeter sensor.
See where those narrow peaks are relative to std obs. You can average a peak with lower res if “-bar” func tion derivarives are close to 0.
SPD is not color. SPD multiplied by -bar functions of an trichomat observer are tristimulus color values.
Do again with WLED PFS (Hint: that SPD you plotted is not actual SPD, peaks are higher, valeys are deeper and ther is a HUGE spike where x-bar derivative reaches max abs value).
Same for GB-LED. Going from 10nm to 3nm reduces error in Z (look at z-bar derivatives), white is cooler at 3nm on an NIST certified i1Pro2, almost a match for an i1d3 corrected with U2413 standalone CCSS provided with DisplayCAL. AT 10nm it goes 3dE off. And a GB-LED has relatively “broad” spikes.
- Display calibration model uses spectral correction at its first step only (XYZ weights of color channels are calculated). So, when spectral data is far away of normative RGB (like many GB-r LED have) visible color cast may appear, though DisplayCAL shows good test results.
No.
i1d3 spectral correction uses device spactral sensivities. If they are good (they are a match of actual device spectral sensivities) and they are “close2 to std obs, then feed whatever spectral power distribution as sample to compute RGB raw (USB data) to XYZ correction matrix. As long as measured light source (or linear combination of it) matches that sample.. all works OK.
If you argue that there are some RGB input combinations do not produce an SPD that can be modeled as something very close to native colorspace SPD from primaries… you have to prove it, with a reference device. Yours is not, no NIST certified and 10nm nominal.
Also there is some uncertainty in observer matameric failure (whic maybe happening on you) and poor GPU for calibration (rounding up or down 16bit correction.
Get an i1d3, feed the known and good SPD samples for them, at least for iMac 2019. If there is a cast on white we may arge about latest sentence above.
I have i1d3 too and I use it after spectral colorimeter correction is done with ColorMunki (I rarely use i1p2 for displays, mostly for printers). I also have BenQ PV270 with RGB LED, however it is second-hand with tint spread and is plugged to 8-bit output. But I don’t have iMac 2019, probably it has the same phosphors. What do you think on almost the same test results for i1p2 correction and ColorMunki correction for PV270? Right, my i1 doesn’t have NIST certificate, it is simply second-hand unit. I also see that all three devices show different color temperature (up to +/- 180K, generally not more than 120K) for the same display.
Hm, what do you think, does the model (not cause of computational issues) can avoid metameric difference between GB-r and pure RGB LED displays?
-Metameric obs. failure if any comes from you/me, not from device.
-Device error vs actual values (10nm or 3nm vs 1nm from a JETI) is SPD reading error. This is an error that comes first, before weighting taht SPD with some observer. And there is a noticieable error with some backlights at 10nm comparing SPD readings.
-PV270 is not RGB LED, RGB LED is an un used backlight that HP used in a very old model. Likely to be a QLED like SW2700PT, shorter wavelength on red peak.
Using your munki at 3nm to correct your i1d3 is cool. There is no Xrite or Benq software spectral correction from them so using your Munki with Argylls seems mandatory. Once corrected use your i1d3 for all readings, just for speed & dark patches should be a huge improvement over munki spectro.
I mean, it is useful to have an spectro… but these graphic arts devices seem more suited to thanks to ArgyllCMS + 3nm correct colorimeters rather than take actual measurements.-CCT is not the proper way of address a whitepoint, hence that way or reasoning only leads to false conclusions.
+-1 K CCT can be 5 or 7dE apart an look green or pink. At least use a*b* to address shifts in readings from one device to another.
There was a graph on wikipedia showing this, a set of colors with the same CCT. Using CCT your are missing one coordinate, a coordinate that tells you about green-pink color cast.Thank you, Vincent! But I still think that “obs.failure” comes from …not device, of course, but from ICC model that does not represent human vision in several practical cases. Think on, XYZ normative spectral curves aren’t realy SML cones sensitivity curves (I saw these in some scientific papers, they’re wide and have huge intersection), they are optimized for the past age analytical math. You say that little spectral difference may produce significant output difference here. But our sensitivity difference is much bigger, I see tint and lightness difference between two my eyes. But, two different people (me and display owner) disputing on the same cast using the same language terms for some calibration that passes test perfectly. Moreover, I usually meet pink cast on less-than-sRGB GB-r panels (with blue peak and green-red hill in spectrum), and this stays in LED-lighted and windows-lighted room both. Note that spectral difference between those panels lighting and normative SML or XYZ spectrum (or iMac/PV270/CS2420 lighting) is much higher than difference between Munki and i1 measurements results. And spectral (and after-eye) difference between humans is also significantly higher. It is hard to believe that instrument tolerance is a bottle neck here.
May be, high peaks blind spectral sensor segments (like iMac can blind old i1), I’ve met rare graphs with “flat top” peaks. I think, you’re right – better to choose whitepoint xy coordinates by eye in some cases (at least for paper matching). Is it possible to use more readable criteria than xy values for white color? Kelvins are good units, but Planck blackbody and daylight models don’t correspond to our IPS lighting perception. Or, probably, DisplayCAL should make perceptual correction for color temperature here. What do you think on?
Thank you, Vincent! But I still think that “obs.failure” comes from …not device, of course, but from ICC model that does not represent human vision in several practical cases. Think on, XYZ normative spectral curves aren’t realy SML cones sensitivity curves (I saw these in some scientific papers, they’re wide and have huge intersection), they are optimized for the past age analytical math.
Not really. Choose any other observer, it’s a mean or median. “each human observer” variance will be there.
You say that little spectral difference may produce significant output difference here. But our sensitivity difference is much bigger, I see tint and lightness difference between two my eyes.
If you want to avoid that variance or human variance… we should move to 7-8 led like RIT prototype but it will much more expensive
But, two different people (me and display owner) disputing on the same cast using the same language terms for some calibration that passes test perfectly. Moreover, I usually meet pink cast on less-than-sRGB GB-r panels (with blue peak and green-red hill in spectrum), and this stays in LED-lighted and windows-lighted room both. Note that spectral difference between those panels lighting and normative SML or XYZ spectrum (or iMac/PV270/CS2420 lighting) is much higher than difference between Munki and i1 measurements results.
This is not a problem at all. Metamerism is wonderful. Such different SPDs producing same color… a blessing. No TV or cimema industries otherwise. Even no realistic painting.
And spectral (and after-eye) difference between humans is also significantly higher. It is hard to believe that instrument tolerance is a bottle neck here.
In WLED PFS it is, at least if we are locked to Xrite licensed software and 10nm readings.
May be, high peaks blind spectral sensor segments (like iMac can blind old i1), I’ve met rare graphs with “flat top” peaks. I think, you’re right – better to choose whitepoint xy coordinates by eye in some cases (at least for paper matching). Is it possible to use more readable criteria than xy values for white color? Kelvins are good units, but Planck blackbody and daylight models don’t correspond to our IPS lighting perception. Or, probably, DisplayCAL should make perceptual correction for color temperature here. What do you think on?
Use Displaycal/Argyll naming in log or HTM reports. Choose closest daylight (or blackbody) locus. That will be your reference/assume white. Then plot (abs value) distance from your white to assumed white. CCT for coolness-warmness, dE to loci for “whiteness”.
i1Pro2 reading a GB-LED at 10nm gives a wrong value… but it is white (error in Z translates to moving x&y across a ~45º line and daylight curve derivative is +- in that place). That’s why even wrong (~3dE) looks “white” (no pink no green)
If your imac or PV270 <3dE daylight locus? Great, I do not care it is is 6400 or 6600K. It is “white”. Even 6900K CCT, cool white but white.
