- This topic has 39 replies, 5 voices, and was last updated 2 years ago by
.
-
Posts
-
Hello,
trying to calibrate my new CS2731 with i1DisplayPlus, and getting different results with ColorNavigator and DisplayCAL. Let’s say I take 120cd D65 2.2 AdobeRGB gammut as target. Then I do the calibration with CN and save to slot number 6. Instantly i notice it looks little bit different as from one slot from factory with AdobeRGB (number 2), slight greenish tint. Target settings are exactly the same in both 2 and 6 slots. Then I also started calibration for AdobeRGB factory slot 2, nothing changed, looks the same as before calibration. Then I started DisplayCAL, configured the same targets, and started the calibration, in the first section “Interactive display adjustment” it instantly shows the greens are too much when slot 6 is active, when I change to AdobeRGB factory slot 2, it gets much better match.. and then I check all other profiles I tried to create with CN (DCI-P3, sRGB, REC.709 and etc.) and all of them on DisplayCAL shows the same green tint..
How the same calibrator can get different values (white point) with CN and DisplayCAL with the same targets?
Maybe I should try to calibrate with DisplayCAL only, but as I understand DisplayCAL will not write to any slot in Eizo monitor. Which slot and what settings I should switch on Eizo, before starting calibrations with DisplayCAL? I’m afraid it will have “double” calibration this way: one in the monitor HW slot, and one calibrate with DisplayCAL..
I don’t have any more ideas why it happens like this… can anyone please give me any suggestions, what can be wrong? Is my calibrator is defective?..
Thanks a lot.
Mindas
User error (there could be other error/misconfigurations but 1st one is yours)
Correction cannot be “none”:
-GB-LED (u2413) fro GB-LED CS (older ones were gb-led)
-WLED PFS (HP Z24x) for WLED with PFS phpshor and near full adoberGB coverage
-user made CCSS by community at 3nm
If using proper correction there is a whitepoint missmatch:
-check CN predeferences. By default is using generic matrix for i1d3 and ypur model. Compatibility mode uses EDR for GB-LEDs, you can use that. *****IF***** your CS is actually a WLED PFS you’ll need to manually update/replace EDR spectral data with an EDR for the HP z24x.
(alternative)
-CN use visual whitepoint editor an match it to DisplayCAL GB-LED/WLED PFS reading of D65.BTW: i find totally useless your choice of preset. Use native gamut instead of AdobeRGB. All apps using images with AdobeRGB colorspace will be color managed, hence limitation is almost pointless unless app has some weird behavior when color managing and limited to 8bit too.
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.Thank you, Vincent, for your bright insights!
Correction cannot be “none”:
This is something I wrongfully did not expected to make big difference (thought these corrections are more subtle differences), but it changes measurements big way. SO last night did more experiments with CN7 “compensation” settings and DisplayCAL corrections. Switching “compatibility mode” on and off, I did not noticed differences in measurements, but “compensation” changes made difference, as you described in another thread:
“AFAIK, for CN if you use “No compensation” on CS line it will take only RG_phosphor EDR, so readings in Argyll with i1Profiler’s RG_phosphor (U2413) CCSS should be the same.
With other than no compensation setting I’m afraid they are using a matrix correction from a CS sample in factory but since no i1d3 is exactly equal that matrix is not valid for all. <…> ”So I did an experiment measuring the same 120cd D65 2.2 Native targets with different “compensation settings” in latest CN7 and compared them with different corrections in DisplayCAL, what I got is in attached screenshot.
Seems like GB-R LED RG Phosphor correction (RG_Phosphor_Family_25Jul12.ccss) matches the best with “compensation off” setting, as you said this way it uses:
uses EDR for GB-LEDs, you can use that
BTW also noticed that with compensation off – usually the result in CN7 shows better contrast, don’t know how it is related..
Ok, so this way I got this “CALIBRATION NUMBER 1” with GB-R RG now visually it has more colder, like little greenish look of white. Again now it matches with DisplayCAL, but who knows if it is correct.. as you said, if this monitor is actually having WLED PFS (HP Z24x) backlight, this calibration could be wrong..
I noticed the same problem “Eizo display showed some wrong whitepoint after calibration. Its incomfortability was sensed by eyes too.” had Алексей Коробов in thread :
You suggested, it could be possible solved this way :
*****IF***** your CS is actually a WLED PFS you’ll need to manually update/replace EDR spectral data with an EDR for the HP z24x.
“BUT with “no compensation” you can detach factory colorimeter matrix correction and use EDR correction in ColorNavigator (NEC can’t) so in theory if you replace spectral samples in RG phosphor file with HP z24x EDR spectral data (repeated several times, or even just replacing files)… voilà! CN + “no compensation” + “forged EDR” = accurate CN readings on newer Eizo CGs and an i1d3.”
Can you suggest me how I can possibly try to “forge” this correction in CN7? where these files are located in CN7? As I understand, I have to put data from file “HP_DreamColor_Z24x_NewPanel.ccss”, right?
Also, it’s a bit weird as everyone has to guess what kind of backlight CS2731 uses, can EIZO just officially inform what kind of backlight it uses, or just simply fix these “phosphor” corrections in CN7, so the regular photoshop guy, didn’t have to mess with all these EDR :))
-CN use visual whitepoint editor an match it to DisplayCAL GB-LED/WLED PFS reading of D65.
For this kind of solution I found out that x-rite i1Profiler also has PFS correction (but possibly P3 version):
Steve Shaw said: ↑
Have just had a follow-up from X-Rite…
They have said they are sending us an updated an EDR for pfs-phosphor backlights. An “EDR for pfs” is available for everybody… it’s in latest i1Profiler (and some OEM HW calibration versions), but it’s a WLED PFS for P3 multimedia/imac displays (crippled green). I hope they send you (and NEC dev team for SV2 software) the “good one” like they did for HP, or even better the two EDRs. WLED PFS “P3” ; WLED PFS “AdobeRGB” (Eizo-like), slight different green, HP-like EDRSo I opened manual white point correction in CN7 and in parallel launched i1Profiler, with this PFS Phosphor correction, and adjusted whitepoint and brightness in CN7 to have exact match to 6500K and 120cd in iProfiler. Closed i1Profiler and finished calibration in CN7. The resulted “CALIBRATION NUMBER 2” visually looks more warm – reddish compared to first one with GB-R RG.
Again did the same thing, just with DisplayCAL with PFS WLED HP Z24x G2 correction and CN7 manual adjustment of whitepoint and brightness. The resulted “CALIBRATION NUMBER 3” visually very close to number 2.
So to conclude, which one would be correct one: number 1 (greenish) with GB-R RG EDR match (done inside CN7 without manual tweak) or number 3 (reddish) with PFS WLED HPZ24xG2 match (with manual tweak)?
Also, if I would try to do this “forging” HP Z24x PFS EDR into CN7, would it be more correct as calibration 3 with manual tweak ? As it would get rid of human error in maual tweaking..
Thank you Vincent.
P.S.
BTW: i find totally useless your choice of preset. Use native gamut instead of AdobeRGB. All apps using images with AdobeRGB colorspace will be color managed, hence limitation is almost pointless unless app has some weird behavior when color managing and limited to 8bit too.
Yes, true, it’s a bright suggestion, no reason to limit gammut. 🙂
As explained before if you found a 3nm CCSS for CS2731… just plot it, plot spectral power distribution. The “i” icon next to correction in DisplayCAL
I’ve done it command line (instead of Displaycal, but it’s the same) it is a WLED PFS like HP z24x:
specplot “Eizo CS2731 (ColorMunki) spectral 120cdm native gamut.ccss”
But since it is measured at 3nm it’s shape is not as clear as the HP EDR at 1nm
Also, do not use other people’s CCMX, you’ll face the same issues as default Compensation table in CN.
Use CCSS which are equivalent to EDR which rely on i1d3 spectral sensivity curves stored in firmware for self correct measurements. They are meant to be “portable” between i1d3 measuring the same backlight technology.
CCMX, 3×3 matrices, are meant to be used if YOU made them for YOUR colorimeter and YOUR display using some other reference measurement device. “Not portable” between devices.
If you cannot make them, always go to CCSS, 3nm or better. Also watch out if some user (since it’s community contribution) amde them wrong: they should be measured at native gamut.Today I got reply from Eizo support in Sweden, I asked them, could they confirm what backlight system is using their CS2731 display… and the answer was : “Backlight system is Blue-LED + RG-phosphor. It wont be any issue in calibration because colornavigator makes calibration regarding the coloredge model and sensor. Im quite sure the result is good if you check it with a grey test picture which you can find i manual setting in colornavigator.”
On that user ccss file graph we see WLED PFS like curves… again confusing. On other hand, when I switched off “compensation” in CN7, without any manual whitepoint adjustment it matches DisplayCAL measurements with GB-R LED RG correction.. Third thing, maybe our visual perception will adjust accordingly these small differences, and it not will be an issue..
So generally speaking, all these “measurement correction” problems are related mainly to LCD backlight system? and it’s all about the correct whitepoint, otherwise calibration colour accuracy is not badly influenced by it?
Another question I have, if I switch to “DUE Brightness” setting in CS2731 (switching uniformity compensation off), do I have to re-calibrate all my targets? Because for AdobeRGB, sRGB, Printproof – “DUE Uniformity” is the best option, but let’s say now I want to calibrate for REC.709, working with video stronger priority is contrast ratio, which I think will be higher with “DUE Brightness”..
Today I got reply from Eizo support in Sweden, I asked them, could they confirm what backlight system is using their CS2731 display… and the answer was : “Backlight system is Blue-LED + RG-phosphor. It wont be any issue in calibration because colornavigator makes calibration regarding the coloredge model and sensor. Im quite sure the result is good if you check it with a grey test picture which you can find i manual setting in colornavigator.”
On that user ccss file graph we see WLED PFS like curves… again confusing. On other hand, when I switched off “compensation” in CN7, without any manual whitepoint adjustment it matches DisplayCAL measurements with GB-R LED RG correction.. Third thing, maybe our visual perception will adjust accordingly these small differences, and it not will be an issue..
They are saying that for them built int 3×3 matrix correction is the best (Compensation table=color management”). But that is false, since it does not take account for unit to unit variation.
Also they are lying regarding backlight or user uploaded CCSS is fake.
If the 2nd is true, using “No compensation” (GB LED U2413 as sample in RG_phoshor.EDR ) should be a good match.
If the 1st is true, using “No compensation” (GB LED U2413 as sample in RG_phoshor.EDR ) may lead to varying grades of error since it will magnify “non ideal colorimeter errors from std observer” where that EDR differs from actual one.Of course if they are omiting proper EDR, and THEY ARE,100% sure, at least for all the current ColorEdge CG line, they won’t acknowlege it.
So generally speaking, all these “measurement correction” problems are related mainly to LCD backlight system? and it’s all about the correct whitepoint, otherwise calibration colour accuracy is not badly influenced by it?
It is an overral error but whitpoint will suffer the most.
Another question I have, if I switch to “DUE Brightness” setting in CS2731 (switching uniformity compensation off), do I have to re-calibrate all my targets? Because for AdobeRGB, sRGB, Printproof – “DUE Uniformity” is the best option, but let’s say now I want to calibrate for REC.709, working with video stronger priority is contrast ratio, which I think will be higher with “DUE Brightness”..
AFAIK this DUE config is global, for all modes so switching it ON affects all OSD modes. The easiest way to check if it is something to bother about is to measure after turning it on/off:
calibrate to softproof target (t1) due on. validate with displaycal
calibrate to video target (t2) due off. validate with displaycal
Choose in CN tray to change calibration to T1 (it shoudl change default display ICC on OS too, full auto), make sure DUE is on, if it is not, activate it, validate with DisplayCAL.
Choose in CN tray to change calibration to T2 (it shoudl change default display ICC on OS too, full auto), make sure DUE is on, if it is not, activate it, validate with DisplayCAL.Reports should not change.
Also DUE=off uniformity report shoudl give you extremely accurate <2dC color errors on every screen patch, but maybe -5 to -10% brightness error (not color error) happens on corners.
Run an uniformity report on displaycal to check this. Default report shows dE (total error, color + brightness). Switch to deltaC on report cerntral grid combo.AFAIK this DUE config is global, for all modes so switching it ON affects all OSD modes. The easiest way to check if it is something to bother about is to measure after turning it on/off:
calibrate to softproof target (t1) due on. validate with displaycal
calibrate to video target (t2) due off. validate with displaycal
Choose in CN tray to change calibration to T1 (it shoudl change default display ICC on OS too, full auto), make sure DUE is on, if it is not, activate it, validate with DisplayCAL.
Choose in CN tray to change calibration to T2 (it shoudl change default display ICC on OS too, full auto), make sure DUE is on, if it is not, activate it, validate with DisplayCAL.Reports should not change.
Hello Vincent,
today tried to check this thing DUE Uniformity Mode (on /off). What I noticed instantly – when I change DUE mode, the calibration slots which were calibrated with DUE ON, instantly shows in CN, that it is not calibrated. I mean it remembers in which mode calibration was done. If I switch to DUE OFF and then switch to the slot which was calibrated with DUE ON, instantly it’s noticeable that brightness did not match.
So I calibrated one slot with DUE ON, and another one with DUE OFF. Then did manual corrections with corresponding EDR (WLED PFS HP) as before. Then I switch to particular slot, change DUE mode to corresponding with calibration, and did verification with DisplayCAL. Got two reports, seems everythings quite close, don’t know exactly where to look particularly?.. Anyway it means when I need REC.709, I switch to particular slot and change mode to DUE OFF. Should be ok, right?
Another question I have. Would like to try 3DLUT calibrations with DisplayCAL for madVR. I know here my CS2731 hardware is incompatible with 3DLUT, so CN is no use. I will do the calibration with DisplayCAL, but what to do with CN? I mean which slot should I leave switched on monitor menu during such calibration? Does CN has to be unloaded from windows?
Thanks!
Of course brightness won’t match calibration target ON/OFF since DUE affects backlight. I meant white and grey calibration. If that is OK and WP does not drift too much as you raise lower brghtness on OSD (that is not guaranteed), it can be used.
Regarding manual corrections you mean EDR file replacement or a*b* manual adjustment after calibration? I would try first one.
Regarding your LUT3D question, (try also DWM LUT as explained i other thread, amazing) your setting con CN should be:
-desired white
-close to native nominal gamma or close to most common LUT3D calibration gamma (2.2 vs 2.4, try 2.2)
-DUE OF (brightness), dC uniformity should be very good.
Then move to DisplayCAL, make a detailed profile XYZLUT with 400+ patches (1500 are easy to read with an i1dispalypro, 30min), save copy it to a working folder, then manialy create as much LUT3Di in madvr .3dlut or iridas/dwmlut (.cube) format as you want…. although CN calibration should be good enough to do not need to use DWMLUT for desktop, it is more useful on troublesome monitors with bad calibration software like LG, Dell, Asus or Benq since you can calibrate grey in GPU shaders avoiding GPU LUT banding on some GPUs.Look at that grey! <0.6 on a*b* range… GOOD, those Coloredges are amazing even the cheaper ones in CS line.
HW calibrations on Dell or LG or Benq can go up to 1.5-2.x and be noticeable without measurements, by eye inspection of a non color managed gradient.Regarding manual corrections you mean EDR file replacement or a*b* manual adjustment after calibration? I would try first one.
Hello Vincent,
today I tried to replace EDR file in CN. I unloaded CN agent. Took HP_DreamColor_Z24x_NewPanel.edr from HP support files for HP Z24x G2 online and replaced CN’s RG_Phosphor_Family_25Jul12.edr file in CN directory. When loaded CN once again, seems all good, no problem. Then I recalibrated slot which was calibrated with CN original RG Phosphor EDR (which had colder look). I see the results are much warmer (seems file replacement is working). But I noticed that is even more warmer/reddish than my manually adjusted whitepoint slot. I loaded DisplayCAL and checked both slots (manually adjusted and patched) against DisplayCAL with HP_DreamColor_Z24x_NewPanel EDR. and strangely results do not match (patched has about delta3.6 whitepoint).. I attached the screenshots. I can conclude to two outcomes:
- Maybe EDR file is not exactly the same. I took binary EDR file from HP Z24x G2, and DisplayCAL uses HP_DreamColor_Z24x_NewPanel.ccss CCSS file… I don’t know how I could convert exactly the same file from Argyll’s CCSS to EDR..
- Maybe CN is interpreting the same file different way.. don’t know why, and how.. maybe it’s something to do with “Refresh Mode” which switches on, as I change to HP Z24x EDR in DisplayCAL..
What are your ideas regarding this?
- They are the same. Easy to check converting EDR to CCSS with Argyll & plot it.
- CN must be configured to use EDR and not built in matrix in preferences.
- If CN is not detecting EDR properly so ingores it*, CN readings usually will match “No correction” in Displaycal. If such issue is happening then manual replacement of spectral series may be needed (Go to RG_phpshor EDR, replace all spectral series with HP’s, hex editor, series length match so it’s not too complicated, just binary copy paste)
“Refresh” is an error in converter from EDR to CCSS. Most of bundled CCSS in DisplayCAL were created from EDR with Argyll tools. Changing CCSS text file REFRESH to “NO” solve that issue, but it’s not needed.
*) like Basiccolor. It’s up to application. CalMAN allows replacement, other tools like Basiccolor 5 did not like it.
If such issue is happening then manual replacement of spectral series may be needed (Go to RG_phpshor EDR, replace all spectral series with HP’s, hex editor, series length match so it’s not too complicated, just binary copy paste)
Is there some special hex editor, how it is possible to find where spectral data starts in that binary file?
For each channel (WRGB)
[
“DISPLAY DATA”
channel info & primary
“SPECTRAL DATA”
n samples in that channel
<actual data>] x n times
n samples (per channel) is equal 351 @ 1nm for WLED PFS and RG_phosphor. HP Z24x should have only 4 samples (WRGB).
RG_phosphor has more (20 = 5 displays as samples), only the last 4 are for an actual GB-LED (U2413). Replacing spectral data on all seems the easier approach.
Keep order as is: display 1 W, display 1 R, display 1 G, display 1 G, display 2 W, display 2 R….There is a tool, CCSS2EDR written in python, google. You cannot use it to generate EDR, since replacement does not work for CN and you have an actual EDR to copy from, but you may use it to forge an EDR for backlights not supported by vendor EDR like QLEDs on Benq SW (maybe it’s wise to interpolate to 1nm from user made 3nm CCSS first).
Also you can check EDR structure with it.Tried to look out for this HEX work, still not sure how I can do it..
But I installed that CCSS2EDR, and tried some conversion, I checked if I took RG_Phosphor_Family_25Jul12.ccss and compiled to EDR, I got binary exactly the same as original EIZO, so it works pretty well. No I think maybe I can try editing in text mode RG_Phosphor_Family_25Jul12.ccss and just change particular data that’s need to be changed, leaving all the headers, and other parts untouched. After compile it with CCSS2EDR, and then to try push to CN again, maybe it will take it.. as HP Z24x file has only 4 sets of data, and RG_Phosphor_Family_25Jul12.ccss has 20 sets, maybe that’s why CN is detecting patched edr file…
So if I understand correctly :
only the last 4 are for an actual GB-LED (U2413)
I have to change last 4 sets of RG_Phosphor_Family_25Jul12.ccss with 4 sets of HP_DreamColor_Z24x_NewPanel.ccss and leave 16 sets as it was in original file ?
No, unless CN is working with it in a special way. I1Profiler, Argyll and all other apps using EDR use ALL of the samples in one EDR file and makes a correction as a mix of ALL (root mean square). So if you want to forge it you have to replace ALL 5 samples with WLED PFS sample. Just repeat it.
