- This topic has 23 replies, 3 voices, and was last updated 12 months ago by
.
-
Posts
-
Hi all, I’ve been trying to calibrate my Eizo CS2400S and apparently DisplayCal disagrees with CN7
Here’s my setup:
I’m calibrating with an OEM i1D3 with CS2731 EDR correction file created by Stuart Pointon.
I’m working with photos so I’m using ICC profile calibration method with Photoshop. I tried using the same test pattern and EDR file for both softwares.
The test pattern being used is ISO 12646 in CN7 and ISO 12646:2008 in DisplayCal.
Both softwares were set to calibrate to sRGB gamma 2.4 at 100 nits in dimly lit room.After running calibration with CN7, the validation part gives quite a different report. CN7 reports quite low deltaE, average 0.4 and max at 1.12 and 0.17 for white balance. Whereas DisplayCal reports deltaE 2.2 with white, max 2.92 and average 0.64. Shouldn’t they report the same thing?
The only thing in common betweeen the 2 softwares being the red spectrum has the highest deltaE.
I also tried taking some measurements with HCFR and while the 3 primaries are around deltaE 0.4, the white is also reported to be deltaE 2.7.Did I do something wrong?
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.For photo editing you should use gamma 2.2. Gamma 2.4 is used for video editing.
Please show me screenshots of the “Display & instrument” and “Verification” tabs.
For photo editing you should use gamma 2.2. Gamma 2.4 is used for video editing.
Please show me screenshots of the “Display & instrument” and “Verification” tabs.
Sorry I forgot to add that I also do some work with video so I have 2 calibration profile, 1 for rec709 and another for sRGB, since I don’t want to change the ambient lighting everytime I switch so I made 2 profiles and configured PTS to work with gamma 2.4. I have some round about ways to make websites with sRGB gamma 2.2 still displays my photos correctly through assigning color profile.
Although I’m not sure if that would affect the accuracy of the color gamut because sRGB and rec709 shares the same coordinates except the gamma curve, right?
When a simulation profile is enabled, DisplayCAL measures how accurately colors are displayed in the simulated color space (e.g. sRGB, Adobe RGB, CMYK). It’s a great way to check how color-accurate your monitor actually is.
Your DisplayCAL readings are just plain bad.
Try to verify your color profile without a simulation profile. Make sure that “Current” is selected in the list of settings at the top.
When a simulation profile is enabled, DisplayCAL measures how accurately colors are displayed in the simulated color space (e.g. sRGB, Adobe RGB, CMYK). It’s a great way to check how color-accurate your monitor actually is.
Your DisplayCAL readings are just plain bad.
Try to verify your color profile without a simulation profile. Make sure that “Current” is selected in the list of settings at the top.
So simulation profile doesn’t mean to measure my current profile against some sort of standard profile? If you don’t mind me asking what is it for then?
The naming of things is confusing tbh.When a simulation profile is enabled, DisplayCAL measures how accurately colors are displayed in the simulated color space (e.g. sRGB, Adobe RGB, CMYK). It’s a great way to check how color-accurate your monitor actually is.
Your DisplayCAL readings are just plain bad.
Try to verify your color profile without a simulation profile. Make sure that “Current” is selected in the list of settings at the top.
Anyway, I tried again and the result doens’t do much better. The validation in CN7 still reports low deltaE while it’s the opposite for DisplayCal. I would get it if both reports roughly the same but alas.
It does. A simulation profile is used to measure how accurately colors are displayed in the simulated color space .
Without a simulation profile, DisplayCAL measures only how well the current color profile matches the display. I want to see if this measurement – without a simulation profile – will yield results similar to CN7’s.
It does. A simulation profile is used to measure how accurately colors are displayed in the simulated color space .
Without a simulation profile, DisplayCAL measures only how well the current color profile matches the display. I want to see if this measurement – without a simulation profile – will yield results similar to CN7’s.
Well the result is roughly the same.
1.97 on white balance but red jumps to 3.09, average deltaE is 0.7.
I tried verifying again with CN7 incase some hue shift due to the monitor being on for quite sometimes but it’s still the same. Max deltaE is 1.11, averages around 0.5, and 0.3 for white.
Both HCFR and DisplayCal reported quite good RGB balance across the gray scale tho, so there’s that I guess.In the “Calibration” tab change the observer to CIE 1964 10″ and validate the profile both with and without a simulation profile.
In the “Calibration” tab change the observer to CIE 1964 10″ and validate the profile both with and without a simulation profile.
The result is almost the same as the 1932 2* observer, maybe a few 0.0x off but mostly the same, in both cases of simulation profile.
Based on the readings alone, I would say I got pretty close so i’m not sure how DisplayCal calculates that as a whole 2.02 deltaE.
Display profile whitepoint:
xy 0.3128 0.3291 (XYZ 95.04 100 108.82), CCT 6499K
Measured whitepoint:
xy 0.3122 0.3311 (XYZ 94.29 100 107.74), CCT 6515KSame goes for the primary red. Not sure how that can be calculated as 3.09 deltaE2000. I tried using some online deltaE2000 calculators and they gives at most 0.7
118 255 0 0 0.6484-0.3309-22.2487
0.646-0.3387-22.0386
These are measured in xyY btw.Hi all, I’ve been trying to calibrate my Eizo CS2400S and apparently DisplayCal disagrees with CN7
Here’s my setup:
I’m calibrating with an OEM i1D3 with CS2731 EDR correction file created by Stuart Pointon.Likely that CN7 is configured to use default matrix correction. Go to Preferences and instead of “Color managed” (matrix, useful for CG with integrated colorimeters) choose “no compensation” (EDR, using GB-LED RG_phsphor… )
I’m working with photos so I’m using ICC profile calibration method with Photoshop. I tried using the same test pattern and EDR file for both softwares.
The test pattern being used is ISO 12646 in CN7 and ISO 12646:2008 in DisplayCal.
Both softwares were set to calibrate to sRGB gamma 2.4 at 100 nits in dimly lit room.After running calibration with CN7, the validation part gives quite a different report. CN7 reports quite low deltaE, average 0.4 and max at 1.12 and 0.17 for white balance. Whereas DisplayCal reports deltaE 2.2 with white, max 2.92 and average 0.64. Shouldn’t they report the same thing?
Whitepoint only errors are 90% chance to be caused by diferent colorimeter corrections while measuring with the same i1d3
The only thing in common betweeen the 2 softwares being the red spectrum has the highest deltaE.
I also tried taking some measurements with HCFR and while the 3 primaries are around deltaE 0.4, the white is also reported to be deltaE 2.7.HCFR must use the same correction and AFAIK it will search for ArgyllCMS forlder in appData Roaming while in DIsplayCAL you may manually choose any CCSS in filesystem.
You can use Argyllcms “specplot.exe path_to_ccss_file” to plot SPD stored in CCSS file. You know: GB-LED broad red primary, WLED PFS double peaks (unless measured at 10nm where it will see only one).
Did I do something wrong?
It is not in preferences but in 1st combo box when you are going to measure for calibrating, chapter 3 section 4 “Select a measurement device and click”
Also it is implied that you need to change CALx slot from “basic” to “advanced”“For the following measurement devices, the current settings for “Compensation method” are displayed (except when the color mode type is set to “Standard (STD)”)”
“Compensation method” = No compensation + i1d3 => EDR
Hi all, I’ve been trying to calibrate my Eizo CS2400S and apparently DisplayCal disagrees with CN7
Here’s my setup:
I’m calibrating with an OEM i1D3 with CS2731 EDR correction file created by Stuart Pointon.Likely that CN7 is configured to use default matrix correction. Go to Preferences and instead of “Color managed” (matrix, useful for CG with integrated colorimeters) choose “no compensation” (EDR, using GB-LED RG_phsphor… )
I’m working with photos so I’m using ICC profile calibration method with Photoshop. I tried using the same test pattern and EDR file for both softwares.
The test pattern being used is ISO 12646 in CN7 and ISO 12646:2008 in DisplayCal.
Both softwares were set to calibrate to sRGB gamma 2.4 at 100 nits in dimly lit room.After running calibration with CN7, the validation part gives quite a different report. CN7 reports quite low deltaE, average 0.4 and max at 1.12 and 0.17 for white balance. Whereas DisplayCal reports deltaE 2.2 with white, max 2.92 and average 0.64. Shouldn’t they report the same thing?
Whitepoint only errors are 90% chance to be caused by diferent colorimeter corrections while measuring with the same i1d3
The only thing in common betweeen the 2 softwares being the red spectrum has the highest deltaE.
I also tried taking some measurements with HCFR and while the 3 primaries are around deltaE 0.4, the white is also reported to be deltaE 2.7.HCFR must use the same correction and AFAIK it will search for ArgyllCMS forlder in appData Roaming while in DIsplayCAL you may manually choose any CCSS in filesystem.
You can use Argyllcms “specplot.exe path_to_ccss_file” to plot SPD stored in CCSS file. You know: GB-LED broad red primary, WLED PFS double peaks (unless measured at 10nm where it will see only one).
Did I do something wrong?
Yes to all that. I changed My CAL slot to advanced and chose DUE uniform priority.
I made sure that the same EDR was used across, the RG_Phosphor_CS2731 EDR by Stuart Pointon. Or at least so I thought.
I tried both methods, no compensation and color managed and I still got roughly the same result when measuring with the 2 other softwares.Yes to all that. I changed My CAL slot to advanced and chose DUE uniform priority.
I made sure that the same EDR was used across, the RG_Phosphor_CS2731 EDR by Stuart Pointon. Or at least so I thought.
I tried both methods, no compensation and color managed and I still got roughly the same result when measuring with the 2 other softwares.Use default Xrite’s RG_phosphor in DisplayCAL, if you get a match in “profile whitepoint vs measured whitepoint” on a CN7 calinbratin where you used “no compensation option”, you had not replaced the EDR.
Remember that on each CN7 update all EDRs are overwritten by default values.If aiming to D65 in AVD CALx slot, i1d3 “no compensation”, with proper patched EDR (WLED PFS), stoping CN7 tray and reopening it again after EDR patch, and you do not get a match with the SAME EDR (CCSS trantaled) in Displaycal, CN7 is doing something weird.
If that happens go to post calibration adjustemnet and make it match with DisplayCAL reading… if white does not look white and it bothers you.Another possibility is that CS2400S uses another backlight like QLED. There is no CS2400S spectral sample in community database. If that happens there is no EDR (maybe Asus ones from asus HW cal software) so CN7 will measure wrong. Measuring with a spectro will be the only way to test this.
uses another backlight like QLED. There is no CS2400S spectral sample in community database. If that happens there is no EDR (maybe Asus ones from asus H
I also suspected that CS2400S uses something else than RG_Phosphor so I tried to import different EIZO’s EDR from the program data folder of CN7.
I found this mapping text file in the folder which says6,WGCCFLFamily_07Feb11.edr 9,WLEDFamily_07Feb11.edr 18,RG_Phosphor_Family_25Jul12.edr
So I tried importing the number 6 and 9 EDRs into DisplayCal and found something weird.
When I choose the imported EDR, not CCSS file, DisplayCal automatically jumps to another CCSS, for example, When I choose the WGCCFL EDR that I marked with a “-eizo” suffix (meaning I pulled this file from CN7’s original EDR), DisplayCal jumps to another CCFL file like in the screenshot.
