- This topic has 2 replies, 2 voices, and was last updated 4 years, 1 month ago by
.
-
Posts
-
During previous comments on forum I’ve mention how I’ve had ongoing trouble with profile verification. This appears to be a glitch in how DCal interacts with MacOS over profile locations.
When a verification pass is run, there is an implicit question as to where the display profile used for the verification should be loaded from. From a layman’s point of view, It could be from the storage folder for the session, or from the user folder ~/Library/Colorsync/Profiles/ or the system folder /Library/Colorsync/Profiles/
In my process, I always install the profile intro the system Colorsync folder because I want it to be available to all users. This results in two copies of the profile being installed: one in the system Colorsync folder and a duplicate in the user Colorsync folder. I prefer to have just one copy of each profile in force, because as I experiment profiles multiply and overflow the System Preferences > Displays > Color control panel. So I have a habit of culling profiles from the user Colorsync folder.
I also always ensure that the desired profile in Displays preference is in force, because MacOS will silently revert calibration to the EDID profile if the one that it loaded is deleted from the Colorsync folder.
It appears that DisplayCal Verify expects the profile under consideration to be in the user Colorsync folder, but if it isn’t, DisplcayCal silent proceeds to verify against an unknown profile and calibration. This causes the verification report results to be at the whim of whatever unknown (to me) VCGT calibration, probably EDID. The verification results show tracking in the red and yet because the desired DisplayCal profile in in force, from the system Colorsync folder, the display response appears to be normal., while verification produces strange results.
I can reproduce this glitch by creating a profile and installing it in system Colorsync, removing the copy from user Colorsync, running a verification pass, which will produce unexpected bad gamma tracking, then replace the profile into user Colorsync and rerunning the verification and get expected results.
It took me forever to understand this because I’m doing several things at once and clean up the user Colorsync folder intermittently in an off moment, but the negative results of this action may not be seen to well after the fact. For the user, this gets further complicated by the fact that Verify may produce odd results for many other reasons of alignment choices!
What’s needed is at least If the profile to be verified can’t be accessed DisplayCal must signal an error. If there’s no way for DisplayCal to know if the profile under consideration is in force, then … 🙁
As to the duplication of profiles which resulted in my confusion. I recall an explanation that it’s unavoidable. At risk of seeming to be a nit-picker: XRite DUCCS is able to install in either user -or- system Colorsync without duplication. Though I notice the XRite is installed as a system service and doesn’t required authentication to install profiles, so I can imagine there is maybe a UI tradeoff around access control.
OMG, this bugaboo has really been a huge source of confusion in my work with these tools. because from high-level it’s been impossible to know whether bad tracking is due to display / HW limits, bad choices of calibration settings or other mysteries of calibration.
When verifying the “<current>” profile (and not an explicit selection), you can see which profile is used for verification in the generated HTML report.
Hey Florian, thanks as always for your kind reply.
So the “bug” in my post title is maybe too-strong or a totally appropriate term…
I experimented some more and find that my trouble is in strictist sense an operator error, but one which maybe can be prevented.
The problem appears precisely when profiles are placed in both /Library/Colorsync and ~/Library/Colorsync. DisplayCal activates the one in ~/Library also nothing tells you which one it active. If it is deleted, this causes no immediate effect on the display calibration. But performing a Verify causes MacOS to silently detect the missing profile and unload its cal in favor of the EDID profile. The verification continues and the report shows tracking errors corresponding to the difference between the display native response and the cal in the intended target profile.
Apparently my error is removing the active ~/Library/Colorsync copy and forgetting to set of the /Library/Colorsync copy.. XXX However I could swear I have been being very careful about this. XXX Nonetheless, I am not currently able to reproduce the problem if I explicitly set the active profile in Displays. My situation is made trickier because two of same type of display. It may be there’s a MacOS bug in profile handling, as I’ve seen things appear to go out of sync, bit admit I’ve gotten lost in details at those occasions and not been able to sort it out. I have occasionally resorted to restarting the computer to try get things working predictably. But this is always a last resort / throwing chicken-bones move on my part. If I come across a specific MacOS bug I’ll post again.
Re profiles as listing in the Displays control panel: Because Apple just lists profiles by “description” you get duplicates in the Displays Pref-pane. If you take trouble to hover mouse over them and wait for several seconds, it will report the disk location, but the only distinguishing difference is the “~” in the popup—fortunately it’s at the front of the name. Displays color is an outdated UI from like System9… IDK Apple may prefer users just forget about this stuff.
As you mentioned, I saw that the report includes the profile name, but no indication of where it’s loaded from (or rather, not loaded from 🙂
If possible, I think it’s important for Verify to help the user establish that the target profile is in fact in force. If this can’t be done, maybe a red warning message about double-checking what’s loaded in the help pane, although I’m prolly not alone in hitting information overload in the help.
Thanks again for support
/wire
