SPD2Matrix - Correlation Files to Matrix Conversion

A serious limitation with the use of Correlation Files with the Calibrite/Xrite i1D3 colourimeters is they cannot take into account the probe-to-probe variations of individual i1D3 units, as is shown on the i1D3 page of the website, the ? Correlation File Accuracy modal, where 5 different i1D3 units are compared using the same Correlation File.
They are also restricted for use just with i1D3 probes.

With ColourSpace's unique Probe Matching capabilities both restrictions can be overcome by converting any Correlation File into a ColourSpace Probe Match file, for use with any colourimeter.
And this is what the Correlation Files to Matrix Converter (SPD2Matrix) app does.

The app generates a ColourSpace .bpd Probe Match file that can be used as the Reference within ColourSpace's Probe Matching capability.
(Obviously, the Correlation File has to be one for your specific display!)

There are two potential limitations.
The first is that as with any Correlation File use, is Luminance matching cannot not performed, as with standard Probe Matching.
Therefore, during the Correlation File to Matrix conversion the measured Peak Y value of the display to be calibrated needs to be entered, with the relative RGB Y values for the file being ripple adjusted.

As this is how Correlation Files work with any i1D3 probe (no Y Luminance matching is performed), the calibration workflow is consistent.

When using the generated Reference .bpd Probe Match file generate the required Active probe match file as normal.
(It is the Y value from this that should be used when generating the Reference file via SPD2Matrix.)
(And if using an i1D3, do not use any Correlation File with the probe!)

To assist with this, SPD3Matrix will attempt to define the original Y value from the Correlation File, if a valid value is available, even if the data has been rescaled.

The second limitation is the display must be in the same state as when the Correlation File was generated when generating the Active probe matching measurements.
In most cases that means having the displays in its uncalibrated, native state.
However, it is possible some Correlation Files may have been generated with the display in a calibrated state.
When SPD2Matrix generates the .bpd Reference file it will define the likely state of the monitor when the Correlation File was generated.

It is also relatively easy to generate a Target colour space from the Reference .bpd data to see exactly what state the display was in when the Correlation File was generated.

The SPD2Matrix app can be downloads via Customer Downloads, or General Downloads.

Steve

I have a correlation file for my panel.
I convert it via (SPD2Matrix) to bpd (assume I indicated 100 Nits, and my panel perfectly matches that value)
Are the probe matched measurements I do with my I1D3 (no correlation) the same I do with my I1D3 set to that correlation file?

No, as the Probe Match workflow means you will be directly matching the i1D3 to the Reference data, which using a Correlation File cannot do, as stated above.
If the result were the same, there would be no point in using SPD2Matrix...

Steve

Do you mean I can take a spectral correction set (I assume RGBW) on my panel, convert it and use it any colorimeter?
Is that the use of the SPD2Matrix tool?

Yes!
Have a read of the Addons page of the website, the Additions section where SPD2Matrix is listed.

Also, if you read the first post in this thread your question is already answered there.

Steve

I asked this on avs but thought it might be helpful to ask here as well because I'm obviously missing something big here. In my mind, this just isn't making sense and I'm either using SPD2Matrix incorrectly or skipping an important step.

My confusion is how it separates individual meter variation from differences in the display state used to create the Active RGBW measurements.

I followed this workflow:
Put the display in its default/uncalibrated state
No correction file
Probe Matching off
Measure All and save the raw RGBW data as Active
Generate the BPD using that Active white Y
Load the raw meter data as Active and the BPD as Reference
Leave the correction file off
Enable Probe Matching

The problem is that my displays have different factory white points, and one also has a substantially different native gamut (assuming original file was created with native enabled while mine is on Auto as that does bring it closer) from the source capture. Changing the mode or calibration state changes the resulting match, which makes sense mathematically, but then I do not understand how the process isolates probe variation. On one display, SPD2Matrix called for a very large correction in the opposite direction from the normal correction file workflow. Applying it produced a result that looked clearly wrong in patterns and real content. Based on further testing, the match appears to be incorporating differences between my display state and the RGBW state stored in the Reference BPD.

What obvious step am I missing? How within this workflow can we distinguish individual probe variation from differences caused by factory white point, picture mode, gamut or calibration state? I've spent the last day testing and working different ideas but I have not come up with a solution so is what makes me think I am missing something in my workflow (likely obvious)

I had made an assumption that users would understand the concept, but in doing so I made an assumption too far.
I have edited the first post to explain a bit more regarding the workflow.

The issue is the Correlation File doesn't explicitly state the configuration the displays was in when it was generated.
That is now explained in the first post.
(And see the next post...)

Steve

To help with this I have just updated SPD2Matrix.
SPD2Matrix will now define the likely state of the monitor when the Correlation File was generated.
It will also suggest the likely peak Y value of the original display white measurement, if possible.
That should help with getting an accurate match.

Steve

Truly appreciate the clarification. It confirms what I suspected from my testing, although some comments elsewhere had me second-guessing it. Which is why I felt I was missing a step.

Just to confirm: the goal is to reproduce the source state as closely as possible (native/calibrated state, gamut, luminance and relevant measurement conditions) but not manually adjust the display to match the file's exact WP/RGB values, as that would be circular? If so, as with any method where no reference probe is present, we must accept some residual uncertainty because probe variation cannot be fully separated from normal panel/sample variation.

Oh, I also don't see the updated build in Customer Downloads yet, so I assume it is still being uploaded. As always, appreciate the feedback.

