- This topic has 38 replies, 2 voices, and was last updated 2 years, 8 months ago by
.
-
Posts
-
Since all is working now as expected, try one of the provived EDRs by Stuart, redo CN7 cal with i1d3 no compensation, then validate WP with your i1pro2 3nm and i1d3 with their CCSS-EDR equivalents.
Looking at the readings, which of the two EDRs do you recommend I use? The CG319 or the CS2731? Or is it much of a muchness?
None of them thad the hump we see in your custom CCSS, but it does not seem to cause huge error in your i1d3, so choose whetever you want. CS2731 EDR has a “full forged structure”, it is identical to original in size and headers, only replacing spectral data so we can consider it “safer” (safer from app rejection) but Stuart tested both in Lightspace and seems to work fine with Xrite SDK.
PFS_Phosphor_Family_31Jan17 has one red channel sample with P3 red closer to what you shown in your CCSS (shorter red wavelength hump, plot them and you’ll see). It may be possible to copy spectral data from that EDR (CCSS) to Stuart’s EDR (CCSS). Then repack that modified CCSS into an EDR with ccss2edr and place it in CN7.
But it may not be worthy of the effort.Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.Since all is working now as expected, try one of the provived EDRs by Stuart, redo CN7 cal with i1d3 no compensation, then validate WP with your i1pro2 3nm and i1d3 with their CCSS-EDR equivalents.
Recalibration using the i1d3 and the CS2731 EDR.
checking with the i1d3 and the CS2731 ccss:
23:51:21,379 Setting up the instrument
23:51:21,379 Product Name: i1Display3
23:51:21,379 Serial Number: I1-18.B-02.314226.09
23:51:21,379 Firmware Version: v2.28
23:51:21,379 Firmware Date: 29Jan14
23:51:21,379 Measured display update delay of 44 msec, using delay of 158 msec & 0 msec ↲
↳ inst reaction
23:51:21,379 Uncalibrated response:
23:51:21,379 Black level = 0.1536 cd/m^2
23:51:21,379 50% level = 21.97 cd/m^2
23:51:21,379 White level = 99.55 cd/m^2
23:51:21,379 Aprox. gamma = 2.18
23:51:21,379 Contrast ratio = 648:1
23:51:21,379 White chromaticity coordinates 0.3126, 0.3289
23:51:21,379 White Correlated Color Temperature = 6510K, DE 2K to locus = 4.6
23:51:21,379 White Correlated Daylight Temperature = 6512K, DE 2K to locus = 0.1
23:51:21,379 White Visual Color Temperature = 6345K, DE 2K to locus = 4.4
23:51:21,379 White Visual Daylight Temperature = 6516K, DE 2K to locus = 0.1
23:51:21,379 Effective Video LUT entry depth seems to be 10 bitsChecking with the i1p2:
23:55:18,393 Setting up the instrument
23:55:18,393 Instrument Type: X-Rite i1 Pro 2
23:55:18,393 Serial Number: 1059871
23:55:18,393 Firmware version: 634
23:55:18,393 CPLD version: 999
23:55:18,393 Chip ID: 01-7e6613180000e4
23:55:18,393 Date manufactured: 20-15-1210
23:55:18,393 U.V. filter ?: No
23:55:18,393 Measure Ambient ?: Yes
23:55:18,393 Tot. Measurement Count: 56341
23:55:18,393 Remission Spot Count: 267
23:55:18,393 Remission Scan Count: 0
23:55:18,393 Date of last Remission spot cal: Thu Jan 01 00:00:00 1970
23:55:18,393 Remission Spot Count at last cal: 0
23:55:18,393 Total lamp usage: 67.499405
23:55:18,393 Display type ignored – instrument doesn’t support display type selection
23:55:18,393 Measured display update delay of 33 msec, using delay of 144 msec & 0 msec ↲
↳ inst reaction
23:55:18,393 Uncalibrated response:
23:55:18,393 Black level = 0.1579 cd/m^2
23:55:18,393 50% level = 23.21 cd/m^2
23:55:18,393 White level = 105.30 cd/m^2
23:55:18,393 Aprox. gamma = 2.18
23:55:18,393 Contrast ratio = 667:1
23:55:18,393 White chromaticity coordinates 0.3115, 0.3271
23:55:18,393 White Correlated Color Temperature = 6585K, DE 2K to locus = 4.1
23:55:18,393 White Correlated Daylight Temperature = 6588K, DE 2K to locus = 0.7
23:55:18,393 White Visual Color Temperature = 6434K, DE 2K to locus = 3.9
23:55:18,393 White Visual Daylight Temperature = 6612K, DE 2K to locus = 0.7
23:55:18,393 Effective Video LUT entry depth seems to be 10 bitsAnd Displaycal verification report done with the i1p2 attached
Seems OK.
I’d trust contrast measurement of i1d3. That CS2740 contrast is lower than expected or seen iin other units: 700-800:1 no UC, -100-200 UC active.
Can you try to ask store for a replacement unit?Anyway, if you were ultra demanding for softproof tasks and loosing more contrast was not an issue for you, then you can run “grayscale priority” (to correct that small black tint ~1.5 b*… I’d say not necessary) and checking “reflect black level in TRC” in ICC profile options in CN7 (= to disable BPC on profile options in DisplayCAL)
Or just “reflect black level in TRC” if you want to enable UC.Actual L* value for black in display ICC profile may be neccesary for very low contrast display while softproofing high dmax printer profiles, to let PS know actual black so it does not think you have infinite contast.
On software whose color mamagement engine does not support BPC choosing to store actual black may result in black crush since that engine will belive that it is Out Of Gamut.So do not store actual black in display profile unless for these specific tasks (or LUT3D creation).
I’d trust contrast measurement of i1d3. That CS2740 contrast is lower than expected or seen iin other units: 700-800:1 no UC, -100-200 UC active.
Can you try to ask store for a replacement unit?I have DUE Priority set to uniformity compensation and that validation showed 735.2:1, so I imagine with it off I’d get higher contrast, although I value good uniformity so don’t really want to turn it off.
So given that you know that UC is on, that contrast reading looks ok, right? I have two units and they both produce comparable contrast ratios with UC on and the same calibration settings, so not sure that asking for a replacement unit would change much, given that they both behave the same.
Anyway, if you were ultra demanding for softproof tasks and loosing more contrast was not an issue for you, then you can run “grayscale priority”
I’ve calibrated a specific profile to do exactly that, with grey balance option on for soft proofing and I’ve even set a minimum black level on that profile, further reducing the contrast.
I’d trust contrast measurement of i1d3. That CS2740 contrast is lower than expected or seen iin other units: 700-800:1 no UC, -100-200 UC active.
Can you try to ask store for a replacement unit?I have DUE Priority set to uniformity compensation and that validation showed 735.2:1, so I imagine with it off I’d get higher contrast, although I value good uniformity so don’t really want to turn it off.
i1d3 says ~650:1
checking with the i1d3 and the CS2731 ccss: 23:51:21,379 Setting up the instrument 23:51:21,379 Product Name: i1Display3 23:51:21,379 Serial Number: I1-18.B-02.314226.09 23:51:21,379 Firmware Version: v2.28 23:51:21,379 Firmware Date: 29Jan14 23:51:21,379 Measured display update delay of 44 msec, using delay of 158 msec & 0 msec ↲ ↳ inst reaction 23:51:21,379 Uncalibrated response: 23:51:21,379 Black level = 0.1536 cd/m^2 23:51:21,379 50% level = 21.97 cd/m^2 23:51:21,379 White level = 99.55 cd/m^2 23:51:21,379 Aprox. gamma = 2.18 23:51:21,379 Contrast ratio = 648:1
but given that CS2740 is an overall low contrast display (vs others in CS line) and if you say that UC is ON, not so unexpected.
Anyway, as explained before and in manual, remember that changing UC setting invalidates all other previpus calibrations.
It does not mean all WP & calibration is off for other CALx, it may be exactly the same (just reduced contrast) if no independent RGB gain was applied to central region.
It just mean that CN7 is unlikely to recognize associated ICC profiles for old CALx when switchn CALx in tray app (before changing UC status)… and this leads to your original issue: apps seeing wrong ICC profile and such.
It is explained in manual but may go unnoticed.
It would be nice of future releases of CN had a checkbox in advenced preferences to say “I know what I’m doing, use older CALx ICC profiles even if I change UC setting” but right now EIzo customers do not have it.but given that CS2740 is an overall low contrast display (vs others in CS line) and if you say that UC is ON, not so unexpected.
Ah, right. I read that 735.2:1 off the attached measurement report, so that was the i1p2 reading.
It just mean that CN7 is unlikely to recognize associated ICC profiles for old CALx when switchn CALx in tray app (before changing UC status)… and this leads to your original issue: apps seeing wrong ICC profile and such.
Gotcha. I’ve always had UC on, so I don’t think that was the cause. The UC was one of the major selling points of the Eizo for me, since I’ve been frustrated by the terrible uniformity on previous monitors I’ve owned. After all, what’s the point of having a perfectly calibrated monitor if it’s only the patch in the middle that’s perfectly calibrated and half the rest of the screen is at dE 5 or even greater away?
That said, after changing to the latest Nvidia studio drivers, updating my OS and making sure I have the latest version of all colour managed apps installed, the ICC profiles seems to be behaving for the moment. I haven’t managed to break it yet – it’s doing as expected, but I’ll wait for a while longer before pronouncing it as “fixed”.
It would be nice of future releases of CN had a checkbox in advenced preferences to say “I know what I’m doing, use older CALx ICC profiles even if I change UC setting” but right now EIzo customers do not have it.
Would be nice if there were a whole lot more advanced options to be honest. It’s a very dumbed down piece of software. I guess it’s probably appropriate to most of the target market, but you’re right that nothing prevents them from adding a few advanced configuration options for users who are comfortable using them. Those matrix corrections would be another obvious benefit, especially considering the limitations of the spectral profiles for the i1d3, probably the most commonly used of all colorimeters.
It just mean that CN7 is unlikely to recognize associated ICC profiles for old CALx when switchn CALx in tray app (before changing UC status)… and this leads to your original issue: apps seeing wrong ICC profile and such.
Gotcha. I’ve always had UC on, so I don’t think that was the cause. The UC was one of the major selling points of the Eizo for me, since I’ve been frustrated by the terrible uniformity on previous monitors I’ve owned. After all, what’s the point of having a perfectly calibrated monitor if it’s only the patch in the middle that’s perfectly calibrated and half the rest of the screen is at dE 5 or even greater away?
I won’t care 4dE as long as same patch is <2dC. Color tint across screen is more disgusting than ~10% drop on corners.
dE as an scalar pseudodistance is like 3D distance, on a room you have 2 points, total distance is floor distance (“color”)+ height distance (broghtnes) , of couse squared & square rooted… but you get the idea.Usually reporting uniformity only in dE is a hint of “i do not know what i am doing” review, plenty of those wanabe review webs on the internet
Buying an eizo grants you that, no color tint, small dC even UC off. Then you aim UC ON/ OFF depending of your task
I’ve arranged for someone to come to do some spectral readings on my CS2740s with a JETI 1511 sometime in September, after they get their device back from the manufacturer post its recalibration, so I’ll post those once I have them. Gonna cost me a few hundred for the service, but probably worth it over the long run. Of course, I’ll have to forge an EDR too…
What do you suggest in terms of the readings? Take a number of readings of each monitor and add all the readings to a ccss? I imagine readings from two monitors would be better than one and more readings would be preferable to less readings?
ArgyllCMS doc says to calculate root mean squared error of several “WRGB” blocks in an CCSS, Xrite SDK is likely to behave the same. RGB 255 and RGB 128 for each WRGB channel seems reasonable to check non ideal behavior but a 255 WRGB reading repeated 4 times in RG_phosphor CCSS, then packed into an EDR will do the job as Stuart did.
Anyway, knowing were the hump is located, practice to build EDR using R channel the samples with near P3 red and the “hump” in PFS_family CCSS. Maybe you do not need to rent that spectro.
Anyway, knowing were the hump is located, practice to build EDR using R channel the samples with near P3 red and the “hump” in PFS_family CCSS. Maybe you do not need to rent that spectro.
So, not sure I’m understanding you correctly, but a picture is worth a thousand words (see attached).
It’s a graph of the CS2731 ccss done with the CS1000 (it looks very similar to the CG319 one) on top of a graph of my CS2740 taken with the i1Pro2. You can clearly see how the poorer resolution of the i1Pro2 misses the dip around 630nm and also the smaller one around 610nm.
So if I understand you correctly, you’re suggesting I deliberately fake the ccss by manually adjusting the readings in the ~590nm to 730nm range in the CS2740 ccss to similar levels as the CS2731 in the sub-10nm intervals where the i1Pro2 would not have been able to get an accurate reading?
No, Im talking about the small hump in red from 570-600nm. That is the difference between yours and typical WLED PFS AdobeRGB flavor. It could bee seen by y and x-bar functions from std. observer.
I remember seeing something like that in PFS_family or in macbooks, but check that sample xy coords on red because it may be less saturated than yours.The “bluriness” of using 3nm in a CCSS vs 1nm on the same SPD (you are not using the same display SPD in 3nm vs 1nm comparisons) is small on these WLED PFS. At least in the samples of WLED PFS and i1d3 units I’ve seen.
Anyway, as said before your i1d3 readings using one of those CCSS fro CS2731 and CG319X maybe good enough to avoid the cost of making a custom one at 1nm or the works of patching an hybrid CCSS with than small hump on red.
Or as you said on the other thread, since newer ccss2edr version can interpolate, generating an EDR from your 3nm CCSS would be good enough for most people on a well behaved i1d3 (one i1d3 were frimwate data and filter data match.BTW, for plot comparisons if green channel has no narrow spikes is easier to scale plots to get same high on green. These way you’ll see peak difference in red because of 3nm averaging.
Just had someone come with a freshly factory calibrated JETI Spectraval 1511 and take a whole bunch of readings of my two monitors.
I’ve attached a manually created CCSS with a total of 80 readings in it (a single ccss usually has 4, so this is a set of 10 individual CCSSs per monitor that I’ve merged into a single CCSS file).
Graphing the readings, they’re similar to the CG319X, but lack the dip in the reds around 611nm and 633nm visible in the 319X and CS2731
Perhaps the most interesting outcome for me of the whole process of verifying my monitors with the JETI was the realization of just how terrible an instrument the i1d3 actually is. It’s hopelessly inaccurate, frankly not fit for purpose, or at least the ones I have aren’t.
The Eizo factory calibrated native gamut setting is pretty accurately calibrated according to the Spectraval and reads a 6512K measured whitepoint on the one monitor and 6504K on the second monitor. Yet when using a CCSS created with the JETI, my i1d3 reads the whitepoint as 6700K. Using no correction reads a whitepoint around 7000K. The i1d3 is not even that old – 3 years. I tried with a second i1d3, slightly older – about 6 years old – and got an even worse result than the first instrument.
Looking at a verification report, the i1d3 reads an identical red primary to the JETI when corrected with the CCSS, but there is a > 0.35 deltaE 2000 difference on the blue and green primaries. The only conclusion possible is that the filters in the i1d3 are out of spec.
Any recommendations on a better colorimeter that might be a little more accurate / reliable than an i1d3 or is this just “state of the art” unless I’m willing to spend a few thousand on a Klein or Colorimetry Research device?
The Eizo factory calibrated native gamut setting is pretty accurately calibrated according to the Spectraval and reads a 6512K measured whitepoint on the one monitor and 6504K on the second monitor. Yet when using a CCSS created with the JETI, my i1d3 reads the whitepoint as 6700K. Using no correction reads a whitepoint around 7000K. The i1d3 is not even that old – 3 years. I tried with a second i1d3, slightly older – about 6 years old – and got an even worse result than the first instrument.
CCT / CDT is meaningless, that test shows nothing.
Looking at a verification report, the i1d3 reads an identical red primary to the JETI when corrected with the CCSS, but there is a > 0.35 deltaE 2000 difference on the blue and green primaries. The only conclusion possible is that the filters in the i1d3 are out of spec.
I’ll say that given that tolerance value they are OK.
You have provided no data indicating an out of spec or innacurate i1d3. You measured in a not useful way.
Measure properly, then evaluate:
-Calibrate white point to some target with JETI Spectraval 1511, the reference.
-Measure CCT / CDT + distances to daylight curve + CIE XYZ with CCSS corrected i1d3. Then dE00 distance to measured coordinates by Jeti. Also take as separate measurement brightness error in whietpoint.
This will you a hint of the error in firmware filter data vs actual filter behavior, which is the colorimeter capabilities to use CCSS/EDR… and only means that, nothing else
-For a (better) numerical match between i1d3 and jeti use CCMX (valid only for that display and that i1d3), then with CCMX corrected i1d3 and teh Jeti take a few grey measurements and saturation sweeps, 50% and 100% or 25-50-75-100, CIE XYZ for both. You do nt need too many. CS2740 “should be” very well behaved, hence a fairly good additivity of primaries. Compute dE00 errors between jeti and CCMX corrected i1d3 on thos patches. This will give you a hint about colorimeter capabilities to measure an additive RGB display.Then you can say my i1d3 is or is not accurate. Comparisons with CCT/CDT as you did are pointless and give you no clue about device accuracy. Same for the ChormaPure test on colorimeter accuracy, useless and meaningless since they were not done in the proper way.
Any recommendations on a better colorimeter that might be a little more accurate / reliable than an i1d3 or is this just “state of the art” unless I’m willing to spend a few thousand on a Klein or Colorimetry Research device?
You’ll get more speed K10A and given the low light issues on i1d3 rev B and HL it’s expected better behavior measuring OLEDs or future miniLED or dual panel solutions like the Eizo Prominence and such. IDNK if you have such needs. A K10A will save you time if you have to make a 17^3 LUT3D from actual measurements (17^3) very often of for a company that has several rooms from grading, so saved enough time in several displays … it may be worth the money and get a ROI quickly.
***************
AFAIK ColorNavigator does not allow for custom CCMX / FCCM for i1d3. Only their cooked & hidden “CCMX” for each model and a generic i1d3 or EDR based corrections (witch will be limited by your results in step 2, be then good or not so good once you measured them properly)… so having a Jeti like that at your disposal and since you are an Eizo customer I’ll contact their support team and request CN7 to have an advanced option where user can provide a custom 3×3 CIE XYZ to XYZ correction matrix, like Calman or ArgyllCMS or Lightspace.
IDNK where they store the default correction, if it is stored in a text /binary data file, if it is hardcoded in a DLL… “we know” how to hack those EDRs but little to nothing about custom matrices built in software for i1d3s (which is the default option in CN7 by the way).So, since you are a customer, request that feature. It should be not very costly for them. It should be your priority if step 2 showed a mismatch between firmware filter data and filter behavior.
***********
Also since it a “CS” model, lut-matrix-lut calibration, I’ll say it has no support from Lightspace, where you could skip CN if step2 showed that your i1d3 is not very accurate with EDRs (so you must use “CCMX”, 3×3 CIE XYZ to CIE XYZ, corrections).
Portrait Displays’ CALMAN support CG-X models but IDNK if it supports HW calibration on CS. Calman supports custom user made matrix corrections so if your i1d3 was not accurate to use with EDR and CS2740 HW cal is supported… maybe Calman is an option.K10-A on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.
