- This topic has 77 replies, 6 voices, and was last updated 2 years, 11 months ago by
.
-
Posts
-
The reason you focus on 10nm PFS is because the relatively wide, as compared to 1nm, spectral sampling internal is not tight enough to capture the peakiness of the primaries for that red/blue LED tech, so the effective response is attenuated and leads to an under-measure, and attendant bias — color cast, lumpy correction, etc?
Or over-measure. SPD is not equal to CIEXYZ, SPD multiplied by std observer & integrated is CIE XYZ. Std. observer acts increasing or decreasing weight.
If I follow your writeup, you are strongly implying that per-device variance within a class is a problem,
On CCSS/EDR it is not a problem, since device stores its response (call it its own deviation from whatever observer).
That’s why Xrite designed i1d3 that way:
-stable non fading filter
-per unit (or per batch) spectral response in firmware
=>
You only need to distribute sample display SPD and device software will autocorrect itCCSS are portable between i1d3, CCMX are not likely to be.
Custom CCMX made by you on your devices always have been an alternative for you, call it “universal colorimeter correction”. Since it’s just for YOU, portability is not an issue.
which brings us to a distinction between consumer-class devices, which we can accommodate locally to make workable alignments, and reference-class devices, which support a chain of trust and allow us to compare devices. IOW, the average consumer, me, Marcel, may think we are buying a sort of reference (the colorimeter) that lets us compare our displays, but we are just buying a link in a chain of trust. The ordinary user faces uncertainty about how well his instrument (probe) matches a class of displays based on illumination and the correction is a way to try to handle this uncertainty, but without a solid chain of reference, in the case you describe, the weak link is i1Pro2 low sampling interval for the peakiness of PFD, you can end up with a lacking overall alignment (in comparison to…?) in spite of the ordinary user thinking he is appealing to accuracy by referring to a spectrophotometer. Basically, the informed user has to be aware of the chain of trust in references and avoid clinging to certain over-simple assumptions about how devices play together.
In the post Marcel referenced from Florian, I think Florian responds by saying that internally you end up with a 3×3 correction matrix whether you get there via a CCMX or the internal processing of the colorimeter firmware and CCSS.
The key being to get the combined device response into the domain of the standard observer well enough to make the whole rest of the model work.
This makes me wonder what the eye does with extremely narrow band stimulus and how the tristimulus model copes with extremely narrow-band tech like lasers?
Huge inter person variance. Laser primaries on device (100% Rec2020) is mostly useless. Rec2020 as encoding colorspace is useful, as ProphotoRGB.
Google RIT 7 led prototype (RGB signal in => LUT => 7 LED display = low varience between human observers)
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.If I follow your writeup, you are strongly implying that per-device variance within a class is a problem,
On CCSS/EDR it is not a problem, since device stores its response (call it its own deviation from whatever observer).
That’s why Xrite designed i1d3 that way:
-stable non fading filter
-per unit (or per batch) spectral response in firmware
=>
You only need to distribute sample display SPD and device software will autocorrect itCCSS are portable between i1d3, CCMX are not likely to be.
Custom CCMX made by you on your devices always have been an alternative for you, call it “universal colorimeter correction”. Since it’s just for YOU, portability is not an issue.
Correction: it is not a problem if device firmware data is accurate and close to std observer ( = i1d3). That was the issue with Spyder 4 & 5 poor hardware.
The current fault from Datacolor is that now they have an stable and more or less accurate HW in SpyderX (close design to i1d3), they have no spectral correction support… so, it’s not future proof (or even “past proof” for an UP2516D). Ironic…SpyderX Pro on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.The reason you focus on 10nm PFS is because the relatively wide, as compared to 1nm, spectral sampling internal is not tight enough to capture the peakiness of the primaries for that red/blue LED tech, so the effective response is attenuated and leads to an under-measure, and attendant bias — color cast, lumpy correction, etc?
Or over-measure. SPD is not equal to CIEXYZ, SPD multiplied by std observer & integrated is CIE XYZ. Std. observer acts increasing or decreasing weight.
In sense that peakiness is not sensed by eye. Re standard observer, got it. The functions are perceptual weights applied to workable primaries (at the time). Today’s emitters and sensors must be further tuned to fit the model.
If I follow your writeup, you are strongly implying that per-device variance within a class is a problem,
On CCSS/EDR it is not a problem, since device stores its response (call it its own deviation from whatever observer).
That’s why Xrite designed i1d3 that way:
-stable non fading filter
-per unit (or per batch) spectral response in firmware
=>
You only need to distribute sample display SPD and device software will autocorrect itIs this stored response compensation per device, per batch, or per generation?
CCSS are portable between i1d3, CCMX are not likely to be.
Custom CCMX made by you on your devices always have been an alternative for you, call it “universal colorimeter correction”. Since it’s just for YOU, portability is not an issue.
The point of transportability is well taken.
which brings us to a distinction between consumer-class devices, which we can accommodate locally to make workable alignments, and reference-class devices, which support a chain of trust and allow us to compare devices. IOW, the average consumer, me, Marcel, may think we are buying a sort of reference (the colorimeter) that lets us compare our displays, but we are just buying a link in a chain of trust. The ordinary user faces uncertainty about how well his instrument (probe) matches a class of displays based on illumination and the correction is a way to try to handle this uncertainty, but without a solid chain of reference, in the case you describe, the weak link is i1Pro2 low sampling interval for the peakiness of PFD, you can end up with a lacking overall alignment (in comparison to…?) in spite of the ordinary user thinking he is appealing to accuracy by referring to a spectrophotometer. Basically, the informed user has to be aware of the chain of trust in references and avoid clinging to certain over-simple assumptions about how devices play together.
In the post Marcel referenced from Florian, I think Florian responds by saying that internally you end up with a 3×3 correction matrix whether you get there via a CCMX or the internal processing of the colorimeter firmware and CCSS.
The key being to get the combined device response into the domain of the standard observer well enough to make the whole rest of the model work.
This makes me wonder what the eye does with extremely narrow band stimulus and how the tristimulus model copes with extremely narrow-band tech like lasers?
Huge inter person variance. Laser primaries on device (100% Rec2020) is mostly useless. Rec2020 as encoding colorspace is useful, as ProphotoRGB.
Google RIT 7 led prototype (RGB signal in => LUT => 7 LED display = low varience between human observers)
I took your advice and found these articles:
Variable Led Hemispherical Imager – Rochester Institute of Technology
http://edge.rit.edu/edge/P11543/public/Tech_Paper1.pdfSo moving beyond RGB emitters to more complex constellations with more stable observer response?
This next one is just fun to see hobbyists reinventing color displays!
RGB LEDs: How To Master Gamma And Hue For Perfect Brightness
RGB LEDs: How to Master Gamma and Hue for Perfect Brightness
You can use std GB-LED CCSS (U2413) rather than user made CCSS for PD2720U. It had bumps in red, maybe its true, maybe it’s other users device malfunction / wrong operation / dirt.
Okay I think Im picking up what you’re putting down haha.
I just tried the ccss you mentioned and it does look better then the user submitted one. Thanks! I’m at 92% DCI-P2, 99.9% SRGB and 99.8% Adobe RGB now. Is there a difference between the “GB-r-LED IPS (Dell U2413)” correction and the “GB-r-LED/RG Phosphor LED Family (AUO B156HW01 V.4, Dell U2413)” Correction? Both look about the same. Maybe slightly less red in the 2nd one.
I’m still curious about what loose standards BenQ might be using to get their numbers though. So I was just messing with more settings and found if I set monitor to native 7500k white, use that CCSS, disable all the calibration settings, it reports 93.1% P3 but adobe goes down to 99.1%, but then when I am looking at the profile information page and choose adobe rgb comparison profile the results are all outside the dotted line, so you would think it would be 100%. However it does show the measured whitepoint is a a little ways away from the profiles whitepoint. But then when you change rendering intent from “absolute chromatic” to anything else, now the image looks more representative of the 99% because a couple parts of the results are now inside the dotted line and the whole result appears to be shifted to match the white point of the profile. I wonder if they are basing their specs on what that absolute chromatic image is showing with the wrong whitepoint and not on what people would actually be using, to gain a few extra %. Any way to calculate percents based on what is being shown in that absolute chromatic view?
I attached pics of what I’m talking about.
“GB-r-LED/RG Phosphor LED Family (AUO B156HW01 V.4, Dell U2413)” is “GB-r-LED IPS (Dell U2413)” plus other non GB-LED samples. “GB-r-LED IPS (Dell U2413)” is a cleaned version. Should be little to none difference. The uncleaned version is teh one distributed by Xrite for i1Profiler and SDK compatible software with EDR support fro GB-LEDs: Dell, Viewsonic, not sure about HP, latest Eizo Color Navigator…
Comparisons must be done in 3D, visually or with “.gam” for % generation. A trick for getting better % anyway. Just focus on dE distance to the RGBCMY to your desired colorspace, if it’s fine… then it’s fine. And if its a GB-LED 91-3% is an expected value. Backlight SPD won’t be able to offer more.
Thanks for this thread, I think this could help me a bit. It sucks because I created a topic about my measurements and after nearly 4 weeks it still says: Awaiting moderation… is this normal here?
I don’t think that’s normal. This thread was my first and only post and I didn’t have to wait for any moderation.
What issue are you having?
@Marcel oh thanks for your reply!
I’m using my i1 DisplayPro more than 1 year and had no issue at all. But since to the mac OS update to 11.1, I cannot get my display calibrated (I know you are on windows but maybe you can have a look at my settings). A lot of people have issues with their external displays and I was forced to switch from DisplayPort to HDMI. So that is why I’m not really sure if it is because of macOs or just my settings…
I am in a similar boat as you. I create videos for Web.
This was before the macos update:
And since the update, I cannot calibrate my display anymore…
I always get these terrible results. Of course I don’t know what 98% of that means, but I guess red is always bad ????
I’m no expert on settings. I’d try using the “SRGB” preset under settings to reset everything back to default. Then for output levels choose “Full Range RGB 0-255” then for correction choose a “Spectral” one for your display rather then “Matrix”. According to the pro, matrix corrections can’t be used unless you created them yourself. Under “Calibration” tab, set your white level back to custom and tone curve to gamma 2.2. Under “Profiling” tab I bump up my patches slider 1 notch to 425. Those are the only settings I change in all the tabs, everything else is left to what ever it defaults to. Then I let it do it’s thing.
As for verification, all I can tell you is make sure simulation profile is unchecked.
With all that said though, if you had it working fine before latest mac update and now it isn’t working after the update, my guess would be apple changed something and displaycal maybe needs an update to be compatible with latest mac version?
I really appreciate your help @Marcel!
I tried my best and used your settings, but nonetheless, I got horrible results and I just don’t know why… Maybe it’s the mac update or maybe my calibrator is broken?
There are my results:
Maybe your HDMI adapter is sending unexpected signal format. I’d say that looks like an OS configuration issue.
Did you change OSD settings between december 2020 calibration and January 2021?
If not, switch to DisplayPort, assign in ColroSync old profile and run a measurement report with the same setting (same wrong CCMX, no simulation profile, etc).Also use latest ArgyllCMS executables for macOS, just in case (2.1.3 beta)
Good morning @Vincent and also thank you for your reply!
I try to summarise what happened between December and January:
- Apple released it’s macOS 11.1 that unfortunately resulted to external monitors issues. Not every monitor has these issues. You can read about it here.
- This resulted that my monitor could only run on 30Hz with DisplayPort.
- I have switched to HDMI to USB C cable to get my 60Hz back
That’s it! The only thing that I have change on my OSD settings are that my monitor is using DP 1.2 not 1.4 because with 1.4 you could not even get 4k resolution (thanks to the update…). And obviously, I have changed the RGB colours to match my set white point D65.
Unfortunately, I’m not home today, but your tips could maybe help me out.
I’m going to try to calibrate my monitor with DisplayPort and then switch back to HDMI (that should work out right?)
And if not I’m trying to get the latest ArgyllCMS executables.
The author of Argyll CMS has recently said on his forum, pertaining to development process, Apple M1 silicon support and changing APIs, that for efficiency and best support he targets older supported MacOS.
And because MacOS 11 attends to big architecture changes in Macs and corresponding API changes, some stuff (relatively minor) breaks when running Argyll in Rosetta2 (Intel compatibility) mode. As Argyll developer does it single-handedly, working on a shoestring budget for his community of users, he’s not jumping to acquire an M1 for testing, and Apple (even with a trillion bucks or so laying around) long ago stopped being a company that practices community support. Apple doesn’t support its community. Today, the community supports Apple!
The problems you are seeing with MacOS 11 *might* (or might not) be an API change that needs a fix from the developer, with the developer not yet caught up.
However, as you have stated, Apple itself is breaking display support with current releases, so the right first step for support is with trillion-$$ Apple, not with developers of small package of free SW, which somehow just so happens also to be best-in-class application up against very well funded private offerings.
I use Macs but, it’s too old for MacOS 11 and DP over Thunderbolt, so I can’t check any of this myself. So it looks you at the moment you carry the mantle of looking into the problem, accessing the logs, piecing together an explanation, and getting the info into the community to help others.
As this is not a commercial support site you can usually find helpful support here 🙂 In this case you may have to pitch in. Search the forums for how to troubleshoot via logs etc.
I think the log data are placed in the support folder created for the device session alogn with the measurement data. You can locate this data using the little folder icon for your specific DCal session. Or you can run Argyll by hand from the command line and look at its logs. Argyll is well-documented by its author on web.
I don’t have these precise details handy, or I would include them.
Other will want to know what you learn!
/wire
@wire Hey so thank you for your long long reply! I really appreciate every answer.
I still use a MacBook with Intel inside. So this shouldn’t be the problem, right? However, switching back to MacOS 10.X is also not an option anymore.
However, I made some little progress!
I have switched the cables to DisplayPort and finally, I get good values for my Measurement Reports again! (Check out the attachments)(Average ΔE*00 of 0.45). But I cannot use DisplayPort for work (because of the above-mentioned display issues).
Does anyone know why I don’t get these numbers with my HDMI cable?
And but still, why is my gamut coverage still so bad? (Look at my second attachment)
I have to say that I’m still a bit confused! As @marcel stated at the beginning of this thread that the “benq pd2720u is advertised as 100% SRGB Coverage, 99% Adobe RGB coverage and 96% P3 Coverage”. I understood that P3 Coverage is not correct. But 83.9% sounds super low for me.
@wire Hey so thank you for your long long reply! I really appreciate every answer.
I still use a MacBook with Intel inside. So this shouldn’t be the problem, right? However, switching back to MacOS 10.X is also not an option anymore.
However, I made some little progress!
I have switched the cables to DisplayPort and finally, I get good values for my Measurement Reports again! (Check out the attachments)(Average ΔE*00 of 0.45). But I cannot use DisplayPort for work (because of the above-mentioned display issues).
Does anyone know why I don’t get these numbers with my HDMI cable?
Check which color format is output through HDMI, try to match it in input format in display.
And but still, why is my gamut coverage still so bad? (Look at my second attachment)
I have to say that I’m still a bit confused! As @marcel stated at the beginning of this thread that the “benq pd2720u is advertised as 100% SRGB Coverage, 99% Adobe RGB coverage and 96% P3 Coverage”. I understood that P3 Coverage is not correct. But 83.9% sounds super low for me.
PD2700U is sRGB. ONLY sRGB. A very good one for its price I must add. All seems fine in your calibrated display (through DisplayPort)
PD2720U is the low cost AdobeRGB version (PG > SW > PD > BL …). It’s a different model with different price.
