- This topic has 62 replies, 4 voices, and was last updated 1 year, 5 months ago by
.
-
Posts
-
You were mixing concepts.
In what way? What do you mean?
Those two statements you write are opposites… and latest one is expected if native gamut of those displays are different.
It’s not expected to look different when calibrated.
even applying a LUT3D simulating a minimum colorspace there are colors you see very diferent… measure them: spotread
If there are colors “I see very different” then there is no reason to calibration when I just seem them differently anyway. Also how do I do spotread?
So first of all, make sure your tests are done in the proper way. Unless that is verified, it’s pointless to go on.
Whats the “proper” way? 100% sure I did it as properly as possible, Using the correct correction for the specific display, calibrating the WP and then measuring the displays with the device and using the created ICC profile.
Let’s say that you have a P3 native gamut that with WP matched numerically (using proper colorimeter corrections etc) to D65 CIE 2012 2 degre or whatever observer you want, shows a slight color cast, so you correct that WP visually or with some numerically provided alt WP coordinates or xy offset.
You want to make a sRGB simulation. Max error should be in WP. Max error should be between relative colorimetric simulation (visual white) and abs colorimetric simulation (numerical match white)
Hence a skin color inside sRGB rendered abs coloremtic VS rel colorimetric should have an error (a numerical error) smaller than WP. Otherwise something is broken in that simulation and it’s not related to observer variation vs some std observer. It may broken computationally (bug) or due to inaccurate measurement of device (bad resolution or bad correction or bad sensivity curves in firmware).Simulated sRGB RGBCMY 50-75% saturation patches should have less error than WP (between predicted with a numerically match D65 and an ACTUAL visual match to other D65 device)
If you cannot trust that simulation to pivot all colors between primaries and WP with him as WP moves around by applying some offset… there should be a huge error in some primary in your measured SPD somehow compensated when mixing to make white 255 255 255 by the other two. And that is HIGHLY improbable for a White LED and a QLED and usual chromatic adaptation matrices. So unlikely that such error should be seen just by switching close CCSSs while measuring primaries.
That’s the principle of visual matching and it works… unless a person is a total outlier for all observer models, but in that case it will be that person problem, unable to judge in a confident way any color under most lightsources, including textiles & prints, not a systemic issue for the majority of people.
For example the outliers causing high max dE on RIT paper white using thier 7led prototype even if mean error of all observers were extremely low. Unfortunate for him but no issue for the many.Go to argyll documentation, spotread. You can use as patch source the app MS paint (non color managed).
If you do actually want to make full colorspace comparisons you can use xicclu (argyllcms tool), it should output RGB values (remember to scale to 0-255) for a given xy coord and a rendering intent in some profile. So you could put whatever xy coord you want (rel col vs obs for example) and get a 0-255 truncated RGB value to use as a patch in MS paint and put that patch in the center of screen.
Of course system wide LUT3D simulation or lut-matrix simulation should have been done properly without double corrections as in EP98 example (VCGT in GPU and also in LUT3D)
=> this is done to compare simulated colorspace to native gamut RAW RGB values that have the same color coords (abs col or rel col), to spot if there is an actual bug in calculated LUT3D if we assume accurate profiles for devices.I hop that you understand thsi now with pivot example
As a visually matched WP moves arround by applying some offset to a numerically matched to measurement WP, it drags with him all 25%-50% saturation patches… and if it does not then primaries coordinates are wrong by a huge error (bad device, unaccurate device, innacurate correction). And you do not have laser like devices to cause naturally such errors on usually accurate devices.
Hence you apply a visual offset to a numerically matched D65 and that’s all. That offset drags saturation patches from WP to primaries with him.
If you still do not see it try to visualize it with a needle and 3 threads. Fix one side of the thread (long enouigh to be loose) attach the othr sie of each thread to needle head and move it. It drags inner colorpace color with him…so you cannot have bigger errors inside colorspace on a visually matched white unless you did something very wrong measuring device colorspace. It drags them to where you said it was a visual match.A side note, if you were such an outlier to human model vision… you just need to use as “source colorspace” in LUT3D creation a visually matched RGB colorspce with alternative xy coord for some minimum common colorspace like sRGB.
You can get those coords from a visually match in MS paint, feeding that RGB value (beware scalling!) to xicclu to get xy coordinate. Then make a synth profile, then freed it to LUT3D creator. You’ll have fixed 4 ends of the needle thread example. That will always match and if it does not it means that your device is not even close to linear, that some color cannot be expresed as some K1, K2 and K3 gains applied to native RGB primaries… and your need a igh end spectrophotometer and a very densely populated XYZLUT mesh to capture such bad behavior. It won’t be your eyes the issue.
So 1D LUT does work. I fucked up. I skipped the 1D Calibration portion everytime.
This time I enabled in software and applied VCGT to 3D LUT for DWM LUT GUI and everything works fine. Delta errors were higher without VCGT applied. So it needs to be enabled. Image looks alot more contrasty too at 2.4 gamma. And I verified with my Jeti.
This time also after I profile my Colorimeter I always verify if it measures the same as my Jeti everytime single time.
If you load the 1D LUT using DisplayCal profile loader, calibration software disables the loader. So if you don’t apply VCGT and load 1D to displaycal loader you’ll need to find a way to not let the software disable 1D lut loading. I usually use Jeti software to do the measurments. But this doesn’t apply to me since I apply VCGT into my 3D LUT.
I found that CIE 1964 10° on my QD-LCD matches well with my D65 1932 CRT. I use this cmf now for calibration on my QD-LCD.
Delta errors are always high on one of the primaries whenever I use a alternate cmf. I tried both CIE 1964 and CIE 2012. I guess because DisplayCal verification uses 1931 for verification?
And Judd-Vos 1978 2° on RGB OLED matches well with CRT but you need to use the correct xy D65 cordinates specific for these alternate colormatching functions. Sony’s cordinates in their paper for the WP in either Judd-Vos or 1931 both do not match the CRT and looks a tad bit more green. So use the D65 cordinates in Jeti’s paper for a better match.
They can be found here in this Jeti paper
https://www.jeti.com/files/content/support/downloads/papers/Lux%202017.pdf
CIE 170, CIE 2012, CIE 2006 I believe are all similar. Jeti software calls it CIE 2006 2° and DisplayCal calls it CIE 2012.
I measured both colormatching functions in both software’s with my Jeti and they spit out the same xy numbers. So they are the same just different names.
So there is no 1 size fits all cmf. You’ll need to experiment on different displays to see what gives you a good match. I use a 1931 D65 CRT as my reference target for all display.
I need to do more testing on my QD-OLED with CMF’s.
So 1D LUT does work. I fucked up. I skipped the 1D Calibration portion everytime.
This time I enabled in software and applied VCGT to 3D LUT for DWM LUT GUI and everything works fine. Delta errors were higher without VCGT applied. So it needs to be enabled. Image looks alot more contrasty too at 2.4 gamma. And I verified with my Jeti.
This time also after I profile my Colorimeter I always verify if it measures the same as my Jeti everytime single time.
If you load the 1D LUT using DisplayCal profile loader, calibration software disables the loader. So if you don’t apply VCGT and load 1D to displaycal loader you’ll need to find a way to not let the software disable 1D lut loading. I usually use Jeti software to do the measurments. But this doesn’t apply to me since I apply VCGT into my 3D LUT.
I found that CIE 1964 10° on my QD-LCD matches well with my D65 1932 CRT. I use this cmf now for calibration on my QD-LCD.
Delta errors are always high on one of the primaries whenever I use a alternate cmf. I tried both CIE 1964 and CIE 2012. I guess because DisplayCal verification uses 1931 for verification?
HTML yes. Console logs are Argyll’s and are affected by obs choice.
And Judd-Vos 1978 2° on RGB OLED matches well with CRT but you need to use the correct xy D65 cordinates specific for these alternate colormatching functions. Sony’s cordinates in their paper for the WP in either Judd-Vos or 1931 both do not match the CRT and looks a tad bit more green. So use the D65 cordinates in Jeti’s paper for a better match.
They can be found here in this Jeti paper
https://www.jeti.com/files/content/support/downloads/papers/Lux%202017.pdf
CIE 170, CIE 2012, CIE 2006 I believe are all similar. Jeti software calls it CIE 2006 2° and DisplayCal calls it CIE 2012.
I measured both colormatching functions in both software’s with my Jeti and they spit out the same xy numbers. So they are the same just different names.
So there is no 1 size fits all cmf. You’ll need to experiment on different displays to see what gives you a good match. I use a 1931 D65 CRT as my reference target for all display.
I need to do more testing on my QD-OLED with CMF’s.
A side effect is that if you were an outlier… you cannot show it to a client.
A side effect is that if you were an outlier… you cannot show it to a client.
The thing is am I an outlier? We don’t know.
Many of the color matching studies and testing was done on a small sample size. And in research into alternate cmf like example CIE 170, it always concludes that it needs more on the field testing to see if they are good alternatives. The industry still uses 1931 because it hasn’t found a good replacement yet. Sony tried CIE 170 on the BVM HX-310 but found it didn’t work well to match their X300. So they went for a different approach.
Displays need an alternate wp to match the reference monitors. So how on earth do we go about this? Reference monitors themselves do not target D65.
Sony has their proposed WP for Dual Layer LCD’s and RGB OLED’s. So if everybody is wanting to be on the same page then they can calibrate to that regardless of metameric failure they see.
But their is no WP for WLED LCD, QD-OLED, QD-LCD. So these need to be matched.
And what are on the field calibrators to do for their home clients? Do they give them a custom wp specific for their eyes? Just like they give them custom luminace and gamma for their environment. Get their clients involved in the match process? Which means having a reference monitor in hand to match to? Which itself isn’t cheap to obtain. If not then the calibrator won’t be able to provide reference results for their clients. They can at best provide sort of a calibration but not refrence calibration.
There is lots of issues. And not really a standardized approach either. Especially when some pro’s tell me some do calibrate modern dual lcd displays to D65. And for RGB OLED’s matched them themselves avoiding Sony’s WP. FSI and Colourspace proposed this as a much more accurate approach.
Hello everyone !
I’m new here and also new to monitor calibration. I didn’t want to start new topic because I think my question could fit in this one.
I have 3 DELL U2518D monitors and from the box they look different. Two monitors are worm (but different) and one is cold when you compare whites. After calibration (I have colormunki smile) two monitors look good (but slightly different) and 3rd one looks worm.
I used default DisplayCAL settings (didn’t touched anything because I don’t understand meaning of any setting) and I manually adjusted R G B and brightness in measurement window (attached image step 1) until I brought all bars to marked position in center.
Can anyone suggest what settings should I change in DisplayCAL before measurement, should I use some of advanced settings which are turned off by default?
Thank you for your time.
Munki Smile is not very accurate and does not allow distributed corrections, hence even if these U2518D were White LED (blue + yellow phosphor) device may fail to get even only one of them to desired white.
If you managed to match 2 monitors use visual white point editor to match 3rd one using one of the others as reference. That’s all.
Thanks for you replay. I did what you said and at the end all 3 looks 98% the same, maybe even more.
I am cg artist, working on interior, exterior and product visualizations. Here is my work if someone is interested. https://sasaposloncec.com/
I have these monitors for more than 4 years. In next few months I’m planing to buy new one. What calibrator would be the optimal choice to buy? I hope usd1000+ is not only way to go.
Unless you are dedicated exclusively to calibrating (JETIs, Klein K-10), the best device for the bucks is Xrite i1Displaypro now labeled as Calibirte “something”, maybe it’s labeled now “Colorchecker Display Pro” or something close.
The cheap one ~160 euro is a colormunki display relabeled. As good as bigger brother bit slower and cannot use hardware calibration solutions.
The pro is about ~260€, no limitations. The Plus flavor is the same as pro but certifed for brightness over 1000nit.
Google “i1displaypro” under “images” and you’ll recognize it. Cheap one 160 euro locked for HW calibration, slow, but accurate, more expensive one 260 vanilla version. I’ll go for the pro, monitors with HW cal are common nowadays.
The key of having an i1d3 is that filters do now fade easily (mine has >10y) and it can be corrected in a distributed way, by sharing CCSS files with spectral power distribution of newer displays.An ADDITION (not an alternative) to that i1DisplayPro would be a cheap spectrophotometer like i1Studio (colormunki photo relabeled), about 450 euro?. You’d use it to correct i1displaypro colorimeter to whatever new display you have. You can also use it for printer profiling although is wastes more paper than an i1Pro”X” spectrophotometer whcih is way more expensive.
If you work on digital an deliver your work on digital (no print) I’ll skip the spectrophotometer since you can get colorimeter corrections for i1display pro (CCSS files) from community for almost every LED backlight in the market.Calibrite Display Pro HL on Amazon Calibrite ColorChecker Studio on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.Do not use Relative Colorimetric. If you are using DWM LUT GUI. Delta Errors are higher in measured colors, color checker and saturation measurements. Use Absolute Colorimetric. It’s alot more accurate. You can verify this in HCFR.
Issue is if you are targeting and alternate White Point using absolute will use the source colorspace white point which is D65 – 0.3127/0.3290.
If you want to target an alternate White Point with absolute Colorimetric, you’ll need to create a new source colorspace, you can do that with synthetic profile creator. And just input your White point cordinates. That way when you generate a 3D LUT with absolute it’ll use your alternate White Point while at the same time use the more accurate Absolute Colorimetric.
If you want to compare absolute and relative when using alternate white points, then generate relative normally, and create an absolute lut with the method I mentioned above and compare the two in HCFR. You’ll see absolute is more accurate.
This may be the issue why your displays aren’t matching.
Proffesional software targets absolute Colorimetric since it’s more accurate.
I bet he is using common grey calibration + proflling, hence what you wrote do not apply. He is suffering typical whitepoint mismatch on regular calibration, that’s all.
Also if he is using typical professional photo image editors for his work, then rendering intent is relative colorimetric as default option (even only option 99% times) when rendering to screen… and he will have no issues because relative colorimetric works as intened on rendering images to screen. It will be very stupid to render image to screen in abs colorimetric, prophotoRGB images edited in LR will have yellow 255 white on typical screen setup. That’s why professional image editors work (almost) always with relative white point intents.I mean his situation is totally different to what you tried (LUT3D simulation of one screen with your other screen) and whatever issues you had with collink.exe and its intents should be reported on argyllcms mailist if you wish them to be fixed.
Is it an issue though? Absolute Colorimetric is working as intended. Everything works. When I verify in hcfr everything is low in delta errors. I don’t really need to report much.
