- This topic has 62 replies, 4 voices, and was last updated 1 year, 5 months ago by
.
-
Posts
-
I bought myself a ColorChecker Display to calibrate my 2 monitors to be identical, but no matter what settings I try, it always seems to be off color wise by the same amount. I own a XF270HUA and a XV272UX, one with normal WLED and the other with PFS WLED. I have checked multiple times that I select the correct settings as well as tried using online presets for these particular monitors. I also tried using bigger test cycles with 5000 color fields but nothing changed the results. When I calibrate both so sRGB and set the ICC profiles system wide with novideo_srgb (also tried windows native and checked in working applications), there is still a color mismatch. On the XF270HU, reds seem more intense, blues are brighter and greens are more yellowish.
Is there a way I can actually make them match? Also how do I know which one is accurate or even if one is accurate?
Calibrite Display SL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.A) Does white match? If not, wrong corrections for those displays. Visual whitepoint match
B) Does both displays cover simulated colorspace? some WLED are 9x% sRGB coverage, hence OOG colors will look different. Check colorspace boundaries on profile info for each display profile.
C) novideo_sRGB relies on matrix profiles, display should be somehow near ideal to be described that way. If displays are not well behaved (if you need a table profile to describe display because matrix profiles show high errors) you should use DWMLUT. Same for color managed apps that do not support table profiles (or color banding in neutrals caused by limited precision calculationson that app).
D) Is there a huge brightness & contrast mismatch between displays and/or using BPC on profiles? Then they cannot behave the same untill brightness in colors are high enough (in grayscale relative level of brightness) to be described accurately by profile TRCA) Yes I matched the whitepoint of both and turned off white point calibration in the profiles created. Though a 100% match is impossible since it changes from position to position of where you look at the monitors. (Green tint on the right side of the monitor and yellowish to the bottom, slight but noticeable)
B) I just tried limiting the color space below sRGB so both displays match all the colors (created custom setting in novideo_srgb). This does make it more close, but it still is off similarly to before.
C) Is there any tutorial to correctly create a .cubic calibration file? I tried making one but the program you mentioned didn’t recognize it so I hope you could help me out here to try this solution.
D) I haven’t checked in my calibration report but I know from reviews that there is a difference in contrast (about 1000:1 on the XV while 1200:1 on the XF) and this is visible with worse blacks. I can simulate lower contrast via the display settings but that would probably not fix hue errors, at most just color intensity which isn’t the only issue.
C)
source : simulation profile
destination: display profile
Use relative colorimetric or perceptual intent, sicne you have matched whites visually.
LUT3D format: iridas .cubeFor each display, open DWMLUT an load each LUT3D simulating the same source colorspace. Set as display profile the simuation profile if yiou wish to use them in color managed apps too.
… or if you wish to use them color managed in full native gamut of each display, use as “source” an idealized colorspace given by each display primaries, D65 and whatever target gamma you want. Create thos eidealized profiles with synth editor in displaycal forlder. Then set as default display profiles in OS the idealized porfiles and load each LUT3D on DWMLUT.
I just found out that apparently DWMLUT doesn’t work on newest Windows 11 version for now, so I guess I’ll have to wait until its updated. I’ll reply here again when I can try it to see if it makes the results better.
Use relative colorimetric or perceptual intent, sicne you have matched whites visually.
I found this lead to innacurate results. White Point never ended up being my alternate target.
What correctly gave me my Alternate White Point was to create a new synthetic profile targeting my alternate White Point. And creating a lut with Absolute Colorimetric & White Point scaling, with my source profile using my newly created synthetic profile.
This got me closer to my perceptually matched White Point.
Does white match? If not, wrong corrections for those displays.
You can use the correct correction and White Point will still not match. You can use a high end reference probe that measures down to 2nm and displays of different tech will still not match. The only display tech I’ve seen match was CRT and CCFL LCD. All other tech don’t match.
Use relative colorimetric or perceptual intent, sicne you have matched whites visually.
I found this lead to innacurate results. White Point never ended up being my alternate target.
What correctly gave me my Alternate White Point was to create a new synthetic profile targeting my alternate White Point. And creating a lut with Absolute Colorimetric & White Point scaling, with my source profile using my newly created synthetic profile.
This got me closer to my perceptually matched White Point.
Hard to believe, since rel col is the default behavior of all color managed apps.
Does white match? If not, wrong corrections for those displays.
You can use the correct correction and White Point will still not match. You can use a high end reference probe that measures down to 2nm and displays of different tech will still not match. The only display tech I’ve seen match was CRT and CCFL LCD. All other tech don’t match.
That’s you, not the procedure (observer metameric failure), hence visual whitepoint match as instructed.
Hard to believe, since rel col is the default behavior of all color managed apps.
Then the issue may be DWM_LUT Gui doesn’t support relative colorimetric.
I verified after I applied the lut to DWM in HCFR. It was off by about 0.0025. Which is a noticble difference. Using synthetic profile creation I mentioned got me closer to my target white point when I measured it.
That’s you, not the procedure (observer metameric failure), hence visual whitepoint match as instructed.
It’s not just me. It’s alot of people including the OP. I do question the reliability of Visual White Point Match. So much can go wrong if the user doesn’t know how to properly do it.
Visually using a 10% window looks different then full screen. How far back you stand can also appear visually different then if you are closer.
Hard to believe, since rel col is the default behavior of all color managed apps.
Then the issue may be DWM_LUT Gui doesn’t support relative colorimetric.
I verified after I applied the lut to DWM in HCFR. It was off by about 0.0025. Which is a noticble difference. Using synthetic profile creation I mentioned got me closer to my target white point when I measured it.
Against what? That statement is pointless because it’s ambiguous.
Also that behavior should not depend on DWMLUT, it just apply a precalculated LUT3D in iridas .cube format.It may be a bug in “collink.exe” (app that computes LUT3Ds) but this has to be proven. Send logs and data to Graeme in Argyll maillist so he can correct it if you are sure about that issue be real and not a misconfiguration of your setup,
That’s you, not the procedure (observer metameric failure), hence visual whitepoint match as instructed.
It’s not just me. It’s alot of people including the OP. I do question the reliability of Visual White Point Match. So much can go wrong if the user doesn’t know how to properly do it.
Visually using a 10% window looks different then full screen. How far back you stand can also appear visually different then if you are closer.
That seems related to uniformity, not related with visual match approach. Make visual match window bigger, I do not remember but you should be able to resize it, if not it’s a cool feature for Erkan’s Python3 port.
Against what? That statement is pointless because it’s ambiguous.
Also that behavior should not depend on DWMLUT, it just apply a precalculated LUT3D in iridas .cube format.Not really ambiguous. I matched my QD OLED to my CRT & CCFL LCD. I use both CRT and CCFL to elimate any possibility of error, since they both match. & to make sure nothing was going wrong with my visual system since CRT’s relatively slow refresh rate can cause issues.
Used my Jeti to get cordinates of my matched QD OLED. Then I set displaycal to alternate wp in the tab. And the relative 3D LUT did not properly hit the cordinates of my set AWP after I verified it.
I re-profiled the Display and my Colorimeter to my spectro multiple times to try to eliminate the possibility of user error. And same issue.
Previously I was using argyll that DisplayCal gave me. Since then I’m using the latest version downloaded from the Website. So I need to verify if the issue is still present.
That seems related to uniformity, not related with visual match approach. Make visual match window bigger, I do not remember but you should be able to resize it, if not it’s a cool feature for Erkan’s Python3 port.
I doubt it’s uniformity. My CRT has a full digital uniformity control. So I can get clean uniformity throughout the entire screen. Plus CRT tech has the widest viewing angles of any technology. So no issuse with viewing angles for white point matching.
QD-OLED’s also has some of the best uniformity of any consumer display on the market right now.
My Guess is viewing angles. QD-OLED has superior viewing angles to RGB OLED and WRGB OLED when I compared them. But still not as good as CRT.
Up too close can cause issue. So I need to stand a good distance back.
From experimenting I’ve seen full window size works better then small windows.
Alright so I just tested the whole thing with DWMLUT on a Windows 10 install of another drive and I sadly have to say that the resulting colors are identical to the result novideo_srgb gives me. All the colors are off in the same similar way as described in the beginning. Is there any explanation or possible fix here? I haven’t fully understood what EP98 tried and how I can set a custom white point so I haven’t tried that yet, but with all I have tried I always come to the same result on both monitors but its always off. White point is a pretty decent visual match in my opinion, I checked this multiple times at different times of day and light sources and it always is very similar though sometimes, depening on light it could shift a bit offset but on average and most of the time it seems identical to me.
If you are visually matching the monitor by eye to your chosen reference monitor. And you measure the display to get an alternate White Point to target.
Lets say for example.
X: 0.3095, Y: 0.3220
Check the profile afterwards and look at the XY cordinates to see of its close to your set Alternate White Point.
I was not getting a match because of the issue I described earlier. Once I found the issue I was able to solve it as described and was able to get a match.
Check the profile afterwards and look at the XY cordinates to see of its close to your set Alternate White Point.
I was not getting a match because of the issue I described earlier. Once I found the issue I was able to solve it as described and was able to get a match.
Alright so I just checked this. I measured the white point first, then calibrated the display with that set whitepoint and looked at the whitepoint in the profile after. I am getting pretty close matches on my end which are off 0.005 on average which seems to me to be a basically identical figure. I am still confused as to what the issue is and why it is always off in a near identical way. No matter what presets I try, which correction filters I use or else, it is always a near identical outcome on both displays but it’s always not identical to each other.
Maybe this is really just a display technology offset that can’t be corrected? Perhaps a Spectrometer would be a more accurate tool I should try?
. I am getting pretty close matches on my end which are off 0.005 on average which seems to me to be a basically identical figure.
XY of 0.005 is a pretty big difference. It’s nowhere near your target. You will see a difference.
For example High End multi thousand dollar Reference displays require a delta error of equal or less then DE 0.5 on grayscale. Likely due to our eyes being more sensitive to grayscale.
I myself can see a difference of even at DE 1.2.
You need to get that number closer to your target. Basically closer to XY +- 0.0010 of your target. I completely ignore DE for grayscale as I find that not very useful. And I just pay attention to XY cordinates instead.
. I am getting pretty close matches on my end which are off 0.005 on average which seems to me to be a basically identical figure.
XY of 0.005 is a pretty big difference. It’s nowhere near your target. You will see a difference.
For example High End multi thousand dollar Reference displays require a delta error of equal or less then DE 0.5 on grayscale. Likely due to our eyes being more sensitive to grayscale.
I myself can see a difference of even at DE 1.2.
You need to get that number closer to your target. Basically closer to XY +- 0.0010 of your target. I completely ignore DE for grayscale as I find that not very useful. And I just pay attention to XY cordinates instead.
Oh yeah sorry I just forgot to add another 0 there. Its on average 0.0005 off is what I was trying to say.
0.005 offset is what I get max by measuring different spots on my displays. Though even when I measure a different spot I still get the same color offsets.
