- This topic has 0 replies, 1 voice, and was last updated 2 years, 7 months ago by
.
-
Posts
-
I use a pair of same model displays. Due to a firmware defect, one of them has a slightly aberrant response, but it calibrates and profiles fine. I profile both as the same name, with only device number (%out = #1 vs #2) distinguishing the units in DisplayCal settings and profiles. In the DisplayCal Display & Instrument pane, one is automatically designated as “Primary” however in the macOS Displays preference pane, it is designated as unit 2. (I’ve never been able to figure out how macOS assigns numbers to displays.) The key here is that the displays are distinguishable and the behavior is consistent enough to work with the displays.
Under DisplayCal Profiling pane, some many moons ago, I changed details of profile name to better reflect my workflow. Somehow (due to either an inadvertent mistake on my part or a bug) I lost the %out formatting which set the device number in all of DisplayCal’s settings, and it got replaced with a fixed string, e.g., “#1”.
So under profile name, I had
“Dell UP2516D #1 Native D65 DCal 2.2”
Where what’s needed for a multi-display system is:
“Dell %dns %out Native D65 DCal %cg”
What happens is that where #2 is intended and expected by selecting the alternate display under Device & Instrument, the profile name will remain #1, and further, all settings are stored under #1.
The key format item is %out because it binds the specific display device name to the naming for all other data including the profile name itself, but not the os device unit number for which the profile will be installed.
The consequence of missing this %out format results in profiles that appear to be generated correctly with no signs of a problem, except the calibration is just wrong!
Consider how many aspects of display behavior are affected by the display device name, where of the display some functionality is based on the way DisplayCal sees the HW, some is based on settings, some of the settings’ names are auto-generated and some are set by hand, whether settings from previous run already exist, what profile gets installed with what name to the OS, and how naming conflicts can disturb these arrangements — IT’S ALMOST IMPOSSIBLE TO TRACK.
For me, the net effect was a calibration with an obvious defect —see the attached screenshots of a calibration with an odd bump in response
Shadows Bump is due to the naming conflict
Shadows Normal is the correct responseKeep in mind that while running my alignment, everything I can see about my workflow says a profile has been properly created and assigned to my display, but due to the %out naming glitch, parts of the calibration for the display under consideration belong to the other display.
As it so happens, DisplayCal remembers the Profile Name string, regardless of whether any settings exist. In other words, the Profile (mis) Name string is meta data that persists beyond all other settings, including Options > Restore Defaults! So the missing %out format will persist. However, by deleting all existing settings for both displays, the conflict is temporarily resolved, and the bogus results are cleared up… Until the second unit is aligned, then results go to wrong again!
THIS IS THE WORST KIND OF BUG, WHICH IS THE SYSTEM APPEARS TO WORK PERFECTLY BUT JUST PRODUCES THE WRONG ANSWER, BUT NOT ALL THE TIME AND EVOLVING WITH USE.
What’s even more dastardly about this glitch, is that if my displays were more closely matched, such that one’s response wasn’t so noticeable compared to the other, I could easily think I am running a properly aligned system, when in fact it’s wrong but I just haven’t noticed yet, and maybe I will never notice at all. Imagine collaborating with customers and seeing wacky effects and blaming them for bad setup, not ever being about to tell that your own alignment is hosed. Or imagine many rants on these forums.. Funny thing is if a user never touches the Profile name string, they would never guess that such a detail could wreck some else’s whole system and the one who is suffering this bug would seem crazy.
Caveat:
Above I wrote that I lost the critical Profile Name %out format “due to either an inadvertent mistake on my part or a bug”. It was probably my fault… Except that the Profile Name string on Mac has other bugs:
• A space character will not be accepted at the end of the string, so if you want to add a term, you have to type a non-space character then left-arrow the cursor to where you want the space and it will be accepted.
• The %dn format includes a duplicated Vendor, such as <b>%dn > “Dell, DELL UP2516D”. In my case, as I was putting a string back together, I ended up with “Dell Dell, DELL UP2516D UP2516D #1 blah blah”; a simple format and not understanding error gets magnified into crazytown effects.</b>
While these two defects are minor, their existence makes it seem not implausible that the format string may have a mind of its own.
As I type this, macOS Chrome thinks that one of the instances of the work “by” above is a misspelling but it offers no correction. Don’t get me started on the insane regressions in iOS 15 🙂
Forgive me, I’m not trying to beat anybody up here. I think DisplayCal / Argyll are greater than sliced bread, I love this stuff! But I think the design of the naming scheme needs a bit more thought.
One more thing, as I was running cals I got a profile summary that reported 82.4% sRGB coverage at the same time as 100% Adobe RGB coverage. See the attached Profile Summary screenshot. I guess this could also be a consequence of mangled data due to naming conflict?
/wire
