[Openicc] _ICC_PROFILE in reality

[Chris Murphy]

And in terms of the user experience between Apple's Preview application on Snow Leopard vs. Adobe Photoshop:

Preview.app: If I have an image and slowly drag to the 2nd screen, but not entirely on that 2nd screen, at a certain threshold point the entire contents of the window "change" with an apparent new transform based on the display profile for that 2nd screen. But of course only the portion of that window displayed on the 2nd display looks correct. It looks wrong on the 1st screen. If you go back and forth, it's not a terribly elegant behavior because there are cases where most of the image at a given time is color managed for the wrong display.

Photoshop and Lightroom behavior on Mac OS: Same instance, there is NO threshold point. If I let go of the drag event for the window at any point, each portion on each display is color managed for that display. That is, a single window's contents are independently color managed for the display the contents appear on. So at all times you have a reliable representation of the contents appearing on the two displays. The update is not live during window dragging, only once the mouse button is release and then there is an update. This is a very good user experience.

I'm unsure of the behavior of these apps on Windows.


On May 26, 2011, at 8:00 AM, Chris Murphy wrote:

> My 2 cents.
> 
> Multiple display support has always stunk on both Mac OS and Windows when it comes to color management. It stinks worse (not usable) with laptops in a mirroring configuration with a projector: you choose whether the laptop or the projector look like snot.
> 
> The only reliable applications I'm aware of that have ever had reliable multiple display color management support are Adobe Lightroom and Photoshop. Everything else looks wrong on the 2nd display.
> 
> Starting with Snow Leopard we get a different behavior where ostensibly every Cocoa application should have multiple display support "for free". In the first three incarnations of this (10.6.0 through 10.6.2), this was not working correctly and actually partially broke dual display support in Lightroom and Photoshop. There was a work around where you could log out and then log back and it would resolve the problem, after a change in hardware configuration (attach or detach a 2nd display).
> 
> I have no confidence this works with three displays. But I haven't tested it. I actually have low confidence that it even works intuitively as it should with two displays on Mac OS because of conflicting color management between the system trying to do it for two displays now, and applications which have implemented this themselves.
> 
> So regardless of how you decide to implement, it really needs to not involve the user at all. And when there is an exception to the rule, it would be nice if there is a UI notation that indicates this somehow. For example if it's simply not possible to do independent color management to two displays in a mirrored configuration, then the UI for setting the display profiles needs to provide some sort of feedback as to which display is not being color managed (or managed improperly).
> 
> 
> Chris Murphy
> 
> 
> 
> On May 26, 2011, at 4:22 AM, Graeme Gill wrote:
> 
>> Richard Hughes wrote:
>>> * The per-output _ICC_PROFILE atoms -- they make logical sense, but
>>> *no* applications use them
>> 
>> If you don't set them, then there's no possibility of them being used
>> by applications. Someone has to make that first step.
>> 
>> Both OS X and MSWin support applications that need color management
>> over multi-monitors. Why should Linux/X11 be deficient in this regard ?
>> How else will a multi-monitor application get correct color across
>> all its monitors ?
>> 
>>> * The _ICC_PROFILE_1 thing -- it doesn't exist in GCM, and no apps
>>> seem to use it.
>> 
>> If I recall correctly, Xinerama is the only multi-monitor solution
>> that allows calibration using proprietary drivers. This will remain
>> the case until Xinerama is adopted universally. I suppose though that
>> there will be no great impact if this is not being supported.
>> 
>> Graeme Gill.
>> 
>> _______________________________________________
>> openicc mailing list
>> openicc at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/openicc
> 
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc