- This topic has 25 replies, 4 voices, and was last updated 2 years, 8 months ago by
.
-
Posts
-
OK, but:
- You loses i1d3 quality issues here. My i1d3 shows significantly different results between spectral correction and personal mtx correction. So, perfect spectral correction in CN won’t give effect if it doesn’t build personal correction for custom i1d3. It seems that it doesn’t. Do you know how it works?
- You dramatize spectrum discretization factor. My practice shows that even 10nm step gives almost the same result as 3 nm in the most cases. I’m not sure that measurement of peaky red phosphor actually needs small steps, this is measurement way question. CN may use proper panel type correction for 10nm measurement (or use spectrophotometer as colorimeter and HQ EDR correction). Here is practical answer: 3nm DisplayCAL test shows good result after CN calibration.
- EDR hack is difficult to me and, I think, impossible for most users. This hole may be used by some experienced persons. But, thank you for this find.
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.OK, but:
- You loses i1d3 quality issues here. My i1d3 shows significantly different results between spectral correction and personal mtx correction. So, perfect spectral correction in CN won’t give effect if it doesn’t build personal correction for custom i1d3. It seems that it doesn’t. Do you know how it works?
what? EDRs? they are based on spectral sensivity curves measured on factory. Missmatch betweeen them an actual device behavior can be:
-worn out unit
-measuring a batch nor representative of your unit.If they are accuracte correction works as follows:
simulated RAW RGB readings from sample = integral (sample SPD x “colorimeter sensivities/observer”)
simulated CIE XYZ =integral (sample SPD x std observer)
simualted CIE XYZ = Mccss x simulated RGB readings f
Solve Mccss = matrix from RGB raw to XYZ, apply that matrix to RAW RGBreadings from USB port.
What you do with a MTX:
- compute matrix from RGB to XYZ using colorimeter sesivities as sample display backlight (= using colorimeter sensivity as CCSS). “Muncorrected”
- measure primaries with i1Pro2 : simulated CIE XYZ =integral (“crippled SPD” measured by i1pro2 x std observer). “Ref”
- Ref = Mcustom x Muncorrected x RAW RGB readings for your display, solve Mcustom
Argyll can output Mccss and Muncorrected if you run it with high -d mode, -d2 or -d3 or something like that.
These 2 matrices are RAW RGB to CIE XYZ. They are not like your MTX which is CIE XYZ to CIE XYZ.- You dramatize spectrum discretization factor. My practice shows that even 10nm step gives almost the same result as 3 nm in the most cases. I’m not sure that measurement of peaky red phosphor actually needs small steps, this is measurement way question. CN may use proper panel type correction for 10nm measurement (or use spectrophotometer as colorimeter and HQ EDR correction). Here is practical answer: 3nm DisplayCAL test shows good result after CN calibration.
for WLED or GBLED or QLED is not a big issue, mostly b* drift mecause Z. “Whiteness” won’t vary, mostly CCT.
for WLED PFS is very significative.- EDR hack is difficult to me and, I think, impossible for most users. This hole may be used by some experienced persons. But, thank you for this find.
Yes. If it can be uploaded do 1fichier it would be just to replace file, set CN to use EDR insted of default MTX and done.
IDNK how to distribute it playing borderline with IP rights.
Maybe if Midas did the CCSS2EDR approach and it worked it’s the easier approach because that way you can avoid to use an hex editor
simulated MTX x Muncorrected = Mccss
simulated MTX = Mccss x Muncorrected ^-1
You can compare your computed MTX with “simulated MTX from CCSS”. Both are CIE XYZ to CIE XYZ and both are very close to identity mtx 3×3 with a grain of salt on components that should be 0.
Mccss or Muncorrected are not close to identity, check Argyll output with spot read or something like that if you run with high debug. No measureent is needed, computed matrices are written to stdout on i1d3 initialization.
Simulated MTX can be used to bring “CCSS-like corrections for YOUR i1d3 device” for very unknow displays (like SW2700PT) measured by community to software like Calman or lightspace that allow custom 3×3 matrices but not custom CCSS.
If Eizo or dell or NEC or Benq … all these guys had a 3×3 MTX box in their software , users (WE) can made custom corrections even without having an spectrophotometer, just with a community provided CCSS and that matrix equation I wrote above.
Hm, here is my i1p2 and ColorMunki (may be mine too, I don’t remember if I measured that CS2731) graphs. Difference is well seen.
Munki lacks of the Green LED + tile present on i1Pro2 for self aligment. Looks like diffraction grating on munki is missaligned. IDNK if munki has some self correction feature. Maybe measuring the reflection of a laser/led pointer on some surface you can see misalignment.
Munki has self-calibration position, this is white tile measurement, it has one inside as I know (I haven’t disassmble it yet). DisplayCAL requests its calibration similarly to i1 calibration. It uses WLED like home light, I’ve measured it with i1p2. It is classified as UV-cut instrument, but obviously it can’t calibrate itself at 377…400 nm cause WLED does not cover this range. I agree that graph by Munki looks like diffraction element misalignement, this may occur cause of wrong lens focusing on it.
Now check attached HP Z24x 1nm and my Eizo graphs. Spectrum covered areas are equalized. Some things are different. Think on: panel lighting itself does not make final RGB curves, we also have RGB filters upon subpixels.
3nm measures are averaged of incoming SPD at its wavelength window + device error vs a JETI/CR reference. I mean, IMHO I see no difference in CCSS once aligned, just different precission devices.
In the same way (but perhaps different scale) you could plot an error graph between i1d3 firmware sensivity curves and actual filter+sensor response on an i1d3 while measuring a monochromator. If you do the same with a lab grade colorimeter with same firmware sensivity curve feature likely to see different high in error graph,As a side note you cannot compare those SPD in a direct way unless they were measuring the same monitor (same unit) because it is going to be a white point mismatch. You can play with a simulated white K1*R+K2*G+K3*R using your munki RGB samples instead of W=> compute XYZ white on 1nm reference CCSS. Then find K1,K2,K3 for your munki sample that will give simulated white the same whitepoint. Then plot. This will give you a hint about averaging.
Or you can try to figure Ki matching individual RGB channels on 1nm sample Rref=K1*R etc. Then plot R+G+B vs K1*Rmunki+K2*Gmunki… etc.
Or even do the same with 10nm and 3nm on your munki to see averaging on spectral window.Then add individual sensor error at nm position, etc. On LEDs easy to measure, like a WLED, QLED, GB-LED 3nm is very likely to hit on spot, but with PFS this kind of averaging may happen.
i1p2 is less precise tool than JETI, of course, but main red peak and its right foot look too different to interpret this as instrument specifics. i1p2 is mainly targeted for print profiling, so it measures red area good enough, I’ve built dozens profiles with it and inspected many paper and paint graphs. I haven’t checked difference in CCSS, but here you may be right, it may only appear if colorimeter cuts of red peak foot (that sounds strange). I will write some words on i1d3 cord repairing and its filters later in separate topic.
Regarding to SPD curves: do you mean they’re written using XYZ weights correction? If so, different figures and graph shifts are still actual, while height and slant are quite wrong. If not, perceptual model is away of spectral investigation.
UPD: Oh, of course, I saw “waved” spectral corrections for i1d3 many times in DisplayCAL, so these spectra are modified. But these HP and Eizo white graph examples are almost clear of this effect.
User made CCSS are taken at whatever WP chooses user whi made them. It does not care for CCSS & i1d3, little to no effect AFAIK (<=1dE)
What I said is that your 2 samples may have slighty different WP. If you cannot calculate it commandline specplot will plot primaries & WP.
But… 1 can be modified to match CIE XYZ of the other, then plot it together. Just apply a gain K to the whole primary serie. Ther is a K1, K2 & K3 that will make them match in measured WP. Just to compare.Unfortunately this comparison is not equal to “2 devices measuring the same display” because reference an an Xrite spectro readings will have sligthly different WP depending on how easy is to measure them and Xrite 3/10nm resolution.
But it is a way to see how the same theoretical WP has slightly different SPD because of device.
