- This topic has 18 replies, 3 voices, and was last updated 1 year, 8 months ago by
.
-
Posts
-
I was tasked to calibrate multiple monitors (same model) in our studio and have some issues when I try to create a CCSS file.
We have a fairly old ColorMunki Photo, which I believe is over a decade old. I also bought a new i1 Display Pro Plus this year. As a spectrometer, ColorMunki takes too long to calibrate and needs to be manually adjusted for self-calibration. So naturally, I thought, why not make a CCSS file and make my life easier? Sadly, the document and description didn’t solve some problems for me.
Here’s the problem:
- I know that when making a spectro correction, the monitor should be in native gamut, but what about RGB settings? Should I start the measurement with the default temperature setting or start with a deltaE<1, custom RGB settings on the monitor?
- Technically, on the same screen, after I made the CCSS file, under the same monitor setting, the spectrometer (ColorMunki Photo) and colorimeter (i1 Display Pro Plus) should measure a similar number. From what I tested, a monitor setting with spectrometer deltaE<1 white point will turn into a deltaE>9 if I change the device to i1 Display Pro Plus. When I load the CCSS file, the deltaE goes to 3, but it’s still not close enough.
- If the CCSS file created on the same monitor yields such a different result, how could I trust to use this CCSS file for the other monitors?
- I can’t upload the CCSS file online, it says “empty manufacture”. But the brand I use is in the list; it can even auto-fill the manufacture name.
I don’t even know which device should I believe now, judging from visually the spectrometer’s whitepoint seems more accurate, but how can I replicate this to the colorimeter.
Calibrite Display Plus HL on Amazon Calibrite Display Pro HL on Amazon Calibrite ColorChecker Studio on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.I was tasked to calibrate multiple monitors (same model) in our studio and have some issues when I try to create a CCSS file.
We have a fairly old ColorMunki Photo, which I believe is over a decade old. I also bought a new i1 Display Pro Plus this year. As a spectrometer, ColorMunki takes too long to calibrate and needs to be manually adjusted for self-calibration. So naturally, I thought, why not make a CCSS file and make my life easier? Sadly, the document and description didn’t solve some problems for me.
Here’s the problem:
- I know that when making a spectro correction, the monitor should be in native gamut, but what about RGB settings? Should I start the measurement with the default temperature setting or start with a deltaE<1, custom RGB settings on the monitor?
CCSS and matrix corrections operate on the basis of perfectly additive display so it should not matter. All in gamut colors, inclusing those tweaked RGB gains are or shoudl be close to a linear compination of true native primaries at a given brightness.
- Technically, on the same screen, after I made the CCSS file, under the same monitor setting, the spectrometer (ColorMunki Photo) and colorimeter (i1 Display Pro Plus) should measure a similar number. From what I tested, a monitor setting with spectrometer deltaE<1 white point will turn into a deltaE>9 if I change the device to i1 Display Pro Plus. When I load the CCSS file, the deltaE goes to 3, but it’s still not close enough.
i1d3 CCSS corrections will create a RGB to XYZ matrix mased on CCSS AND colorimeter sensivities stored in fimrware
colormunki photo self correction and QC is not close to the higher end 10nm devices of Xrite.
Hence you have two uncertainties. I’ll trust CCSS +i1d3 over raw munki photo: tust a brand new i1d3 spectral sensivity data under/over correcetd on some wavelengths by an “aproximate” SPD of display provided by munki, than a munki without traceable reference (with is the main diference over an i1pro2, excluding UV measurement for printing)
If you want a match to the munki photo use a matrix correction CCMX since it will create a XYZ to XYZ matrix from an XYZ reading form your i1d3 that used (by default) is own spectral sensivities as CCSS.
(CCMX matrix XYZ to XYZ) x ((RGB to XYZ of an ideal display with same SPD as filter) x RAW RGB readings from an i1d3) = XYZ reading from munki photo.It should be extremely close to the munki, although it may be further from actual coordinates. If you get 9dE with a CCMX there is something you did wrong, like some autodimming on display or stuff like that. You can try to plot CCSS to see thse kind of issues, W=R+G+B should hold on the graph
I am assuimg an RGB display not W-RGB OLED of stuff like that.
- If the CCSS file created on the same monitor yields such a different result, how could I trust to use this CCSS file for the other monitors?
Usually the CCSS is not the problem unles created in a wrong way.
- I can’t upload the CCSS file online, it says “empty manufacture”. But the brand I use is in the list; it can even auto-fill the manufacture name.
I don’t even know which device should I believe now, judging from visually the spectrometer’s whitepoint seems more accurate, but how can I replicate this to the colorimeter.
Explained above.
Thanks for your reply Vincent!
CCSS and matrix corrections operate on the basis of perfectly additive display so it should not matter. All in gamut colors, inclusing those tweaked RGB gains are or shoudl be close to a linear compination of true native primaries at a given brightness.
From what I tested both of them have around 3dE, there’s some minor difference so I’m not sure which one is right. Guess they are in the safe margin.
i1d3 CCSS corrections will create a RGB to XYZ matrix mased on CCSS AND colorimeter sensivities stored in fimrware
colormunki photo self correction and QC is not close to the higher end 10nm devices of Xrite.
Does this means i1d3 have an embedded spectral correction file in it. Do I still need to use Tools-correction-import colorimeter correction from vendor software. And for a specific display, I should load a specific ccss/ccmx file? For the monitor in this case there’s no public ccss file though.
If you want a match to the munki photo use a matrix correction CCMX since it will create a XYZ to XYZ matrix from an XYZ reading form your i1d3 that used (by default) is own spectral sensivities as CCSS.
(CCMX matrix XYZ to XYZ) x ((RGB to XYZ of an ideal display with same SPD as filter) x RAW RGB readings from an i1d3) = XYZ reading from munki photo.Should I leave observer as default CIE 1931 and check minimize xy chromatically difference?
It should be extremely close to the munki, although it may be further from actual coordinates. If you get 9dE with a CCMX there is something you did wrong, like some autodimming on display or stuff like that. You can try to plot CCSS to see thse kind of issues, W=R+G+B should hold on the graph
I am assuimg an RGB display not W-RGB OLED of stuff like that.
I did some research the monitor is using a BOE MV270QUM-N40 panel, so a WLED backlight ips.
That 9dE is when I adjust monitor setting with colormunki photo reading to a 1dE then switch device to i1d3(vendor correction imported)
Usually the CCSS is not the problem unles created in a wrong way.
That’s what I’m concerned. I thought even if munki photo isn’t right, the ccss file it created should yield a similar result, I’ll test a matrix correction tomorrow.
I’m not sure if I should trust this munki photo anymore. Maybe it deteriorates over time. Should I buy a new i1 studio as spectrometer for reference or just stick with the i1d3 for now.
Thanks for your reply Vincent!
CCSS and matrix corrections operate on the basis of perfectly additive display so it should not matter. All in gamut colors, inclusing those tweaked RGB gains are or shoudl be close to a linear compination of true native primaries at a given brightness.
From what I tested both of them have around 3dE, there’s some minor difference so I’m not sure which one is right. Guess they are in the safe margin.
Then all your previous claims are false. There is no 9dE. A mild error like 3dE may be due to de two uncertainties explained before.
CCSS 3nm + i1d3 likely to be more accurate than munki photo 3nm… but it is an statistical statement….
i1d3 CCSS corrections will create a RGB to XYZ matrix mased on CCSS AND colorimeter sensivities stored in fimrware
colormunki photo self correction and QC is not close to the higher end 10nm devices of Xrite.
Does this means i1d3 have an embedded spectral correction file in it.
No. It has its own spectral sensivities… but knows nothing about the SPD it is measuring.
Do I still need to use Tools-correction-import colorimeter correction from vendor software.
Yes, bceause you need to provide what is missing in my sentence above. Or import some CCSS from comunity or create a CCSS by yourself.
And for a specific display, I should load a specific ccss/ccmx file? For the monitor in this case there’s no public ccss file though.
Yes. For each display you are going to measure with an i1d3 youmust choose closest CCSS fro whatever you have at your disposal. If you do not own a munki phoot, choose by tech type.
If you want a match to the munki photo use a matrix correction CCMX since it will create a XYZ to XYZ matrix from an XYZ reading form your i1d3 that used (by default) is own spectral sensivities as CCSS.
(CCMX matrix XYZ to XYZ) x ((RGB to XYZ of an ideal display with same SPD as filter) x RAW RGB readings from an i1d3) = XYZ reading from munki photo.Should I leave observer as default CIE 1931 and check minimize xy chromatically difference?
If you want a numeric match, use a CCMX. It does not mean that it will be more accirate, just to get a closer match in i1d3 to whatever your munki photo measures. In a CCMX the munki photo is the only one “reference”. In a CCSS ther are two references, spectral sensivities (individual per i1d3) and a SPD sample (distributed).
It should be extremely close to the munki, although it may be further from actual coordinates. If you get 9dE with a CCMX there is something you did wrong, like some autodimming on display or stuff like that. You can try to plot CCSS to see thse kind of issues, W=R+G+B should hold on the graph
I am assuimg an RGB display not W-RGB OLED of stuff like that.
I did some research the monitor is using a BOE MV270QUM-N40 panel, so a WLED backlight ips.
That 9dE is when I adjust monitor setting with colormunki photo reading to a 1dE then switch device to i1d3(vendor correction imported)
You may have imported it but you were not using it. A widegamut display cannot be “WLED”, it must be something else, hence it looks like user misconfiguration and your claims about 9dE mismatch are not real.
Usually the CCSS is not the problem unles created in a wrong way.
That’s what I’m concerned. I thought even if munki photo isn’t right, the ccss file it created should yield a similar result, I’ll test a matrix correction tomorrow.
I’m not sure if I should trust this munki photo anymore. Maybe it deteriorates over time. Should I buy a new i1 studio as spectrometer for reference or just stick with the i1d3 for now.
From this last post it seems that you configured the i1d3 in a wrong way so all your devices should be ok… maybe because you did not know what you were doing. Since you have a custom made CCSS, plot it see it shape 3nm (WLED PFS phosphor? those 2 narrow peaks in red blured by the bad resolution, 3nm?) Then load the closest CCSS from vendor catalog which cannot be WLED/White LED if you have a widegamut.
You may have imported it but you were not using it. A widegamut display cannot be “WLED”, it must be something else, hence it looks like user misconfiguration and your claims about 9dE mismatch are not real.
I may have phrased it a bit confusing in previous post. I thought the vendor correction would be applied automatically, or it only updates the list of the correction dropdown menu.
That 9dE is just a reference, when I set the correction to none, it have 9dE difference. With the ccss file I create with munki photo it goes to 3dE. I’ll try matrix tomorrow.
For the panel type it says a-Si TFT-LCD, LCM, WLED backlight, guess it’s a W-LED with PFS phosphor type. If custom ccss not working I’ll try some of the ccss file in these families.
You may have imported it but you were not using it. A widegamut display cannot be “WLED”, it must be something else, hence it looks like user misconfiguration and your claims about 9dE mismatch are not real.
I may have phrased it a bit confusing in previous post. I thought the vendor correction would be applied automatically, or it only updates the list of the correction dropdown menu.
2nd, you’ll have to choose one manually, exactly the same as with any non HW cal calibration software (i1Profiler, unless a few selected models)
That 9dE is just a reference, when I set the correction to none, it have 9dE difference.
Expected and no issue, they are uncorrected measurements (corrected to a CCSS eaual to filter sensivity).
Accuracy of an i1d3 using distributed correction relies on the accuracy of sensivity curves in firmware vs actual ones, not exactly on sensivity curves matching CIE 1931 2 degree. If fimrware data matches actual filter curves and you provide a “good match” for actual SPD of display, i1d3 is accurate.With the ccss file I create with munki photo it goes to 3dE. I’ll try matrix tomorrow.
matrix should be a closer numerical match, although may not be the more accurate one. Choose the one you like most
For the panel type it says a-Si TFT-LCD, LCM, WLED backlight, guess it’s a W-LED with PFS phosphor type. If custom ccss not working I’ll try some of the ccss file in these families.
3dE vs munki photo i’ll say it’s working. Munki photo is not an actual “true reference”.
Regarding families, “PFS phosphor family 2017” CCSS is a correction of several but very diffent ones, it’ll aim for the smaller RMS E of all.
WLED PFS 95% is for P3 multimedia displays, smaller native green than P3 green.
HP z24x G2 is meant for WLED PFS with AdoberGB green, P3 red.
Macbook retina for WLED PFS displays with exactly P3 primaries (all Apple P3 displays)Sorry for the late response. I used matrix and toggled to minimize xy chromatic difference, and the resulting dE is lower than 0.5.
I know I shouldn’t use a decade-old munki photo as a reference, but at least all the monitors have a relatively similar reference point.
Thanks again for your in-depth reply!
Hi, to which mode do I have to set my panasonic jz oled for measuring the panel spd?
“Native” isn’t provided, only “dci-p3”, rec2020, “natural” (which is less saturated than rec2020)
Is the i1pro 2 sufficient for capturing the spd of an amoled notebook display correctly and will a calibrated non-wcg ccfl lcd provide the most reliable whitepoint for visual matching?
Thx!
I’ve done some research since last calibration. It’s not recommended to measure OLED panel with spectro with i1pro2 high res mode, even 2nm spectro isn’t that correct. It’s recommended to measure and calibrate a LCD monitor then use that as the target to visual match the white point on OLED panel.
Do you refer to rgb oled or woled panels, their SPDs differ substantially.
And lcd isn’t very specific, a wcg lcd might also have too narrow spectral bands.
AFAIK CRT or non-wcg CCFL displays are most suitable for calibrating with a >5nm spectro and can be used for visual whitepoint matching, but I might get corrected.
None of them will have the proper white point since i1 pro 2 can’t measure them correctly. Visual match to your calibrated LCD is the way.
Hi, to which mode do I have to set my panasonic jz oled for measuring the panel spd?
“Native” isn’t provided, only “dci-p3”, rec2020, “natural” (which is less saturated than rec2020)
Measure all, plot SPD, choose cleanest. But likely to use P3 as base even if you got a little channel mixing.
Is the i1pro 2 sufficient for capturing the spd of an amoled notebook display correctly
Should, high res. Also there is no other tool untill you spend much more $ and whatever AMOLED laptop you want to calibrate won’t be worth the investment because you will get into macbook XDR prices wchih are teh stae of teh art for laptop screens even if they lack of AdoberGB green & cyan.
and will a calibrated non-wcg ccfl lcd provide the most reliable whitepoint for visual matching?
Thx!
No… or yes, CCFL peaks are narrow… when you go off road you cannot assume statistics about you and std observer.
Measure all, plot SPD, choose cleanest. But likely to use P3 as base even if you got a little channel mixing.
May I ask why?
Thought, I should measure the panel’s native gamut, so no r/g/b channel overlapping allowed?
Measure all, plot SPD, choose cleanest. But likely to use P3 as base even if you got a little channel mixing.
May I ask why?
If there is no native gamut OSD preset… close the cleanest, the one with less mix.
Thought, I should measure the panel’s native gamut, so no r/g/b channel overlapping allowed?
But you said there is no one, and Rec2020 mode MAY expect rec2020 in -> firmware translator -> panel native RGB equivalent (with some topemapping) out.
If there is no native gamut preset, likely that P3 is the one with less mix, but as i said, measure them, plot spd and see the mix.
But you said there is no one, and Rec2020 mode MAY expect rec2020 in -> firmware translator -> panel native RGB equivalent (with some topemapping) out.
There is no color mode called “native”, but I can apply the rec2020 mode even with sdr material and it stretches the colors to a wide gamut leading to very saturated colors, more saturated than p3 or “natural”.
Anyway, I’ve tried to plot the rgb amoled ccss files as spd graphs with specplot, but it didn’t work and gives me strange results (bad cct, bad vct) when opening these with specplot.exe.
Haven’t tried displaycal yet, only hcfr set to “hi-res mode”, “videolut disabled”, dci-p3, GDI Fullscreen, rgb range 0-255
