- This topic has 92 replies, 3 voices, and was last updated 3 years, 9 months ago by
.
-
Posts
-
Matrix gave just +10 nits and slightly better result than spectral, but still not as good as what i1 Studio produced directly.
The LUT correction code I’ll have to write, it will take some time. I’ll add and checkMatrix + Spectral first. (Spectral first with matrix on top.)
Calibrite ColorChecker Studio on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.Short version, CCMX made for DisplayPro is allegedly not a correction, because these are supposed to be calibrated. (It should give display primaries.) Unless you make a 1024+ point LUT style correction for i1d3 which is not what CCMX is.
No… you do not understand the basics.
It is a correction on a literal sense of the word. 3 vector in -> XYZ to XYZ matrix -> 3 vector out. IT NEEDS to be dependent on correcetd device (not just display) by definition. If you read Argyll code you’ll know it. It seems you didn’t
CCSS integrated x std observer is what gives you display primaries… actualy latest DisplayCAL version do it for you with a primaries 2D plot.
I’ll characterize the differences in these three approaches later. And you should probably stop dissing.
You should learn the basics before operating this kind of equipment, mostly because you mix oranges & apples and may confuse other people.
Aesop has a fable about a flute. Blowing != musicAgain, CCMX is a correction matrix… Relating *relating display primaries to the probe*. In short is a transform of primaries into primaries.
(Not entirely true because the display primaries are measured using another probe, but close enough.)
It’s still a profile, not a calibration.Which *should* be equivalent to a matrix relating CCSS data primary means to i1d3 calibration primary means. Except it is not, because the probe is not correctly calibrated.
And the probe is nonlinear too, so a matrix fails to correct fully anyway.CCSS is a display profile. CCMX is a display + probe combined profile. (Similar to vcgt applied vs not applied.)
You can recover display primaries matrix by multiplying it by inverse of i1d3 primary means. (Inaccurate if i1d3 is not calibrated.) This is what I mean by portable. You could instead of a CCMX give out a device primary matrix and use the calibration data, or store the calibration data alongside to make it as portable as CCSS. (NOT a whole lot.)Both methods fail to correct fully.
A colorimeter correction matrix would not be tied to any display whatsoever and would relate its calibration primaries to its true primaries. And CCMX unfortunately is tied to a display. It relates display primaries to measured values by the colorimeter. (You can recover actual correction matrix with some math as I described above.)
Again, CCMX is a correction matrix… Relating *relating display primaries to the probe*. In short is a transform of primaries into primaries.
(Not entirely true because the display primaries are measured using another probe, but close enough.)
It’s still a profile, not a calibration.As I said before forcing naming it will be like a “device link profile” or a LUT3D, a transformation that makes somde device behave (measure) as another one. Not a “profile” = “device description”.
Which *should* be equivalent to a matrix relating CCSS data primary means to i1d3 calibration primary means. Except it is not, because the probe is not correctly calibrated.
Actually if you knew what you were talking about (actually I wrote it here before) a CCSS once read i1d3 firmware is used to compute a matrix (and RGB to XYZ instead of XYZ to XYZ, but equivalent). In the end you get a 3×3 matrix. It has been writen before.
But not by CCSS alone. CCSS and i1d3 are independent.CCSS is a display profile. CCMX is a display + probe combined profile. (Similar to vcgt applied vs not applied.)
As I said before forcing naming it will be like a decive link profile or a LUT3D.
You can recover display primaries matrix by multiplying it by inverse of i1d3 primary means. (Inaccurate if i1d3 is not calibrated.)
Hence it does not store display primaries. Additional data is needed.
This is what I mean by portable.
Portable means valid between several devices (i1d3). Since CORRECTION (that’s what it is) in a CCMX data includes both display and particular colorimeter data, they are not.
That’s why Xrite figured this method, to get rid to a high extent from inter instrument agreement issues as long as you provide stable filters and spectral sensivity data.
Tha’ts why an SpyderX is not very future proof or why selling built in (built in= not on site, for your display) corrections for an i1d3 is close to scam business model. That’s why people laugh about it in AVSforum.You could instead of a CCMX give out a device primary matrix and use the calibration data
I’m not sure if you know what are talking about…
A colorimeter correction matrix would not be tied to any display whatsoever and would relate its calibration primaries to its true primaries. And CCMX unfortunately is tied to a display. It relates display primaries to measured values by the colorimeter. (You can recover actual correction matrix with some math as I described above.)
The smoking gun proof that you do not known what you are talking about.
Since colorimeter observer and your reference observer do not match in several bands, it HAS TO BE tied to SPD being measured.
Why? because XYZ coordinates come from ain integral where SPD is weighted against an observer.Please read at least wikipedia article on CIE colorspace before posting nonsense.
Preferably colorimeter correction matrix would be done by measuring multiple reference wideband white light sources. (Of any different CCT and brightness.)
Surprise!
What can be obtained with a monochromator and a “filter+sensor” system like those inside in a i1d3? Yes… device spectral sensivity curves.
What can be obtained with a “close to” standard but “non equal to” colorimeter observer (spectral sensivity curves) and a reference light source (EDR/CCSS)? YES! a 3×3 matrix correction to make that colorimeter behave like (with some tolerance) to some std/reference observer… like Xrite SDK does and ArgyllCMS does.You invented the wheel… no, you did not. Actually Xrite (or somebody before them) did it long time ago. And it is written in this thread several post ago.
Did they? Then why CCSS and CCMX correction methods do not match? (With CCSS being the more wrong.) Same display, same spectrometer, same colorimeter. Same screen position. Same CIE observer. Math in Argyll code seems correct too.
Something is off in how they calibrate i1d3. Either is not calibrated for every device, the monochromator is broken, reference bulbs are wrong, there is a major uncorrected inter-filter nonlinearity or of it uses an optical splitter it’s of low quality. Anyway, it seems I get to correct the device itself so that CCSS files are useful.
Argyll does not provide the functionality yet. 3DLUT I envision would correct for a given device and colorimeter pair but would be highly not portable between displays alone. The idea is to run the parallel profiling process on many displays, then nnrev a common 3D spectral correction. (Potentially even flash it into i1d3.)
Perhaps i1d3 is mechanically unstable (you hit it, it goes wrong), or components are calibrated, not the whole device as it has been assembled.
Monochromizer of good quality or a set of tunable lasers is not cheap, so something else would have to be done.
Specifically these cost exactly as much as a high end spectrophotometer, because they’re the main expensive component of the slower ones of them. (Like $8k plus.)
Did they? Then why CCSS and CCMX correction methods do not match? (With CCSS being the more wrong.) Same display, same spectrometer, same colorimeter. Same screen position. Same CIE observer. Math in Argyll code seems correct too.
CCSS sets a reference to compute a matrix based on spectral sensivities. Both “reference observer” and “colorimeter observer” get the same SPD data, app computes a matrix to transfrom readings between one onserver to ref observer.
When you make a CCMX, reference observer (through spectro read) gets a “limited” SPD reading to whatever capabilities reference measurement device has.
Then ***ACTUAL*** SPD from light source gets through colorimeter filter+sensor, applies default correction and gets uncorrected XYZ readings.
Then a matrix is computed to get a transformation from uncorrected to reference XYZ values.
Colorimeter observer and reference observer get DIFFERENT SPDs.If you have a true reference device, like a JETI, make CCSS by yourself and a CCMX for a display, CCSS corrected readings vs CCMX corrected readings differences are caused by innacuracies in firmware spectral sensivities. But you have to make that CCSS for YOUR display to test this.
If you have a graphics art spectro like an i1pro2 CCSS vs CCMX can be caused by limited/cripled SPD reading in spectro vs ACTUAL SPD going through filters. WLED PFS is a good example. Of course there is the possibility of colorimeter sensivity curves being innacurate but you CANNOT know unless you do the test above (JETI or equivalent test)
Hence as a general recommendation for well behaved colorimeter with spectral sensivities like i1d3:
-Do you have a JETI?
Make CCMX (most accurate = read the same WP as JETI), also if you do not mind make a CCSS and share it with community
-Do you have an i1pro2/munkiphoto/etc?
Make a CCSS 3nm, share it with comunity. Take a look on SPD lot and look for potentially troublesome shapes that in a sensible guess may point to very narrow SPD peaks that your spectro cannot read properly. If that SPD matches a well known 1nm CCSS SPD maybe colorimeter would measure better with the one @1nm bundled in displaycal or from community
In those cases watch for huge WP shifts if you move from 10nm to 3nm.Something is off in how they calibrate i1d3. Either is not calibrated for every device, the monochromator is broken, reference bulbs are wrong, there is a major uncorrected inter-filter nonlinearity or of it uses an optical splitter it’s of low quality. Anyway, it seems I get to correct the device itself so that CCSS files are useful.
No. Just happens that you did not know the basics about how CCSS/CMX work. Or that you have a broken/faulty i1d3, if warranty is valid use it
Perhaps i1d3 is mechanically unstable (you hit it, it goes wrong), or components are calibrated, not the whole device as it has been assembled.
That’s is a reasonable cause of your i1d3 being broken, I wrote it several post above, maybe it was hit by something.
Monochromizer of good quality or a set of tunable lasers is not cheap, so something else would have to be done.
Specifically these cost exactly as much as a high end spectrophotometer, because they’re the main expensive component of the slower ones of them. (Like $8k plus.)
Since it is done at factory by Xrite… seems no problem.
Just curious but how does the CIE2012 observer in displayCAL work, and how accurate is it when the probe (i1d3) itself is based on CIE 1931, also are there verification reports/simulation profiles for CIE 2012 CMF/whitepoint?
AFAIK, confirm it with Florian, HTML reports are CIE 1931 2 degree. Argyll’s console information, like in DisplayCAL console reports about (un)calibrated white point CCT + dE to loci can use alternative observers.
AFAIK a WP in CIE 2012 should look very close to CIE 1931 in a* axis. In b* axis D65 2012 is seen as cooler in 1931, but white.Just curious but how does the CIE2012 observer in displayCAL work, and how accurate is it when the probe (i1d3) itself is based on CIE 1931, also are there verification reports/simulation profiles for CIE 2012 CMF/whitepoint?
AFAIK, confirm it with Florian, HTML reports are CIE 1931 2 degree. Argyll’s console information, like in DisplayCAL console reports about (un)calibrated white point CCT + dE to loci can use alternative observers.
AFAIK a WP in CIE 2012 should look very close to CIE 1931 in a* axis. In b* axis D65 2012 is seen as cooler in 1931, but white.Hmm i see, would you say that CIE2012 is more accurate due to it being newer?
Maybe, but for compatibility reasons and since all image editing color managed apps(*) use relative whitepoint intents for “image file to screen”, I’ll use CIE 1931 2 degree + whatever visual white point adjustment you need (usually none).
(*) excluding SW or HW LUT3D with abs col intents, for visual wp you may want rel col intent in such LUT3D
