- This topic has 43 replies, 4 voices, and was last updated 4 years, 9 months ago by
.
-
Posts
-
Te answer appears to be not the DTP-94, but that Apple does something non-standard with the graphics for the MPB.
Spend a good day reviewing my setup, learning how to do DisplayCal verify, and CMS assumptions of my tools. Reset displays and compared with two more old IPS Dells in good working order. 5 displays agree, and agree with my memory of the LG but I will have to revisit.
Everything I see through the DisplayCal alignments looks great and behaves as I would expect WRT changes in target gamma. Verify says everything checks out.
I’ve seen no objective support for that claims.
The Apple-spplied Macbook Profile has a TRC that does something unconventional in the deep shadows. They clamp near blacks in a way that makes the display look punchier with miniscule loss of lowest detail, and without blowing the rest of the curve or the color.
Easy to test:
Use DisplayCAL or another tool on factory macbook display profile, dump/plot TRC and let’s see if it is actually 2.2, sRGB or there are some magic value in TRC.
Then do the same on custom profiles (accurate or not).
The last part would be capturing actual macbook TRC, buy may need extra HW ( I mean to test of applied such TRCs make sense, to test if using such profiles allows you to see images as intended)Since macOS have that issue with complex profiles with 3xTRC and such, it is very unlikely that they have something unconventional (a “complication” in watch jargon) under the hood just for an older macbook. It looks like limited precision arithmetic and extremely simplified color management that goes wild due to rounding errors when truncating the modifications required per channel TRC values.
Feed that engine with a true neutral TRC and things should go smooth. Feed it with the same TRC as source and you get no transformation, 1 to 1 identical mapping on a sRGB-like screen (AFAIK that were older LED macbooks).What you may whant to know is actual shape of such TRC (default profile) that minimizes color transformations (which result in truncations) in macOS color engine.
Get default macbook profile, read TRC, plot it on a 2D graph (like DispayCAL’s plot vs L* ramp) and you will know.Nothing at the moment otherwise suggests my DTP-94 has issues and 5 displays all agree and look great according to everything I can send them.
It cannot measure accurately widegamut LED displays without external help as reference (like an spectrophotometer), take that as granted.
It is not designed to do that, just for typical CRT or CCFL LCD.
That means that at least custom LG P3 screen profile made with it is not very accurate and it’s extremely likely to fail in while point if verified with a more accurate tool. sRGB LED screen is likely to fail too.The factory profile is attached to my first message in this thread,
Attached to this message are DisplayCal ICC Profile Info results for that profile. You can see the factory profile does sRGB with its TRC and seems to do something else beyond linearization to the calibration, which is what led to my original question.
At one point I thought I saw a DisplayCal report say that the Apple calibration was nominally 2.4. I think I was trying to learn how to simulate the DisplayCal generated sRGB-target profile against the Apple profile… Or vise versa… I got confused — I want to look into this again.
Attached here are DisplayCal / DTP94 results for same Macbook.
One is sRGB-target TRC with native white.
The other is a 2.4-target TRC with native white.
(I use native on TN panel to avoid significant color cast in highlights with vertical axis viewing shift that comes from lid angle. This viewing angle induced error of a white corrected TN panel far outweighs error of native whitepoint against standard, which is a basic compromise of the tech.)
Couple other notes:
• Apple uses a true sRGB transfer func in the factory profile — well, I didn’t check the numbers but if you plot TRC in Info the splice is plotted and the formula is reported by Info — whereas DCal sRGB target produces literal 2.2, according to Info
• The 2.4 profile is included because it shows calibration gamma tracking that agrees with 2.4 except for the darkest measurement — I read Florian discuss the error near black as normal, and as to why the last step is omitted. In the sRGB target, the calibration gamma tracking is reported as less conformant. I’ve tried building profiles on this same Macbook with target as high as 2.6 and as low as 1.72 (old Mac) and cal gamma tracking for these gets quite bad. The 2.6 grayed out shadows and was useless. Playing with 1886 preset and gamma ranging from 2.2 to 2.35 and 2.4 produced verification reports with poor numerical conformance to the target but no discrepancy. The cal reports all hugged 2.1. The literal TRC seems to be target. I don’t have an easy way to crosscheck. This sounds like it’s in zone of instrument-related error you have warned about. But my sRGB and 2.4 target numbers track (yes they may be wrong) and the results eyeball believably. (I am nerding out on this to learn. Obviously it makes sense to find a couple hundred grisbees and get an i1dp :$)
• Will DCal alert about gamma measurements that substantially mistrack setting target?
Again I’m keeping in mind all this started with my wonderment about Apple’s Cal and comparing notes with DCal, which I find an amazing program
The factory profile is attached to my first message in this thread,
Attached to this message are DisplayCal ICC Profile Info results for that profile. You can see the factory profile does sRGB with its TRC and seems to do something else beyond linearization to the calibration, which is what led to my original question.
At one point I thought I saw a DisplayCal report say that the Apple calibration was nominally 2.4. I think I was trying to learn how to simulate the DisplayCal generated sRGB-target profile against the Apple profile… Or vise versa… I got confused — I want to look into this again.
I’m not sure if I understood what you wrote. I’m going to write what I belive you said as a conditional statement:
If factory apple’s default icc for your macbook screen stores this TRC
but when you calibrat e witha DTP-94 and DisplayCAL you get this calibration curve (which is a LUT, a correction applied to grey ramp)
then there are two possible interpretations:
a ) Apple’s factory profile is wrong. I mean it is inaccurate = it does not store an accurate description of your display behavior at this point in time (june 2019)
b ) DTP-94 isn unable to take accurate readings in your display, because it is old and has degraded (unlikely, they are known to be good) or because it is trying to measure a backlight not suitable for it unless you provide a correction (more likely)…. hence that correction LUT gives you unwanted results in grey neutrality and gamma.
Choose at least one (A or B), the one you like the most, or what looks visually better. It is possible that A and B to be true at the same time but it is not possible that A and B are false at the same time. It is not possible that macbook default profile is accurate and at the same time when calibrate it with an accurate DTP-94 you get that calibration curve.
So:
-If A is true, you should not use apple’s default profile if you want to use color managed applications in a reliable way.
-If B is true, all calibrations and profiles done with taht DTP-94 are not reliable unless you validate them with a more accurate device.It is as simple as this: A OR B evaluate to TRUE and this leads to my first message in this thread.
A couple things:
- The Apple supplied profile does make an extra punchy image and is not good for accuracy, or even white point.
- I think your issue has to do with the 1886 tone curve which expands the deepest shadows so that you can see separation between all the tones. I think this is a flawed approach and you will better served by choosing “gamma 2.2” manually in Displaycal settings so that you are using a power law gamma 2.2 relative curve. Try making your profile/calibration with these settings and it should solve your issues.
OK, thx.
To claify findings since orig post.
My original question was about why a DisplayCal plus a DTP94 resulted in one alignment on a Dell 2209WA and an visibly different alignment on a 2012 15in Macbook Pro.
I was shooting for an sRGB alignment.
Along the way I found that the DisplayCal MPB results (and DisplayCal for an LG Ultrafine) had distinctly lifted blacks compared to Apple’s supplied profiles. And the the DisplayCal Dell sRGB was closer to Apple’s alignment on the MPB and the LG Ultrafine.
I had no good reason to think that Apple’s alignment should agree with DisplayCal except the assumption that Apple would target sRGB TRC. This turns out to be incorrect. The Apple-supplied profile has a proper discontinuous sRGB tonal response curve, but he display calibration curve is 2,4, with a bit more pull into deep blacks than a DisplayCal 2.4 alignment for same. This was determined by running DisplayCal verify on the MBP with the Apple profile. The only reason I can think of for Apple doing this is that it makes the display more saturated and punchy and suited to iTunes video. It’s unlikely to affect photos shared by ordinary users, and if it does, photos will tend to present on PC with slightly more black detail and less contrast, which in turn gives the Mac produced photos appearance of more detail appeal when compared directly with competition, while the industry standard camera curve is preserved in those cases with the user doesn’t edit tonality.
As to why the DCal Dell sRGB alignment appears more contrasty than the DCal MPB sRGB, that seems to be about a combination of somewhat different contrast ratios, vertical off-axis response of the TFT, and the DTP94 not seeing the MPB LEDs with exactly the same sensitivity as the CCFL in the Dell.
As to 1886. On all these displays 1886 2.4 produces an alignment which is in between 709 (2.4) and sRGB. There are vanishingly slight differences in the bottom end, which seems consistent with intention of 1886 to mimic the slightly steeper pull out of black of an old-timey CRT broadcast video monitor.
My purposes are straight sRGB and the DCal rendering on this MBP has excellent tonality, neutrality and smoothness. For my purposes it is perfectly acceptable.
Next step is to acquire a i1DP and compare results.
My sense is that Apple chooses its alignments carefully and well with excellent looking results; nothing wrong at all for ordinary users. But if you were doing grading work on contract, you for sure would want to do a more careful alignment.
My sense is that Apple chooses its alignments carefully and well with excellent looking results; nothing wrong at all for ordinary users. But if you were doing grading work on contract, you for sure would want to do a more careful alignment.
No, not even close… it’s pretty generic as most driver/EDID TRC profiles.
Yes, as I said, the TRC is just the formula for sRGB. Literally! Apple wrote the boilerplate into the profile!
And that’s the a fine thing to do. The display gamut is measured as… sRGB! Imagine that.
The supplied panel curves reasonable correct the TN panel that Apple sourced so that grays are perfectly neutral up and down the line, whitepoint is native and a bit cold but vision adapts to this well and TN panel demands using native or it would look worse. Apparent tonality is smooth, but calibration curvre punches up color and contrast a bit to be pleasing but still fair and useful rendering. And the appearance is consistent with Their alignment agrees with industry standards and is consistent across their other products, given tolerances.
This is good engineering, making pragmatic tradeoffs.
If you were competing with Apple and wanted to do a better job, how would you approach the alignment? What would you do differently?
How do you feel about Apple’s phone displays by comparison?
It’s pretty generic as most driver/EDID TRC profiles.
Apple is no special in this subject, so you are wrong, they do not make a special profile carefully chosen. Take a look in EDID data from some new LED display, almost all are the same = TRC sRGB.
If your hangup is my choice of the word “carefully” how do you suggest Apple can use more care? Extend their assembly line uniquely profile every unit?
Do you feel most users would benefit from this compared to their current approach?
After a lot of practice using DCal, by trying many variations and configurations, I’ve homed in on consistent and highly satisfactory results, within the limits of these displays.
I believe my original question arose from of my limited understanding of DCal’s controls and options and the creation of erroneous profiles, combined with my assumption that Apple’s stock config would be sRGB, when in fact it presents 709.
Attached are some screenshots. I know that the Lagom.nl reference images are considered a low-grade assessment of display fidelity, but they reveal basics. Here’s some shots comparing the two displays using a DCal sRGB alignment via the DTP94.
The Macbook clips the top 4 lightness values in its native mode, so that’s an unavoidable limit of the unit. As I said in prev posts, MPB whitepoint must be native, which is closer to 7500K, and off-axis tonality variation of the MBP TN panel is unavoidable. But everything I look at on these displays is great with a near perfect sRGB capable (99%ish) gamut and tonality. With good agreement of the units I’m comfortable that I’m heading towards consistent results. I have nothing at stake except my own taste.
Later when I can get a newer colorimeter, I’ll revisit to see how things compare to another reference. Also will take another look at the LG Ultrafine wide-gamut.
DCal is an awesome program and rewarding to learn. Thanks for the great work and support!
If your hangup is my choice of the word “carefully” how do you suggest Apple can use more care? Extend their assembly line uniquely profile every unit?
Do you feel most users would benefit from this compared to their current approach?
Most manufacturers wrote sRGB TRC in EDID data. Also driver ICM (for Windows computers) stores the same TRC.
It’s all the same for almost every modern display. Apple does nothing different from other manufacturers. It’s default behavior for all modern displays.There is nothng special about Apple choosing of TRC in default profile.
You keep talking about sRGB TRC in profile, but I’m talking about what ICC Profile Info reports as “Calibration Curves”
When I looked into EDID some time ago, I didn’t see any provision for calibration curves, just a generic statement of panel type and target response.
So where does Apple get the details for the calibration curve?
Is that actually in the EDID and I’m missing it in the spec?
If so, why doesn’t Apple (or Windows or Linux) use it to make a 3rd party display look as good as one of its built-ins? When I plug these Dells into my Mac they have a presentation that’s not on par with any Mac built-in display. And I’ve seen plenty of 3rd party displays with much worse presentation compared to Apple’s worst. It’s this fact that makes DCal so valuable for users!
So where is the data to align the built-in panel coming from? My guesses are that Apple keeps a catalog of curves for every model of display it offers in the OS and quality control is sufficient to make this approach feasible, or, Apple extends EDID in the firmware for the displays it sources. Both of these ideas count to me as using “care”, though still don’t know what’s true and both may be wrong.
I have not seen this consistency on Windows or Linux, which makes sense because they are not vertically integrated suppliers of systems. Apple is doing something to normalize their dispkays and it works natively and cradle to grave.
Just for sake of argument, maybe Apple intentionally ignores EDID calibration info just to make 3rd party displays look bad? But by same token, for decades of OS software releases they’ve supplied a visual calibrator in the Displays control panel to help you make the most of whatever display you’ve got. (Though in last couple years you have to hold the Option key to find it).
I don’t know what’s going on but it appears Apple takes some “care” on this that PCs don’t (or can’t). This is the reasoning behind my language.
Feel free to beat me over the head some more, but an explanation would is what I’m seeking
