- This topic has 10 replies, 2 voices, and was last updated 1 year, 1 month ago by
.
-
Posts
-
When I used displaycal to validate color quality after calibrating with Spectraview II by NEC, I found no corrections fit for later validating calibrating with Spectraview II, they all yielded wrong white temperature. So I have a question: should I use spectrometer instead of my present colorimeter or do not believe Spectraview II’s calibrating result because of its not using corrections for colorimeters?
PA271Q is WLED PFS like current widegamut Eizo Coloregde counterparts.
Spectraview II lacks of WLED PFS EDR files, it only has a GB-LED sample for PA243W, hence ***WHITEPOINT*** calinbration is wrong. Some users reported in polish forum mva.pl that latest Spectraview II applied an XYZ -> XYZ matrix on top of EDR cprrection, but if true, as with any matrix correction, is taylor made for an specific i1d3 unit, not for all i1d3 colorimeter.
Also 10nm measurement from an Xrite specto may not be the best reference for a WLED PFS.So you can try:
-spectral replacement in PA243W EDR, and trust that mva.pl info is false, so this trick will work as it does for EIzo Color Navigator. You can use Eizo CG319X EDR available on Lift Gamma Gain and liked on several threads here. Search for Eizo EDR here, there shourl be a thread from 1 or 2 weeks ago. (close SVII try app first)
-Do your calibration in SVII as is, then customize post calibration till whitepoint & brightness matches ArgyllCMS/DisplayCAL measurement applying an AdoeRGB variant pf WLED PFS (like Eizo ones or the HPZ24X G2 bundled with DisplayCAL for i1d3)Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.Thanks in advance. But I don’t know about “spectral replacement in PA243W EDR”, since SVII have no option settings on itself, how can I apply pa243w EDR for my monitor on SVII? And “search for Eizo EDR here” I will have a try, but the same: when I found EIZO EDR, how can I apply it on SVII. And “close SVII try app first” I don’t know the meaning, try app? what app?
I have tried HPZ24X G2 correction on DisplayCal, its green beyond far from the marked position in the center on measurement after calibration with SVII, so do I believe the HPZ24X G2 correction setting? Is it fit for PA271Q condition?
I’m afraid that fixing these issues needs a minimum of computer user experience. If you do not know you may request thise to a local computer technician
Anyway, just in case:
1)Spectraview II install in it folders a set of EDRs. Corrections for i1d3. The one applied to LED widegamut is NEC_64_690E_PA242W_2013-02-28.edr.
It stores in binary format a GB-LED spectral sample for PA242W (2013) and some metadata.
-IF app is well designed you can place another EDR with the same name replacing this (make backup) so when SVII measures screen it will apply the contents of the new file. Done.
-IF app is not so well designed, or locked somehow on purpose it mat require headers and matadadta to match, rejecting an easy file replacement. That implies to replace ONLY spectral data of NEC_64_690E_PA242W_2013-02-28.edr with WLED PFS spectral data. Typical scenario for this means converting to text data CCSS using ARgyllCMS, replace spectral data in text which is easy 4 rows with WRGB spectral data on each row, then pack to binary using CCSS2EDR python tool (google)2) Eizo EDR samples here are:
-CS2731 “spectral replacement” of Xrite RG_phoshor, like option 1.2 above, bit for Xrite not that NEC file -> it actually replaces RG_phpshor.edr even if app checks headers (but not md5 or sha1)
-CG319X is a new one with its own metadata an headers. It works on apps that use Xrite SDK in a “fair” way, whithout checking for specific headers. Most apps that use EDR work this way.3) thet should be an spectraview II runing on background, accesibel from tray, next to date/time in windows taskbar. close it, replace EDR files, run SV2 again.
*IF* SV2 is applying that dirty hack of a correction placed on top of EDR correction like some people suggest on mva.pl forums… EDR replacement will not work and the best you can do to get a custom calibration is to run a post calibratin adjustment in SV2 ( to to manual) and tweak gains in SV2 user interface until a DisplayCAL measurement window with proper correction says it’s ok.
Photoshop won’t care about this alternative whitepoint (by “wrong” xy measurment of xy) stored in ICC profile.I have tried HPZ24X G2 correction on DisplayCal, its green beyond far from the marked position in the center on measurement after calibration with SVII, so do I believe the HPZ24X G2 correction setting? Is it fit for PA271Q condition?
does it looks white after tweaking RGB gains in SV2 to match WLED PFS in DisplayCAL? If not it’s likely that you did something wrong.
Also all your claims lack of actual data to appraise the measurement mismatch. DIsplayCAL reports help to visualize it.does it looks white after tweaking RGB gains in SV2 to match WLED PFS in DisplayCAL? If not it’s likely that you did something wrong.
Also all your claims lack of actual data to appraise the measurement mismatch. DIsplayCAL reports help to visualize it.I didn’t see certain tweaking RGB gains in SV2, do you mean the 6-axis color trim? I’ve used the HPZ24X G2 correction with displaycal as you suggested after calibrating with SV2 for validating the calibration result, the whitepoint deviated a bit large
does it looks white after tweaking RGB gains in SV2 to match WLED PFS in DisplayCAL? If not it’s likely that you did something wrong.
Also all your claims lack of actual data to appraise the measurement mismatch. DIsplayCAL reports help to visualize it.I didn’t see certain tweaking RGB gains in SV2, do you mean the 6-axis color trim?
I forgot that NEC software (and HW) is far more primitive than Eizo’s.
It is located as “custom whitepoint” (visual match) BEFORE calibrating.
Pag 17, use ArgyllCMS commandline meaurements (spotread, dispcal) or Displaycal and SV2 RGB gains on user interface (not in displaycal’s or monitor OSD)
So instead of aiming to D65 xy coordinates, which SV2 is going to measure wrong unless you correct (if possible) the EDR mismatch, you will aim to an alternative xy coordinate that measured with a good EDR/CCSS (from i1d3 bundle, from Eizo, from Community https://colorimetercorrections.displaycal.net/, CCSS ONLY, not CCMX) and DisplayCAL gives you D65.
As 1st approach RGB gains will give you a hint about SV2 error, save alt xy coordinates for white as SV2 preset an use it.
But if possible EDR replacement will be a more permanent solution. Also it will be more robust if you try to limit gamut (like sRGB) in SV2.I’ve used the HPZ24X G2 correction with displaycal as you suggested after calibrating with SV2 for validating the calibration result, the whitepoint deviated a bit large
Expected since SV2 measures wrong. 2-4 dE only in whitepoint is the kind of error bc colorimeter correction mismatch.
I’m using post calibration adjustment through monitor OSD’s x y coordinates of white to match the white level with HPZ24X G2 correction setting on DisplayCal, now validating whitepoint temperature is good. But using Eizo EDR replacement method yielded not so good result(see attachment below), so I choose the post calibration adjustment method.
You can request to NEC that allows to use a custom XYZ to XYZ matrix imported from a CGATS file, but SVII seems abbadonware.
AFAIK same request was sent to Eizo for CN7 and ignored too.It’s a shame for both. It is possible with some maths and debug output from ARgyllCMS to compute an XYZ to XYZ from a CCSS applied to i1d3 device (and only valid for that), without measurements. It woudl be a nice addition but they seem to ignore this feature for each software upgrade.
