- This topic has 29 replies, 5 voices, and was last updated 5 days, 6 hours ago by
.
-
Posts
-
Why did he ask for a report? lol . No offense meant. To me I seen them enough. If there is comments on it that is fine. When I rerun it the 73 was under 2. It is pointless to discuss it since I will adjust it anyway. I observed the blue 100% xy is way off so it is not goign to align. It could be internal problem too. 60% is fine 70%is high and 80 % is fine. 60 was where I needed to adjust hue and then fine tune for the low end since it was worse in the low end. Lows are important and highs sometimes are hard to see. Close is better in high.
This could help with useing HCFR. I did it just for help. He needs to send a report was a message from Vincent. Sorry if I was off topic.
Oops. He wanted a ICC profile. I see no purpose to that. You are supposed to make your own or use a factory one. I used curves plus matrix for profile but the report says that.
Yeah I’m not sure why he asked for a icc lol. But here it is if you want to see it:
https://www.cloud-cello.com/s/CS3EMjR8z3m3PRH
you’re both clearly incredibly knowledgeable, but I have no idea what even half of what either of you are talking about means. Maybe there are some patches that don’t come out accurate enough for either of you in Calibrite Profiler or something? To my eyes, it turned out to be very comparable to my hardware-calibrated more “professional” display. It’s software calibration with a icc, so of course it’s not going to be quite as good, but it’s extremely close (again, just to my eyes).
the most important improvement as I see it is my capacity to calibrate my QD-OLED without seeing near-black levels raised too high. This was happening in previous attempts over a year ago, and thankfully, that no longer seems to be the case. The colors have always been pretty on point to my eyes.
I do color-sensitive work, but not to the level of a color-grading artist. Perhaps there are use cases where super-accurate is an absolute necessity. You both seem to only be interested in calibration if it is absolutely flawless. Maybe for that use case, Profiler won’t work? Maybe even a colorimeter isn’t up to the task of meeting your expectation and a tripod-mounted light meter is more necessary, I’m not sure. But I thought I’d come and just share what I’ve learned.
always a pleasure to see the passion you both have for the practice. It’s a rare and niche craft, so it’s cool to see you both discuss it and share what you know here online (even if I don’t understand the half of it lol).
Yeah I’m not sure why he asked for a icc
To evaluate the accuracy of the various corrections stored in the profile.
DaniJ,
Wouldn’t that only be useful if he had access to the exact QD-OLED I made the icc for? Otherwise, it’ll just be a series of corrections, none of which are particularly useful unless applied to the exact panel, the exact display they were custom-written for. Please correct me if I’m wrong, but that is my understanding of how icc profiles work, and why I assume both Ben and I were confused
There are certain issues one can spot just by looking at the various information in a profile, like:
- Measured color primaries being way off, indicating the measurement was incorrect
- Low bit depth VCGT
- 1D/3D LUTs that generate a lot of artifacts
MPG321UX_OLED_26-05-22_V3 doesn’t have these issues. They only thing I would have done differently would be to use 2.2 (or 2.4) gamma and avoid lifting the blacks for sRGB.
Yes, 2.2 gamma was my initial approach. Unfortunately, it crushed blacks on my particular display. Opting for sRGB corrected this. It’s not a perfect solution but it’s pretty darn close
Hey just thought I’d update you. For some reason, my near-black values were off when using 2.2 gamma ONLY in Calibrite Profiler. Now that I’ve tried in DisplayCal, and managed to use a QD-OLED profile correction file from an online source, the gamma tracking is extremely accurate using a 2.2 target. Now, it’s what we’d expect, and the opposite of what I had before: 2.2 is the correct target, and sRGB curve will instead crush blacks. So at least DisplayCal is behaving as expected (not sure what’s going on with Calibrite Profiler).
Now, I’m dealing with a new issue, which is that colors are generally a bit desaturated on my QD-OLED after calibration. This is less noticeable after a calibration with DisplayCal vs the previous attempts in Calibrite, but it’s still noticeable. Colors just aren’t quite right, and I’m not sure how to fix it. I would greatly appreciate any thoughts or ideas. The issue is that the ICC report after it’s done calibrating claims total, accurate coverage of sRGB (with plenty of volume to spare), but when pulling up sRGB content in color managed apps, and comparing between my QD-OLED and hardware-LUT-calibrated reference display, the reference is more saturated than the QD-OLED. In other words, the calibration looks the way it does because the software (DisplayCal) and hardware (the colorimeter) both seem to think it’s accurate, even though it very clearly is not.
To be extra clear: I’m not talking about a massive drop off in saturation. It looks to me sort of like the equivalent of viewing 100% sRGB vs 90-95%. Colors are just a tad duller everywhere.
Hey just thought I’d update you. For some reason, my near-black values were off when using 2.2 gamma ONLY in Calibrite Profiler. Now that I’ve tried in DisplayCal, and managed to use a QD-OLED profile correction file from an online source, the gamma tracking is extremely accurate using a 2.2 target. Now, it’s what we’d expect, and the opposite of what I had before: 2.2 is the correct target, and sRGB curve will instead crush blacks. So at least DisplayCal is behaving as expected (not sure what’s going on with Calibrite Profiler).
Greyscale patch count in CalibriteProfiler (CP) is more limited. Inspecting CP’s profile in VCGT may shed light on this… maybe it was crushed on monitor (near linear VCGT on near blacks) and due to low number of patches CP did not correct it (it did not measured this issue) or maybe it was a result of CP VCGT.
Now, I’m dealing with a new issue, which is that colors are generally a bit desaturated on my QD-OLED after calibration. This is less noticeable after a calibration with DisplayCal vs the previous attempts in Calibrite, but it’s still noticeable. Colors just aren’t quite right, and I’m not sure how to fix it. I would greatly appreciate any thoughts or ideas. The issue is that the ICC report after it’s done calibrating claims total, accurate coverage of sRGB (with plenty of volume to spare), but when pulling up sRGB content in color managed apps, and comparing between my QD-OLED and hardware-LUT-calibrated reference display, the reference is more saturated than the QD-OLED. In other words, the calibration looks the way it does because the software (DisplayCal) and hardware (the colorimeter) both seem to think it’s accurate, even though it very clearly is not.
You need to verify is HW calibraed display is behaving as it should vs its reference profile on that OSD mode. Same on QD-OLED. Display and default display ICC profile must match, otherwise ICC color management does not work.
Also check legal vs full video levels.
You provide no information for further diagnosis… but this is usually user’s fault (levels or ICC mismatch vs current OSD display mode)
Did you use a CCMX profile correction found online?
Hi DaniJ, yes I did. I’ve tried a variety, and some are more consistent than others. My methods have involved testing in DisplayCal, Calibrite Profiler, and even the Wacom Color Manager application (which is for all intents and purposes the same as xrite’s old calibration software, repurposed for the additional function of hardware LUT calibration on Wacom professional displays).
On the Wacom/xrite software, I can select an “OLED” generic correction profile, and the same goes for Calibrite Profiler. It seems Calibrite still hasn’t taken the time to integrate a proper QD-OLED correction profile. As for DisplayCal, as always, I need to find a correction profile for my monitor, the MPG 321URX, from an online source. Although they’re not all perfect, there are thankfully enough of them that I could at least find a few that get as close to reference as Calibrite’s software. Sadly, that’s as far as it’ll go, and as I mentioned before, Calibrite isn’t perfect.
When using Spectral correction profiles in DisplayCal from community sources, the near-black performance is consistently poor, elevated above the reference target. There are only two matrix-based correction profiles among the files provided by the online community, and thankfully, those correct the problematic TRC in the low region. I don’t know enough to explain why, but with my particular set up, using a colorimeter to calibrate my display on MacOS, the matrix profiles are clearly better than the spectral ones. However, they still exhibit the same issue as when calibrating via Calibrite’s software: undersaturation, minimally in blue, somewhat in green, and most prominently in red.
Also, Vincent, to address some of your statements/assumptions/theories:
“You need to verify is HW calibraed display is behaving as it should vs its reference profile on that OSD mode. Same on QD-OLED. Display and default display ICC profile must match, otherwise ICC color management does not work… this is usually user’s fault (levels or ICC mismatch vs current OSD display mode)”
I’ll address this first. It’s clear to me that in order for you to take what I’m saying seriously, I need to explain in words, as clear as day, that I have verified my monitor settings, ensured everything matches, and confirmed that my hardware-calibrated display is an accurate representation of reference. I can assure you, it is. I have also compared it to a second rather accurate display, the MacBook Pro’s XDR display, and they both match up to my eyes. If I could bring you into my apartment to prove this to you myself, I’d love to crack open a few cold beers and we could take a look together, but something makes me doubt that’s an option haha. You’ll have to take my word for it, and assume the display is, in fact, reference. Otherwise, I doubt our conversation can be constructive.
“Greyscale patch count in CalibriteProfiler (CP) is more limited. Inspecting CP’s profile in VCGT may shed light on this… maybe it was crushed on monitor (near linear VCGT on near blacks) and due to low number of patches CP did not correct it (it did not measured this issue) or maybe it was a result of CP VCGT.”
If I’m understanding you correctly, you’re assuming that Calibrite Profiler doesn’t use enough dark patches in the near-black region to diagnose crushed blacks, and so your theory is that the black levels actually SHOULD be raised to compensate, and Calibrite is simply failing to do so. I’ll explain why I believe this assumption is incorrect:
- Again, I’m comparing the monitor visually to reference. Assuming you can hop on board with what I’ve stated above regarding the accuracy of my reference, hardware-calibrated display and display XDR, you can hopefully understand why seeing a sudden, sharp lift in near-blacks on my OLED, by comparison, is a pretty obvious red flag. If you assume the blacks are crushed on the monitor, you’d have to also assume that they were somehow crushed on the Display XDR and the reference hardware-calibrated display as well, because the result in Calibrite, at least for low-luminance TRC, tracks extremely close to those reference displays. So take your pick: either one monitor is wrong when using one specific calibration technique, or all three are.
- I get it, you don’t care much for Calibrite Profiler. You believe DisplayCal to be far superior. I won’t argue there. But that concern quickly becomes irrelevant when DisplayCal also calibrates to the referenced TRC. I will reiterate: using matrix-based correction profiles for my QD-OLED in DisplayCal results in identical behavior to Calibrite’s calibration, Wacom Color Manager’s calibration, my reference display’s calibration, and a MacBook Pro’s factory-calibrated Display XDR. That’s an insurmountable pile of evidence placed against the spectral profiles some people in the online community are using for their QD-OLED monitors.
“Also check legal vs full video levels.”
I’m not sure what this means, could you please clarify? Bear in mind I’m on Apple Silicon hardware, so LUT calibration isn’t a system-wide option unless the monitor has the internal hardware functionality and a software that can control it (such as my Wacom Cintiq Pro 24″ reference display, using Wacom Color Manager for hardware calibration)
“You provide no information for further diagnosis”
What other information would you like me to provide?
Oh, and I forgot point #3 in my list above: It’s also worth noting that Calibrite actually USED to have the black raise issue. Since last year, after some software updates, that’s no longer the case. Just another piece of evidence to point towards the near-black behavior I assume to be correct, IS correct.
So to summarize:
#1) multiple reference-grade displays demonstrate the visual behavior I have noted in my own head as “reference”
#2) DisplayCal can also achieve this correct behavior, when using matrix-based correction profiles during calibration (and avoiding those which are spectral)
#3) Calibrite USED to have the issue, but it’s since been updated to correct for it. In all probability, this was an intentional correction on their part, especially when compiled with points 1 and 2
Did you use a CCMX profile correction found online?
Hi DaniJ, yes I did. I’ve tried a variety, and some are more consistent than others. My methods have involved testing in DisplayCal, Calibrite Profiler, and even the Wacom Color Manager application (which is for all intents and purposes the same as xrite’s old calibration software, repurposed for the additional function of hardware LUT calibration on Wacom professional displays).
On the Wacom/xrite software, I can select an “OLED” generic correction profile, and the same goes for Calibrite Profiler. It seems Calibrite still hasn’t taken the time to integrate a proper QD-OLED correction profile. As for DisplayCal, as always, I need to find a correction profile for my monitor, the MPG 321URX, from an online source. Although they’re not all perfect, there are thankfully enough of them that I could at least find a few that get as close to reference as Calibrite’s software. Sadly, that’s as far as it’ll go, and as I mentioned before, Calibrite isn’t perfect.
When using Spectral correction profiles in DisplayCal from community sources, the near-black performance is consistently poor, elevated above the reference target. There are only two matrix-based correction profiles among the files provided by the online community, and thankfully, those correct the problematic TRC in the low region. I don’t know enough to explain why, but with my particular set up, using a colorimeter to calibrate my display on MacOS, the matrix profiles are clearly better than the spectral ones. However, they still exhibit the same issue as when calibrating via Calibrite’s software: undersaturation, minimally in blue, somewhat in green, and most prominently in red.
CCSS translate to a 3×3 matrix=> CCSS_MATRIX x 3_vector_RGB_measurement = CIE XYZ
CCMX are a (near identity) 3×3 matrix => CCMX x DEFAULT_CCSS_MATRIX x 3_vector_RGB_measurement = CIE XYZ
Thus it is applying the same correction to all colors, so you must be doing soemthing wrong. Also CCMX are not portable between displays so whitepoint may result in a color tint.
Also, Vincent, to address some of your statements/assumptions/theories:
“You need to verify is HW calibraed display is behaving as it should vs its reference profile on that OSD mode. Same on QD-OLED. Display and default display ICC profile must match, otherwise ICC color management does not work… this is usually user’s fault (levels or ICC mismatch vs current OSD display mode)”
I’ll address this first. It’s clear to me that in order for you to take what I’m saying seriously, I need to explain in words, as clear as day, that I have verified my monitor settings, ensured everything matches, and confirmed that my hardware-calibrated display is an accurate representation of reference. I can assure you, it is.
No matter what you say, it needs to be measured.
I have also compared it to a second rather accurate display, the MacBook Pro’s XDR display, and they both match up to my eyes. If I could bring you into my apartment to prove this to you myself, I’d love to crack open a few cold beers and we could take a look together, but something makes me doubt that’s an option haha. You’ll have to take my word for it, and assume the display is, in fact, reference. Otherwise, I doubt our conversation can be constructive.
No matter what you say, it needs to be measured.
“Greyscale patch count in CalibriteProfiler (CP) is more limited. Inspecting CP’s profile in VCGT may shed light on this… maybe it was crushed on monitor (near linear VCGT on near blacks) and due to low number of patches CP did not correct it (it did not measured this issue) or maybe it was a result of CP VCGT.”
If I’m understanding you correctly, you’re assuming that Calibrite Profiler doesn’t use enough dark patches in the near-black region to diagnose crushed blacks, and so your theory is that the black levels actually SHOULD be raised to compensate, and Calibrite is simply failing to do so. I’ll explain why I believe this assumption is incorrect:
- Again, I’m comparing the monitor visually to reference. Assuming you can hop on board with what I’ve stated above regarding the accuracy of my reference, hardware-calibrated display and display XDR, you can hopefully understand why seeing a sudden, sharp lift in near-blacks on my OLED, by comparison, is a pretty obvious red flag. If you assume the blacks are crushed on the monitor, you’d have to also assume that they were somehow crushed on the Display XDR and the reference hardware-calibrated display as well, because the result in Calibrite, at least for low-luminance TRC, tracks extremely close to those reference displays. So take your pick: either one monitor is wrong when using one specific calibration technique, or all three are.
- I get it, you don’t care much for Calibrite Profiler. You believe DisplayCal to be far superior. I won’t argue there. But that concern quickly becomes irrelevant when DisplayCal also calibrates to the referenced TRC. I will reiterate: using matrix-based correction profiles for my QD-OLED in DisplayCal results in identical behavior to Calibrite’s calibration, Wacom Color Manager’s calibration, my reference display’s calibration, and a MacBook Pro’s factory-calibrated Display XDR. That’s an insurmountable pile of evidence placed against the spectral profiles some people in the online community are using for their QD-OLED monitors.
Again no matter what you say, this is verified by VCGT inspection on CP resulting ICC, and by measuring actual TRC vs TRC stored in ICC profile (if it was accurate instead of ideal).
“Also check legal vs full video levels.”
I’m not sure what this means, could you please clarify? Bear in mind I’m on Apple Silicon hardware, so LUT calibration isn’t a system-wide option unless the monitor has the internal hardware functionality and a software that can control it (such as my Wacom Cintiq Pro 24″ reference display, using Wacom Color Manager for hardware calibration)
signal set as video levels to a display that expects full slightly desaturates colors and destroys contrast
Again this is done by a test
“You provide no information for further diagnosis”
What other information would you like me to provide?
Explained above.
Oh, and I forgot point #3 in my list above: It’s also worth noting that Calibrite actually USED to have the black raise issue. Since last year, after some software updates, that’s no longer the case. Just another piece of evidence to point towards the near-black behavior I assume to be correct, IS correct.
So to summarize:
#1) multiple reference-grade displays demonstrate the visual behavior I have noted in my own head as “reference”
They do not, if not verified with the same measurement device and proper correction to discard a system issue
#2) DisplayCal can also achieve this correct behavior, when using matrix-based correction profiles during calibration (and avoiding those which are spectral)
This cannot work as you suggest. Also you have not tested as required.
#3) Calibrite USED to have the issue, but it’s since been updated to correct for it. In all probability, this was an intentional correction on their part, especially when compiled with points 1 and 2
This should verified in the same way as #1. VCGT and TRC are stord inside older ICC profiles.
*************************
Too much text for a pretty straight forward verification procedure that has not been done.
Hi Vincent,
I agree with your assessment of the situation and the best course of action. I worry I might not be able to carry out the method you’ve proposed.
You keep returning to the point that the display needs to be measured rather than judged visually, and I don’t disagree with that. The difficulty I’m running into is that I only have a colorimeter available, not a spectrometer.
That creates a circular problem. Any verification I perform is necessarily being done with the same measurement device and the same correction that was used to create the profile in the first place. If a correction is inaccurate for my display, the resulting verification can still appear excellent because the instrument is effectively validating against its own measurement model.
This is why I’ve been placing weight on the convergence of multiple independent workflows rather than on a single verification report. At present, the following all produce very similar visual results:
– Calibrite Profiler
– Wacom Color Manager
– DisplayCAL when using certain matrix-based corrections
– Comparison against a hardware-calibrated reference display
– Comparison against the MacBook Pro XDR display (to be extra clear, the display is freshly calibrated from factory, NOT calibrated by my own device)By contrast, some of the community-supplied spectral corrections produce both elevated near-black behavior and lower saturation relative to all of the above.
I’m not claiming that this proves those spectral corrections are wrong. What I’m saying is that, given the equipment available to me, it raises a legitimate question about whether those particular corrections are appropriate for my display.
You have suggested measuring the actual TRC and inspecting the VCGT, which I agree could provide useful information. However, unless I’m missing something, those measurements would still be dependent on the correction being used by the colorimeter. If there is a way to objectively determine which correction is accurate without access to a spectrometer, I’d be genuinely interested in hearing more about that process.
Hi Vincent,
I agree with your assessment of the situation and the best course of action. I worry I might not be able to carry out the method you’ve proposed.
You keep returning to the point that the display needs to be measured rather than judged visually, and I don’t disagree with that. The difficulty I’m running into is that I only have a colorimeter available, not a spectrometer.
That creates a circular problem. Any verification I perform is necessarily being done with the same measurement device and the same correction that was used to create the profile in the first place. If a correction is inaccurate for my display, the resulting verification can still appear excellent because the instrument is effectively validating against its own measurement model.
Mac P3 (WLED PFS) is in default bundle pack for DIsplayCAL and i1d3.
Newer QLED for newer XDR dispays is available on community database or by EDR (thus can be translated to CCSS with ARgyllCMS oeminst) in the new calibration app from Apple.
Hence if your i1d3 sees something wrong with default gamma/gamut.. you know were the problem is.Regarding Wacom it could be GB-LED if it is >10y 27″ widegamut Cintiq, but using the EDR (thus CCSS) bundled in Wacom app will get you a hint about its behavior, discarding minor whitepoint issues due to innacurate coloriemter correction.
This is why I’ve been placing weight on the convergence of multiple independent workflows rather than on a single verification report. At present, the following all produce very similar visual results:
– Calibrite Profiler
– Wacom Color Manager
– DisplayCAL when using certain matrix-based corrections
– Comparison against a hardware-calibrated reference display
– Comparison against the MacBook Pro XDR display (to be extra clear, the display is freshly calibrated from factory, NOT calibrated by my own device)All these can be tested as instructed and see if the visual reference is behaving as it should.
By contrast, some of the community-supplied spectral corrections produce both elevated near-black behavior and lower saturation relative to all of the above.
CCSS cannot produce that as explained before.
I’m not claiming that this proves those spectral corrections are wrong. What I’m saying is that, given the equipment available to me, it raises a legitimate question about whether those particular corrections are appropriate for my display.
CCSS are 3×3 matrices (RGB to XYZ). Using a CCMX implies using a CCSS to (a CCSS with an SPD equal to your i1d3 spectral sensivities)
In fact you can extract a “CCMX” equivalent from a sample CCSS for your particular i1d3 by running spotread.exe or any other measurement app from ArgyllCMS with high debug so these RGB to XYZ matrices are ploted. Hence:
CCSS_RGB_TO_XYZ = CCMX_EQUIVALENT * NO_CCSS_RGB_TO_XYZ
And it should be near identity in the same way as CCMX made by other users.
Colorimeter corrections are applied globally and (unless wome weird SPD is used) only noticeable in whitepoint.
You have suggested measuring the actual TRC and inspecting the VCGT, which I agree could provide useful information. However, unless I’m missing something, those measurements would still be dependent on the correction being used by the colorimeter.
No, as explained above bc it’s applied globally to all measurements.
Another totally different thing is that your i1d3 is clipping raw RGB data sent through USB on near black (thus unrelated to any kind of colorimeter correction because it is not applied yet), but this is inspected in a report, not visually.
If there is a way to objectively determine which correction is accurate without access to a spectrometer, I’d be genuinely interested in hearing more about that process.
By device technology.
The default approach is not “choosing the best visually pleasing one”, but to choose the correction that matches display technology, then if there is some kind of observer metameric error in whitepoint as in old RGB OLED used for grading, open visual whitepoint editor in DisplayCAL (or calman or whatever) and aim to a visually pleasing white, visually close to D65 in other reference display.
This visual approach implies not using absolute colorimetric LUT3D to D65 colorspaces or the visual match will be undone.Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.
