- This topic has 6 replies, 2 voices, and was last updated 6 years, 5 months ago by
.
-
Posts
-
Since I don’t have a spectrometer I’m trying to adjust this Dell GBr-LED correction for use on an Eizo CS2730. I’ve read it has to have the last four lines deleted for that purpose but have no clue as to which lines are the ones to delete. I’ve attached the css file in question.
AFAIK Xrite’s bundle of Spectral Power Distribution may be copyrighted. You should not upload them here.
DisplayCAL (actually ArgyllCMS) allows you to convert and use Xrite’s SPD contained in EDR files, being that EDR files contained in Xrite setup program, which can be downloaded for free.
That’s is a little different from “public distribution” of CCSS with that SPDs.*****
Now, your answer. U2413’s SPD is the last four series, so you should:
-delete the other ones
-re-numer each undeteled row (U2413’s) from 1 to 4 instead of 10, 11, 12… or whatever number they have.
-Set the total number of avaliable rows to 4.
Then you have a clean U2413’s GB-LED CCSS… but you do not need it:
This one is free, it’s a full gamut GBLED-like without smaller gamut emulation and it’s almost the same than Xrite’s, perhaps a little bigger gamut in green.
Hi Vincent
Thanks for the reply!
I already have the CS2420 file and it says it is for a WLED. When I open the file it has a line: TECHNOLOGY “LCD White LED. The file I attached in my first post has the same line except it uses GBr insted of White: TECHNOLOGY “LCD GBr LED”. It also has this line: NUMBER_OF_SETS 4, BEGIN_DATA So is that the line that should be at 4? If so the file seems to have already been corrected. I have the i1Display Pro and not a ColorMunki and have tried the CS2420 CCSS but it gives different results than the GBr file.
The problem I’m having is in the verification test using the GBr file the assumed White Point is always 200K higher than the profile being verified. For example if the profile has a White Point of 6000K then with the GBr correction the assumed White Point is 6200K. I hope this is a clear explanation of the problem.
My monitor is an Eizo CS2730
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.First of all, CS2420 CCSS is from a GBLED… it’s a text file. Take its data and render it in a graph. Two led spike plus broad red phosphor emision.
And that’s the same as the last 4 lines from Xrite’s RGPhosphor EDR.Second, as explained may times by a lot of people (like Florian or andrew rodney “Digital Dog”), color colorrelated temperature is a meaningless term to determine a measured white point. Use color coordinates and dE00 formula.
“Measured” it’s not “Assumed”.Unless you have an i1DisplayPro with an observer too far away from CIE 1931 2º, CS2420’s CCSS and a “cleaned” version (and even uncleaned) of Xrite’s RGphoshor should measure almost the same white ( <3dE differenece between “MEASURED” white coordinates).
Third if you take a “raw” RGPhsophor GBLED, you have in NUMBER_OF_SETS more than 4.
Then you keep just the last 4 rows, “re-number” them from 1 to 4, update “NUMBER_OF_SETS whatever” to “NUMBER_OF_SETS 4” and you are done.I thought that you have edited a raw CCSS from ArgyllCMS’ Oeminstall, built form Xrite’ EDR, then you uploaded it. My apologies for my mistake if you downloaded it from DisplayCAL correction database.
IDNK what if your uploaded file is right or wrong, but the steps shown before are a way to get what you seek from Xrite’s pack of spectral corrections.Last one, Xrite’s sample EDRs are not SPDs which color coordinates are D65, or D50.
It’s should not matter and its easy to get a transformation in which each channel multiplied by a real number gives you an SDP with D65 white coordinates.
I think that Xrite’s U2413 sample was near 5800K at 10dE from daylight locus towards cyan.It should not matter for ArgyllCMS computed correction, just keep in mind if you render that SPDs to see that my linked CS2420’s CCSS is actually a GBLED like the one from Xrite.
Thanks for the reply.
A couple of things I find confusing:
- In the text of the CS2420 file has a line: TECHNOLOGY “LCD White LED” which is different from the same line in the GBrLED file: TECHNOLOGY “LCD GBr LED”. This difference is confusing to me. It doesn’t help that Eizo refuses to reveal whether the CS2730 is GBr or WLED. Whatever the technology is I’m getting better results using the CS2420 file.
- I’ve discovered that in the Color Navigator program (here after CN) the xy coordinates for the whitepoint at a color temp of 6500K are different than the xy coordinates for DisplayCal’s Verification Report (Attached). For example setting CN at a Wht Pt of 6500K results in an xy .3129 , .3293 6490K which is correctly reported on the line Display Profile Whitepoint of the Measurement Report (here after MR) the color temp being slightly different at 6488K. The line Measured whitepoint of the MR reads xy .3076, .3257 6822K making the line Assumed target whitepoint 6800K. Am I to conclude that CN is actually in error by 332K on the Wht Pt setting in any given calibration? Or might this error be caused by not having the right correction for the i1Display Pro colorimeter in DisplayCal?
Thank you for for any help with this dilemma!
1- CS2420’s CCSS is a GB-LED, 100% certain. Render it, see it by yourself.
“LCD White LED” is a text description mabe BY UPLOADER. Uploader could have set “cute rabbits with ribbons” in text description….and it would be a GB-LED too.2- You set “6500K” as “target” for CN. CN did its stuff with whatever colorimeter correction it uses and calibrated monitor. After calibration, it measured the monitor to build ICM profile, IN THAT stage CN measured “xy 0.3129 0.3293 (XYZ 95.03 100 108.63), CCT 6488K”. This is what it is stored in ICM profile.
“Target” for calibration is one thing and “result” (or profile white point) is another thing. I mean that CN does not say that “6500k” is equal to “xy 0.3129 0.3293 (XYZ 95.03 100 108.63), CCT 6488K”. One is what you wanted, the other is what you got.It may be even possible for calibration software to take some kind of idealized behaviour as “true” in order to simplify (or cheat) color management and avoid some rounding errors. For example TRC, I’m pretty sure all high end monitors build profiles with 1xTRC taking grey neutrality as granted (and they are) without actual “double check”.
Now to the core of your question, all this stuff and measured are taken with “whatever correction CN applies to your i1DisplayPro”.
Since you use a different correction for DisplayCAL (because CN corrections are unknown, unless you see some EDR in CN folder) that two measurements could get difrerent results.
Which is better?
Since CS2420’s is a GBLED, CS2730 looks 99.999% like a GB-LED (gamut, contrast and DCI-P3 coverage) and DisplayCAL/ArgyllCMS are reliable software… I believe that CN “fails” in its measurents and that “xy 0.3076 0.3257 (XYZ 94.43 100 112.6), CCT 6822K” is very close to “reality”. BUT… it’s white (low dE to assumed WP), just a little cooler than D65, but “white”, it should look “white” (no pink no green)
IDNK what results you get with Xrite’s RGphosphor EDR (“cleaned to just GB-LED” or not) but I would say that if you run a MR with RGPhosphor correction “measured white coordinates” will be not too far (<3dE) from “xy 0.3076 0.3257 (XYZ 94.43 100 112.6). I mean you cannot say “I’m getting better results using the CS2420 file“. That is not true unless your i1DisplayPro observer curves are far off from CIE 1931 2º and your particular device is highly innacurate (very unlikely).
The key point is “why” does CN use whatever corrections they use instead of EDR (Xrite’s SDK) or CCSS (argyll like approach… which is the same but with text files).
Does CN use a generic matrix correction for all CS GB-LED series? That would be a wrong practice, matrix corrections are made for a specific colorimeter unit and monitor which could not have the same behaviour as yours.
On the other side, spectral corrections (EDR/CCSS) read “colorimeter observer” from its firmware, read a “sample” spectral power distribution for a display type (like those 2 corrections: CS2420 and “cleaned” RGphosphor, they are almost equal) and then compute a correction for THAT particular colorimeter, your your particular unit. As long as colorimeter observer is close to CIE 1931 2º observer and “colorimeter observer” data from factory is accurate (and all kind of i1D3 reviews point to that), then EDR/CCSS trick works like a charm.
This is why I truly believe that in your situation CN is faling to measure your display “in the best way we can do it” , hence “xy .3076, .3257 6822K” is “REAL” or close to real.
But since its “white” (I mean no color tint, just a little cool), and grey calibration is flawless… I would not over think about your problem, even less since it looks like an sRGB emulation.
Just use it and make sure that Eizo knows this kind of problems with their software, otherwise it could not be solved.
