- This topic has 38 replies, 2 voices, and was last updated 2 years, 8 months ago by
.
-
Posts
-
I took delivery a few days ago of a pair of EIZO CS2740s. Wonderful monitors and hugely capable. But I’m terribly disappointed in the Color Navigator software.
I’m more looking for validation here and some sense of whether there’s a better way to get a decent calibration and colour managed workflow than the (somewhat clumsy) way I’ve been forced into by software and probe limitations.
My two probes are, unsurprisingly, an i1d3 and an i1p2. In the 10 years or more that I’ve been using Displaycal, my use case has been the typical “create a matrix correction for the particular display with the i1p2 and then use the i1d3 for the calibration and profiling”.
I understand the limitations of the i1p2. Its white measurement is not the most accurate. Empirically, the Argyll driver seems to do a lot better job than the Xrite driver. The i1p2’s 10nm wavelength means it doesn’t have the necessary resolution to be able to create a set of spectral readings that can be used with confidence as a colorimeter ccss correction (I’ve tried numerous times and the results are way off), but it does a more than acceptable job when creating a matrix ccmx correction.
Now my gripes. Color Navigator rather shockingly does not have any decent spectral calibrations for the i1d3 and this panel type. I’m gobsmacked that Eizo could not ship a halfway decent spectral correction EDR with the software. Even the faked EDR produced by Stuart Pointon from Eizo APAC results in a visually poor calibration. There’s a fair bit of inter-batch variation in these i1d3s it seems. And sadly, Colour Navigator will not allow the user to create a correction matrix, so you’re stuck with using the very dated EDR shipped by Xrite or Stuart Pointon’s one.
As far as I can tell, the ICC profiles produced by Color Navigator are pointless and not needed. They do not characterize/profile the display and have linear calibration curves, as would be expected from a hardware calibration. An sRGB colourspace image on a native gamut calibrated monitor profile shows cartoonishly saturated colours unless I profile the calibrated display with Displaycal and use the Displaycal ICC profile instead. But on to the actual calibration observations and questions instead.
Having established that I cannot use the i1d3 with Colour Navigator and get an acceptable result, I resorted to using the i1p2 to calibrate with Colour Navigator – not really happy about being forced to do this, as my i1p2 will likely die a lot sooner as a result of being forced to use it in this way.
This produces a visually much better result, but still with a white point that’s off. This appears to be the difference between the Argyll driver and the native Xrite driver for the i1p2.
I have a matrix correction in Displaycal that I’ve made some effort to validate: it reads the same values on the i1d3 as shown by the i1p2. So I can use the i1d3 with Displaycal and measure patches to compare against Colornavigator readings with the i1p2. Colornavigator thinks it’s got the right whitepoint, but according to the reading I’m taking with Displaycal and the matrix corrected i1d3, the Color Navigator reading is off by about dE 1.5. The cause of this I can only theorise to be the difference between the Argyll and the Xrite i1p2 drivers.
So I’ve adopted the following workflow. Curious to have comments on this and ideas if there is anything better I can do beyond going to buy a very expensive Klein, JETI or CR, which is a non-option.
– Use Colornavigator to calibrate with the i1p2
– When done, load up Displaycal, set the white point target to D65 and everything else to “As measured”. Click on the interactive adjustment checkbox and start taking readings. It shows around a dE 1.5 difference on the whitepoint to what Colour Navigator’s i1p2 readings claim.
– Use the manual correction option in Colornavigator to adjust the whitepoint so it matches the i1d3 readings, effectively meaning that the whitepoint would have been set as if using the Argyll i1p2 driver and not the Xrite driver. This gives a visually better result, but Colour Navigator thinks it’s got a custom whitepoint target with about a dE 1.5 difference to D65 and the generated ICC profile reflects this.
– Now apply the manual correction to the Colour Navigator calibration and save the calibration to the hardware
– Now verify the calibration with Displaycal. It’s going to report the correct measured whitepoint (ie, the one I manually set), but the verification shows some some dE in the results because the Colour Navigator generated ICC profile contains the modified target white point. But, I just ignore that: the measured whitepoint is D65 with 0.1 or 0 dE, the gray balance is perfect and so is the gamma. Exit Colour Navigator and stop the Colour Navigator agent from running.
– Now profile the calibrated display using Displaycal (that is to say, uncheck interactive calibration, use all values “as measured”) and profile with a few hundred patches. The end result produces a profile where the calibration and profiling is revealed to be extremely accurate and visual result looks very good.So, is this method a sensible one, or am I fooling myself and just solving mathematically to make the readings match my matrix corrected i1d3 without really affecting the inherent accuracy of the calibration and profiling?
The key assumptions behind this methodology are
1. The i1p2 is more accurate than the i1d3 when using Colour Navigator due to the lack of an acceptable spectral correction for this panel available to Colour Navigator
2. The Argyll i1p2 driver is more accurate than the Xrite driver, particularly on the white measurements
3. Using the i1p2 is preferable to using the faked EDR created by Stuart Pointon from Eizo APAC with the i1d3If these assumptions hold true, then I think that this methodology results in a better overall calibration and profiling, but curious to have any comments or observations. Perhaps there’s a better way outside of spending a few thousand on a reference spectroradiometer?
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.I took delivery a few days ago of a pair of EIZO CS2740s. Wonderful monitors and hugely capable. But I’m terribly disappointed in the Color Navigator software.
I’m more looking for validation here and some sense of whether there’s a better way to get a decent calibration and colour managed workflow than the (somewhat clumsy) way I’ve been forced into by software and probe limitations.
My two probes are, unsurprisingly, an i1d3 and an i1p2. In the 10 years or more that I’ve been using Displaycal, my use case has been the typical “create a matrix correction for the particular display with the i1p2 and then use the i1d3 for the calibration and profiling”.
I understand the limitations of the i1p2. Its white measurement is not the most accurate. Empirically, the Argyll driver seems to do a lot better job than the Xrite driver. The i1p2’s 10nm wavelength means it doesn’t have the necessary resolution to be able to create a set of spectral readings that can be used with confidence as a colorimeter ccss correction (I’ve tried numerous times and the results are way off), but it does a more than acceptable job when creating a matrix ccmx correction.
Now my gripes. Color Navigator rather shockingly does not have any decent spectral calibrations for the i1d3 and this panel type. I’m gobsmacked that Eizo could not ship a halfway decent spectral correction EDR with the software. Even the faked EDR produced by Stuart Pointon from Eizo APAC results in a visually poor calibration. There’s a fair bit of inter-batch variation in these i1d3s it seems. And sadly, Colour Navigator will not allow the user to create a correction matrix, so you’re stuck with using the very dated EDR shipped by Xrite or Stuart Pointon’s one.
Does Stuart EDRs/CCSS differ from your own i1p2 SPD readings at 3nm? Mine are spot on for these Eizos. Attach measurements.
Does your i1d3 difts severely using your own 3nm CCSS vs CCMX at 3nm? Mine are spot on for these Eizos. Attach measurements.
I mean my >10yo i1d3 internal sensivity curves match the actual curves at the accuracy provided by my i1p2: CCMX vs CCSS give <1dE to dayloght curve on almost same CDT (2 last digits)
Also CN must be configured to use EDRs, by default it is using a generic offset for i1d3 (hence not portable).As far as I can tell, the ICC profiles produced by Color Navigator are pointless and not needed. They do not characterize/profile the display and have linear calibration curves, as would be expected from a hardware calibration.
Your statement is false and points to a poor understanding of CN and the whole process.
CN creates matrix 1TRC profile types. This is the proper choice for extremely well behaved displays and these fall into this category.
But you can customize the matrix profile type it creates:
-choose primaries & TRC from target or from measurement
-choose actual black vs ideal black (like in DisplayCAL)1st one usually does not matter, just run a verification.
2nd one may matter if you aim to warm whitepoint + grayscale priority + uniformity correction, try to softproof a very high Dmax combination of ink and paper and have low percentile performer unit by chance… since if you choose “fake infinite contrast black” on ICC creation and for example in PS you chose such glossy paper softproof PS will belive infinite contrast (and not actual one) and lift more that it shoudl be on simulation. But actual display contrast muys be very very very poor to matter (like a combination of user misconfiguration and low percentile unit in QC)Aim for standard priority on grayscale. Validate profile on DisplayCAL.. the we may consider your claims and figure out what you did wrong.
An sRGB colourspace image on a native gamut calibrated monitor profile shows cartoonishly saturated colours unless I profile the calibrated display with Displaycal and use the Displaycal ICC profile instead. But on to the actual calibration observations and questions instead.
Looks like you are running not color managed software, or color managed software not compatible with ICCv4.
Again an user misconfiguration. Choose ICCv2 on CN7, there is no need at all of v4… Mr. Graeme has explained it many times. Even more pointless for create a matrix display profile.Having established that I cannot use the i1d3 with Colour Navigator and get an acceptable result, I resorted to using the i1p2 to calibrate with Colour Navigator – not really happy about being forced to do this, as my i1p2 will likely die a lot sooner as a result of being forced to use it in this way.
As explained before, very high chances of user misconfiguraion of these applications. Also missing data.
From my own measurements with GB-LED and WLED PFS backlights (AdobeRGB green flavor) i1p2 at 10nm, like measurements from Xrite software, basiccolor or CN7 measure same whiteness (dayloght curve) but my i1p2 @10nm sees white “yellower” by 100-200K vs 3nm and proper CCSS on my i1d3.
I mean, you should get a “white” whitepoint with an i1p2 but a bit cooler. Aiming at -100K should do the job. PS/LR & cia won’t care at all, rendering is always relative whitepoint.
When making LUT3D these alt white maust be taking inti account when making abs colorimetric LUT3D but for such lut3d you usually use a custom 3dmash profile…so it does not apply here.This produces a visually much better result, but still with a white point that’s off. This appears to be the difference between the Argyll driver and the native Xrite driver for the i1p2.
It does not. Seems your i1p2 is malfunctioning in some way. Attach SPD readings + measurement data in fast console “report on uncalibrated display”
Also share CCSS @3nm with comminity. There is no one and ypu should give as much you take form commuity if giving is in your hands : you have an i1p2, a CS2740 and yiu can use DisplayCAL… so, share those CCSS first to see what is going on.
I have a matrix correction in Displaycal that I’ve made some effort to validate: it reads the same values on the i1d3 as shown by the i1p2. So I can use the i1d3 with Displaycal and measure patches to compare against Colornavigator readings with the i1p2. Colornavigator thinks it’s got the right whitepoint, but according to the reading I’m taking with Displaycal and the matrix corrected i1d3, the Color Navigator reading is off by about dE 1.5. The cause of this I can only theorise to be the difference between the Argyll and the Xrite i1p2 drivers.
It is a pointless test unless you verify what I wrote above:
i1d3 CCSS 3nm (YOURS) vs stuarts 1nm
i1d3 CCSS 3nm vs CCSS 10nm
i1d3 CCSS 3nm vs i1p2 3nm
i1d3 CCSS 3nm vs i1p2 10nmThat will give you a hint about how off is your i1d3 (or your i1p2)
So I’ve adopted the following workflow. Curious to have comments on this and ideas if there is anything better I can do beyond going to buy a very expensive Klein, JETI or CR, which is a non-option.
– Use Colornavigator to calibrate with the i1p2
As said before may bet a little b* off , but white-
– When done, load up Displaycal, set the white point target to D65 and everything else to “As measured”. Click on the interactive adjustment checkbox and start taking readings. It shows around a dE 1.5 difference on the whitepoint to what Colour Navigator’s i1p2 readings claim.
Not needed. Your configuration of CN or color managed apps seems to be wrong. Read what I wrote.
– Use the manual correction option in Colornavigator to adjust the whitepoint so it matches the i1d3 readings, effectively meaning that the whitepoint would have been set as if using the Argyll i1p2 driver and not the Xrite driver. This gives a visually better result, but Colour Navigator thinks it’s got a custom whitepoint target with about a dE 1.5 difference to D65 and the generated ICC profile reflects this.
Which readings? I mean your tests are pointless unless you see what is going on.
– Now apply the manual correction to the Colour Navigator calibration and save the calibration to the hardware
– Now verify the calibration with Displaycal. It’s going to report the correct measured whitepoint (ie, the one I manually set), but the verification shows some some dE in the results because the Colour Navigator generated ICC profile contains the modified target white point. But, I just ignore that: the measured whitepoint is D65 with 0.1 or 0 dE, the gray balance is perfect and so is the gamma. Exit Colour Navigator and stop the Colour Navigator agent from running.
– Now profile the calibrated display using Displaycal (that is to say, uncheck interactive calibration, use all values “as measured”) and profile with a few hundred patches. The end result produces a profile where the calibration and profiling is revealed to be extremely accurate and visual result looks very good.Using post calibration whitepoint adjustment seems a good choice if your i1d3 is actually wrong, if firmware data and actual sensivity curves do not match against a “reference” device. Let’s consider i1p2 3nm a reference. Do the test I showed you above.
.. but runing again DIsplayCAL to profile display is not needed. As saif before you have wrong configuration on CN7 or your color managed app. You can use the ICC profile generated by CN7 (unless you plan to use it as LUT3D source with alt whites)
So, is this method a sensible one, or am I fooling myself and just solving mathematically to make the readings match my matrix corrected i1d3 without really affecting the inherent accuracy of the calibration and profiling?
The key assumptions behind this methodology are
1. The i1p2 is more accurate than the i1d3 when using Colour Navigator due to the lack of an acceptable spectral correction for this panel available to Colour Navigator
2. The Argyll i1p2 driver is more accurate than the Xrite driver, particularly on the white measurements
3. Using the i1p2 is preferable to using the faked EDR created by Stuart Pointon from Eizo APAC with the i1d3If these assumptions hold true, then I think that this methodology results in a better overall calibration and profiling, but curious to have any comments or observations. Perhaps there’s a better way outside of spending a few thousand on a reference spectroradiometer?
As explained above, your CN7 or your color managed apps have wrong configuration.
At best you may beed only CN7 + EDR +i1d3. Then validate with DisplayCAL and a suitable CCSS
At worst scenario, a brfoken i1d3 or an i1d3 unit with spectral sensivity vs firmware data mismatch you’ll need only CN7 + post calibration WP adjustment . Then validate with DisplayCAL and a suitable CCMX.To figure what you did wrong and your potential misconfiguration you’ll have to provide data. CCSS @3nm for community will be a good starting point.
Does Stuart EDRs/CCSS differ from your own i1p2 SPD readings at 3nm? Mine are spot on for these Eizos. Attach measurements.
Does your i1d3 difts severely using your own 3nm CCSS vs CCMX at 3nm? Mine are spot on for these Eizos. Attach measurements.
I mean my >10yo i1d3 internal sensivity curves match the actual curves at the accuracy provided by my i1p2: CCMX vs CCSS give <1dE to dayloght curve on almost same CDT (2 last digits)Vincent, thanks for your reply and the suggestions. But your baseline and oft-repeated assumption that everything is me misconfiguring things or not understanding colour management is unnecessary and incorrect. I have more than a passing familiarity. Perhaps not your level of expertise, but hey, that’s why I’m asking questions here.
I only have an EDR Stuart created – I don’t have a ccss or a text report of the readings because I cannot register on Lift Gamma Gain to download attachments and the EDR is binary. I have a tool to convert ccss to edr, but not the other way around. Happy to compare if you happen to have text format readings of Stuart’s measurements. I cannot register on Lift Gamma Gain because the forum signup page is not showing the captcha on attempted signup and then giving an error. I’ve tried 3 different browsers and set privacy settings to the lowest so it doesn’t block the captcha, but still no luck…
That said, in Displaycal, a ccss produced with my i1p2 is terrible. See attached Excel file showing the raw data from using Displaycal to run a verification using the testchart for colorimeter correction. First the i1p2 and then the i1d3 using both the ccss and the ccmx, right after doing a fresh calibration run with CN7 using the i1p2.
The calibration settings and results, as well as the preferences for CN7 are also attached. It’s a fairly basic piece of software with not a lot of options.
As you can see, using the ccss gives a large dE from the i1p2 readings. The ccmx a lot less so. The instruments seem reasonably consistent to me in terms of readings, with each set of 5 readings for each instrument not differing wildly from each other, but then I’m not a colorimeter or a spectroradiometer expert.
Numerous comments on various forums, including the liftgammagain one, point to the i1p2 not having good enough resolution to create a reliable spectral correction for these panels.
Even your own post here suggests the same and that the Argyll driver takes readings without averaging, hence my original comment that speculates that the driver difference might be the reason for the differing whitepoint readings in CN7 vs Displaycal: https://hub.displaycal.net/forums/topic/displaycal-profil-loader-eizo-color-navigator/#post-30781
Whatever the underlying reason, the ccss consistently produces readings that are way off.
Also CN must be configured to use EDRs, by default it is using a generic offset for i1d3 (hence not portable).
The very first thing I did was to turn off the additional CS2000 correction in CN7 by setting “No compensation”. See the attached preferences screenshot. So yes, CN7 is configured to “use EDRs”. Well, more precisely, configured not to use the CS2000 correction Stuart referred to here: https://www.liftgammagain.com/forum/index.php?threads/eizo-cs2731-calibration-issues.16585/#post-161266
Your statement is false and points to a poor understanding of CN and the whole process. (hence not portable).
That was a question phrased as a “as far as I can tell” and was a deduction or guess that I made because they appeared, from the results I was getting, to not have profiled the display at all. That odd behaviour could just be a symptom of another problem, such as the profile not being loaded correctly or something interfering with it.
Sure, I started with a “poor understanding of CN”, since I’m new to CN7 and CN7 is not documented very well at all. Nowhere is there an explanation of the ICC profiles it generates. Everything in the documentation is dumbed down and brief to the point of absurdity.
Looks like you are running not color managed software, or color managed software not compatible with ICCv4.
Again an user misconfiguration. Choose ICCv2 on CN7, there is no need at all of v4… Mr. Graeme has explained it many times. Even more pointless for create a matrix display profile.Again, I’m categorically using colour managed software. And again, the software is configured correctly. I’m using ICC v2 profiles, not V4, precisely because some apps are not 100% compatible with ICC v4 profiles.
I created XYZ LUT + matrix profiles with Displaycal to replace the CN7 ones to see if it fixed the issue of the lack colour managed workflow I was having. Which it did. Why, I’m not sure. One of the reasons I made this post in fact…
Only when I re-profile using Displaycal and use the Displaycal generated profile instead of the CN7 ones does the colour management work correctly and as expected.
Literally the only difference is that I’m using the Displaycal profiles and Displaycal’s profile loader and not the CN7 generated ones and the CN7 agent. No changes to the apps settings, to Windows or to any other configuration. So ergo, the app configuration must be correct, otherwise the colour management wouldn’t work when I install the Displaycal profiles!
That leaves only two possibilities: either the CN7 agent is not loading the profiles correctly or the latest version of CN7 has bugs and it’s generating profiles that have something wrong with them.
It does not. Seems your i1p2 is malfunctioning in some way.
That may be the case. I’m not sure. It doesn’t look to me that this is necessarily the case judging by the readings in the attached Excel file. They’re fairly consistent by the looks of it.
There is no one and ypu should give as much you take form commuity if giving is in your hands : you have an i1p2, a CS2740 and yiu can use DisplayCAL… so, share those CCSS first to see what is going on.
Ask and you shall receive. This was my first forum post and I didn’t exactly refuse to post it. Most forum users wouldn’t know what to do with it, so I didn’t post it. No need to use an accusatory tone. i1p2 ccss done on the Eizo is attached.
Using post calibration whitepoint adjustment seems a good choice if your i1d3 is actually wrong, if firmware data and actual sensivity curves do not match against a “reference” device. Let’s consider i1p2 3nm a reference. Do the test I showed you above.
I guess I wasn’t clear enough. I’m not using the i1d3 to calibrate because of the aforementioned issues with corrections. I’m using the i1p2. The CN7 calibration using the i1p2 produces a result where it tells me it has exactly hit the desired D65 whitepoint. However when done and the calibration is saved to the monitor and CN7 is shut down, a verification with the same i1p2 in Displaycal consistently shows a whitepoint 100k cooler than what CN7 says it is.
See the results of the CN7 calibration and the Displaycal verification attached. The i1p2 seems to be producing different readings in CN7 vs Displaycal for the blue primary (the difference perhaps due to differences between the Xrite and Displaycal drivers. I don’t know. This is a guess). This is repeatable. It happens every time. The whitepoint CN7 reaches always reads as 100k cooler when doing a Displaycal verification.
Looking at the verification results (attached both for CN7 and for DCAL), you can see that there is de2000 difference of over 5 for the blue primary readings between CN7 and DCAL verification runs, which explains the cooler whitepoint reading in DCAL (perhaps the problem is DCAL and not CN7, hard to tell). I’ve keyed these verification run measurements into the Excel file in a separate tab called CN vs DCAL and calculated the delta E, so you can read it off there. Note that the Excel file has a macro in it for the deltaE2000 calculation, so check out the code before enabling macros to be sure you’re ok with it.
This is why I did a manual whitepoint adjustment, because that way I can get the whitepoint to exactly D65. The CN7 result isn’t terrible, but it can be improved with a manual adjustment, so why not?
As saif before you have wrong configuration on CN7 or your color managed app. You can use the ICC profile generated by CN7 (unless you plan to use it as LUT3D source with alt whites)
As I said before, I’m 100% certain my apps are not misconfigured and you’re making incorrect assumptions. They’ve been working fine for years in colour managed mode. And I don’t think that CN7 is misconfigured either. You have the screenshots to go by.
There are three distinct and quite probably unrelated issues at play here
1. The EDR bundled with CN7 is a bad match to the panel. We know this. So I get a better result with the i1p2 than with the i1d3. It would be nice if I could find a better correction so I don’t have to kill my i1p2 through constant use. When I replaced the EDR with Stuart’s one, the calibration was obviously off. I didn’t need a probe to tell me that.
2. The i1p2 seems to produce different readings for CN7 and for Displaycal on the blue primary, resulting in a cooler whitepoint than desired.
3. An ICC profile issue. I haven’t worked out what this is. I just know that it doesn’t happen if I reprofile with Displaycal. Then everything works correctly. The only thing that changed is the ICC profile. Ergo, it’s either the profile itself or the way it’s being loaded.The i1d3 is a retail device bought in January of 2019
23:54:42,704 Product Name: i1Display3
23:54:42,704 Serial Number: I1-18.B-02.314226.09
23:54:42,704 Firmware Version: v2.28
23:54:42,704 Firmware Date: 29Jan14
23:54:42,704 Default calibration:
23:54:42,704 Emissive matrix = 0.032586 -0.019982 0.014535
23:54:42,704 -0.000447 0.000955 0.069689
23:54:42,704 Ambient matrix = 0.179745 -0.109229 0.085718
23:54:42,704 -0.002006 0.004372 0.415365The i1p2 I can’t recall when I bought it, but here’s the data. Prior to CN7, it had seen very limited use – only to generate the occasional ccmmx for Dispcal and nothing else. It’s been getting a lot more work the last week.
00:05:49,145 Instrument Type: X-Rite i1 Pro 2
00:05:49,145 Serial Number: 1059871
00:05:49,145 Firmware version: 634
00:05:49,145 CPLD version: 999
00:05:49,145 Chip ID: 01-7e6613180000e4
00:05:49,145 Date manufactured: 20-15-1210
00:05:49,145 U.V. filter ?: No
00:05:49,145 Measure Ambient ?: Yes
00:05:49,145 Tot. Measurement Count: 55293
00:05:49,145 Remission Spot Count: 261
00:05:49,145 Remission Scan Count: 0
00:05:49,145 Date of last Remission spot cal: Thu Jan 01 00:00:00 1970
00:05:49,145 Remission Spot Count at last cal: 0
00:05:49,145 Total lamp usage: 66.203842EDIT: the forum software would not allow me to attach the Excel file. It can be downloaded here
For some reason, clicking on the link I supplied to the Excel file doesn’t launch when clicked on and now I can’t edit the post. Right click on the link, copy link address and paste it into the browser bar. The link is correct: http://www.kz3.uk/download/deltae.xlsm
Does Stuart EDRs/CCSS differ from your own i1p2 SPD readings at 3nm? Mine are spot on for these Eizos. Attach measurements.
Does your i1d3 difts severely using your own 3nm CCSS vs CCMX at 3nm? Mine are spot on for these Eizos. Attach measurements.
I mean my >10yo i1d3 internal sensivity curves match the actual curves at the accuracy provided by my i1p2: CCMX vs CCSS give <1dE to dayloght curve on almost same CDT (2 last digits)Vincent, thanks for your reply and the suggestions. But your baseline and oft-repeated assumption that everything is me misconfiguring things or not understanding colour management is unnecessary and incorrect. I have more than a passing familiarity. Perhaps not your level of expertise, but hey, that’s why I’m asking questions here.
I only have an EDR Stuart created – I don’t have a ccss or a text report of the readings because I cannot register on Lift Gamma Gain to download attachments and the EDR is binary. I have a tool to convert ccss to edr, but not the other way around. Happy to compare if you happen to have text format readings of Stuart’s measurements. I cannot register on Lift Gamma Gain because the forum signup page is not showing the captcha on attempted signup and then giving an error. I’ve tried 3 different browsers and set privacy settings to the lowest so it doesn’t block the captcha, but still no luck…
oeminst ArgyllCMS will create the CCSS from any EDR.
Also Stuart bundled EDR and CCSS in his attahment.. so you shoudl have the two files.That said, in Displaycal, a ccss produced with my i1p2 is terrible.
I’d say the CCSS is fine. CCSS is a file with SPD readings. It is good or not depending on the reference device used to create it.
If it is faulty, then you CN calibration with i1p2 is wrong too. So it seems tha some concepts are not 100% understood.Anyway, your CCSS shows a WLED PFS but with a hump in shorter red wavelegths, like the ones on PFS family EDR/CCSS. Hence theoretically an “accurate i1d3” (actual sensivities match frimware data) using Stuart’s CS2731 EDR/CCSS will result in slightly wrong XYZ.
Option A) i1d3 is accurate (i1d3 CCSS 3nm measure same or close “color” coordinates -exclude L*- as i1pro2 3nm)
Re create and EDR by:
-interpolating your CCSS to 1nm,
-then copy/duplicate GB-LED EDR bundled with DIsplayCAL (RG_Phosphor_Family_25Jul12.edr/.ccss)
-replace 4 times (there are 4 display samples, each one with WRGB data) your interpolated WRGB spectral distribution data in RG_Phosphor_Family_25Jul12
-save forged RG_Phosphor_Family_25Jul12 file.
-use CCSS2EDR to rebuild a forged RG_Phosphor_Family_25Jul12.edr
-the replace in CN7Option B)
If your i1d3 is innacurate, if i1d3 filter & firmware behavior do not match, then no EDR/CCSS will be able to correct properly your i1d3 => You’ll have to use CN post calibration WP fine tune… or even simpler: Calibrate once (full procedure), then measure the offset with i1d3 (using default or EDR correction) and calibrate to an alternative whitepoint target with that offset applied. As said before PS/LR/… wont care about WP. Just keep in mind that you are using alt whitepoints while creation abs colorimetric LUT3D because it will undo what you did.See attached Excel file showing the raw data from using Displaycal to run a verification using the testchart for colorimeter correction. First the i1p2 and then the i1d3 using both the ccss and the ccmx, right after doing a fresh calibration run with CN7 using the i1p2.
The calibration settings and results, as well as the preferences for CN7 are also attached. It’s a fairly basic piece of software with not a lot of options.
I do not see profile configuration. That is what you have missconfigured hence your color management issues like oversaturation come from that (and from other app misconfiguration , not enabling v4 profiles and such).
As you can see, using the ccss gives a large dE from the i1p2 readings. The ccmx a lot less so. The instruments seem reasonably consistent to me in terms of readings, with each set of 5 readings for each instrument not differing wildly from each other, but then I’m not a colorimeter or a spectroradiometer expert.
Numerous comments on various forums, including the liftgammagain one, point to the i1p2 not having good enough resolution to create a reliable spectral correction for these panels.
Even your own post here suggests the same and that the Argyll driver takes readings without averaging, hence my original comment that speculates that the driver difference might be the reason for the differing whitepoint readings in CN7 vs Displaycal: https://hub.displaycal.net/forums/topic/displaycal-profil-loader-eizo-color-navigator/#post-30781
Whatever the underlying reason, the ccss consistently produces readings that are way off.
I do not see the data I asked to rate your i1d3.
Just run Tools / Report / Report on uncalibrated display.
This must be done on some “good state” of display, like for example after CN7 HW calibration using i1pro2. Do not change anything on display. Just measure that report:
A-on i1pro2 10nm
B-on i1pro2 3nm
C-on i1d3 with stuart 1nm CCSS (it will have some error vs “actual coordinates” since CS2740 SPD has a hump in shorter wv length)
D-on i1d3 with your own CCSS 3nmAttach report, copy paste. No excels.
Usually A vs B should show only a slight b* error
B vs C error can be in “color” or in L*, that’s why I ask full report log.Assesing B vs C we can get a hint about how bad is your i1d3, if it can be EDR corrected or not.
Also CN must be configured to use EDRs, by default it is using a generic offset for i1d3 (hence not portable).
The very first thing I did was to turn off the additional CS2000 correction in CN7 by setting “No compensation”. See the attached preferences screenshot. So yes, CN7 is configured to “use EDRs”. Well, more precisely, configured not to use the CS2000 correction Stuart referred to here:https://www.liftgammagain.com/forum/index.php?threads/eizo-cs2731-calibration-issues.16585/#post-161266
Your statement is false and points to a poor understanding of CN and the whole process. (hence not portable).
That was a question phrased as a “as far as I can tell” and was a deduction or guess that I made because they appeared, from the results I was getting, to not have profiled the display at all. That odd behaviour could just be a symptom of another problem, such as the profile not being loaded correctly or something interfering with it.
Sure, I started with a “poor understanding of CN”, since I’m new to CN7 and CN7 is not documented very well at all. Nowhere is there an explanation of the ICC profiles it generates. Everything in the documentation is dumbed down and brief to the point of absurdity.
Looks like you are running not color managed software, or color managed software not compatible with ICCv4.
Again an user misconfiguration. Choose ICCv2 on CN7, there is no need at all of v4… Mr. Graeme has explained it many times. Even more pointless for create a matrix display profile.Again, I’m categorically using colour managed software. And again, the software is configured correctly. I’m using ICC v2 profiles, not V4, precisely because some apps are not 100% compatible with ICC v4 profiles.
I created XYZ LUT + matrix profiles with Displaycal to replace the CN7 ones to see if it fixed the issue of the lack colour managed workflow I was having. Which it did. Why, I’m not sure. One of the reasons I made this post in fact…
Only when I re-profile using Displaycal and use the Displaycal generated profile instead of the CN7 ones does the colour management work correctly and as expected.
Literally the only difference is that I’m using the Displaycal profiles and Displaycal’s profile loader and not the CN7 generated ones and the CN7 agent. No changes to the apps settings, to Windows or to any other configuration. So ergo, the app configuration must be correct, otherwise the colour management wouldn’t work when I install the Displaycal profiles!
Attach profiles. You are doing something wrong 100% sure. CN7 ICC v2 profiles are supported by all my windows apps.
Also it is not very clever to create an XYZLUT profile for a well behaved display. Roundig errors due to 3TRC will cause more harm than the slight 3D volume innacuracies.
If you insist in creating a no calibretion profile with DisplayCAL choose matrix + single curve. Then choose idealized black or actual black depeding on what you’re going to do and BPC support in that color managed app. > ~700:1 can have ideal black for most tasks.That leaves only two possibilities: either the CN7 agent is not loading the profiles correctly or the latest version of CN7 has bugs and it’s generating profiles that have something wrong with them.
Use displayCAL to read default display profile and see were are the primaries… but you must use default one in OS not whatever you missconfigured in DisplayCAL upper combobox. This will test if CN is publising ICC profiles to OS.
CN does nt support mixing calibrations with uniformity compensation ON and OFF, when you recall CALx setting on CN tray icon if CN data does not match UC status of display it won’t load it. It’s user missconfiguration and manual states it. UC setting is global for display, not for each preset. If you missconfigured it you’ll have to recalibrate all CALx presets whose UC setting do not match actual UC setting.You can test it even by checking your OS color management setting, withput DisplayCAL, just check which profile is published as default display profile. In fact… this should be your 1st test.
It does not. Seems your i1p2 is malfunctioning in some way.
That may be the case. I’m not sure. It doesn’t look to me that this is necessarily the case judging by the readings in the attached Excel file. They’re fairly consistent by the looks of it.
There is no one and ypu should give as much you take form commuity if giving is in your hands : you have an i1p2, a CS2740 and yiu can use DisplayCAL… so, share those CCSS first to see what is going on.
Ask and you shall receive. This was my first forum post and I didn’t exactly refuse to post it. Most forum users wouldn’t know what to do with it, so I didn’t post it. No need to use an accusatory tone. i1p2 ccss done on the Eizo is attached.
Using post calibration whitepoint adjustment seems a good choice if your i1d3 is actually wrong, if firmware data and actual sensivity curves do not match against a “reference” device. Let’s consider i1p2 3nm a reference. Do the test I showed you above.
I guess I wasn’t clear enough. I’m not using the i1d3 to calibrate because of the aforementioned issues with corrections. I’m using the i1p2. The CN7 calibration using the i1p2 produces a result where it tells me it has exactly hit the desired D65 whitepoint. However when done and the calibration is saved to the monitor and CN7 is shut down, a verification with the same i1p2 in Displaycal consistently shows a whitepoint 100k cooler than what CN7 says it is.
See the results of the CN7 calibration and the Displaycal verification attached. The i1p2 seems to be producing different readings in CN7 vs Displaycal for the blue primary (the difference perhaps due to differences between the Xrite and Displaycal drivers. I don’t know. This is a guess). This is repeatable. It happens every time. The whitepoint CN7 reaches always reads as 100k cooler when doing a Displaycal verification.
Looking at the verification results (attached both for CN7 and for DCAL), you can see that there is de2000 difference of over 5 for the blue primary readings between CN7 and DCAL verification runs, which explains the cooler whitepoint reading in DCAL (perhaps the problem is DCAL and not CN7, hard to tell). I’ve keyed these verification run measurements into the Excel file in a separate tab called CN vs DCAL and calculated the delta E, so you can read it off there. Note that the Excel file has a macro in it for the deltaE2000 calculation, so check out the code before enabling macros to be sure you’re ok with it.
This is why I did a manual whitepoint adjustment, because that way I can get the whitepoint to exactly D65. The CN7 result isn’t terrible, but it can be improved with a manual adjustment, so why not?
because as expalined above 3nm vs 10nm on widegamut readings with i1pro2 That’s typical.
If you had attached the data I asked you’ll se that. (A vs B)As saif before you have wrong configuration on CN7 or your color managed app. You can use the ICC profile generated by CN7 (unless you plan to use it as LUT3D source with alt whites)
As I said before, I’m 100% certain my apps are not misconfigured and you’re making incorrect assumptions. They’ve been working fine for years in colour managed mode. And I don’t think that CN7 is misconfigured either. You have the screenshots to go by.
There are three distinct and quite probably unrelated issues at play here
1. The EDR bundled with CN7 is a bad match to the panel. We know this. So I get a better result with the i1p2 than with the i1d3. It would be nice if I could find a better correction so I don’t have to kill my i1p2 through constant use. When I replaced the EDR with Stuart’s one, the calibration was obviously off. I didn’t need a probe to tell me that.
Explained above. Your WLED PFS backlight has a hump on shorted wv on reds … and (we do not know yest becsuse of the missing data) your i1d3 may be uncorrectable with CCSS/EDR.
If your i1d3 is fine, your’ll have to make an EDR by yourself.
If your i1d3 is a poor performer and you want to use it with CN7 you’ll have to use post calibration adjustment to i1pro2 3nm readings, then next recalibration to an alternative whietpoint … or if you are fine with i1pro2 10nm white next recalibration use alt wp target to use your i1d3 without post calibration wp adjustments.Of course you can ask Eizo to add a full custom/manual XYZ to XYZ correction to CN, like the one in Calman or Lightspace. It need to be full manual since if it allowed you to correct your i1d3 with i1pro2 it will use 10nm data, since all apps relying on Xrite driver do not use ArgyllCMS 3nm approach. You/we need to input 3×3 matrix or manual FCCM data.
Also CN allows to correlate CG-X internal probe to i1pro2 but does not allow to correlate to an i1d3. That will be a fine feature for CN7 (although full custom matrix will be better). Ask Eizo support to add it in next releases.
2. The i1p2 seems to produce different readings for CN7 and for Displaycal on the blue primary, resulting in a cooler whitepoint than desired.
3nm vs 10nm
3. An ICC profile issue. I haven’t worked out what this is. I just know that it doesn’t happen if I reprofile with Displaycal. Then everything works correctly. The only thing that changed is the ICC profile. Ergo, it’s either the profile itself or the way it’s being loaded.
Explained some possible reasons above. Mixing UC and No UC calibrations may be one of the reasons. Also changing OSD modes manually instead of using CN7 tray app. There are several user misconfiguration combinations.
The i1d3 is a retail device bought in January of 2019
23:54:42,704 Product Name: i1Display3
23:54:42,704 Serial Number: I1-18.B-02.314226.09
23:54:42,704 Firmware Version: v2.28
23:54:42,704 Firmware Date: 29Jan14
23:54:42,704 Default calibration:
23:54:42,704 Emissive matrix = 0.032586 -0.019982 0.014535
23:54:42,704 -0.000447 0.000955 0.069689
23:54:42,704 Ambient matrix = 0.179745 -0.109229 0.085718
23:54:42,704 -0.002006 0.004372 0.415365The i1p2 I can’t recall when I bought it, but here’s the data. Prior to CN7, it had seen very limited use – only to generate the occasional ccmmx for Dispcal and nothing else. It’s been getting a lot more work the last week.
00:05:49,145 Instrument Type: X-Rite i1 Pro 2
00:05:49,145 Serial Number: 1059871
00:05:49,145 Firmware version: 634
00:05:49,145 CPLD version: 999
00:05:49,145 Chip ID: 01-7e6613180000e4
00:05:49,145 Date manufactured: 20-15-1210
00:05:49,145 U.V. filter ?: No
00:05:49,145 Measure Ambient ?: Yes
00:05:49,145 Tot. Measurement Count: 55293
00:05:49,145 Remission Spot Count: 261
00:05:49,145 Remission Scan Count: 0
00:05:49,145 Date of last Remission spot cal: Thu Jan 01 00:00:00 1970
00:05:49,145 Remission Spot Count at last cal: 0
00:05:49,145 Total lamp usage: 66.203842EDIT: the forum software would not allow me to attach the Excel file. It can be downloaded here
Also it is not very clever to create an XYZLUT profile for a well behaved display. Roundig errors due to 3TRC will cause more harm than the slight 3D volume innacuracies.
If you insist in creating a no calibretion profile with DisplayCAL choose matrix + single curve. Then choose idealized black or actual black depeding on what you’re going to do and BPC support in that color managed app. > ~700:1 can have ideal black for most tasks.Of course you can create XYZLUT profiles for making LUT3D, what I wrote was a recomendation for color managed apps relying on display ICC profiles like PS and others.
Since you paid a Coloredge with near perfect grey it will not be very useful to corrupt grayscales due to a potential rounding error at 8bit because 3 independent TRCs.Also Stuart bundled EDR and CCSS in his attahment.. so you shoudl have the two files.
I don’t unfortunately have both his two files.
I cannot register on the Lift Gama Gain forum and so I cannot download attachments (see previous reply for details). The only reason I was able to get an EDR was because a link was posted in the clear to a Google Drive location: https://www.liftgammagain.com/forum/index.php?threads/eizo-coloredge-cg-2700x-or-similar-options-to-sdr.17560/#post-168303. The link in the post below it (which I assume is you, given the same first name) I cannot access because I cannot register on and login to the forum, so I don’t even know if the EDR on that Google Drive link is correct or not.
Perhaps you’d be so kind as to post the ones you know are correct in a reply here so that I can test against them?
That said, I did the requested C.) test against the EDR I already have, converted to a ccss with Argyll’s oeminst. Thanks for that pointer.
If your i1d3 is innacurate, if i1d3 filter & firmware behavior do not match
What do I do to determine whether the filter and firmware behaviour match or not?
I do not see profile configuration. That is what you have missconfigured hence your color management issues like oversaturation come from that (and from other app misconfiguration , not enabling v4 profiles and such).
Sorry, my bad. I forgot to attach the file showing the CN7 preferences. For the tests below, I did a brand new calibration and then took the Displaycal readings directly afterwards to eliminate any possible drift due to different states of instrument and display warm-up and ambient temperature.
Relevant files attached to this reply.
I do not see the data I asked to rate your i1d3.
Just run Tools / Report / Report on uncalibrated display.
This must be done on some “good state” of display, like for example after CN7 HW calibration using i1pro2. Do not change anything on display. Just measure that report:
A-on i1pro2 10nm
B-on i1pro2 3nm
C-on i1d3 with stuart 1nm CCSS (it will have some error vs “actual coordinates” since CS2740 SPD has a hump in shorter wv length)
D-on i1d3 with your own CCSS 3nmAttach report, copy paste. No excels.
Here you go. Caveat that I don’t know if I even have the right EDR file, given that I downloaded it from that Google Drive link, but the ccss I created from it with oeminst is attached to this reply.
A). LCD (generic) Adaptive 10nm mode
16:24:46,251 Setting up the instrument
16:24:46,251 Instrument Type: X-Rite i1 Pro 2
16:24:46,251 Serial Number: 1059871
16:24:46,251 Firmware version: 634
16:24:46,251 CPLD version: 999
16:24:46,251 Chip ID: 01-7e6613180000e4
16:24:46,251 Date manufactured: 20-15-1210
16:24:46,251 U.V. filter ?: No
16:24:46,251 Measure Ambient ?: Yes
16:24:46,251 Tot. Measurement Count: 56341
16:24:46,251 Remission Spot Count: 267
16:24:46,251 Remission Scan Count: 0
16:24:46,251 Date of last Remission spot cal: Thu Jan 01 00:00:00 1970
16:24:46,251 Remission Spot Count at last cal: 0
16:24:46,251 Total lamp usage: 67.499405
16:24:46,251 Display type ignored – instrument doesn’t support display type selection
16:24:46,251 Measured display update delay of 36 msec, using delay of 148 msec & 0 msec ↲
↳ inst reaction
16:24:46,251 Uncalibrated response:
16:24:46,251 Black level = 0.1323 cd/m^2
16:24:46,251 50% level = 21.93 cd/m^2
16:24:46,251 White level = 99.46 cd/m^2
16:24:46,251 Aprox. gamma = 2.18
16:24:46,251 Contrast ratio = 752:1
16:24:46,251 White chromaticity coordinates 0.3130, 0.3292
16:24:46,251 White Correlated Color Temperature = 6488K, DE 2K to locus = 4.5
16:24:46,251 White Correlated Daylight Temperature = 6491K, DE 2K to locus = 0.2
16:24:46,251 White Visual Color Temperature = 6327K, DE 2K to locus = 4.3
16:24:46,251 White Visual Daylight Temperature = 6497K, DE 2K to locus = 0.2
16:24:46,251 Effective Video LUT entry depth seems to be 10 bits16:26:46,421 Setting up the instrument
16:26:46,421 Instrument Type: X-Rite i1 Pro 2
16:26:46,421 Serial Number: 1059871
16:26:46,421 Firmware version: 634
16:26:46,421 CPLD version: 999
16:26:46,421 Chip ID: 01-7e6613180000e4
16:26:46,421 Date manufactured: 20-15-1210
16:26:46,421 U.V. filter ?: No
16:26:46,421 Measure Ambient ?: Yes
16:26:46,421 Tot. Measurement Count: 56341
16:26:46,421 Remission Spot Count: 267
16:26:46,421 Remission Scan Count: 0
16:26:46,421 Date of last Remission spot cal: Thu Jan 01 00:00:00 1970
16:26:46,421 Remission Spot Count at last cal: 0
16:26:46,421 Total lamp usage: 67.499405
16:26:46,421 Display type ignored – instrument doesn’t support display type selection
16:26:46,421 Measured display update delay of 42 msec, using delay of 156 msec & 0 msec ↲
↳ inst reaction
16:26:46,421 Uncalibrated response:
16:26:46,421 Black level = 0.1489 cd/m^2
16:26:46,421 50% level = 21.92 cd/m^2
16:26:46,421 White level = 99.50 cd/m^2
16:26:46,421 Aprox. gamma = 2.18
16:26:46,421 Contrast ratio = 668:1
16:26:46,421 White chromaticity coordinates 0.3130, 0.3291
16:26:46,421 White Correlated Color Temperature = 6489K, DE 2K to locus = 4.5
16:26:46,421 White Correlated Daylight Temperature = 6491K, DE 2K to locus = 0.2
16:26:46,421 White Visual Color Temperature = 6328K, DE 2K to locus = 4.3
16:26:46,421 White Visual Daylight Temperature = 6498K, DE 2K to locus = 0.2
16:26:46,421 Effective Video LUT entry depth seems to be 10 bitsB). LCD (generic) Adaptive Hires 3nm mode
16:29:55,074 Setting up the instrument
16:29:55,074 Instrument Type: X-Rite i1 Pro 2
16:29:55,074 Serial Number: 1059871
16:29:55,074 Firmware version: 634
16:29:55,074 CPLD version: 999
16:29:55,074 Chip ID: 01-7e6613180000e4
16:29:55,074 Date manufactured: 20-15-1210
16:29:55,074 U.V. filter ?: No
16:29:55,074 Measure Ambient ?: Yes
16:29:55,074 Tot. Measurement Count: 56341
16:29:55,074 Remission Spot Count: 267
16:29:55,074 Remission Scan Count: 0
16:29:55,074 Date of last Remission spot cal: Thu Jan 01 00:00:00 1970
16:29:55,074 Remission Spot Count at last cal: 0
16:29:55,074 Total lamp usage: 67.499405
16:29:55,074 Display type ignored – instrument doesn’t support display type selection
16:29:55,074 Measured display update delay of 34 msec, using delay of 145 msec & 0 msec ↲
↳ inst reaction
16:29:55,074 Uncalibrated response:
16:29:55,074 Black level = 0.1353 cd/m^2
16:29:55,074 50% level = 21.76 cd/m^2
16:29:55,074 White level = 98.71 cd/m^2
16:29:55,074 Aprox. gamma = 2.18
16:29:55,074 Contrast ratio = 730:1
16:29:55,074 White chromaticity coordinates 0.3112, 0.3268
16:29:55,074 White Correlated Color Temperature = 6607K, DE 2K to locus = 4.2
16:29:55,074 White Correlated Daylight Temperature = 6610K, DE 2K to locus = 0.6
16:29:55,074 White Visual Color Temperature = 6452K, DE 2K to locus = 4.0
16:29:55,074 White Visual Daylight Temperature = 6631K, DE 2K to locus = 0.6
16:29:55,074 Effective Video LUT entry depth seems to be 10 bits16:31:52,669 Setting up the instrument
16:31:52,669 Instrument Type: X-Rite i1 Pro 2
16:31:52,669 Serial Number: 1059871
16:31:52,669 Firmware version: 634
16:31:52,669 CPLD version: 999
16:31:52,669 Chip ID: 01-7e6613180000e4
16:31:52,669 Date manufactured: 20-15-1210
16:31:52,669 U.V. filter ?: No
16:31:52,669 Measure Ambient ?: Yes
16:31:52,669 Tot. Measurement Count: 56341
16:31:52,669 Remission Spot Count: 267
16:31:52,669 Remission Scan Count: 0
16:31:52,669 Date of last Remission spot cal: Thu Jan 01 00:00:00 1970
16:31:52,669 Remission Spot Count at last cal: 0
16:31:52,669 Total lamp usage: 67.499405
16:31:52,669 Display type ignored – instrument doesn’t support display type selection
16:31:52,669 Measured display update delay of 32 msec, using delay of 142 msec & 0 msec ↲
↳ inst reaction
16:31:52,669 Uncalibrated response:
16:31:52,669 Black level = 0.1289 cd/m^2
16:31:52,669 50% level = 21.72 cd/m^2
16:31:52,669 White level = 98.72 cd/m^2
16:31:52,669 Aprox. gamma = 2.18
16:31:52,669 Contrast ratio = 766:1
16:31:52,669 White chromaticity coordinates 0.3111, 0.3267
16:31:52,669 White Correlated Color Temperature = 6611K, DE 2K to locus = 4.2
16:31:52,669 White Correlated Daylight Temperature = 6614K, DE 2K to locus = 0.6
16:31:52,669 White Visual Color Temperature = 6456K, DE 2K to locus = 4.0
16:31:52,669 White Visual Daylight Temperature = 6636K, DE 2K to locus = 0.6
16:31:52,669 Effective Video LUT entry depth seems to be 10 bitsC.) i1d3 with RG_Phosphor_Family_25Jul12_CG319X.ccss
17:13:04,587 Setting up the instrument
17:13:04,587 Product Name: i1Display3
17:13:04,587 Serial Number: I1-18.B-02.314226.09
17:13:04,587 Firmware Version: v2.28
17:13:04,587 Firmware Date: 29Jan14
17:13:04,587 Measured display update delay of 45 msec, using delay of 160 msec & 0 msec ↲
↳ inst reaction
17:13:04,587 Uncalibrated response:
17:13:04,587 Black level = 0.1483 cd/m^2
17:13:04,587 50% level = 20.32 cd/m^2
17:13:04,587 White level = 92.16 cd/m^2
17:13:04,587 Aprox. gamma = 2.18
17:13:04,587 Contrast ratio = 622:1
17:13:04,587 White chromaticity coordinates 0.3127, 0.3301
17:13:04,587 White Correlated Color Temperature = 6498K, DE 2K to locus = 5.4
17:13:04,587 White Correlated Daylight Temperature = 6499K, DE 2K to locus = 0.9
17:13:04,587 White Visual Color Temperature = 6305K, DE 2K to locus = 5.2
17:13:04,587 White Visual Daylight Temperature = 6471K, DE 2K to locus = 0.8
17:13:04,587 Effective Video LUT entry depth seems to be 10 bits17:16:27,656 Setting up the instrument
17:16:27,656 Product Name: i1Display3
17:16:27,656 Serial Number: I1-18.B-02.314226.09
17:16:27,656 Firmware Version: v2.28
17:16:27,656 Firmware Date: 29Jan14
17:16:27,656 Measured display update delay of 35 msec, using delay of 146 msec & 0 msec ↲
↳ inst reaction
17:16:27,656 Uncalibrated response:
17:16:27,656 Black level = 0.1484 cd/m^2
17:16:27,656 50% level = 20.32 cd/m^2
17:16:27,656 White level = 92.27 cd/m^2
17:16:27,656 Aprox. gamma = 2.18
17:16:27,656 Contrast ratio = 622:1
17:16:27,656 White chromaticity coordinates 0.3124, 0.3302
17:16:27,656 White Correlated Color Temperature = 6512K, DE 2K to locus = 5.6
17:16:27,656 White Correlated Daylight Temperature = 6514K, DE 2K to locus = 1.1
17:16:27,656 White Visual Color Temperature = 6312K, DE 2K to locus = 5.4
17:16:27,656 White Visual Daylight Temperature = 6477K, DE 2K to locus = 1.1
17:16:27,656 Effective Video LUT entry depth seems to be 10 bitsD.) i1d3 with own ccss (the one posted in the previous reply)
16:34:00,752 Setting up the instrument
16:34:00,752 Product Name: i1Display3
16:34:00,752 Serial Number: I1-18.B-02.314226.09
16:34:00,752 Firmware Version: v2.28
16:34:00,752 Firmware Date: 29Jan14
16:34:00,752 Measured display update delay of 36 msec, using delay of 148 msec & 0 msec ↲
↳ inst reaction
16:34:00,752 Uncalibrated response:
16:34:00,752 Black level = 0.1470 cd/m^2
16:34:00,752 50% level = 20.59 cd/m^2
16:34:00,752 White level = 93.30 cd/m^2
16:34:00,752 Aprox. gamma = 2.18
16:34:00,752 Contrast ratio = 635:1
16:34:00,752 White chromaticity coordinates 0.2991, 0.3372
16:34:00,752 White Correlated Color Temperature = 7168K, DE 2K to locus = 15.0
16:34:00,752 White Correlated Daylight Temperature = 7157K, DE 2K to locus = 12.7
16:34:00,752 White Visual Color Temperature = 6437K, DE 2K to locus = 14.6
16:34:00,752 White Visual Daylight Temperature = 6575K, DE 2K to locus = 12.3
16:34:00,752 Effective Video LUT entry depth seems to be 10 bits16:35:13,761 Setting up the instrument
16:35:13,761 Product Name: i1Display3
16:35:13,761 Serial Number: I1-18.B-02.314226.09
16:35:13,761 Firmware Version: v2.28
16:35:13,761 Firmware Date: 29Jan14
16:35:13,761 Measured display update delay of 31 msec, using delay of 141 msec & 0 msec ↲
↳ inst reaction
16:35:13,761 Uncalibrated response:
16:35:13,761 Black level = 0.1470 cd/m^2
16:35:13,761 50% level = 20.59 cd/m^2
16:35:13,761 White level = 93.26 cd/m^2
16:35:13,761 Aprox. gamma = 2.18
16:35:13,761 Contrast ratio = 634:1
16:35:13,761 White chromaticity coordinates 0.2992, 0.3371
16:35:13,761 White Correlated Color Temperature = 7160K, DE 2K to locus = 14.9
16:35:13,761 White Correlated Daylight Temperature = 7149K, DE 2K to locus = 12.6
16:35:13,761 White Visual Color Temperature = 6437K, DE 2K to locus = 14.5
16:35:13,761 White Visual Daylight Temperature = 6576K, DE 2K to locus = 12.2
16:35:13,761 Effective Video LUT entry depth seems to be 10 bitsAttach profiles. You are doing something wrong 100% sure. CN7 ICC v2 profiles are supported by all my windows apps.
Also it is not very clever to create an XYZLUT profile for a well behaved display. Roundig errors due to 3TRC will cause more harm than the slight 3D volume innacuracies.
If you insist in creating a no calibretion profile with DisplayCAL choose matrix + single curve. Then choose idealized black or actual black depeding on what you’re going to do and BPC support in that color managed app. > ~700:1 can have ideal black for most tasks.Profile attached.
Yes, I know it’s not good to reprofile. I was trying to debug to find the cause of the incorrect colour management. Isolate, eliminate. So using Displaycal to reprofile was a way to test if potentially CN7 had a bug. It’s not something I’d want to use permanently at all. I’d rather find and eliminate the cause of the problem so that I don’t have to do that.
I did subsequently find that if I stopped running CN7 agent and used Displaycal’s profile loader instead, with the CN7 profiles generated by CN7, that I didn’t have the same colour management issue. The colour management works as expected.
I’ll update my graphics drivers to the latest Nvidia Studio driver. I’m running a dated version and I’m not sure if it’s the studio or game-ready driver, since you can’t really tell just looking at the list of installed programs in control panel or from the system information dialog in Nvidia control panel. It’s theoretically possible that an old buggy Nvidia driver could cause odd behaviour. They make a habit of releasing buggy drivers based on past experience.
Explained some possible reasons above. Mixing UC and No UC calibrations may be one of the reasons. Also changing OSD modes manually instead of using CN7 tray app. There are several user misconfiguration combinations.
I’m not changing OSD modes manually. I’m using the CN7 agent. If I did happen to change manually, then I’d also need to manually associate the right profile.
Anyway, I don’t need to change modes at the moment, since I’m testing the colour management with the left-hand monitor in Native gamut mode and the identical right-hand monitor in sRGB mode (I have a pair of CS2740s), with identical copies of the same sRGB colourspace image up on each monitor in a properly colour managed app to assess the colour management.
Also Stuart bundled EDR and CCSS in his attahment.. so you shoudl have the two files.
I don’t unfortunately have both his two files.
I cannot register on the Lift Gama Gain forum and so I cannot download attachments (see previous reply for details). The only reason I was able to get an EDR was because a link was posted in the clear to a Google Drive location: https://www.liftgammagain.com/forum/index.php?threads/eizo-coloredge-cg-2700x-or-similar-options-to-sdr.17560/#post-168303. The link in the post below it (which I assume is you, given the same first name) I cannot access because I cannot register on and login to the forum, so I don’t even know if the EDR on that Google Drive link is correct or not.
Perhaps you’d be so kind as to post the ones you know are correct in a reply here so that I can test against them?
It does not matter, you can even use HP Z24x G2 akin to stuart one. The point is that your CS2740 has a hump om reds thatthose doesplays do not have… hence even with a very accurate i1d3 may result in slighty off whitepoint.
That said, I did the requested C.) test against the EDR I already have, converted to a ccss with Argyll’s oeminst. Thanks for that pointer.
If your i1d3 is innacurate, if i1d3 filter & firmware behavior do not match
What do I do to determine whether the filter and firmware behaviour match or not?
I wrote it above… B vs C (or versus any other suitable CCSS like Stuart’s).
I do not see profile configuration. That is what you have missconfigured hence your color management issues like oversaturation come from that (and from other app misconfiguration , not enabling v4 profiles and such).
Sorry, my bad. I forgot to attach the file showing the CN7 preferences. For the tests below, I did a brand new calibration and then took the Displaycal readings directly afterwards to eliminate any possible drift due to different states of instrument and display warm-up and ambient temperature.
Relevant files attached to this reply.
This one:
This setup is close to DisplayCAL singe curve + matrix, BPC=on
I do not see the data I asked to rate your i1d3.
Just run Tools / Report / Report on uncalibrated display.
This must be done on some “good state” of display, like for example after CN7 HW calibration using i1pro2. Do not change anything on display. Just measure that report:
A-on i1pro2 10nm
B-on i1pro2 3nm
C-on i1d3 with stuart 1nm CCSS (it will have some error vs “actual coordinates” since CS2740 SPD has a hump in shorter wv length)
D-on i1d3 with your own CCSS 3nmAttach report, copy paste. No excels.
Here you go. Caveat that I don’t know if I even have the right EDR file, given that I downloaded it from that Google Drive link, but the ccss I created from it with oeminst is attached to this reply.
So we assume that display was set to CN7 HW cal with i1pro2 (10nm)
-i1pro2 10nm displaycal is spot on, same measurement.
-i1pro2 3nm says that is cooler but white (no a* error) sine 10nm reads it yellower than it is. Totally normal behavior.
-i1d3 with generic WLED PFS (adobeRGB flavor) seems to be close to what it should be, given the uncertain on red wvlength hump
-i1d3 with you own CCSS looks bad, so you may have create dit wrongly. SPD plot of that CCSS showed no unusual thing.
But since i1pro2 vs i1d3 with 1nm CCSS is fine… I wont say that your i1d3 is wrong.I tested your CCSS on an WLED PFS and it is fine… so it seems taht you are using that CCSS in a wrong way:
Place instrument on test window. Hit Esc or Q to give up, any other key to continue: Uncalibrated response: Black level = 0.1212 cd/m^2 50% level = 26.97 cd/m^2 White level = 121.50 cd/m^2 Aprox. gamma = 2.17 Contrast ratio = 1002:1 White chromaticity coordinates 0.3122, 0.3276 White Correlated Color Temperature = 6542K, DE 2K to locus = 4.0 White Correlated Daylight Temperature = 6545K, DE 2K to locus = 0.8 White Visual Color Temperature = 6397K, DE 2K to locus = 3.8 White Visual Daylight Temperature = 6573K, DE 2K to locus = 0.8
Also CG319X CCSS:
Hit Esc or Q to give up, any other key to continue: Uncalibrated response: Black level = 0.1209 cd/m^2 50% level = 26.90 cd/m^2 White level = 121.36 cd/m^2 Aprox. gamma = 2.17 Contrast ratio = 1004:1 White chromaticity coordinates 0.3127, 0.3286 White Correlated Color Temperature = 6505K, DE 2K to locus = 4.3 White Correlated Daylight Temperature = 6508K, DE 2K to locus = 0.5 White Visual Color Temperature = 6352K, DE 2K to locus = 4.1 White Visual Daylight Temperature = 6523K, DE 2K to locus = 0.4
Attach profiles. You are doing something wrong 100% sure. CN7 ICC v2 profiles are supported by all my windows apps.
Also it is not very clever to create an XYZLUT profile for a well behaved display. Roundig errors due to 3TRC will cause more harm than the slight 3D volume innacuracies.
If you insist in creating a no calibretion profile with DisplayCAL choose matrix + single curve. Then choose idealized black or actual black depeding on what you’re going to do and BPC support in that color managed app. > ~700:1 can have ideal black for most tasks.Profile attached.
Profile seems fine, 2.2. Should be supported by all apps like Adobe or Edge.
Yes, I know it’s not good to reprofile. I was trying to debug to find the cause of the incorrect colour management. Isolate, eliminate. So using Displaycal to reprofile was a way to test if potentially CN7 had a bug. It’s not something I’d want to use permanently at all. I’d rather find and eliminate the cause of the problem so that I don’t have to do that.
I did subsequently find that if I stopped running CN7 agent and used Displaycal’s profile loader instead, with the CN7 profiles generated by CN7, that I didn’t have the same colour management issue. The colour management works as expected.
Easier to check if changing Calx om CN7 tray app also changes default OS display profile. Mixing UC and NO UC Calx causes those issues for example, since they are not supported at the same time as explained in manual, although they may be clearer.
I’ll update my graphics drivers to the latest Nvidia Studio driver. I’m running a dated version and I’m not sure if it’s the studio or game-ready driver, since you can’t really tell just looking at the list of installed programs in control panel or from the system information dialog in Nvidia control panel. It’s theoretically possible that an old buggy Nvidia driver could cause odd behaviour. They make a habit of releasing buggy drivers based on past experience.
Explained some possible reasons above. Mixing UC and No UC calibrations may be one of the reasons. Also changing OSD modes manually instead of using CN7 tray app. There are several user misconfiguration combinations.
I’m not changing OSD modes manually. I’m using the CN7 agent. If I did happen to change manually, then I’d also need to manually associate the right profile.
Anyway, I don’t need to change modes at the moment, since I’m testing the colour management with the left-hand monitor in Native gamut mode and the identical right-hand monitor in sRGB mode (I have a pair of CS2740s), with identical copies of the same sRGB colourspace image up on each monitor in a properly colour managed app to assess the colour management.
But you have to test if OS default profile is the one you want. Move to “user” slot on CN7 tray, check that OS default profile is CS2740 for User, change back to CAL3, then check if default profie is the one you attached.
If not CN7 is nit publishing the custom ICC to OS. Check all other apps that may be interacting with OS color management of profile loading ,like Xrite VCGT tray app, DIsplayCAK loader, Basiccolor loader… close them all. Close CN7, restart it, to the change again USER, CAL3, check if OS notices the change.I mean, since I’ve tested your CCSS and it’s fine, these two measurements cannot be OK at the same time:
C.) i1d3 with RG_Phosphor_Family_25Jul12_CG319X.ccss 17:13:04,587 Setting up the instrument 17:13:04,587 Product Name: i1Display3 17:13:04,587 Serial Number: I1-18.B-02.314226.09 17:13:04,587 Firmware Version: v2.28 17:13:04,587 Firmware Date: 29Jan14 17:13:04,587 Measured display update delay of 45 msec, using delay of 160 msec & 0 msec ↲ ↳ inst reaction 17:13:04,587 Uncalibrated response: 17:13:04,587 Black level = 0.1483 cd/m^2 17:13:04,587 50% level = 20.32 cd/m^2 17:13:04,587 White level = 92.16 cd/m^2 17:13:04,587 Aprox. gamma = 2.18 17:13:04,587 Contrast ratio = 622:1 17:13:04,587 White chromaticity coordinates 0.3127, 0.3301 17:13:04,587 White Correlated Color Temperature = 6498K, DE 2K to locus = 5.4 17:13:04,587 White Correlated Daylight Temperature = 6499K, DE 2K to locus = 0.9 17:13:04,587 White Visual Color Temperature = 6305K, DE 2K to locus = 5.2 17:13:04,587 White Visual Daylight Temperature = 6471K, DE 2K to locus = 0.8 17:13:04,587 Effective Video LUT entry depth seems to be 10 bits D.) i1d3 with own ccss (the one posted in the previous reply) 16:34:00,752 Setting up the instrument 16:34:00,752 Product Name: i1Display3 16:34:00,752 Serial Number: I1-18.B-02.314226.09 16:34:00,752 Firmware Version: v2.28 16:34:00,752 Firmware Date: 29Jan14 16:34:00,752 Measured display update delay of 36 msec, using delay of 148 msec & 0 msec ↲ ↳ inst reaction 16:34:00,752 Uncalibrated response: 16:34:00,752 Black level = 0.1470 cd/m^2 16:34:00,752 50% level = 20.59 cd/m^2 16:34:00,752 White level = 93.30 cd/m^2 16:34:00,752 Aprox. gamma = 2.18 16:34:00,752 Contrast ratio = 635:1 16:34:00,752 White chromaticity coordinates 0.2991, 0.3372 16:34:00,752 White Correlated Color Temperature = 7168K, DE 2K to locus = 15.0 16:34:00,752 White Correlated Daylight Temperature = 7157K, DE 2K to locus = 12.7 16:34:00,752 White Visual Color Temperature = 6437K, DE 2K to locus = 14.6 16:34:00,752 White Visual Daylight Temperature = 6575K, DE 2K to locus = 12.3 16:34:00,752 Effective Video LUT entry depth seems to be 10 bits
You must have configured DislayCAL in a wrong way.
As you asked:
Original EDR
https://1fichier.com/?bb05h759gqmtjmlpqmpwCS2731 EDR
https://1fichier.com/?li5gwjaicz6qxcgf0kf2CG319X EDR
https://1fichier.com/?eidiui09ijbzatijjzviFirst of all redo all your i1d3 test, that 12dE + way cooler measurement is wrong but CCSS seems right. Also your i1d3 supports Stuart’s CCSS… so there must be something wrong in your DisplayCAL setup.
Even try to measure it command line to discard that you have messed up DIsplaYCAL so much that it may be no unusable unless full reinstall.
For measurement on command line make dur ArgyllCMS bin folder is on PATH, then:dispcal.exe -R -X "FULL_PATH_TO_WHATEVER_CCSS_YOU_WANT_TO_USE.ccss"Then make the suggested test to check if CN7 is publishing ICC profiles properly or ther is some other app in your system causing troubles.
Close all accesing VCGT like Xrite, DIsplayCAL tray… etc. Manually assing the proper ICC to your CAL3 while in CAL3. Then do all the round CAL3->User->CAL3 chekcing each time ICC is published properly.
Or even if you caused them by mixing CALx/User slots with or without uniformity compensation. If you change UC setting, all calibration slots are not valid as stated in manual.If you change UC setting, all calibration slots are not valid as stated in manual.
“untill next calibration” I forgot to write.
You must have configured DislayCAL in a wrong way.
I don’t think I’m using it in the wrong way – see screenshot attached
I mean, since I’ve tested your CCSS and it’s fine, these two measurements cannot be OK at the same time:
That’s a definitive indication either I misconfigured Displaycal or that my Displaycal installation is corrupted. Given that my Displaycal installation is years old and using the ccss is fairly simple, I assumed the latter. So I deleted it, cleaned out all the AppData\Roaming\DisplayCAL folders and downloaded a fresh copy.
Well, that makes a material difference. Here’s some readings with the same ccss file. I did a manual Argyll reading as you suggested to double check the Displaycal one.
21:48:50,864 Setting up the instrument
21:48:50,864 Product Name: i1Display3
21:48:50,864 Serial Number: I1-18.B-02.314226.09
21:48:50,864 Firmware Version: v2.28
21:48:50,864 Firmware Date: 29Jan14
21:48:50,864 Measured display update delay of 51 msec, using delay of 168 msec & 0 msec ↲
↳ inst reaction
21:48:50,864 No distict refresh period
21:48:50,864 Uncalibrated response:
21:48:50,864 Black level = 0.1513 cd/m^2
21:48:50,864 50% level = 20.59 cd/m^2
21:48:50,864 White level = 93.20 cd/m^2
21:48:50,864 Aprox. gamma = 2.18
21:48:50,864 Contrast ratio = 616:1
21:48:50,864 White chromaticity coordinates 0.3106, 0.3292
21:48:50,864 White Correlated Color Temperature = 6618K, DE 2K to locus = 6.1
21:48:50,864 White Correlated Daylight Temperature = 6619K, DE 2K to locus = 1.8
21:48:50,864 White Visual Color Temperature = 6389K, DE 2K to locus = 5.8
21:48:50,864 White Visual Daylight Temperature = 6557K, DE 2K to locus = 1.7
21:48:50,864 Effective Video LUT entry depth seems to be 10 bits21:52:01,080 Setting up the instrument
21:52:01,080 Product Name: i1Display3
21:52:01,080 Serial Number: I1-18.B-02.314226.09
21:52:01,080 Firmware Version: v2.28
21:52:01,080 Firmware Date: 29Jan14
21:52:01,080 Measured display update delay of 46 msec, using delay of 161 msec & 0 msec ↲
↳ inst reaction
21:52:01,080 Quantizing to 0.020147 msec
21:52:01,080 Uncalibrated response:
21:52:01,080 Black level = 0.1513 cd/m^2
21:52:01,080 50% level = 20.58 cd/m^2
21:52:01,080 White level = 93.22 cd/m^2
21:52:01,080 Aprox. gamma = 2.18
21:52:01,080 Contrast ratio = 616:1
21:52:01,080 White chromaticity coordinates 0.3106, 0.3292
21:52:01,080 White Correlated Color Temperature = 6619K, DE 2K to locus = 6.1
21:52:01,080 White Correlated Daylight Temperature = 6620K, DE 2K to locus = 1.7
21:52:01,080 White Visual Color Temperature = 6390K, DE 2K to locus = 5.8
21:52:01,080 White Visual Daylight Temperature = 6559K, DE 2K to locus = 1.7
21:52:01,081 Effective Video LUT entry depth seems to be 10 bitsC:\Argyll_V2.3.1\bin>dispcal -R -X”G:\Eizo CS2740 (i1 Pro 2).ccss”
Place instrument on test window.
Hit Esc or Q to give up, any other key to continue:
Uncalibrated response:
Black level = 0.1513 cd/m^2
50% level = 20.61 cd/m^2
White level = 93.24 cd/m^2
Aprox. gamma = 2.18
Contrast ratio = 616:1
White chromaticity coordinates 0.3107, 0.3293
White Correlated Color Temperature = 6612K, DE 2K to locus = 6.1
White Correlated Daylight Temperature = 6613K, DE 2K to locus = 1.7
White Visual Color Temperature = 6384K, DE 2K to locus = 5.8
White Visual Daylight Temperature = 6552K, DE 2K to locus = 1.7
Effective Video LUT entry depth seems to be 10 bits
The instrument can be removed from the screen.Since I got such a wildly different result on my own ccss, it makes sense to redo the CG319 ccss as well:
CG319 EDR
22:03:23,280 Setting up the instrument
22:03:23,280 Product Name: i1Display3
22:03:23,280 Serial Number: I1-18.B-02.314226.09
22:03:23,280 Firmware Version: v2.28
22:03:23,280 Firmware Date: 29Jan14
22:03:23,280 Measured display update delay of 50 msec, using delay of 166 msec & 0 msec ↲
↳ inst reaction
22:03:23,280 Uncalibrated response:
22:03:23,280 Black level = 0.1509 cd/m^2
22:03:23,280 50% level = 20.58 cd/m^2
22:03:23,280 White level = 93.18 cd/m^2
22:03:23,280 Aprox. gamma = 2.18
22:03:23,280 Contrast ratio = 618:1
22:03:23,280 White chromaticity coordinates 0.3118, 0.3289
22:03:23,280 White Correlated Color Temperature = 6556K, DE 2K to locus = 5.1
22:03:23,280 White Correlated Daylight Temperature = 6558K, DE 2K to locus = 0.5
22:03:23,280 White Visual Color Temperature = 6369K, DE 2K to locus = 4.9
22:03:23,280 White Visual Daylight Temperature = 6539K, DE 2K to locus = 0.5
22:03:23,280 Effective Video LUT entry depth seems to be 10 bits22:18:39,599 Setting up the instrument
22:18:39,599 Product Name: i1Display3
22:18:39,599 Serial Number: I1-18.B-02.314226.09
22:18:39,599 Firmware Version: v2.28
22:18:39,599 Firmware Date: 29Jan14
22:18:39,599 Measured display update delay of 57 msec, using delay of 176 msec & 0 msec ↲
↳ inst reaction
22:18:39,599 Uncalibrated response:
22:18:39,599 Black level = 0.1508 cd/m^2
22:18:39,599 50% level = 20.58 cd/m^2
22:18:39,599 White level = 93.15 cd/m^2
22:18:39,599 Aprox. gamma = 2.18
22:18:39,599 Contrast ratio = 618:1
22:18:39,599 White chromaticity coordinates 0.3116, 0.3289
22:18:39,599 White Correlated Color Temperature = 6565K, DE 2K to locus = 5.2
22:18:39,599 White Correlated Daylight Temperature = 6567K, DE 2K to locus = 0.7
22:18:39,599 White Visual Color Temperature = 6373K, DE 2K to locus = 5.0
22:18:39,599 White Visual Daylight Temperature = 6543K, DE 2K to locus = 0.7
22:18:39,599 Effective Video LUT entry depth seems to be 10 bitsAnd then do the CS2731 EDR that you kindly supplied a link to
CS2731 EDR
22:13:41,048 Setting up the instrument
22:13:41,048 Product Name: i1Display3
22:13:41,048 Serial Number: I1-18.B-02.314226.09
22:13:41,048 Firmware Version: v2.28
22:13:41,048 Firmware Date: 29Jan14
22:13:41,048 Measured display update delay of 63 msec, using delay of 184 msec & 0 msec ↲
↳ inst reaction
22:13:41,048 Uncalibrated response:
22:13:41,048 Black level = 0.1507 cd/m^2
22:13:41,048 50% level = 20.56 cd/m^2
22:13:41,048 White level = 93.13 cd/m^2
22:13:41,048 Aprox. gamma = 2.18
22:13:41,048 Contrast ratio = 618:1
22:13:41,048 White chromaticity coordinates 0.3126, 0.3287
22:13:41,048 White Correlated Color Temperature = 6510K, DE 2K to locus = 4.5
22:13:41,048 White Correlated Daylight Temperature = 6513K, DE 2K to locus = 0.3
22:13:41,048 White Visual Color Temperature = 6350K, DE 2K to locus = 4.3
22:13:41,048 White Visual Daylight Temperature = 6521K, DE 2K to locus = 0.3
22:13:41,048 Effective Video LUT entry depth seems to be 10 bits22:15:29,574 Setting up the instrument
22:15:29,574 Product Name: i1Display3
22:15:29,574 Serial Number: I1-18.B-02.314226.09
22:15:29,574 Firmware Version: v2.28
22:15:29,574 Firmware Date: 29Jan14
22:15:29,574 Measured display update delay of 62 msec, using delay of 182 msec & 0 msec ↲
↳ inst reaction
22:15:29,574 Uncalibrated response:
22:15:29,574 Black level = 0.1507 cd/m^2
22:15:29,574 50% level = 20.56 cd/m^2
22:15:29,574 White level = 93.13 cd/m^2
22:15:29,574 Aprox. gamma = 2.18
22:15:29,574 Contrast ratio = 618:1
22:15:29,574 White chromaticity coordinates 0.3126, 0.3287
22:15:29,574 White Correlated Color Temperature = 6510K, DE 2K to locus = 4.5
22:15:29,574 White Correlated Daylight Temperature = 6513K, DE 2K to locus = 0.3
22:15:29,574 White Visual Color Temperature = 6350K, DE 2K to locus = 4.3
22:15:29,574 White Visual Daylight Temperature = 6521K, DE 2K to locus = 0.3
22:15:29,574 Effective Video LUT entry depth seems to be 10 bits22:16:55,857 Setting up the instrument
22:16:55,857 Product Name: i1Display3
22:16:55,857 Serial Number: I1-18.B-02.314226.09
22:16:55,857 Firmware Version: v2.28
22:16:55,857 Firmware Date: 29Jan14
22:16:55,857 Measured display update delay of 59 msec, using delay of 178 msec & 0 msec ↲
↳ inst reaction
22:16:55,857 Uncalibrated response:
22:16:55,857 Black level = 0.1508 cd/m^2
22:16:55,857 50% level = 20.57 cd/m^2
22:16:55,857 White level = 93.13 cd/m^2
22:16:55,857 Aprox. gamma = 2.18
22:16:55,857 Contrast ratio = 618:1
22:16:55,857 White chromaticity coordinates 0.3126, 0.3287
22:16:55,857 White Correlated Color Temperature = 6510K, DE 2K to locus = 4.5
22:16:55,857 White Correlated Daylight Temperature = 6513K, DE 2K to locus = 0.3
22:16:55,857 White Visual Color Temperature = 6350K, DE 2K to locus = 4.3
22:16:55,857 White Visual Daylight Temperature = 6521K, DE 2K to locus = 0.3
22:16:55,857 Effective Video LUT entry depth seems to be 10 bitsQuite honestly, I have no idea why a fresh installation would do this. I’d expect it to either stop working entirely or work properly, not not work properly on some and not on others. I used exactly the same ccss for these reports and the same settings on Displaycal.
Incidentally, what is the technical reason that when using a spectral correction like this that it seems to under-read the luminosity by a good 7cdm2?
Or even if you caused them by mixing CALx/User slots with or without uniformity compensation. If you change UC setting, all calibration slots are not valid as stated in manual.
I have not altered the uniformity compensation settings. Left them the same all the time.
Easier to check if changing Calx om CN7 tray app also changes default OS display profile. Mixing UC and NO UC Calx causes those issues for example, since they are not supported at the same time as explained in manual, although they may be clearer.
But you have to test if OS default profile is the one you want. Move to “user” slot on CN7 tray, check that OS default profile is CS2740 for User, change back to CAL3, then check if default profie is the one you attached.
If not CN7 is nit publishing the custom ICC to OS. Check all other apps that may be interacting with OS color management of profile loading ,like Xrite VCGT tray app, DIsplayCAK loader, Basiccolor loader… close them all. Close CN7, restart it, to the change again USER, CAL3, check if OS notices the change.Yes, it’s changing profile correctly. I’ve checked this repeatedly and I usually have the colorcpl.exe app open when calibrating and testing to make sure it’s changing the profile. If I change the monitor profile with the CN7 app, it definitely changes the Windows ICC profile to the one associated with that monitor setting.
I’ve now updated my Nvidia drivers to the latest Studio version of the drivers. I’ll switch back to the colour navigator agent and do some more testing of the profile issue.
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.
Also remember that when CN7 gets and update, RG phosphor EDR will be replaced by the original file, so you’ll have to replace itRegarding the “refresh type” issue, it seems a bug in oeminst.exe. Change CCSS in a TXT editor REFRESH to “NO” or leave it as is, won’t make noticeable change.
IDNK what may have cause the corruption in your DisplayCAL isntallation.
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?
Also remember that when CN7 gets and update, RG phosphor EDR will be replaced by the original file, so you’ll have to replace it
Good tip, thanks – yes I’ve kept copies.
Regarding the “refresh type” issue, it seems a bug in oeminst.exe. Change CCSS in a TXT editor REFRESH to “NO” or leave it as is, won’t make noticeable change.
I was wondering what caused it to force refresh mode. Should have looked inside the CCSS.
Thanks a ton for the assistance you’ve given thus far.
