- This topic has 35 replies, 3 voices, and was last updated 2 years, 1 month ago by
.
-
Posts
-
While I’m still pondering this, I have one question: how are CCSS applied? Is this something that is passed to the driver for the device and the device uses it internally to create a new matrix? Because I guess we don’t get to see the sensitivity curves stored in firmware…
We “see” them. There is a hid command to dump external eeprom which stores sensivity curves (RGB raw).
Since this is some kind of observer, you pass SPD to std observer, then pass same SPD to sensivity curves, then compute a matrix to make the second equivalent to first, which gives you RGB -> XYZ matrix.
No correction means sensivity curves are used as SPD… whcih gives you another RGB -> XYZ. Then is pretty simple to find a XYZ->XYZ (CCMX) from those matrices.
It all runs on software and i1d3 is a HID device… hence is future proof. You only need unlock codes for each i1d3 flavor (and that sensivity curves are more or less accurate: they match device behavior and device behavir remains stable over teh years).
Computed RGB -> XYZ matrices for each CCSS can be dump with Argyll command line running on high verbose -d3 or soemthing like that ( 3 or 4 decimal places)Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.So I played around some more. Attached you can find a plot of my display primaries vs. the 2nd of the three samples in the Pana ccss file (subsampled to 3nm). The Pana curves don’t have the hump, but it seems the green primary is shifted quite a bit, and this is also visible in the (also attached) resulting chromaticies. The Pana green is right at the intersection of Adobe and P3 triangles, my screen’s green is more inside the Adobe triangle.
Is this possible? I still don’t think my spectro can be so much off, also you can see that blue matches up perfectly, and red is also quite a good fit (disregarding the slightly different weighting of the primaries here). But even this translation only leads to a CIE2000 difference of about 1.5 in the green channel when evaluated at around Y=60 (yes, I did the math, evaluated with the 2° CMFs, normalized XYZ to the Y of the whitepoint to get an approximate Y at which to compare).
For CIE2000 based on Yxy I use this: http://colormine.org/delta-e-calculator/cie2000
I got the cmf from here (1931 2°, 1nm): http://cvrl.ioo.ucl.ac.uk/cmfs.htm
Apart from that, I think I still don’t understand how colorimeter firmware correction actually works. If I have the primaries measured with the spectro as ccss, I can always construct a correction matrix when calibrating by measuring the primaries also with the colorimeter and computing the matrix on the fly. How would using the firmware curves be any better here?
And where in the files generated by argyll (in the storage directory) can I find values output by the colorimeter directly (I think this is in the ti3-files for ccmx-generation), and where can I find values generated using the correction (I want to check what XYZ-values the colorimeter outputs for my primaries, particularly after ccss correction).
So I played around some more. Attached you can find a plot of my display primaries vs. the 2nd of the three samples in the Pana ccss file (subsampled to 3nm). The Pana curves don’t have the hump, but it seems the green primary is shifted quite a bit, and this is also visible in the (also attached) resulting chromaticies. The Pana green is right at the intersection of Adobe and P3 triangles, my screen’s green is more inside the Adobe triangle.
Build an hybrid CCSS
Apart from that, I think I still don’t understand how colorimeter firmware correction actually works. If I have the primaries measured with the spectro as ccss, I can always construct a correction matrix when calibrating by measuring the primaries also with the colorimeter and computing the matrix on the fly. How would using the firmware curves be any better here?
Because to compute XYZ you are using a crippled SPD while colorimeter to measure raw RGB counters with is own observer is receiving full non discrete step SPD.
CCSS + firmw colorimeter curves “add/substract” weights depening on how much colorimeter observer drifts from observer, while “trusting” the wieght of some wavelengths where it is accurate. Hence a CCMX computed with a crippled SPD in the specific wavelengths where colorimeter is accurate its theoretically less accurate than a CCSS applied to an accurate i1d3 (accurate i1d3 means that its firmw curves matches i1d3 behavior, DOES NOT MEAN that firmw curves match std observer).
I’ve used the word weight to account that since a colorimeter does not output wavelength information all these corrections are added into a matrix.To sumarize:
CCMX: i1pro outputs crippled SPD -> compute XYZ for one observer, i1d3 outputs raw RGB measured with full SPD, then CCSS corrects to itself. Compute a matrix created from 2 measurements OF DIFFERENT SPD
CCSS: i1pro outputs crippled SPD , i1d3 outputs firmw curves, “synth measure” i1pro XYZ, “synth measure” i1d3 raw RGB output. Compute a matrix created from a single SPD.Depending on SPD (on max abs value of derivatives of “real world” SPD) and where colorimeter curves drift from observer you’ll have to deal with different errors.
If firmw curves are accurate (match real behavior) it is better to use CCSS with Xrite 10nm spectros. Otherwise CCMXAnd where in the files generated by argyll (in the storage directory) can I find values output by the colorimeter directly (I think this is in the ti3-files for ccmx-generation), and where can I find values generated using the correction (I want to check what XYZ-values the colorimeter outputs for my primaries, particularly after ccss correction).
Colorimeter does not output XYZ, outputs RAW RGB counter values. An uncorrected colorimeter is CCSS correcetd using as CCSS its own curves.
If you want to drop raw RGB sensivity curves and equivalent xyz observer (x-bar, y-bar etc) you’ll have to compile Argyll with some defines. Look at the code.So I played around some more. Attached you can find a plot of my display primaries vs. the 2nd of the three samples in the Pana ccss file (subsampled to 3nm). The Pana curves don’t have the hump, but it seems the green primary is shifted quite a bit, and this is also visible in the (also attached) resulting chromaticies. The Pana green is right at the intersection of Adobe and P3 triangles, my screen’s green is more inside the Adobe triangle.
Build an hybrid CCSS
What exactly are you suggesting? Do you think the green curve is measured incorrectly and should be like the Pana curves? or do you mean I should take the green curve from the i1pro and the red and blue ones from the pana files?
Apart from that, I think I still don’t understand how colorimeter firmware correction actually works. If I have the primaries measured with the spectro as ccss, I can always construct a correction matrix when calibrating by measuring the primaries also with the colorimeter and computing the matrix on the fly. How would using the firmware curves be any better here?
Because to compute XYZ you are using a crippled SPD while colorimeter to measure raw RGB counters with is own observer is receiving full non discrete step SPD.
CCSS + firmw colorimeter curves “add/substract” weights depening on how much colorimeter observer drifts from observer, while “trusting” the wieght of some wavelengths where it is accurate. Hence a CCMX computed with a crippled SPD in the specific wavelengths where colorimeter is accurate its theoretically less accurate than a CCSS applied to an accurate i1d3 (accurate i1d3 means that its firmw curves matches i1d3 behavior, DOES NOT MEAN that firmw curves match std observer).
I’ve used the word weight to account that since a colorimeter does not output wavelength information all these corrections are added into a matrix.To sumarize:
CCMX: i1pro outputs crippled SPD -> compute XYZ for one observer, i1d3 outputs raw RGB measured with full SPD, then CCSS corrects to itself. Compute a matrix created from 2 measurements OF DIFFERENT SPD
CCSS: i1pro outputs crippled SPD , i1d3 outputs firmw curves, “synth measure” i1pro XYZ, “synth measure” i1d3 raw RGB output. Compute a matrix created from a single SPD.Depending on SPD (on max abs value of derivatives of “real world” SPD) and where colorimeter curves drift from observer you’ll have to deal with different errors.
If firmw curves are accurate (match real behavior) it is better to use CCSS with Xrite 10nm spectros. Otherwise CCMXI think my question is different. Let’s assume you have a reference CCSS (measured with a 1nm reference spectro). Why would I want to use the colorimeter firmware curves to create a correction matrix and not just use the colorimeter to measure RGBW and compute a correction matrix from the measured colorimeter values (the corresponding XYZ-values I can get from the CCSS). This way I don’t have to trust the firmware correction but just use the measured values, where the filters are actually applied to my actual screen.
That brings me to another question how to evaluate the relevance of this. As I’ve written above, I can compute XYZ from the measured (or provided) SPDs, as well as normalize these values by the Y from white so it is 0<Y<100, and thus compute Yxy. But what color difference metric would you suggest if we want to mostly look at chromaticities? Color differences require a luminance at which to evaluate, and the relationship is non-linear. Yes, some pages (e.g., the Chromapure pages) assign deltaE-values to chromaticities. Is this computed at the maximum Y? Obviously, for this to make sense, the Y-values need to be the same for both colors.
So I played around some more. Attached you can find a plot of my display primaries vs. the 2nd of the three samples in the Pana ccss file (subsampled to 3nm). The Pana curves don’t have the hump, but it seems the green primary is shifted quite a bit, and this is also visible in the (also attached) resulting chromaticies. The Pana green is right at the intersection of Adobe and P3 triangles, my screen’s green is more inside the Adobe triangle.
Build an hybrid CCSS
What exactly are you suggesting? Do you think the green curve is measured incorrectly and should be like the Pana curves? or do you mean I should take the green curve from the i1pro and the red and blue ones from the pana files?
It you can use your data, use them and where you cant becuse it has/may have too much error take closest reference. Depending on colorimeter this may not have impact.
Apart from that, I think I still don’t understand how colorimeter firmware correction actually works. If I have the primaries measured with the spectro as ccss, I can always construct a correction matrix when calibrating by measuring the primaries also with the colorimeter and computing the matrix on the fly. How would using the firmware curves be any better here?
Because to compute XYZ you are using a crippled SPD while colorimeter to measure raw RGB counters with is own observer is receiving full non discrete step SPD.
CCSS + firmw colorimeter curves “add/substract” weights depening on how much colorimeter observer drifts from observer, while “trusting” the wieght of some wavelengths where it is accurate. Hence a CCMX computed with a crippled SPD in the specific wavelengths where colorimeter is accurate its theoretically less accurate than a CCSS applied to an accurate i1d3 (accurate i1d3 means that its firmw curves matches i1d3 behavior, DOES NOT MEAN that firmw curves match std observer).
I’ve used the word weight to account that since a colorimeter does not output wavelength information all these corrections are added into a matrix.To sumarize:
CCMX: i1pro outputs crippled SPD -> compute XYZ for one observer, i1d3 outputs raw RGB measured with full SPD, then CCSS corrects to itself. Compute a matrix created from 2 measurements OF DIFFERENT SPD
CCSS: i1pro outputs crippled SPD , i1d3 outputs firmw curves, “synth measure” i1pro XYZ, “synth measure” i1d3 raw RGB output. Compute a matrix created from a single SPD.Depending on SPD (on max abs value of derivatives of “real world” SPD) and where colorimeter curves drift from observer you’ll have to deal with different errors.
If firmw curves are accurate (match real behavior) it is better to use CCSS with Xrite 10nm spectros. Otherwise CCMXI think my question is different. Let’s assume you have a reference CCSS (measured with a 1nm reference spectro). Why would I want to use the colorimeter firmware curves to create a correction matrix and not just use the colorimeter to measure RGBW and compute a correction matrix from the measured colorimeter values (the corresponding XYZ-values I can get from the CCSS). This way I don’t have to trust the firmware correction but just use the measured values, where the filters are actually applied to my actual screen.
You’ll have to use firmware curves too. No correction=use firmw curves as CCSS.
But yes, if you have a JETI specbos you want a CCMX (i1d3 curves as CCSS -> RGB to XYZ, then additional XYZ -> XYZ from CCMX). But that CCMX only works for you.
If you want other people to measure accurately that display type you’ll have to create a CCSS and distribute it for other i1d3 users since your CCMX is mosty useless for other i1d3s.That brings me to another question how to evaluate the relevance of this. As I’ve written above, I can compute XYZ from the measured (or provided) SPDs, as well as normalize these values by the Y from white so it is 0<Y<100, and thus compute Yxy. But what color difference metric would you suggest if we want to mostly look at chromaticities? Color differences require a luminance at which to evaluate, and the relationship is non-linear. Yes, some pages (e.g., the Chromapure pages) assign deltaE-values to chromaticities. Is this computed at the maximum Y? Obviously, for this to make sense, the Y-values need to be the same for both colors.
I’d say normalize (W channel with Y=100, W=R+G+B) then a*b* or u*v* and 2D plot them. You want to see “saturation”&”hue” error, not L*. Not perfect but for a 2D plot you can get a hint.
ean I should take the green curve from the i1pro and the red and blue ones from the pana files?
It you can use your data, use them and where you cant becuse it has/may have too much error take closest reference. Depending on colorimeter this may not have impact.
So given the image I posted, what would be your concrete suggestion?
blu reference (or yours, it seems that does not matter)
green yours
red check which 6 reference are closer to yours: HP Z24x, VVX panasonic, 4 from PFS family
then W=R+G+B (chosen ones)
Interpolate when needed to 1nm. I think that argyll code has a comment somewhere about its prefered interpolation method but I do not remember where it is.Then compare vs your CCSS 3nm, maybe it does not matter in your i1d3 => 3 RGB sensors are very close to std observer on those wavelengths . IDNK, firmw data is supposed to be unique per unit or a mean/sample per batch.
blu reference (or yours, it seems that does not matter)
green yours
red check which 6 reference are closer to yours: HP Z24x, VVX panasonic, 4 from PFS family
then W=R+G+B (chosen ones)
Interpolate when needed to 1nm. I think that argyll code has a comment somewhere about its prefered interpolation method but I do not remember where it is.Then compare vs your CCSS 3nm, maybe it does not matter in your i1d3 => 3 RGB sensors are very close to std observer on those wavelengths . IDNK, firmw data is supposed to be unique per unit or a mean/sample per batch.
So to find out whether this all makes sense, I successively averaged a well-matching pana-curve and compared it to the i1pro curve. I found that I had to take an average of 9 values to have the spikes disappear in a similar way as in the i1pro curve (see image, yellow is i1pro and blue is 9-point averaged+subsampled pana curve).
This tells me the i1pro doesn’t really get near 3nm resolution, it’s still more or less 10nm.
There is another difference: the i1pro decays much faster to the left of the leftmost spike, there the pana curve remains much higher (you would probably call it “desaturated”). I wonder what that means…
So in order to get a reasonable result I would have to take the spiky part form the pana curve and the decay from the i1pro. What do you think?
You’ll have to use firmware curves too. No correction=use firmw curves as CCSS.
But yes, if you have a JETI specbos you want a CCMX (i1d3 curves as CCSS -> RGB to XYZ, then additional XYZ -> XYZ from CCMX). But that CCMX only works for you.
If you want other people to measure accurately that display type you’ll have to create a CCSS and distribute it for other i1d3 users since your CCMX is mosty useless for other i1d3s.I don’t understand what “no correction = use firmw curves as CCSS” means.
Let’s assume I have a hires CCSS. To generate a CCMX matrix, I would compute XYZ for all the 4 curves in the CCSS. And then measure the corresponding patches with the colorimeter (without any correction), and get another 4 color values (either XYZ or RGB, I don#t know). After balancing using the white curve, I could just create a 3×3 matrix from that (9 equations, 9 unknowns), and it would use the hires curves from the CCSS and the actual measurements from the colorimeter, so it would correspond perfectly to the colorimeter. Hmmm, actually, thinking about it more, I wouldn’t even need the spectral curve – the XYZ of the primaries and white would be sufficient!
So what am I missing? I just don’t understand why I need the firmware curves to “simulate” measuring the spectral distribution with the colorimeter, when I can just “do it” and measure them!
Maybe I’m missing something fundamental about the whole process, but the fact that you can generate a matrix is motivated by Grassmann laws (additivity), so they should work as well for the workflow I suggested, no?
I don’t understand what “no correction = use firmw curves as CCSS” means.
If you set i1d3 colorimeter to “No correction”, it is using colorimeter sensivty curves stored in firmware as a sample display (as a sampe CCSS).
As explained before i1d3 colorimeter does not outut XYZ coordinates, it outputs RGB RAW counter values than need a RGB -> XYZ matrix. This matrix is computed with CCSS and sensivity curves. ALWAYS. It needs this.
Using a CCMX matrix (a JETI matrix correction) means to
1) apply a CCSS to get XYZ (if no correction it means using colorimeter curves as sample display)
2) apply a XYZ to XYZ (CCMX) to match XYZ on ref probe (JETI) and “inaccurate probe” (i1d3)But why not just use the raw RGB counters to compute the matrix? Why does it always need this inbetween matrix? The product of 2 3×3 matrices is a 3×3 matrix, and could be computed directly. Instead of RGB->XYZ1->XYZ2 I could go directly RGB->XYZ2…
But why not just use the raw RGB counters to compute the matrix? Why does it always need this inbetween matrix? The product of 2 3×3 matrices is a 3×3 matrix, and could be computed directly. Instead of RGB->XYZ1->XYZ2 I could go directly RGB->XYZ2…
That 1 step matrix is a matrix obtained from a CCSS.
CCMX are XYZ to XYZ, a generic hw agnostic way to correct one measurement with a reference. CCMX are close to identity. RGB to XYZ are not. Plot them running ArgyllCMS with high verbose -d3 or so.
Could you code a tool that takes raw RGB values and outputs corrected XYZ with a ref device and several measurements? yes, but that will be i1d3 specific.
