- This topic has 52 replies, 4 voices, and was last updated 4 years, 8 months ago by
.
-
Posts
-
I’ve been playing with making LUT profiles on Mac Mpjave 10.14.6 and the problems described for Sierra are still present, per this post from 2019-07-04
But what strikes me is that the rendering glitch looks a lot like what you are reporting for your Pioneer TV.. See attached screenshot of my Dell with an XYZ LUT profile
Thoughts / questions:
• What’s notable to me is the profile you posted (which when I test I see no problem) and is a 1xCurve+MTX. Yet the screenshot you posted, presumably based on the profile your shared, looks like what I see as the MacOS LUT display profile glitch… Notice where the cutoff occurs in the shadows and the contour—very similar…
• You made an LUT profile for your TV at one time, no? Possible confusion about what profile is assigned to your TV?
• Maybe the same MacOS glitch that occurs for LUT profiles can occur for matrix under certain conditions?!
• Reading the stackexchange writeup and other posts carefully, it seems some users have reported this glitch with various 3rd party profiling systems, so is it just about LUT profiles or something deeper?
• I went over the the decades old Apple Colorsync Mailing list archive, and the list is still barely alive. That forum used to be a hotbed of dialog for color/ICC nerds back in the day, There is no discussion of this problem at all. I saw Florian has a post or two in the last year on that list about another topic… How has this defect not got any traction there, it seems like a decent place to connect with Apple or at least other engineers? Does everybody hate Apple now as much as they once did Microsoft?! 🙂
Maybe the same MacOS glitch that occurs for LUT profiles can occur for matrix under certain conditions?!
The only profile types compatible with Preview are the ones created by default, single curve (or gamma value) + matrix, with baked-in black point compensation, and calibration that maps input zero to output zero (so no black point hue correction possible). Since a few versions, DisplayCAL will warn you if you try to deliberately create a different profile type on macOS 10.8 or newer.
How has this defect not got any traction there, it seems like a decent place to connect with Apple or at least other engineers?
The colorsync-users list is almost exclusively used by industry professionals, with a relatively strong print- and prepress-centric focus. I assume not many care about Apple’s Preview there, as most are using Adobe’s or other professional solutions (which have their own CMMs, thankfully largely unaffected by Apple bugs).
The colorsync-users list is almost exclusively used by industry professionals, with a relatively strong print- and prepress-centric focus. I assume not many care about Apple’s Preview there, as most are using Adobe’s or other professional solutions (which have their own CMMs, thankfully largely unaffected by Apple bugs).
I haven’t browsed it, but I find it amusing that colorsync-users list should be dedicated to anything but Apple’s own CMM.
There was a misunderstanding on my end apparently. The profile I have attached earlier is indeed fine. I do have problems with more complex profiles, which are Apple CMM incompatible as Florian suggested. I have also confirmed there are issues with those on “real” Macs as well. Do take a look at this problematic profile.
I’m relieved to hear your hackintosh is behaving like a Mac, as it should strike terror into hearts if computers seem to run programs mostly fine with occasional arbitrarily wrong results . When this happens civilization will be on brink of doom due either infrastructure failure or awakening of Skynet.
Since perusing the problem reports on stackexchange and the DisplayCal docs I gather that this problem with display profile variation which can be generated with DisplayCal and those compatible with Mac is a bit of a red herring. The DC docs imply that (in spite its limits) MacOS is the best adapted desktop OS to ICC display profiles.
Our situation seems to be DC can readily produce profiles of a form not compatible with desktop OS graphics and OS silently accepts incompatible versions.
As to what is compatible, this is murky and known through trial and error.
So what’s needed?
• More focused contact with Apple? Raise hell with ICC to document state of industry?
• Adjust DisplayCal UI to help users down the primrose path?
Given DC powers, wealth of options, and nature of a lot of forum traffic, to me it looks like the next DC frontier is helping users know how to best apply its powers to specific scenarios.
Right now DC UI gives neophyte user no clue where to begin in a maze of options. And documentation is an well-organized extraordinary collection of observations with no bearing to scenarios.
Per user psychology: offering users a way to do something will always attract some users to that way no matter if its wrong, and there will be a persistent minority that once started down an offered path, telling them they shouldn’t continue results in the challenge being accepted 😉
One way to prevent bad starts is if presets were to be first organized by scenario, then subcategorized by rendering goal.
Put another way, offering options (eg LUT, black-point factors) then telling users they’re doing it wrong is less effective than drawing users towards what works; eg for this application head this way.
Make settings help users find the best path.
Re raising hell with Apple, there may be sound engineering reasons for current limits. Or they could be lazy, have stopped caring, or deem details proprietary (!) on this last guess so much for the ICC.
Re comments about colorsync list, it was desktop publishing / prepress that defined the design of the Mac. I openly wonder how to engage Apple to improve this stuff. It used to be a point of pride for the platform.
Well, DisplayCAL is really a GUI on top of Argyll CMS (https://www.argyllcms.com). So you might as well ask Graeme about the issue. Also if you have the time, why not post a message to https://lists.apple.com/mailman/listinfo/colorsync-users? I may do it myself later but if you have the time, do ask about our issue on the list.
I’d like to hear from Florian about the origins of the “Apple CMM being incompatible with anything but curve-based profiles”. Surely there was a thread, or some kind of investigation that may be ongoing and that we could monitor or participate in.
Without knowing where the idea originated I can only speculate, but it’s not unconceivable to imagine that there’s some small incompatibility, like a slightly incorrectly filled field in ICC profiles generated by Argyll that is not liked by macOS which expects that field to conform to some strict standard, whatever that may be.
It just doesn’t make much sense to half-support XYZ+matrix profiles, logically Apple CMM should simply ignore such profiles if it “knows” it cannot work with those types rather than produce the weirdness that we’re seeing. Which implies that there is a workaround, but we don’t know what it may be without having a sample fully supported XYZ profile that doesn’t break Apple’s CMM.
I submitted feedback to Apple outlining this situation in succinct non-tech terms and requesting that 3rd-party ICC-compliant profiles which are correctly handled by Adobe should produce correct results in MacOS -OR- MacOS should not accept such profiles as valid display config in the Displays prefs.
I’m happy to tune the dialog dimensions / directions if I get any traction on topic—which is doubtful
So what’s needed?
All that was really needed was changing the default profile type under macOS to single curve + matrix + BPC + no calibration black hue correction along with the warning I added some versions ago. Any Preview related discussion has pretty much died down since then.
I’d like to hear from Florian about the origins of the “Apple CMM being incompatible with anything but curve-based profiles”. Surely there was a thread, or some kind of investigation that may be ongoing and that we could monitor or participate in.
Sure, I think the stackoverflow thread was linked here (I don’t have the URL handy), after hours upon hours of frustrating trial-and-error we finally figured out what it was that Preview wasn’t liking, although of course the underlying technical reason for the rendering quirk is still a mystery.
it’s not unconceivable to imagine that there’s some small incompatibility, like a slightly incorrectly filled field in ICC profiles generated by Argyll
No, it’s just cLUT tags, and TRC tags that do not conform to the restrictions I mentioned above. Any A2Bx/B2Ax present, and the problem occurs. You can take any profile that Preview has problems with, remove the cLUT tags, replace the TRC tags, without changing anything else, and voila, Preview will be happy. Believe me, I have done this more times than I can count.
there may be sound engineering reasons for current limits.
Reasons maybe. Sound, definitely not, unless you consider it sound to have rendering bugs that didn’t exist until 10.8 came around. But,…
Apple CMM should simply ignore such profiles if it “knows” it cannot work with those types
…I doubt this is a design choice, it’s a bug. cLUT profiles work fine with ColorSync Utility by the way, which can be used instead of Preview to open images.
Just a quick one: so I imagine those new Apple monitors don’t really need any fancy profiles (provided by Apple) and having a basic curves profile like they have for any other embedded display is enough?
That seems about right. You will still gain a benefit from calibration, but due to the good additive nature of the newer Apple displays, you can get good enough accuracy even with a matrix profile in most cases.
Don’t know if it helps, probably not, but I watched Console while switching between profiles and got those warnings (also on some supported and Apple-provided profiles):
[WARN] - Attempting to get 3-channel linearization table capabilities from plane with no 3-channel linearization table support CGColorCurveGetParameters: CGColorCurve type kCGColorTRCTable used as parametric. Returning estimated gamma
I submitted a query about MacOS glitching to colorsync mailing list.
I framed in terms of stackexcgange post that’s been posted on these forums, and offered a takeaway re “bug” using quotes from Florian above, then asking if anyone there is aware of this problem and what they suggest about getting it corrected.
I beat them over the head a little which prolly works against things but it felt good 🙂
I see your post. Great. Let’s hope that at least anyone can chime in.
So the profile would/should work just fine in Windows, then? Don’t have access to it, can’t check.
And then it’s just the displays. How about, say, paper profiles provided by paper manufacturers? I don’t know much about those, but could it be that they are affected as well when printing from Preview, Pages and the like?
PS. Your English is amazing by the way, Wire. Been a long time since I saw language flowing effortlessly like that.
Ah thank u, re writeup props. I’m relieved the gist comes through typos, run-on sentenced and all—I’m typing on a phone :$
It appears by fate that this subject is right now being discussed on Colorsync list under another thread titled “Possible ColorSync discontinuity bug introduced in OS 10.14.6”. Not sure why that thread is pigeon-holing this to latest MacOS version? One of the participants is an old-school digi-imaging trainer who has his own website where he’s discussing MacOS problems with LUT profiles in 2018… Confusion abounds.
As to why this is such a morass, I’ve been looking at related posts on forums and I see observations all over the map. There are so many variables involved from a user point-of-view: hardware/software combos, compatibility and obsolescence, ICC profile versions, various presentations of symptoms, and unrelated systemic change occurring along the way. Some users are flummoxed and stymied by complete asides such as Apple introducing Gatekeeper in Sierra. Gatekeeper is a security enhancement that stops unsigned programs from running, but it does so pretty much without explanation, which the user experiences as applications being broken with attendant fear, uncertainty and doubt. (My god. Mac has become every bit as error-prone, unreliable and incomprehensible as Windows.)
OTOH there is some hope that a wide range of reported symptoms are about to coalesce to an understanding of a specific Colorsync pathology, which will be fixed. Not quite there yet.
I misrepped the Colorsync list thread title above, it’s “Possible ColorSync discontinuity bug introduced in OS”. The convo is focused on latest OS and the word “introduced” implies something changed recently, but the dialog reads as pretty much the same as the profile glitch we’re talking about.
To be clear, is this MacOS display profile glitch possible with 1Curve+MTX profiles using certain black-point options? Or is it limited to XYZ LUT profiles?
Re inventory of symptoms:
A post on Colorsync list per above mentions in context another symptom that graphics LUT (vcgt?) calibration is slightly too light… As I played w XYZ LUT profiles I saw this myself on one Mac but not on another—it was a slight diff and I didn’t focus on it at the time, but now I’m thinking about it.
**mg the terminology per “LUT” is mindnumbing re this issue
Beats me too. The problem certainly occurred earlier than the recent update.
Here’s an interesting snippet from the conversation they have ongoing:
If display calibration software, which puts native RGB values up on the screen with calibration disabled, instead gets colors that are artificially lighter in the shadows with the largest error being immediately above pure black), it’s going to compensate by using the calibration luts in the final display profile to pull down the shadows to compensate.. this is artificially compensating for the uncalibrated display response being “wrong”, and will result in the shadows being unnecessarily compressed
On the other hand, I’m not seeing any issues with Dispcal-generated profiles in Photoshop so the problem is probably multi-faceted and appears in various contexts at different times.
You don’t have Catalina beta to test out if the bug is present there by any chance?
