- This topic has 14 replies, 3 voices, and was last updated 5 years, 6 months ago by
.
-
Posts
-
I have an Eizo CS2420 which has been hardware calibrated using ColorNavigator and i1Display Pro. I’m using displayCAL to verify the quality of the display /profile, but i’m not sure i’m doing it right… In an effort to be coherent, the question i want to ask is:
- Can i use displayCAL to test a hardware-calibrated monitor? (And if yes, are there any specfic settings i need to change when verifying a hardware calibration?)
-Previously, i’ve used displayCAL to calibrate and /or verify displays through the graphics-card, and i kind of understand what i’m doing (but yes, i do find this stuff a challenge). I’m unsure about the Eizo and displayCAL because i’m getting results from the measurment reports which seem not-optimal (in respect to what i’d expected from the display).
With thanks 🙂
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.-SInce originally posting i’ve realised a better way to ask what i need (sorry about that):
I’ve attached the measurment-report for the hardware-calibrated display; D65, 100cdm2 , Ga2.2.
- Why is the ‘Assumed White-point’ 6800k? -should it not be 6500k?
- Is this why the display fails on target white-point and profile white-point? (Criteria: RGB + gray balance).
Basically i want to know if the report shows that i’m doing something wrong, or if the report is saying the display white-point is off?
Hope this times it’s clearer 🙂
DisplayCAL could validate everything :D, including HW calibrations. I would even say that it would be mandatory to do this.
i1d3 colorimeters need corrections for each backlight “family”. Read displayCAL documentation.
CS models used to be GB-LED (RGphosphor) but newer CGs moved to W-LED PFS (which can be obtanied from HP Z32x software). IDNK if last revisions of current CS use the new one. Test it.Why is the ‘Assumed White-point’ 6800k? -should it not be 6500k?
Assumed WP is closest daylight curve white to your display white. So asumption is right, maybe is the lack of correction in your measurements which causes that 3dE deviation.
AFAIK Color Navigator does not use standard correction for i1d3 family. It’s a blakc box, so it is unknown if they use a proper one (hidden inside binaries) or if they just use a generic matrix for each Eizo’s backlight (which would be lame and inaccurate).
Once you know which backlight uses your display /GB-LED / W-LED PFS phosphor) I would trust DisplayCAL measurement rather than Color Navigator report.
If you do not like results, complain to Eizo. You are its customer.Is this why the display fails on target white-point and profile white-point? (Criteria: RGB + gray balance).
Because what I’ve explaned before.
-You did not use a correction for i1d3
-ColorNavigator could (or could not) used a good one.
These options are not exclusive. 1st option is TRUE (for sure), 2nd one IDNK at 100%.Re do verification with standard GB-ED correction (RG-phosphor… or some “Eizo CS” GB-LED correction in community database).
If WP keeps “far” (it’s actually not so far) try with the one in HP HW calibration software (take a look on other threads like this one: https://hub.displaycal.net/forums/topic/xrite-i1-display-pro-colormunki-or-wacom-color-manager/page/2/#post-13863 geet HP software, install, get EDR, uninstall, convert to CCSS, use it)Thanks VIncent for your reply. Confirmation that dCAL can do this is a relief, CN and iProfiler don’t do validations on the same level.
– Yes, i forgot about loading the corrections… i have since loaded up both ‘RGBLEDFamily_07Feb11.ccss’ and ‘WLEDFamily_07Feb11.ccss’ colorimeter corrections from the i1d3 download that displayCAL directs me to. Using RGBLED i’m getting dEmax 1.85 on assumed-target whitepoint, and dEmax 3.49 on display-profile whitepoint. (Using WLED i get 2.21 and 2.27 respectively).
*”Assumed WP is closest daylight curve white to your display white. So asumption is right, maybe is the lack of correction in your measurements which causes that 3dE deviation.”
– I’m assuming now that it was the lack of correction which gave the poor dE numbers, and that the corrections i’ve used now are still not optimal, so the results are still not accurate.
“get HP software, install, get EDR, uninstall, convert to CCSS, use it.”
- I’ve tried to find the correction file from the HP software after installation to test it, but i don’t know how to -sorry, i’ve never been able to understand how to do it from the manual or the forums. (I found a post which stated where the file(s) could be found in Windows, but i use a Mac and it isn’t the same /similar path to the folder.) Please would you make it clear how i can find it…?
Am i right in thinking that if i get the proper correction loaded in dCAL, there should be a match between the measured and target whitepoints (and <2 dEmax) ?
With thanks,
Asim
As said before you can use RG_phosphor correction (GB-LED, a sample from a U2413) or a CS (a GB-LED) sample from community or something called “HP_Dreamcolor_z24xnew panel” (a W-LED PFS sample).
Bold letters to usual Eizo’ CS backlights.It seems that you did not use them, you use others because of unknown reasons. Using WLED is a wrong choice.
Note: with a very accurate i1d3 colorimeter (firmware data matching closely CIE 1931 2º observer) it is possible that RGB LED could render results close to actual values. With other not so accurate i1d3 units… maybe not. That is a good reason to use the proper correction, to avoid or minimize that uncertainty.
IDNK if HP has software for mac & Z32x. Use a virtual machine if you do not find mac version.
Since it could be subject of intelectual property by HP or Xrite I won’t upload it. It’s your work to get it from a free download from those manufacturers.IDNK if HP has software for mac & Z32x… since it could be subject of intelectual property by HP or Xrite I won’t upload it. It’s your work to get it from a free download from those manufacturers.
I have downloaded and installed the mac software, i just don’t know how to find the EDR file (nor can i find instructions on how to in the forums or otherwise)… but fair enough, it’s beyond my ability.
you can use RG_phosphor correction (GB-LED, a sample from a U2413)…
Yes, sorry, i forgot i did manage to find this file through the forums: it gave the best result so far, the single issue being dEmax 3.4 on display-profile white-point (i’ve attached the report). To confirm, it’s called ‘RG Phosphor Family 25July12.css’ -is this the file you mean?
* Am i right in thinking that i now have an accurate colorimeter correction for my display, and can trust the numbers reported in dCAL?
Regards.
Yes, that correction. (BTW, <1000:1 it looks like a GBLED, not a W-LED PFS phosphor… so just use RGphosphor for measurements: DisplayCAL, i1Profiler, Basiccolor….etc)
From measurement it seems that it is white (GOOD,not pink or green), but a bit cool (blue).
Visual check ¿does it look white (no pink or green)? Answer = White (even it is a bit cool), it is good!Why Color Navigator do that… who knows. It does no use EDRs in the same way as NEC, Dell, Viewsonic or other manufacturers.
If you whish actual D65, try 6300K daylight in CN.
Maybe CN is making fakeprofiles (white=target even it is not) .
Actual monitor white vs CN profile white does not matter for PS/LR. Do not worry. I mean… let’s say that you put 6200K inCN & calibrate. You get near D65 in DislayCAL validation… but still get measured vs profile white mismatch (like in your last report). Don’t worry for PS, LR.. etc.Anyway, DisplayCAL can make profiles without calibration. That means that you use CN to make HW calibration, then build with DisplayCAL an accurate profie for whatever you want (with actual values)
It is written in documentation: just set calibration tab to native/as measured and button will change from “calibrate & profile” to “profile” (make sure you check linear calibration when asked). Your HW calibration seems to be very good (whitepoint exception), so if you use DisplayCAL to build a profile without calibratuon, choose single curve + matrix.
A drawback is that you may loose “fast HW calibraton change” in CN tray app. Since that is a very very cool feature of NEc & Eizo monitors… do whatever you want.Thanks again Vincent for your reply. I’ve had a chance to process what you’ve said and made new calibrations /tests…
I made a software-calibration in displayCAL (quitting ColorNavigator completely), with the Eizo set to Custom /Native Gamut /D60 /100cdm, the same settings as the current hardware-calibration: The verification report was excellent -correct Assumed and Measured Whitepoints (attached).
-It seems that dCAL cannot measure the correct Whitepoint when the display’s in HW mode. For example, it measures cdm correctly (2-3 cdm lower than what CN reports), but not chromaticity -which is reflected in the reports. So yes, there is some disconnect between the Eizo’s HW and dCAL in Whitepoint, as you suggested.
There is no such issue when using a software-calibration in the display’s Custom mode.
I wanted to use dCAL to (A) verify the colour quality, and (B) the Uniformity of the display.
The software-calibration report has confirmed (A) -in fact, it seems the HW calibration reports also confirm it in dE max and avg numbers, only the Whitepoint is mis-reported. As you’ve confirmed that in Photoshop everything will look as it should (whatever the reason for the Whitepoint-issue), this has been resolved for me.
As a result i’ve done a Uniformity measurment on the display using dCAL (while in software-calibration), knowing dCAL is working with i1Display accurately, so (B) too is resolved.
I’d just like to add, on colorimter-corrections, that i found the ‘RGPhosphorFamily’ and ‘WhiteLEDSamsung’ to be as good as each other. (I chose to use WhiteLEDSamsung in the end, mainly because i have in my notes that the display-panel is a “Samsung PLS with MG LED backlight”, but also it is stated as a W-LED backlight in technical-specs… ).
Thanks for your help with this Vincent. I’m still a beginner with displays /calibrations /interpreting reports, but this process has helped me to get a bit more control over what i’m doing.
Regards,
Asim
–It seems that dCAL cannot measure the correct Whitepoint when the display’s in HW mode. For example, it measures cdm correctly (2-3 cdm lower than what CN reports), but not chromaticity -which is reflected in the reports. So yes, there is some disconnect between the Eizo’s HW and dCAL in Whitepoint, as you suggested.
It’s quite the opposite (*). Color navigator seems unable to get CIE 1931 2º D65 in your display.
There is no such issue when using a software-calibration in the display’s Custom mode.
because you are using the same correction with the same target observer.
I’d just like to add, on colorimter-corrections, that i found the ‘RGPhosphorFamily’ and ‘WhiteLEDSamsung’ to be as good as each other.
That points to your particular colorimeter being very close to ideal CIE 1931 2º observer. It is good.
(I chose to use WhiteLEDSamsung in the end, mainly because i have in my notes that the display-panel is a “Samsung PLS with MG LED backlight”, but also it is stated as a W-LED backlight in technical-specs… ).
It is not a W-LED equal to “Xrite WLED” correction. It cannot be because yours is a widegamut and Xrite’s WLED belongs to sRGB office LED IPS displays.
Xrite bundled WLED is a wrong choice but you do not see it (from your own owrds) because your colorimeter seems very good at wavelengths where those 2 corrections are different (all but blue).If you wich to use a W-LED widegamut backlight correction (very different from Xrite’s WLED correction) there are several threads taliking about it. It is bundled in HP Z32x software.
Another close oene but different in green will a correction named Panasonic VVX[…] bundled in i1d3 correction pack.The main diference between W-LED widegamut and GB-LED is red (Panasonic VVX[…] ‘s red). If the huge differences between “Xrite’s WLED” and “RGphosphor” did not show up in corrected measurements it’s very unlikely that using a “true” W-LED PFS phosohor widgamut correction will fix Color Navigation mismatch in D65.
(*) Unless CN is aiming to another observer which is close to CIE 1931 2º 6900K.
ArgyllCMS comand line tools may be a way to test it.It’s quite the opposite (*). Color navigator seems unable to get CIE 1931 2º D65 in your display.
When i open dCAL after HW calibration in order to do a verification report, the display’s icc profile is the correct HW profile. However, when i run the measurments, the display profile changes to ‘Temporary dCAL’ -it’s not the HW profile that’s being used in the measurment. -I don’t know why this happens, but i haven’t been able to prevent it; clearly it’s something dCAL generates.
Also, when i make a Whitepoint measurment from the dCAL /Calibration options, i recieve an error notice: “Frame buffer depth 8 doesn’t match VideoLUT 10.” -Error- File ‘CS240profile.icc’ is not a valid ICC profile or Argyll .cal file.”
This is why i said that the CN HW profile seems to disengage when dCAL is used to verify the display. CN’s HW validation report hits the Whitepoint every time (and of course the display’s icc profile does not change).
(Btw, iProfiler cannot do a QA /Verification report at all on the CN HW calibration -it simply won’t do it; similar to dCAL, it displays an error message stating it is not a suitable .icc, as it contains no Settings.)
Anyway, i’m still digesting a lot of information, most of which i don’t properly understand 🙂 I have faith it will become clearer somewhere down the line. -I appreciate u seem to think my i1Display is an accurate one (although again, i don’t really understand why).
Regards.
If CN profile is broken… it does not matter, HW cal and HW cal profile are not binded. For HW cal, ICM profile is just a description of monitor response… nothing more. “Profile only” and make one… it’s just measuring, no GPU cal.
So if this happens build a “profile only” profile in DisplayCAL. Your 5500K last one have a calibration, not as intented. (It is also useful to make ICC V2 profiles in CN)Autochange of profile if CN is not broken could be due to user. Make sure that upper combo says “Settings : current”. Then make sure your HW cal CN’s ICM is default profile for that display.
i1Profiler refuses to validate profiles not made by it or OEM versions of itself (dell, Viewsonic…). It is a DESIGN choice.
DisplayCAL as long as profile can be read validates profiles from almost every vendor I know.I’ve since re-measured, ensuring CN’s HW profile is used for the display, throughout measurment, and it is -same results in the report. Settings confirmed as current. (ICC profile is v2.2.)
DisplayCAL as long as profile can be read validates profiles from almost every vendor I know.
I thought this was the problem: dCAL can’t read CN’s HW icc profile (even though it performs the measurement)…? -For example, it does load /read i1Profiler’s icc profile when that is used to (software) calibrate the display, and its validation matches iProfiler’s validation.
Unfortunately, i’ve become more confused since i’ve been looking into this, even though i’ve learned a lot more than i knew before in the last 10 days! 🙂 However, i do get that you’re saying there should be no problem; that if the display is accurate and properly calibrated then the dCAL validation will show the same measured, assumed & profile Whitepoints as reported by ColorNavigator…
I’ve also become aware that i need to confirm the accuracy of my colorimeter. Support@Eizo, who i’ve been in contact with regarding ColorNavigator and the validation reports its giving me in Native-gamut calibration, have suggested there may be a problem with my iD3. Obviously, if the iD3 is at fault, it’s not a dCAL issue at all. So, i will have to address this issue first.
Regards 🙂
I thought this was the problem: dCAL can’t read CN’s HW icc profile (even though it performs the measurement)…? -For example, it does load /read i1Profiler’s icc profile when that is used to (software) calibrate the display, and its validation matches iProfiler’s validation.
I’ll try to explain it again: It does not matter at all.
You use a CS with CN and choose as target CIE 1931 2º D65 coordinates, calibrate and now you try to validate results.
If your CS is a GB-LED, you use GB-LED correction with i1d3 and DisplayCAL reports ~6900K but “white” under CIE 1931 2º observer(assumed vs measured with very low dE)… it is Color navigator’s fault.
If your CS is a W-LED widegamut, you use W-LED widegamut correction (from HP) with i1d3 and DisplayCAL reports ~6900K but “white” under CIE 1931 2º observer (assumed vs measured with vry low dE)… it is Color navigator’s fault.
But is a small error.
I’ve also become aware that i need to confirm the accuracy of my colorimeter. Support@Eizo, who i’ve been in contact with regarding ColorNavigator and the validation reports its giving me in Native-gamut calibration, have suggested there may be a problem with my iD3. Obviously, if the iD3 is at fault, it’s not a dCAL issue at all. So, i will have to address this issue first.
Regards
I do not see hints that i1d3 or DisplayCAL are doing something wrong.
Your report & findings do not prove that but the opposite:
Color navigator is failing to achieve CIE 1931 2º D65 with that colorimeter when you request “D65” or “6500K” in its user interface.Why? Several options, for example:
-CN is using a non portable correction (matrix)
-CN is using non suitable correction (spectral)
–not aiming to CIE 1931 2º D65 when you setup “D65” as target. It is aiming to something else… and it is possible that this “something” may be called “6500K” and “white” too. In that situation CN will be still wrong because this “something” is not what other people uses as “D65”. Of course it could be useful but not as a default behavior for a user friendly not tech oriented UI of Color Navigator.And you do not even need DisplayCAL or the ICM profile from CN to test that 3 options. ArgyllCMS has a wonderful set of comand line tools to make single readings on screen.
Of course you are free to follow “CN is right” path but all your findings aim to the opposite.
Of course you are free to follow “CN is right” path but all your findings aim to the opposite.”
-No, i can’t follow the ‘CN is right’ path, partly because of what you’ve said on this post…
I know there is a problem somewhere with the CN HW calibration… there is a noticeable difference in numbers (dE2000, and particularly dEab) between the Native and AdobeRGB gamut calibrations in Native and AdobeRGB gamuts… on this issue, Eizo have questioned the accuracy of my i1D3, based on the reports i sent them (Red patch measurment is apparently off).
Unfortunately, it’s gonna take me some time to process the more technical information /procedures you’re giving me. I’ve also realised there are a lot of holes in my calibration understanding in general. -I’m also trying to track down other dCAL-using Eizo owners, who i’ve come across on other forums (i didn’t have the impression from their posts that there was any issue /limitation in using dCAL with their Eizos).
I’ll definitely update this post when i’ve made progress /worked out the problem. Hopefully, sooner rather than later 🙂
I know there is a problem somewhere with the CN HW calibration… there is a noticeable difference in numbers (dE2000, and particularly dEab) between the Native and AdobeRGB gamut calibrations in Native and AdobeRGB gamuts… on this issue, Eizo have questioned the accuracy of my i1D3, based on the reports i sent them (Red patch measurment is apparently off).
IDNK/I did not see those comparisons you talk about… but when a widegamut user complains about “AdobeRGB” and “red” (and no others) it is possible that user is comparing native gamut vs AdobeRGB profile or AdobeRGB gamut emulation against native profile.
Measured red agaisnt profile red in 2D a*b* plot should provide a visual confirmation of this issue.
