- This topic has 62 replies, 4 voices, and was last updated 1 year, 5 months ago by
.
-
Posts
-
You can ask Graeme to add some custom observer instead the 5-6 bundled ones, like “-X file.ccss -obs file.cmf” for i1d3 or without -X for your JETI.
Although if visual error is only on white and not in primaries perceptual whitepoint approach will be enough.Anyway, if a rel col LUT3D is not outputing RGB 255 255 255 for white, send your LUT3D and logs to graeme to fix collink.exe, or to tweak comandline adding some alternative chromatoc adaptation matrices
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.You can ask Graeme to add some custom observer instead the 5-6 bundled ones, like “-X file.ccss -obs file.cmf” for i1d3 or without -X for your JETI.
I tried the CMF with Quantum Dot displays and unable to get a match. I tried different CMF’s with QD-LCD and QD-OLED and no match to CRT. It seems they don’t work with QD displays.
Anyway, if a rel col LUT3D is not outputing RGB 255 255 255 for white, send your LUT3D and logs to graeme to fix collink.exe, or to tweak comandline adding some alternative chromatoc adaptation matrices
So I was able to figure out what the issuse was with DWM LUT GUI.
The problem is applying VCGT, it seems DWM LUT GUI is applying grayscale calibration twice which causes the shift in White Point. I mistakenly attributed rendering intent to be the problem, I didn’t realize in the 3D LUT generation software I had it disabled.
I generated a LUT as I described before. Absolute Colorimetric with White Point scaling and saw a shift in White Point from the target I wanted. Then I investigated this issue some more and found that Disabling 1D LUT VCGT in 3D LUT generation fixed my issue when I use luts with DWM LUT GUI. White Point now correctly tracking to my target.
I did more testing with it enabled and disabled when generating luts. And see the shift with enabled, and no shift disabled. I also tested it with relative colorimetric disabled and relative was correctly hitting my White Point target.
So to fix issue disabled 1D LUT VCGT so that grayscale calibration doesn’t get applied twice with DWM LUT.
I also use synthetic profile to target the perceptual matched White Point I want since it allows me to input XYZ values. To get more precise White Point instead of xy. I just use the XYZ Jeti software spits out after I match to CRT.
No need to 1D LUT anyway since 3D LUT should have grayscale and gamma calibration already. You can also skip 1D LUT portion to speed up calibration. Just create XYZ 3D LUT.
That was discussed on DWMLUT thread. DisplayCal GUI applying VCGT to GPU and DWMLUT are separate entities. Same for Resolve & DisplayCAL
You may want to run both but if you wish to keep VCGT calibration loaded & maintaned by DisplayCAL create LUT3D without VCGT. This is a tuypical example of a Resolve GUI display keeping system wide grey calibration if monitor has grey color errors, also that will preserve custom ICC fro color managed apps like browser or image editor while you run Resolve.
A typical DWMLUT scenario is (at least statistically) more suitable to be used in an exclusive way (VCGT on LUT3D, DisplayCAL loader switched to “reset”).
That was discussed on DWMLUT thread. DisplayCal GUI applying VCGT to GPU and DWMLUT are separate entities. Same for Resolve & DisplayCAL
The issue is I’m not loading any 1D lut into DisplayCal profile loader. Everytime I generate a 3D LUT for DWM, I skip the 1D lut loading everytime.
In DisplayCal profile loader I always have sRGB IEC611966-2.1 loaded. To turn off any calibration on the GPU level. And just let the 3D LUT in DWM handle everything.
The issue was present with this set up. So I need to generate a 3D LUT without 1D LUT VCGT. Even if I have 1D LUT calibration turned off in Profile Loader. I will still get a shift if VCGT is enabled.
I just want to post something in here again to clear some stuff up.
To quote Vincent from a few posts back “The more narrow peaks SPD has, the more probable is that your eyes differ form std observer in that tiny wavelength region where the peak is.”
I don’t get what you are trying to say? I am not able to match my 2 monitors because of my vision and not because of the display? I obviously understand that equipment can’t measure light exactly like humans do which I could see as the problem but if I understand you correctly you mean that for some person out there those 2 displays would look the same but not for me? If thats what you are saying I highly doubt this. I could probably ask some friends to look at my displays and I am fairly certain it would be similarly off for everyone.
If thats not what you are saying then clearly It’s just that measurement equipment isn’t working good enough to simulate human vision and there is no point in calibrating when every displays output looks different.
That was discussed on DWMLUT thread. DisplayCal GUI applying VCGT to GPU and DWMLUT are separate entities. Same for Resolve & DisplayCAL
The issue is I’m not loading any 1D lut into DisplayCal profile loader. Everytime I generate a 3D LUT for DWM, I skip the 1D lut loading everytime.
In DisplayCal profile loader I always have sRGB IEC611966-2.1 loaded. To turn off any calibration on the GPU level. And just let the 3D LUT in DWM handle everything.
The issue was present with this set up. So I need to generate a 3D LUT without 1D LUT VCGT. Even if I have 1D LUT calibration turned off in Profile Loader. I will still get a shift if VCGT is enabled.
Then it would be a bug in collink.exe, params -a/-H/-O (IDNK which one is using DisplayCAL). Since standalone app does not make logs (AFAIK), ypu’ll need to search in python code or aks in maillist.
I just want to post something in here again to clear some stuff up.
To quote Vincent from a few posts back “The more narrow peaks SPD has, the more probable is that your eyes differ form std observer in that tiny wavelength region where the peak is.”
I don’t get what you are trying to say? I am not able to match my 2 monitors because of my vision and not because of the display? I obviously understand that equipment can’t measure light exactly like humans do which I could see as the problem but if I understand you correctly you mean that for some person out there those 2 displays would look the same but not for me? If thats what you are saying I highly doubt this. I could probably ask some friends to look at my displays and I am fairly certain it would be similarly off for everyone.
CIE XYZ coords are calculated this way:
X = Integral ( x-bar function * SPD, evaluated from ultraviolet to infrared)
Y = Integral ( y-bar function * SPD, evaluated from ultraviolet to infrared)
Z = Integral ( z-bar function * SPD, evaluatedfrom ultraviolet to infrared)Not SPD alone, but multiplied by each -bar (std observer) functions, hence peaks may cause huge shift in coords depending where they are (-bar derivative)
Spectros measure SPD, so every height error and wavelength error causes an error and error severity depends on -bar function.
Colorimeters compute SPD*bar function in an analogic way, a filter + a sensor, futher corrected by firmware -bar data of colorimeter observer + CCSS (SPD data), hence CCSS error or firware data drift from actual colorimeter observer causes error.
These are “tecnological errors”.-bar functions (std observer, mean, “model”) erros vs YOUR -bar functions causes observer metameric failure, “biological / statistical” errors. -bar derivative may play a significant role, higher derivative (+-slope) can cause an over/underestimaton if SPD peak is placed on such wavelegths. Also -bar height errors would do the same trick.
We were talking abut this second one if you can be sure enough that 1st one does not apply
If thats not what you are saying then clearly It’s just that measurement equipment isn’t working good enough to simulate human vision and there is no point in calibrating when every displays output looks different.
No, error if any would be on WP. Once corrected all photo oftware uses rel colorimetric intent when rendering an image to screen, so all data in ICC profiles is accurate, even if you do not like WP (just correct it visually).
I mean Photoshop & all these software do not care about WP at all. It won’t alter their calculations and (excluding rounding errors that causes banding) all of them will be accurate becaue they use rel col. So fix your white point to solve whatever wp visual error you have and that’s all.
When using software that MAY use abs colorimetric, like 3DLUT creator you need to worry about WP match. If you do not want to worry about it and just use your visual WP match use relative colorimetric and it work accurately as Photoshop… unless there is a bug in collink.exe application from ARgyllCMS. That was what EP98 & I were taking about, EP98 said that rel col was not working as intended becsue of some VCGT issue.
-bar functions (std observer, mean, “model”) erros vs YOUR -bar functions causes observer metameric failure, “biological / statistical” errors. -bar derivative may play a significant role, higher derivative (+-slope) can cause an over/underestimaton if SPD peak is placed on such wavelegths. Also -bar height errors would do the same trick.
Isn’t this exactly what I tried to understand before? You are saying that in this case the displays would not match because of my vision personally?
. If you do not want to worry about it and just use your visual WP match use relative colorimetric and it work accurately as Photoshop
Well even if I keep my whitepoint as measured and even if I make a visual WP match, I still always get the same offset in colors. That is my issue. My issue is that both displays after calibration always look the same no matter how often I calibrate them, they just never match each other. Maybe there is another way to make them match? Any idea maybe?
Well even if I keep my whitepoint as measured and even if I make a visual WP match, I still always get the same offset in colors. That is my issue. My issue is that both displays after calibration always look the same no matter how often I calibrate them, they just never match each other. Maybe there is another way to make them match? Any idea maybe?
I don’t think it’s possible to get displays of two different tech to match.
I’ve tried. I’m still unable to do it. I can only get White Point close enough.
Color Matching wasn’t an issue back then when everyone was on a CRT. But with all this different tech with different SPD’s, they don’t match.
Im trying to find a solution to this problem but can’t find any.
For me I’m mostly concerned with Video. And the goal is to match a Reference Monitor, so that you see colors the way the colorists intended. Issue is there is no consistency in calibration in the professional industry. There is no standardized approach so there is no industry standard.
All displays that is not CRT, Plasma, CCFL needs a alternate White Point. That includes professional monitors. D65 hasn’t been industry standard not since wide gamut displays, this is what I have been told, since we moved away from CRT and started getting wide gamut displays.
Most common Reference Monitors right now are Dual Layer LCD and RGB OLED’s. And for both Sony recomends an alternate White Point to try to mimick a D65 CRT.
https://pro.sony/s3/2021/01/22153635/Monitor_Colormatching_v100_201222_E.pdf
But not everyone agrees with Sony’s approach. Sony themselves had issues with it and changed their offset values a couple of times. And I’ve been told Sony’s White Point is not accurate. I have both pro displays the CRT and RGB OLED and to my eyes they don’t match when I tried Sony’s alternate Judd Offset.
https://www.lightillusion.com/perceptual_match_guide.html
When I try to find answers on this I get very inconsistent answers. For example on Dual Layer LCD’s, Some professionals told me they adjust their reference monitors to D65, some others say they adjust to Sony’s offset, some use the perceptual match approach. There is no consistency on how these are calibrated, so no industry standard approach. There is no standards as far as I’m concerned.
I try to match to a pro CRT calibrated to D65 as that’s what Sony tried to do. Or use a CCFL as this matches the CRT well. But I have people telling me don’t match to CRT, they are no longer standard. Plasma was another displays that was suppose to match CRT but now I hear people say don’t use Plasma anymore because they do not match Dual Layer LCD’s using Sony’s alternate White Point. You will not get the correct colorists intended look on a Plasma calibrated to D65. Dual Layer LCD with Sony’s White Point is the new white point standard.
CRT, Plasma, and CCFL was suppose to be the gold standard for D65, and I’ve been told to matchbto them, but I guess not anymore? The same Proffesional’s that told me to match to them now say don’t match to them. They changed and being inconsistent with themselves.
So I don’t know really what to say to be honest. So many inconsistencies in the answers I’m getting. And these are industry Proffesional’s that are giving me inconsistent answers. Not some random guy. It seems they themselves can’t figure this stuff out either. Everything is a mess to be honest.
-bar functions (std observer, mean, “model”) erros vs YOUR -bar functions causes observer metameric failure, “biological / statistical” errors. -bar derivative may play a significant role, higher derivative (+-slope) can cause an over/underestimaton if SPD peak is placed on such wavelegths. Also -bar height errors would do the same trick.
Isn’t this exactly what I tried to understand before? You are saying that in this case the displays would not match because of my vision personally?
Your vision on that particular SPD. And mostly for whitepoint.
. If you do not want to worry about it and just use your visual WP match use relative colorimetric and it work accurately as Photoshop
Well even if I keep my whitepoint as measured and even if I make a visual WP match, I still always get the same offset in colors. That is my issue. My issue is that both displays after calibration always look the same no matter how often I calibrate them, they just never match each other. Maybe there is another way to make them match? Any idea maybe?
IDNK what you mean by “match”, try to be more precise in nest messages.
Non color managed won’t match unless you use DWMLUT simulating a common minimum colorspace shared by all your screens (and use that common colorspace as display ICC and you profiled displays in an accurate way)
Color managed will match as long as colors in image can fit inside all displaycolorspaces (and you profiled displays in an accurate way)
Of course if contrast ratios are too different and you are faking TRC for ICC profiles it will be a missmatch in all colors bellow some brightness where TRC differ.Well even if I keep my whitepoint as measured and even if I make a visual WP match, I still always get the same offset in colors. That is my issue. My issue is that both displays after calibration always look the same no matter how often I calibrate them, they just never match each other. Maybe there is another way to make them match? Any idea maybe?
I don’t think it’s possible to get displays of two different tech to match.
I’ve tried. I’m still unable to do it. I can only get White Point close enough.
Color Matching wasn’t an issue back then when everyone was on a CRT. But with all this different tech with different SPD’s, they don’t match.
Im trying to find a solution to this problem but can’t find any.
For me I’m mostly concerned with Video. And the goal is to match a Reference Monitor, so that you see colors the way the colorists intended. Issue is there is no consistency in calibration in the professional industry. There is no standardized approach so there is no industry standard.
All displays that is not CRT, Plasma, CCFL needs a alternate White Point. That includes professional monitors. D65 hasn’t been industry standard not since wide gamut displays, this is what I have been told, since we moved away from CRT and started getting wide gamut displays.
Most common Reference Monitors right now are Dual Layer LCD and RGB OLED’s. And for both Sony recomends an alternate White Point to try to mimick a D65 CRT.
https://pro.sony/s3/2021/01/22153635/Monitor_Colormatching_v100_201222_E.pdf
But not everyone agrees with Sony’s approach. Sony themselves had issues with it and changed their offset values a couple of times. And I’ve been told Sony’s White Point is not accurate.
As soon as I see bluer alt WP… I think of CIE 2012 2 degre obs (CIE 170 in that paper). Its D65 is just old D65 with a slight blue shift.
(I cannot find original source right now , only this image from DisplayCAL forum:
https://postimg.cc/XXtkq9VYTheir claims CIE-170 without experimental data variation analisys like they did for others seems unreliable from thier side. (Maybe because they blow up their former RGB OLED recomendations… it’s a business after all, 50% state of the art high end tech 50% snake oil so “ours is better than theirs”)
Also the last part of their paper may be inaccurate. They show 3 different SPD of WLED PFS…but differences in blue spike main wavelength. So you may need to deal with z-bar variations in shorter wavelengths + CIE 1931 2 degree inaccuracies in that region.
Also depending on colorimeter you may need to switch between HP Z24x correction (short) and others (peak closer to 450nm).RIT paper showed a synthetic superposition of several -bar functions variation computed from slight variations in LMS response.
I have both pro displays the CRT and RGB OLED and to my eyes they don’t match when I tried Sony’s alternate Judd Offset.
https://www.lightillusion.com/perceptual_match_guide.html
When I try to find answers on this I get very inconsistent answers. For example on Dual Layer LCD’s, Some professionals told me they adjust their reference monitors to D65, some others say they adjust to Sony’s offset, some use the perceptual match approach. There is no consistency on how these are calibrated, so no industry standard approach. There is no standards as far as I’m concerned.
I try to match to a pro CRT calibrated to D65 as that’s what Sony tried to do. Or use a CCFL as this matches the CRT well. But I have people telling me don’t match to CRT, they are no longer standard.
As you saw, CRT SPD has narrow spikes…but not in blue. They are safer in z-bar variations and/or innacuracies on z-bar of CIE 1931 2degree, less safe in x-bar variations.
Plasma was another displays that was suppose to match CRT but now I hear people say don’t use Plasma anymore because they do not match Dual Layer LCD’s using Sony’s alternate White Point. You will not get the correct colorists intended look on a Plasma calibrated to D65. Dual Layer LCD with Sony’s White Point is the new white point standard.
Plasma has spikes close to CRT in red. Also they go to shorter violet wavelengths so z-bar variations may give you surprises.
CRT, Plasma, and CCFL was suppose to be the gold standard for D65, and I’ve been told to matchbto them, but I guess not anymore? The same Proffesional’s that told me to match to them now say don’t match to them. They changed and being inconsistent with themselves.
So I don’t know really what to say to be honest. So many inconsistencies in the answers I’m getting. And these are industry Proffesional’s that are giving me inconsistent answers. Not some random guy. It seems they themselves can’t figure this stuff out either. Everything is a mess to be honest.
RGB OLED and QLED are widegamut and have “broad” spikes but to be sure of that you’ll have to plot SPD*bar function instead of instead of SPD alone (also they have a valley on max y-bar)
I can match WLED and GB-LED without issue (broad peaks) with CIE 1931 2 degree so I assume less -bar variations in me, but I had such issues like both of you i’ll try to switch to 2012 2 degree.
Remember that although ArgyllCMS can use alt obs, DIsplayCAL HTML report defaults to CIE 1931 2 degree, hardcoded. You can ask Erkans on his Python 3 port to add this feature in HTML reports. I mean you can run log console “test on (un)calibrated display” for these tests since it runs dispcal -R/-r but you should not use HTML reports.
You can use “spotread” on non whitepoint patches that you find problematic matching and play with different obs.I cannot edit
because they blow up their former RGB OLED recomendations
I meant “they” => “it would”
I forgot that you where there too, hahaha
Anyway, excluding some of you having a more severe drift from “whatever mean/median/mode” we use for human vision, CIE 2012 2 degree should got better match for “general population” as Raj said on that thread.
Once white is fixed and if software has no bug, relative colorimetric intents to preserve white and if display is well behaved single curve ICCs to avoid color cast in grey due to rounding errors.IDNK what you mean by “match”, try to be more precise in nest messages.
Non color managed won’t match unless you use DWMLUT simulating a common minimum colorspace shared by all your screens (and use that common colorspace as display ICC and you profiled displays in an accurate way)
Color managed will match as long as colors in image can fit inside all displaycolorspaces (and you profiled displays in an accurate way)
Of course if contrast ratios are too different and you are faking TRC for ICC profiles it will be a missmatch in all colors bellow some brightness where TRC differ.What else do I have to explain? I said from the very beginning that my displays look completely different after calibration. I explained before that I use a below sRGB color space so all colors should be identical. All colors are offset. As I said in the beginning, reds for example, even if I take the purest, most saturated red color that you can show on the display, is more saturated on my XF270HU than the red on my XV272UX, yellows are brighter, greens are more yellowish, blues are more cyan. It’s always the same mismatch. I tried visual white point match, I tried just going with the white point it tells me to go for. Then maybe the white is off but it doesn’t help with the colors either, they are still similarly offset.
I tried using DWMLUT, tried using absolute colorimetric, tried relative, with no improvement. I am sticking with novideo_srgb for now though since it’s compatible with my windows version and easily usable, but I saw no difference between using novideo_srgb and DWMLUT, it was the same result.
I don’t think it’s possible to get displays of two different tech to match.
I’ve tried. I’m still unable to do it. I can only get White Point close enough.
Color Matching wasn’t an issue back then when everyone was on a CRT. But with all this different tech with different SPD’s, they don’t match.
Im trying to find a solution to this problem but can’t find any.
Probably gonna stick with this explanation. Because there isn’t really anything else to try at this point anyway. I guess different tech just can’t be visually matched. I personally will probably just go with 2 identical monitors in the future so I don’t have these problems anymore. I am just waiting for 27″ 1440p 240hz oled (hopefully QD-oled) displays ????
IDNK what you mean by “match”, try to be more precise in nest messages.
Non color managed won’t match unless you use DWMLUT simulating a common minimum colorspace shared by all your screens (and use that common colorspace as display ICC and you profiled displays in an accurate way)
Color managed will match as long as colors in image can fit inside all displaycolorspaces (and you profiled displays in an accurate way)
Of course if contrast ratios are too different and you are faking TRC for ICC profiles it will be a missmatch in all colors bellow some brightness where TRC differ.What else do I have to explain? I said from the very beginning that my displays look completely different after calibration.
Expected & explained long time ago. You were mixing concepts.
I explained before that I use a below sRGB color space so all colors should be identical. All colors are offset.
As I said in the beginning, reds for example, even if I take the purest, most saturated red color that you can show on the display, is more saturated on my XF270HU than the red on my XV272UX, yellows are brighter, greens are more yellowish, blues are more cyan. It’s always the same mismatch.
Those two statements you write are opposites… and latest one is expected if native gamut of those displays are different.
I think that you did not understand it from the begining non color managed vs color managed enviroment… hence all your visual test would be flawled.
Also as explained above if even applying a LUT3D simulating a minimum colorspace there are colors you see very diferent… measure them: spotread (remember to add -X and the custom observer if any).
You are claiming observer metameric failure without even checking it… so this thread is pointless without data. Myself could write “I get a match on those two tech” and end of discussion, “same data provided”.
If measured are different over certain dE00 there is no “display mismatch” because your eyes or devices, the problem is in calibration/profling itself! (and/or user misconfiguration)-Under certain brightness color/brightness mismach in color managed apps is due to profile TRC mismatch with actual screen on limited contrast displays. It can be measured and it not related to observers or matameric failure… because it can be measured
-Non color managed mismatch after applying an accurate LUT3D (after individual validation of that LUT3D on its display, otherwhise it’s pointless) could point to your claims, but we have not see such verification (if LUT3D is accurately simulating that minimum common colorspace on its window of contrast)
-Missmatch of LUT3D to its display (like original discussion about rel colorimetric LUT3D), a numerically measured mismatch is due to collink.exe behavior and its not related at all with “different led tech and observers”.So first of all, make sure your tests are done in the proper way. Unless that is verified, it’s pointless to go on.
I tried visual white point match, I tried just going with the white point it tells me to go for. Then maybe the white is off but it doesn’t help with the colors either, they are still similarly offset.
I tried using DWMLUT, tried using absolute colorimetric, tried relative, with no improvement. I am sticking with novideo_srgb for now though since it’s compatible with my windows version and easily usable, but I saw no difference between using novideo_srgb and DWMLUT, it was the same result.
If display could be described with a matrix profile in an accurate way they should be close… that the difference between a lut-matrix-lut (newer GPU HW for colorspace simulation) and a LUT3D. They would do the same.
I don’t think it’s possible to get displays of two different tech to match.
I’ve tried. I’m still unable to do it. I can only get White Point close enough.
Color Matching wasn’t an issue back then when everyone was on a CRT. But with all this different tech with different SPD’s, they don’t match.
Im trying to find a solution to this problem but can’t find any.
Probably gonna stick with this explanation. Because there isn’t really anything else to try at this point anyway. I guess different tech just can’t be visually matched. I personally will probably just go with 2 identical monitors in the future so I don’t have these problems anymore. I am just waiting for 27″ 1440p 240hz oled (hopefully QD-oled) displays