As with any probe matching you need the displays to be in the same underlying state.
With the changes to SPD2Matrix that should be easier.
And yes, the new build is uploaded and called the same.
(Clear your browser cache of you see the old download.)

Steve

A new update for SPD2Matrix has just been uploaded.
This version adds the ability to determine what the original peak Y value was, even if the Correlation File data has been rescaled, as can happen.

Steve

Thanks Steve,

I uploaded the new update today. But I still have some questions.

I measured my LG G5 WOLED display in SDR with Unity Bypass for 1D and 3D LUTs. I had slightly different readings with Calibration mode on or off from my meter. I am using off for the following example. I got close to the 90.5 cd/m2 reading used for the correlation file. With this reading of my meter.

R 20.1345 0.6788 0.3246
G 64.2624 0.2455 0.7100
B 8.5727 0.1494 0.0480
W 91.7172 0.2795 0.2818

Using 91.72 to generate the .bpd produced these numbers

R 27.8351 0.6910 0.3068
G 64.4086 0.2492 0.7029
B 9.1891 0.1514 0.0529
W 91.7200 0.3045 0.3017

Here is text out from running the latest SPD2Matrix on the LG G5 correlation file.

./spd2matrix.exe LGG5.csv -o out --white-y 91.72 --name LGG5-91.72
input : 4 measurements x 401 bands -> 380-780 nm @ 1 nm
observer: built-in CIE 1931 2 deg
auto-detected (row = input row, 1-based):
R = row 2 G = row 3 B = row 4 W = row 1
target white Y: 91.72 cd/m2

[matrix]
x y Y cd/m2
R 0.690957 0.306810 27.8351
G 0.249198 0.702943 64.4086
B 0.151380 0.052860 9.1891
W 0.304535 0.301733 91.7200
R+G+B 101.4327 (+10.59% vs white)
display state (advisory, from R/G/B/W chromaticities):
white : xy 0.3045,0.3017 nearest D93 du'v'=0.0151 [off]
gamut : nearest P3 max primary du'v'=0.0255 [off]
peak : white integrates to 9.046e+04 cd/m2 [scaled ~x1000, likely mW->W]
original white Y probably ~ 90.5 cd/m2 (confirm with --white-y 90)
relative Y (W=100): R 30.3 G 70.2 B 10.0
=> NATIVE / uncalibrated; measure the new display in its native, uncalibrated state

Written 1 file(s):
out/LGG5-91.72.bpd

I think this text out makes things clearer about what were the possible source settings for the correlation file. That is a nice improvement.

After running all three versions, I think the math used to create the values in all three remained the same.

I have a concern about the measured Red Y of my meter vs the Red Y of the .spd. The .spd Red Y is about 38% higher than my measured i1d3 Y. Green looks fine for Y with xy a bit off. Blue measurement of Y is a bit low with xy a bit off again.
I guess my biggest concern is White xy being so far off from the .spd.

I have found that the Red Y and Blue Y maintain there relatively lower measured values even as the .spd scales up to over 1000 nits.

Could my meter be broken? Could there be a problem because I am measuring a WOLED? When I measure with the correlation file in place, my Red Y and Blue Yand White xy are much closer to my measured values without a correction filke than the those in the .spd.

I hope you had a good holiday Steve,

LeRoy

As it says, the original Correlation File was generated with the display in its native uncalibrated state, with a peak measured white of about 90.5 nits.

If your display is set to that, but not matching the values extracted from the Correlation File, your display it just different.

Likely means using the Correlation File will also be generating inaccurate results...

I should add that it's unfortunately impossible to know which of the two results are 'closer' to correct, without having a high-end spectro to compare to.

Steve

Hmmm,

Mine is a later production G5, I tried the G6 correlation file to see what it generated. Both use the same Tandem panel technology.

./spd2matrix.exe LGG6.csv -o out --white-y 91.72 --name LGG5-91.72
input : 7 measurements x 401 bands -> 380-780 nm @ 1 nm
observer: built-in CIE 1931 2 deg
auto-detected (row = input row, 1-based):
R = row 2 G = row 3 B = row 4 W = row 1
ignored: row 5 6 7 (x,y shown below)
row 5 x=0.1931 y=0.3432 Y=66.23
row 6 x=0.3487 y=0.1401 Y=23.80
row 7 x=0.4289 y=0.5452 Y=79.69
target white Y: 91.72 cd/m2

[matrix]
x y Y cd/m2
R 0.690603 0.308316 20.0286
G 0.245100 0.711950 64.9193
B 0.150589 0.042414 4.8346
W 0.307071 0.327457 91.7200
R+G+B 89.7826 (-2.11% vs white)
display state (advisory, from R/G/B/W chromaticities):
white : xy 0.3071,0.3275 nearest D65 du'v'=0.0037 [borderline]
gamut : nearest Rec2020 max primary du'v'=0.0376 [off]
peak : white integrates to 89.7 cd/m2 [plausible; may be real, verify with --white-y]
relative Y (W=100): R 21.8 G 70.8 B 5.3
=> NATIVE / uncalibrated; measure the new display in its native, uncalibrated state

Written 1 file(s):
out/LGG5-91.72.bpd

Interesting, the Red Y and Green Y are very close to what I measured. And my Blue Y is now much higher than the G6 .spd. It appears that the G6 is much closer to D65 in uncalibrated state than my panel is.

Would reducing 2 point Blue High to get the panel closer to D65 help in getting the meter correction right?

LeRoy