- This topic has 12 replies, 2 voices, and was last updated 1 year, 1 month ago by
.
-
Posts
-
Hi, I have 2 laptops with a calibrated LG monitor. I do some photo and video work, but only as somwhat hobby and I don’t need to be super accurate.
I’m trying to match colors and whitepoint between 2 laptops and my monitor, I’m using i1DisplayPro.
The monitor is verified at 6500K.
As for laptops, from what I’ve read on this forum, it’s not good to adjust colors with GPU panel since it will conflict with 3DLUT.
One laptop is 100% P3 gamut, and I used potrait display’s software (that’s laptop’s offical one) to remap it to SRGB. The other one is a regular 100% SRGB screen.
(Edit: the potrait display’s software can use i1DisplayPro to calibrate, however it seems that it only calibrates color and my whitepoint is still off.)
The P3 one’s native white point is about 6900K, and the SRGB one is noticably greener and warmer.
I have 2 options now, one is to set whitepoint to 6504K in DisplayCal and let it somehow fix the whitepoint. Is it OK if I “force fix” move that much? 2 laptops 6504k looked very different, and they all different to monitor, even in verification it said the same.
Another option is to use visual white point, I have done that as best as I can, now they looked very similar, however in verification’s report the “Measured vs. assumed target whitepoint ΔE*00” is way off on both of my laptops. P3 laptop reports profile whitepoint XYZ 93.31, 100, 106.99, measured XYZ 93.46, 100, 107.1 . SRGB laptop reports differently but in the same fashion. The assumed whitepoint is 6600K daylight with XYZ 94.99, 100, 110.26. However to my eyes, whitepoint is almost the same between 3 screen. As for Delta E, they are result with a maximum of 1 and minimum of about 0.3-0.5.
Which option will give me the most reliable and accurate result? Thanks.
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.So after some researching, here’s my understanding :
Our eyes need to set a white point and know color corresponding that white, so the color calibration is to make sure you have accurate color at a specific white point.
Also, modern day display panel technology is different from each other’s so even we have the same XYZ values they can behave differently. The P3 laptop uses PFS WLED while SRGB uses regular WLED. They are all at the same xz, but one looks very different to the other.
If working with one display, there aren’t much worry since we see color based on a certain white point but when working with different monitors the difference can be somewhat apparent, especially comparing side by side.
So my question is, is it ok to use visual white point editor, and then get a report that failed at measured vs assumed? Or should I stick with the right one but looked differently? I read on this forum where people said it’s either because poor instrument or bad measuring, so it’s not something to be desired. My guess is ignore that since the whitepoint is customed to different backlighting and unified with eyes so pure numbers won’t work?
It’s likely to be simpler. Your MSI or lenovo with a limited Calman app fro calibration is VERY VERY likely to lack of the accurate EDR correction for i1d3 and that backlight. ‘Cause they don’t care if such calibration solution is working, nor do the online reviewers.
Measure un corrected measuremenst of RGB primaries and find the EDRs available to that calman lite app. Then you may guess if there is some portential valid EDR or not. If not, you’ll have to forge one… but it os not an easy task for unexperienced users. Search thread about CS2731 by Midas as an example.But lets say you skip that calman lite app from laptop manufecturer, only displayCAL. DisplayCAL can correct laptops white in GPU at the expense of contrast as you may know, but you need to provide the accurate CCSS for i1d3. Right now there are some sRGB only displays that use W-LED PFS phosphor variants becasue they are cheap…. so you need to find out which actual LED technology is used by each display. This stuff could be waaaaaaay more easy if those online reviewers filling lots of images with useless CALMAN generated graphs that contain no useful information plotted in a JPG actual spectral power distribution (SPD) of display…. but they don’t (likely because they do not actually know what they are doing).
And at last lets assume that there is no way to
-locate a suitabel EDR to that calman lite app, or forge one.
-find actual backlight type (SPD) of each display
the you’ll have to rely on visual whirepoint match.So my question is, is it ok to use visual white point editor, and then get a report that failed at measured vs assumed?
Yes you’ll have to ignore assumed vs measured and use relative white color transfomations, or absolute but to a modified prpfile with your numerical alternative white. For example making a LUT3D for DWMLUT you cannot use abs colorimetric transformations to a standard profile defined with D65.
Or should I stick with the right one but looked differently?
I’ll try to find if that calman lite has the accurate EDR (my guess is no, but it’s a guess) and try to find a suitable one if you find online such info or from native gamut readings.
Then i’ll try to find CCSS fro actual LED backlights of each display… that sRGB display may be not a traditional White LED.
And only after this or if you find it too cumbersome, do visual whiteopoint approach.
if visual mismatch is so high between displays is better to aim to an alternative visually matched white that to keep a white with a numerical measurement close to d65 (usually because unsuitable colorimeter correction.. although thery can be other causes) . Photoshop or any other imageediting tool won’t care since they work only with relative whitepoint transformations. They wont care if your visually matched white is 6100K and 6dE from daylight curve, image 255 white will be rendered as calibrated display 255 white, no matter what are their values.
ONly if you need a LUT3D remember that you cannou use absolute colorimetric AND a source colorspace with D65 (you need to use relatibe whitepoint or an alternative source colorspace with your numerical/measured white instead D65)Thank you for your detailed reply!
I’m using MSI, the True Color app is only for gamut change. From what I know, display calibration isn’t going to let you change color gamut, so maybe that app is the only reliable option to display SRGB. However the app is very lackluster of calibrating, since you can’t change anything when calibrating and it calibrates only at maximum brightness. I use that app to change my screen to SRGB, and then use DisplayCal to calibrate. The panel is AUO B160QAN02.P from what I remember, I checked Colorimeter Corrections Database and there’s only K, L, Q, M which are 165hz and miniled models. So there’s no corrected for my panel, either I’m going to choose the WLED PFS, or either I have to buy something and figure it out myself?
Another laptop I’m using is just a Dell with 100%SRGB display so there’s nothing to change before calibration. The panel is SHP14AF which I can’t find anything about it, but from panelook.com I found all 13.4 related sharp displays are the same WLED so I guess it’s WLED as well?
I’m relative new to this, sorry for dumb questions. The reason I choose my MSI as Dell’s reference is because after True Color’s SRGB remap and displaycal’s calibration, it looked very similar to my monitor which has hardware RGB controls. So that means, I should keep MSI as it is now, calibrated with WLED PFS Family, and use visual whitepoint editor on my Dell, with WLED Family to match them?
Also for my MSI should I use the 99%P3 that said Macbook Pro or just the family?
If there is no review and no CCSS in database and you cannot get/rent a spectrophotometer… you’ll have to guess by year and RGB primaries. For the reasons you wrote, your guess of CCSS seems OK for me
Also for my MSI should I use the 99%P3 that said Macbook Pro or just the family?
If it is a WLED PFS (no QLED variant), guess its flavor by RGB primaries coordinates, measured or from EDID data. If that MSI is AdobeRGB 96+% use HP Z24x G2 CCSS.
Thanks. My msi is not 96%+ AdobeRGB so I selected the PFS Family. Now I’m just trying to match my Dell with visual whitepoint editor as close as possible.
Ok, so I tried visual whitepoint match on my Dell, Just to check, although I know MSI is WLED PFS,
Dell is WLED, selected in DisplayCal and set them to the same xz whitepoint, they looked different. This is normal because different panel backlight technology right? The correction is just a universal one, not specific for my panel as the spectrum can be different so it won’t perfectly match each other, even with correction selected right?
With visual whitepoint editor, I get very close results to each other. Although CCT isn’t going to represent that much, but after adjusting it still reports 6548k which looks fine. However the assumed vs measured is at 6.18 which is not OK, but I should ignore because I’m using visual whitepoint Editor right?
Just check my fish brains a bit:
-If I have the tool to measure and create spectrum correction for my 2 specific displays, when setting to exactly the same xz it should look exactly the same
-If I use DisplayCal’s WLED PFS Family and WLED Family, it won’t match perfectly between 2 displays, but somehow can make a more accurate measurement (I tried different ones and indeed the whitepoint in interactive adjust menu is a tiny bit different)
-When using DisplayCal’s profile as above, because I cannot get the exact same whitepoint, so I use visual whitepoint editor to make them visually close, so in the report I should ignore assumed vs measured delta.
Are my thoughts right?
Ok, so I tried visual whitepoint match on my Dell, Just to check, although I know MSI is WLED PFS,
Dell is WLED, selected in DisplayCal and set them to the same xz whitepoint, they looked different. This is normal because different panel backlight technology right? The correction is just a universal one, not specific for my panel as the spectrum can be different so it won’t perfectly match each other, even with correction selected right?
NO. It is beacuse you lack of the appropiate equipment (or source or sample) for correction of your i1d3 AND/OR because your eyes differ from the model of human vision (std observer) hence there may and will be an statistical error.
The panel does not give you colors, is the backlight LED. The different backlight LED techonologies ARE NOT the source of missmatch for a tricromat observer (there will be some matching but different SPDs)… the source of mismatch is the inaccuracies of your device and the lack of “knowledge” (spectral power distribution sample, CCSS, or a reference device to create “offset/matrix” corrections) AND/OR YOUR statistical deviation from a “MEAN” / “MODEL” of human vision.
So it’s not because teh different LED, it’s because the device (or its correction configuration) and/or because the observer (you).
With visual whitepoint editor, I get very close results to each other. Although CCT isn’t going to represent that much, but after adjusting it still reports 6548k which looks fine.
once you go to visual match CCT is meaningless. Even matching numerocally CCT is meaningless since that coordinate lack of green-pink axis with usually is the most “ugly” mismatch.
However the assumed vs measured is at 6.18 which is not OK, but I should ignore because I’m using visual whitepoint Editor right?
Yes, ignore it, and do not create LUT3Ds with absolute colorimetric intent to D65 colorspaces.
Just check my fish brains a bit:
-If I have the tool to measure and create spectrum correction for my 2 specific displays, when setting to exactly the same xz it should look exactly the same
Not guaranteed: spectrophotometer may be unable to measure properly that SPD by low resolution, or by noise, or by wavelength misplacement.
Also even with perfect equipment your statistical deviation from a “mean”/”model” of human vision may cause a mismatch.So you play with those 2 uncertainties: device acuracy and your statistical deviation from a modeled human vision.
In your specific case:
DEVICES:
-(know to be true) lack of custom and accurate CCSS samples for each LED type on each display
-(statistic, costs) mismatch between actual i1d3 filter behavior and filter behavior measured at factory and stored in firmware (CCSS LED type sample + firmware filter behavior => individual device correction)
VISION
-(statistic) how far YOU are from one standard observer (typicsal CIE 1931 2 degree the most common or CIE 2012 2 degree).
Although you can calibrate to CIE 2012 2degree and measure via log window (or commandline in ARgyllCMS) , HTML reports in displaycal use CIE 1931 2degree-If I use DisplayCal’s WLED PFS Family and WLED Family, it won’t match perfectly between 2 displays, but somehow can make a more accurate measurement (I tried different ones and indeed the whitepoint in interactive adjust menu is a tiny bit different)
-When using DisplayCal’s profile as above, because I cannot get the exact same whitepoint, so I use visual whitepoint editor to make them visually close, so in the report I should ignore assumed vs measured delta.
Are my thoughts right?
Yes.
Sorry for another dumb question here if you are still here:
I have reset the MSI True Color and I found some defect on my original install. Now it looks different by default, but the SRGB profile is way too cold. DCI-P3 is significantly warmer, which I guess is calibrated by MSI.
There’s a custom panel that you can select SRGB or P3 and RGB value stuff, which I don’t know if that works exactly same as Intel’s iGPU panel, but I created a measurement report based on default SRGB profile, it’s bad on everything. However if I manually use that True Color’s RGB setting (really extreme thats like -1R,-2G ,-12B), match that to 6500K, surprisingly it gives me an OK result will everthing falls in green! (Not as good as DisplayCal calbrated but still Delta E maximum is below 2)
Also, I have corrected the white point to 6500K with DisplayCal with native whitepoint in SRGB, and white point result looks very much the same as I changed in True Color’s custom panel. In measurement report, I get better color accuracy.
The laptop should be color calibrated from the factory, but I don’t know if it’s saying DCI-P3 mode since the default SRGB profile is way too off. Should I live with True Color’s custom panel, or leave it very cold and then force to 6500K in DisplayCal? Either way it’s gonna change a lot so maybe there’s a big contrast loss, but I wonder which way is better. From what I’ve read in this forum, it seems DisplayCal has a better way to handle this than drivers from manufacturer?
Sorry for another dumb question here if you are still here:
I have reset the MSI True Color and I found some defect on my original install. Now it looks different by default, but the SRGB profile is way too cold. DCI-P3 is significantly warmer, which I guess is calibrated by MSI.
There’s a custom panel that you can select SRGB or P3 and RGB value stuff, which I don’t know if that works exactly same as Intel’s iGPU panel, but I created a measurement report based on default SRGB profile, it’s bad on everything. However if I manually use that True Color’s RGB setting (really extreme thats like -1R,-2G ,-12B), match that to 6500K, surprisingly it gives me an OK result will everthing falls in green! (Not as good as DisplayCal calbrated but still Delta E maximum is below 2)
Then it should not be bad on everuthing, just in whietpoint.
Also, I have corrected the white point to 6500K with DisplayCal with native whitepoint in SRGB, and white point result looks very much the same as I changed in True Color’s custom panel. In measurement report, I get better color accuracy.
Because you did not change whitepoint in DisplayCAL, just corrected grey (if it needed) and made a custom profile (like a taylor made suit) storing actual sRGB mode behavior.
It DOES NOT mean that matches sRGB, just that your taylor made suit matches display behavior.The laptop should be color calibrated from the factory, but I don’t know if it’s saying DCI-P3 mode since the default SRGB profile is way too off.
Calibration needs a “target” to mimic and most factory calibration claims jsut give a MEAN error (so hitepoint can be worse than mean) under some X dE to an unknown target.
Should I live with True Color’s custom panel, or leave it very cold and then force to 6500K in DisplayCal? Either way it’s gonna change a lot so maybe there’s a big contrast loss, but I wonder which way is better. From what I’ve read in this forum, it seems DisplayCal has a better way to handle this than drivers from manufacturer?
I would try to fake/forge/inject the EDR equivalent of the CCSS you used in DisplayCAL into that “calman lite” app for HW calibration. Read CS2731 thread by Midas.
That will fix white MEASUREMENT (measured vs profile whitepoint), but that portrait display app may make lots of oversimplifications so resulting white and grey may be off, like laptops that whose WP varies too much with brightness slider or uncalibrated bad grey color (bad a*b* range).
You’ll have to test or provide HTML reports (file, not captures) of these steps to find where MSI app is not behaving as it should.I would try to fake/forge/inject the EDR equivalent of the CCSS you used in DisplayCAL into that “calman lite” app for HW calibration
I would like to but it’s not something I can do. The app is indeed oversimplified, it’s literally one button calibration and I can’t find edr or ccss anywhere, so nothing I can change and I have to rely fully on it’s own. So I didn’t use that to calibrate, but that’s the only way I can use SRGB emulation on the laptop, otherwise it will be in P3.
So I set to SRGB in that app and then calibrate in DisplayCal. If I also set RGB sliders (which maybe I shouldn’t), and don’t calbrate at all, then measure uncalibrated in DisplayCal, I get everything even assumed vs measured OK. If I leave RGB sliders to 0 and set 6500k in DisplayCal, then calibrate in DisplayCal, I get similar visual and also eveything OK report.
I usually don’t change anything but SRGB emulation in MSI app, so there’s nothing in there I guess. Anyway, after either way, it looks very like my monitor which has hardware RGB control and calibrated, although a bit more reddish (maybe just very very slight that I have to stare at them together). Also used visual whitepoint on my Dell, although can’t make them 100% matched but pretty close now. On my Dell I just found I can’t get the white exactly match, the reason is the laptop’s panel change color temperature with different angles or even from one side to another side, which is very bad but I have to live with.
I would try to fake/forge/inject the EDR equivalent of the CCSS you used in DisplayCAL into that “calman lite” app for HW calibration
I would like to but it’s not something I can do.
Right click on desktiop shourtcut and if it is not some store-like app yopu’ll be able to navigate to installation folder. In that instalation folder with some subfolder manual search you’ll find the EDRs.
Once found and with some educated guess about wich one it is using you can try to measure using the CCSS equivalent of that EDR. This wil test if “even using wrong EDR” that MSI apps fail or do not fail to meet calibration target. If it meets calibration targert under some aceptable error, then EDR “forging” is possible. It it fails oatching MSI app with an accurate EDR will be pointless.
