- This topic has 7 replies, 2 voices, and was last updated 8 years, 10 months ago by
.
-
Posts
-
It may be helpful to allow users to specify the tristimulus observer (dispcal -Q) from the UI.
I wasted many hours trying to get a wide gamut and a standard gamut display to match to my eyes. The wide gamut display appeared to have a greenish color cast, despite using CCSS corrections. Then I happened across this EIZO white paper that suggests it’s better to use a 10-degree field of view observer:
http://www.eizo.ch/netmanager/download/product/pdf/9b25f50d04c81d878c3d1210a2ca188e.pdfIndeed, setting -Q1964_10c finally yields a good subjective match for me, both for the displays as well as print output. (-Q1964_10 yielded an equally good match between the two displays, but made both displays appear to have a green cast.)
It may be helpful to allow users to specify the tristimulus observer (dispcal -Q) from the UI.
Yes, I’ve thought about this for a while. The next version will include an observer choice (as an advanced option).
The problem is the i1Pro probe, it’s lack of spectral resolution (and accuracy), NOT CIEXYZ 1931
Compute XYZ(lambda) values at 1nm for several CCFL-sRGB monitor calibrated to D65, there are lots of peaks higher than what bottom plot suggest: main red is higher and there is very visible spike in blue near green that almost does not exist in their plot.
It’s a joke that Eizo uses a “toy” like i1Pro for that “scientific paper” when they have lab grade 1-4nm spectroradiometers (as seen in their promo factory calibration videos & images) but they didn’t use that devices for supporting their claims…
If using 10º observer in these poor performer spectrophotometers (Munki Photo, i1Pro, i1Pro2) improves their accuracy, that update is welcome, but one needs to point to actual culprit: poor performer 10nm spectrophotometers dealing with narrow spikes in spectra near fast rising, fast falling zones in ovserver’s curve. I mean, it would be an update to partially fix some devices inaccuracies, no a “FIX” to “human color model”.
BTW MunkiPhoto/i1Pro/i1Pro2 missreadings are pretty common in WLED an GB-LEDs too: 3.3nm steps with low SNR to 10nm optical readings and a not so good diffraction grating makes 2-3dE error readings in white almost unavoidable.
It’s a joke that Eizo uses a “toy” like i1Pro for that “scientific paper” when they have lab grade 1-4nm spectroradiometers (as seen in their promo factory calibration videos & images) but they didn’t use that devices for supporting their claims…
You don’t seem to understand what the purpose of a white paper is then (a white paper is not a scientific paper, it’s a marketing tool). The specific point of that particular white paper was to show a method to get a better match between two displays, using widely available consumer-level instrumentation that is often used in graphics arts, and in essence promoting a specific product (EIZO monitors and ColorNavigator software).
That purpose is not filled becasue the whole explanation is wrong.
Easier (and true) to explain consumer level spectrophotometer limitations and Eizo’s solution to problems related with that kind of probes (which is wellcome) instead of talinkg of a “re-thought of human color vision”.
The main problem may be that most of their customers would love an explanation involving “evaluation by eye” terms than to see their 1000 euro TOY spectrophotometer “compromised”, so may be they took that workaround without naming actual culprit (not their monitors, but xrite’s specrophotometers), which is a shame (to my eyes).Same applies to Color Navigator with colorimeters, instead of relying in EDRs for their “well know panels’ spectra” like NEC did (which at 1nm i1DisplayPro samples for WLED, WG CCFL & GB-LED will not show this behaviour in their P-IPS/AH-IPS monitors), Eizo guys took their own propietary library aproach (matrix not device independent corrections if we look at library size, look at them) which increases errors when dealing with newer revisions ( & sensitvity curves) of “CCSS-capable” colorimeters.
So they made wrong programming for “consumer level devices” (i1DisplayPro) that actually do not show that kind of missbehavior (opposite to 10nm toys) if proper high res “CCSS” is supplied. They made a new problem where there were not such problems.Eizo has great hardware, but their software solutions are not so good.
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.That purpose is not filled becasue the whole explanation is wrong.
You don’t seem to understand the underlying problem. Read up on metamerism and metameric failure.
Same applies to Color Navigator with colorimeters, instead of relying in EDRs for their “well know panels’ spectra” like NEC did (which at 1nm i1DisplayPro samples for WLED, WG CCFL & GB-LED will not show this behaviour in their P-IPS/AH-IPS monitors)
I don’t know anything about ColorNavigator, but in case they support the i1D3 it would surprise me greatly if they weren’t using the X-Rite SDK and thus the same EDR files as everyone else (btw, that paper is from 2008, the i1D3 wasn’t available back then).
And I can tell you for a fact that spectral resolution alone is not the be-all end-all solution to metameric failure. I have a WLED and WGCCFL display sitting right in front of me, and using appropriate high res spectral sample (EDR) supplied by X-Rite does not fix the visual whitepoint mismatch, and even lab-grade spectroradiometers like Minolta CS-2000, Photoresearch, or Jeti can’t fix metameric failure because it’s related to how human observers and CMFs operate.Eizo guys took their own propietary library aproach
Regarding to how the instruments are driven? I doubt it. Vendor SDKs are a thing.
(matrix not device independent corrections […])
EDRs are not device independent, that’s a silly claim.
The only difference technically between regular 3×3 matrix approaches and the way EDR spectral samples are used is that with the combination of known sensor spectral sensitivity (for the i1D3) + EDR (spectral display response) the matrix is generated on the fly. So the end result in both cases is a 3×3 matrix.- This reply was modified on 2015-06-21 13:26:33 by fhoech.
I think that is you who does not understand the point:
Let’s measure sRGB CCFLs and old WG CCFL monitors (which are not the same backlight as PA241W, no “extended red”, ot’s seen in the spectra drawings) and manually fix white point with OSD controls acording those measurements, but let’s use a Jetispecbos 1211 device (<5nm resolution)
¿Does the same problem happen?
No = It’s a problem caused by toy espectrophotometers UNSUITABLE for proper screen calibration, but somehow “good enough” for creating CCSS in high res mode, and the measure with a proper tool, like a CCSS capable colorimeter.
Yes = let’s find another observer accurater than CIE 2º 1931, we found a severe flaw on the way we are mesuring screens.That’s the point, IMHO the basis of the paper is wrong.
They use a “broken” tools not to argue how can they improve their readings but for a rethought of how ALL measurements should be done. If you want the second, you must use a measurement tool with very low (or the lowest possible) error to support your claims.
That last one is “science approach”, not “Simpson & son” magic paper on colorimetry approach.SDK used in Color Navigator does not rely on EDRs, they use a library “cn_Procs” which stores… ???? who knows. It’s a propietary Eizo approach.
NEC, Dell, BEnq, LG, Samsung rely on EDRs files supplied by Xrite SDK (and some of these companies do not supply proper EDRs for their monitors! no GB-LED support!)
Checkout by yourself, free download from their web sites. That’s a fact.“EDRs are not device independent, that’s a silly claim.”
That trully is a silly claim, a way to distort language until it matches your needs.
They are “colorimeter independent” (for those CCSS capable instruments), thus measurement device independent. I can get an EDR, transform to CCSS and get a very accurate spectral sample to correct Spyder4, 5, Munki Display and i1DisplayPro devices (and future ones if they have embeded ther sensivity curves).
It does not matter which device I have from those in the CCSS capable list, it does not matter which revision.
That’s the point of using CCSS/EDRs, because they are measurement device independent.- This reply was modified on 2015-07-25 23:39:17 by *anonymous.
I think that is you who does not understand the point:
Have you even read the OP’s post?
By the way:
This is the last warning. Either adjust your tone, or I will simply delete your posts in the future. I will not condone rude and insulting behavior on this forum. This is a place where people should feel welcome to ask questions and get answers, not being talked down on by complete strangers who don’t even have the common decency to post their condescending uninformed drivel under their real name instead of as Mr. Anonymous.¿Does the same problem happen?
Yes it can, because it is not related to the instrument, but the way the human visual system works. Again, read up on the underlying color science.
SDK used in Color Navigator does not rely on EDRs, they use a library “cn_Procs” which stores… ????
cn_Procs seems to be a general purpose plugin DLL. It doesn’t provide instrument-related functionality as far as I can tell.
That trully is a silly claim, a way to distort language until it matches your needs.
Well perhaps you should re-read your own post, because it was your claim.
That’s the point of using CCSS/EDRs, because they are measurement device independent.
They are not, you need to have access to the spectral sensitivity of an instrument to do anything with EDR files.
- This reply was modified on 2015-06-24 01:28:36 by fhoech.
