- This topic has 88 replies, 13 voices, and was last updated 3 months, 2 weeks ago by
.
-
Posts
-
@Janos if your dealing with narrow spectrum displays (aka wide gamut) then you should check out this paper:
https://opg.optica.org/oe/fulltext.cfm?uri=oe-31-4-5670&id=525741
and use Graeme’s oled.cmf that was posted to argyll’s mailing list. This is the most up to date solution for color matching and deals with CIE metameric failure for these spd types.
Well, thanks for the reply.
I actually use ColourSpace for WOLED calibration (ArgyllCMS produces reddish near-black when a 3×3 comparation matrix is used for the i1d3), so I am technically limited to CIE 1931 at the moment anyway. I am just curious about if and how we could theoretically figure out the x,y values for Rec709 and Rec2020 gamut targets in proposed alternative CMFs (especially since we can’t just measure back Rec2020 on legacy display techs using a new CMF…).
Although it would be nice to have a tool that helps me figure out the “offset WP” for a generic WCG display. It’s tedious to do by “eyeballing”. And my eyes seem to be very sensitive to green on WCG IPS LCDs (others usually agree that those are greenish compared to most other displays when set to standard D65 but once they tune it for their eyes, I still see them VERY greenish).
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.For my LG C1 I use oled.cmf and i1pro2 to create the ccmx for my i1d3. For calibration I use the methods developed in the LG C8 Lut thread.
When targeting D65, the white point is visually very close to the apple studio display and HP dreamcolor 27x G2. Other people on the mailing list also report good results. In the past, when I used woled CCSS I got signficantly more yellow white point. The big improvement came from oled.cmf
I have no issues with black point hue (shadow) when targeting 2.4gamma absolute with blackpoint correction at 100%. https://argyllcms.com/doc/dispcal.html#k
https://www.freelists.org/post/argyllcms/Observer-optimized-for-measuring-OLEDs
maybe this link can become a sticky for others to find
https://www.freelists.org/post/argyllcms/Observer-optimized-for-measuring-OLEDs
maybe this link can become a sticky for others to find
My understanding of the linked text is that Graeme basically tried to construct these “Korean OLED CMFs” from the empirical Korean research data in a way that aimed to provide a close numerical match of the actual standard D65 illuminant and the ~Rec709 R,G,B primary colors (as observed on native ~Rec709 gamut displays that use CRT/PDP/CCFL-like phosphor) x,y chromaticity coordinates between CIE 1931 and Korean-OLED-CMF. Thus, in theory, I can use the standard Rec709 R,G,B,W CIE 1931 x,y coordinates as 3DLUT calibration targets with this Korean-OLED-CMF and expect a fairly great match with a native ~Rec709 CRT/PDP/CCFL display (calibrated with either CIE 1931 or Korean-OLED CMF). And I guess, since DCI-P3 and Rec2020 definitions are also based on CIE 1931 and we have no better reference points than native ~Rec709 CRT/PDP/CCFL primaries (where CIE 1931 still worked but stopped working beyond) to pick for CMF derivation, I can also use this “wide band matched” Korean-OLED-CMF for DCI-P3 and Rec2020 targets (this CMF sort-of does what I previously mentioned: “extrapolate Rec2020 primary targets based on Rec709 matching”).
Did I get this right…?
As for the colored near-black… It’s somewhat possible that my i1d3p is not as great as the average. I recently noticed that it always tends to measure the near-black gray-scale as somewhat bluish on several kinds of displays (including LG WOLED with neutral 1D and 3D LUTs, EIZO IPS LCD with neutral 3DLUT, Sony RGB OLED PVM-X550 monitor in native gamut and Jodd-Voss-D65-adjusted WP, etc). However, this doesn’t seem to create any visible issues on the end results in most cases when I create a 3DLUT with ColourSpace (the pre-, and post-cal charts tend show roughly equal bluishness but the displays mostly look visually fine). But I also noticed that even ColourSpace 3DLUTs can result in reddish near-black on some LG WOLED displays (this is a strange phenomenon because it’s like 3 out of 5 LG 55CX with the same main firmware look fine after ColourSpace calibration but the same 2 will always be reddish if I re-profile all 5, so I attributed this to display differences, like a “panel lottery” kind of thing, extended to the whole unit, like low-level panel driver firmware revision or date of manufacturing, possibly the production line those panels came from, main board hardware revision, etc – I don’t know which one, I am just speculating). But it’s possible that based on the degree of measured bluishness, ColourSpace sometimes classifies this as probe-imperfection and other times it decides to take it at face value and tries to compensate. The workaround for the problematic units is usually a manual override by editing the near-black part of the 3DLUT in Resolve to bring it back to “native” or to eye-ball match the darkest shades to the somewhat brighter shades.
I wish I had (or could at least temporarily rent) a reference grade colorimeter (Klein or CR) to investigate this further. On one hand, it’s not really viable for me to buy reference-grade instruments (I operate in a small and relatively poor country, so I would need to make this my main job and work hard just to get the price of the probes back). On the other hand, my educated guess is that given the limitation of CMFs, most display hardware, and even most calibration software solutions, the end results wouldn’t be nearly as much better as the price premium on the better probes (and the license levels on the software that can operate those probes). Alas, I considered buying a fresh Calibrate Display Pro HL but it looks like their near-black sensitivity is actually worse than that of the older X-Rite Diplay Pro (Plus).
At this point, I am not even sure which one to trust more in absolute terms: i1d3p+ccss(hires.from.a.refence.probe), i1pro2, i1pro2_HiRes(ArgyllCMS.HiRes). These all produce different results. This old review suggests that i1d3+referenceCCSS is better than the i1pro: https://www.drycreekphoto.com/Learn/Calibration/MonitorCalibrationHardware.html But many “high profile” calibrators advise to use an i1pro (to create a matrix-style correction for the i1d3) over an i1d3+reference.CCSS. When I experimented, I found that my i1d3p measures closer to my i1Pro2 when it has no matching CCSS compared to having a CCSS created with the same i1Pro2 (which is a bit strange, given how any potential inaccuracy of the i1Pro2 is “baked into” the CCSS it creates, although the i1d3p obviously uses the CCSS in a very different way compared to how the i1Pro2 uses it’s built-in factory calibration curves…).
But, “at the end of the day”, the observer metamerism error seems to be comparable in size to whatever inaccuracies these cheaper probes might have. So why pay ~5x for a better probe and still end up “eyeballing” the white point…?
At any rate, I will give this new Korean-OLED-CMF a try. However, I think I would have preferred if Graeme used the raw data of the CIE 2012 empirical tests instead of the Korean experiments in a similar fashion (actual D65 illuminant and wide-band R,G,B matched). The Korean study itself mentions that the presented results should not be used alone because the sample size is not representative (most of the participants were young/ish Asian women, no other ethnic groups were included, and we know the sunlight looks a bit different based on geographical location, the eye ages, etc).
CCSS + i1d3 is not 100% accurate on the fact we dont know if i1d3 sensitivity was indivdually verified, I’ve read claims theyre made in batches.
In my experience CCMX from i1pro2 + oled.cmf gave the best result:
https://www.freelists.org/post/argyllcms/Observer-optimized-for-measuring-OLEDs,1
You should do one of the following with a CMF:
1) Create a .ccmx for a particular display and a particular colorimeter and
that CMF. i.e. ccxxmake -o oled.cmf etc. The .ccmx then has the CMF baked
into it, and so you don’t need it anymore, just use the .ccmx with dispcal
and dispread.2) If you are using an i1d3 and a .ccss, use dispcal -Q oled.cmg and dispread
-Q oled.cmf
You don’t need it after that.3) If you are using a spectrometer, use dispcal -Q oled.cmf and either dispread
-Q oled.cmf
or colprof -o oled.cmf or both.[ Technically the CMF is needed where the spectral to colorimetric conversion
is done. For a colorimeter using a .ccmx that’s when the reference
spectrometer
measures the display. For an i1d3 colorimeter that’s when the .ccss is turned
into a 3×3 matrix by the driver. For a spectrometer that’s when the spectral
measurement
is turned into colorimetric values within dispcal, in dispread, or in colprof
if dispread provides spectral values to it in the .ti3 file. ]Another reason I would prefer using CCSS with ArgyllCMS over CCMX for WOLED is that LightIllusion and Portrait Display say that WRGB needs something like the “Bonder method” (multiple 3×3 matrices depending on expected RGB->WRGB, a.k.a. “white substitution” outcome since R+G+B!=W). To be honest, I am not entirely sure how much that actually matters with the overall accuracy one can expect with the X-Rite probes. However, using a CCSS can theoretically give similar results to the “Bonder method” (although I am not sure if a given SPD curve is picked from the CCSS that is closest to the sample measured but I guess that’s the case and not an overall average is used).
By the way, I am relatively pleased with the results of what ArgyllCMS does nowadays when I give it 10^3 measurements of a somewhat “broken”, uncalibrated display (it’s an old CCFL LCD with a significantly yellowish gray-scale and prominent near-white crush, plus low-quality internal processing which prompts me not to use the internal white point or contrast controls either). The 3DLUT created from an XYZ profile seems to correct most of the gray-scale (although the near-black color temperature is less nice and the near-black gamma isn’t that great – something that might improve with a bigger patcher and/or iterative 1DLUT calibration before profiling) when the Absolute intent is selected and in-gamut mixed colors are fine as well.
However, feeding it with a high resolution (like 51 steps of) R,G,B,W measurement set (so no mixed colors included at all) to create an XYZ profile still produces something that makes my eyes roll back 180° in their sockets like Satan emerged from the floor. (As I understand, in theory, all you would need to measure on an additive RGB LCD is the R,G,B ramps with as much resolution as you can and all colors could be calculated from that because XYZ is additive as well but most software will refuse to work without at least a single white(/gray) patch, yet even also feeding it hi-res gray-scale measurements but still no mixed colors often results in crazy outcomes and/or makes the LUT generation crash/hang forever ).
The reason I care about these cases is because WOLEDs look “broken” in HDR (W-boost) mode and it’s easier to test things on an LCD (also avoids building up IR on the WOLED by torturing it in HDR mode with experimental measurements).
Does anybody happen to have a spreadsheet or script to convert LightIllusion’s spectral CSV files into ArgyllCMS CCSS files?
LG (Ben Bodner) and Sony (WP Offsets) are cross referenced in the paper
I think the paper’s CMF is developed by Samsung, at least the funding. If you google the authors they are Samsung employees. Since samsung does not use woled, they developed a more universal CMF.
Samsung buys some WOLED panels from LG, so it’s probably not completely irrelevant for them.
Ok, I managed to profile both SDR and HDR using my custom CCSS for the i1d3p created with an i1Pro2 on an LG C9 (with some caveats: I forgot to add custom patches to the ccmx.ti3 and I couldn’t profile the HDR mode in VRR mode – so I how I usually feed it – because I had to use an HDFury Integral to inject fake HDR metadata and it’s not VRR compatible) using this “Korean OLED CMF” with a 10^3 patch set.
SDR doesn’t look too much different from a profile with factory LUTs and the WP adjusted in the SM to Judd-Voss D65 (using the i1Pro2 and the FSI proposed JV coordinates, not the D65 calculated ones but those are very close). Actually, the white point is not very far but even primary colors look definitely different (for example, Red is significantly less saturated while blue is a bit more saturated). Overall, the grayscale homogeneity is fine. The near-black has a small tint (strangely not red) but ColourSpace also leaves a similar amount of tint when I use a 10^3 patchset (even 17^3 does, only TEDD’s custom patchset works nicely and with the factory 1DLUT left in place instead of using a neutral 1DLUT).
But HDR is a small catastrophe. First of all, don’t get me wrong, I couldn’t get any really usable results out of ColourSpace either (and I tried much harder than this) but I managed to get close with a hand-curated patchset and aggressive drift compensation (most colors looked fine, like sRGB colors outputted by Windows 11’s sRGB->Rec2020 conversion but there were some “glitches” on the highly saturated and bright ends which I didn’t notice until I started scrolling through an HDR movie with CGI animated scenes). I would even say most of the grayscale is either on par or even somewhat better than what I got out of ColourSpace using 10^3 profiling but the near-black has a crazy amount of red tint with the ArgyllCMS+DisplayCAL created Rec2020+gamma2.2 3DLUT. Strangely enough, I see no “glitches” on the wider/upper ends (I scrolled through the aforementioned HDR movie scene and it looks fine, save for the crazy near-black red-tint). So it’s somewhat promising. Maybe using aggressive drift compensation with Alrgy+DC as well (I didn’t want to spend too much time on this at first and I had a bad experience with ArgyllCMS’s drift compensation in the long past, so I completely omitted it for this test) and/or using a bigger patchset (possibly hand-curated to include numerous dark points) might just work. -> Please let me know if you have a battle-tested LG WOLED HDR patchset! (Alternatively, I could try to hand-edit the red-tinted region with Resolve for some okay-ish result.)
As for the custom CMF… I would need to fire up my old Pioneer Kuro, create a 3DLUT for it, and compare some scenes to tell if the new CMF gives a better or worse match overall (I was skeptical about getting anything useful out of Argy+DC for this display, so I started relatively small but I would need to re-profile with a bigger patch set before that comparison would make much sense).
However, I see an elephant in the room next to me: I would wager that pretty much nobody in the film/photo/game/etc industry will ever use this particular CMF in production. So even if this gives a better match to PDP Rec709 colors but the industry uses either standard D65 white with CIE 1931 or JV-AltWP with CIE1931 then what’s the point besides entertaining our curiosities? 🙂
Ah, I made a small mistake with the relative comparison above. I shouldn’t have compared “ArgyllCMS 3DLUT with Korean_OLED_CMF using standard Rec709 coordinates” to “LG factory LUTs + JuddVoss_D65_WP” but rather to “ColourSpace 3DLUT with JuddVoss_D65_WP”. Now, those are pretty close (both in white balance and saturation). There are some small differences but much smaller (and some small difference is expected from the different colorimeter correction methods alone). I can’t really tell which one matches better with the CCFL LCD. The fact that this old LCD has fairly poor homogeneity makes this a little harder but these all being fairly close to one another in general also makes it harder to judge.
Since JuddVoss isn’t expected to provide an absolute 100% match between CRT and WOLED white either, this Korean_OLED_CMF achieves something very close when fed with standard Rec709 coordinates as targets (including the standard CIE 1931 x,y D65 white coordinates instead of back-measured or re-calculated x,y white coordinates like in case of other non-1931 CMFs) is very promising (not having to use unique coordinates can make things easier).
Now this is very peculiar. If I apply the HDR 3DLUT to a grayscale image with Resolve and leave the hardware 3DLUT at neutral, the grayscale is fine (nothing to break open a campaign for but far from “obviously broken”). If I upload it to hardware, it’s a complete mess near black (very very red). I tried exporting the 3DLUT from DisplayCAL in both BMD format in 33x33x33 and 65x65x65 sizes and in DeviceControl format (this one is probably closer to what the display expects) before importing them to ColourSpace and uploading them to hardware (I am not sure if the import process might “reinterprets” the LUT but this workflow worked with the SDR 3DLUT).
This also means I have no idea how to try “nudging it to place’ by naked eye and hand in Resolve, since I see nothing obviously wrong in Resolve (preview and scope included).
Going through the video quickly, they are using CR-300 reference meter to create a bodner profile for the CR-100 colorimeter.
Regarding bodner method, I refer you to this post that questions its effectiveness vs FCCM
Regarding CCSS vs Matrix. Ive been experimenting with CCSS and for me I get best results when I take CCSS at native panel response 192,192,192 and g2.2 and calibrate with the panel left at 192,192,192 without any precal using oled.cmf. By changing the temp gain in the service menu the panel is no longer at native response (since oled does not have a backlight does this change CCSS accuracy?)
@Janos two days ago Portrait released a new 1 hour long “how to calibrate C2” video. I havent watched yet but maybe its of some interest to you, youtube. com/watch?v=uVfL0AvY8q0
Well, thanks but it doesn’t really interest me. I know how CalMAN handles LG TVs and I stopped paying to Spectracal years ago. I would rather “bribe” Greamme with donation money to implement extra features into AregyllCMS for WOLED calbration (if that could help). 🙂
Regarding CCSS vs Matrix. Ive been experimenting with CCSS and for me I get best results when I take CCSS at native panel response 192,192,192 and g2.2 and calibrate with the panel left at 192,192,192 without any precal using oled.cmf. By changing the temp gain in the service menu the panel is no longer at native response (since oled does not have a backlight does this change CCSS accuracy?)
That’s what I do as well with CCSS. I think using 192,192,192 is best because that’s where you theoretically get closest to the state where only the W sub-pixel is in use (or is in use relatively the most compared to the other 1 or 2 R,G,B componenst that might be mixed in). I read somewhere something like “the factory R,G,B gains are alligned to match the native ~10’000 K white temperature of the W-subpixel” (but it’s also said that “no more than 3 sub-pixel is used at the same time”). And it has always been the general advice to use the native R,G,B primaries (measure withouth gamut emulation) for sensor profiling.
Although, LightIlusion puts extra colors into their EDR/CSV files. I didn’t check but I gess they include C,M,Y and may be the 50% saturated 6 patches (to better capture where and how W and RGB crosses over).
I experimented with WOLED HDR profiling but, for some reason, the actual end results don’t always reflect the excpectations based on indirect simulations. For example, when I create two 3DLUTs with ArgyllCMS+Displaycal: Rec709 D65 g2.2 and Rec2020 D65 g2.2 and I apply them with Davinci Resolve, the converted grayscale look *very* similar but when I upload them to the hardware, the the Rec709 3DLUT look sane whereas the Rec2020 3DLUT produces a heavy tail colored tint across a fairly wide range on the lower end. May be I should try mesuring in PQ rather than gamma space but that’s tricky because then I have to provide a peak luminance target during 3DLUT creation and the end-result is not known before the 3DLUT is applied and the calibrated white luminance is measured back.
By the way, you can grab “reference” SPDs for ~50 different displays from here:
The data in these CSV files is always interpolated/extrapolated to 380 – 780 nm range at 1nm resolution regardless of what the intrument originally reported, so it shouldn’t be hard to convert these into ArgyllCMS compatible CCSS files. Only <=5nm, expensive spectros were used to create these. However, I don’t think they use 192,192,192 WP for WOLED but rather factory Warm2, Judd-Voss D65, or custom eye-matched AltWP because LigtIllusion (and “loose associates”, plus the “just follow the F’in manual” users) recommend leaving the 1DLUT at factory state and adjusting the SM Wamr WP to Judd-Voss D65 or “eye-match to YOUR reference display”). Based on my experience, the i1d3 probes I came across produce virtually the same results with unidentical but fairly close CCSS files (for example, the LG C8 and CX use different sub-pixel structure, yet using these two CVS files in ColourSpace give the same result within the expected short-term repeatability range of the i1d3), so I am not sure if using these might give significantly better results. If they do produce different results compared to a home-made CCSS with 4 patches, I guess that’s probably because these include >4 samples and not because the underlaying measurement resultion and accuracy is superior to an i1Pro.
