Virtual displays for ICC monitor profiles

[doug-walker]

In OCIO v1, the burden fell on the config author to anticipate all of the possible displays that were going to be used. While this is fine within the context of a controlled studio environment, it makes it difficult to use OCIO in less structured conditions. As discussed in the v2 proposal, we want to give config authors the option to use ICC monitor profiles, when it is useful for them. The ICC profile not only provides a way of obtaining a viable characterization for unanticipated displays (e.g., laptops), it also would allow OCIO to simulate the contents of viewports managed by ICC-based applications.

MacOS and Windows are able to provide a profile for each connected display. Even in cases where a custom calibration is not available, the OS is often able to generate a plausible fallback using the EDID from the monitor itself. (Given that wide-gamut monitors have become commonplace, this is often better than "just assuming everything is sRGB.")

This issue proposes a way to refer to that profile via an OCIO config and define views for it.

Our original thinking was to introduce a new type of Transform (e.g. SystemMonitorTransform) that would be able to access the user's current ICC profile. However, after going down that path, we decided it's not the best approach. First of all, we never want a Transform to throw (e.g. if OCIO is running on a headless server). (And we don't want to return an arbitrary "sRGB" fallback.) Also, we don't want this display to show up in a user menu if it is not valid (e.g. potentially on Linux, where getting a profile is less standardized). Furthermore, we want to be able to support the case where there are multiple monitors, each with a different profile. (Photoshop and other apps are able to do this already.)

So our proposal is to allow config authors to define a "virtual display" in the config. This display would allow the config author to define the views that are appropriate for use with an ICC profile. Then at runtime an application would ask OCIO to instantiate a real display from the virtual display using the ICC profile for a given monitor (and would be able to instantiate several displays if there is more than one monitor). Likewise, if there are no displays, or the OS is not able to supply an ICC profile, no displays would be instantiated (and a user would not see any new displays added to menus).

Here is the proposed YAML syntax (the first display is a typical one, the second display is the virtual one):

displays:
  sRGB:
    - !<View> {name: Raw, colorspace: nc10}
    - !<View> {name: Film, view_transform: filmView, display_colorspace: sRGB}

virtual_display:
    - !<View> {name: Raw, colorspace: nc10}
    - !<View> {name: Film, view_transform: filmView, display_colorspace: <USE_DISPLAY_NAME>}

OCIO would then instantiate a real display that looks like this (for example):

  Dougs-ICC-Profile:
    - !<View> {name: Raw, colorspace: nc10}
    - !<View> {name: Film, view_transform: filmView, display_colorspace: <USE_DISPLAY_NAME>}

And a display color space:

display_colorspaces:
  name: Dougs-ICC-Profile
  from_display_reference:
    - !<FileTransform> {src: /Library/ColorSync/Profile/Displays/dougs_color_lcd_2020-07-31.icc}

The first view "Raw" would ignore the ICC profile, since the config author knows it would not make sense for that view. The second view "Film" would leverage the new display_colorspaces from PR #939 and <USE_DISPLAY_NAME> from PR #1038. It also leverages the ability for FileTransform to load an ICC monitor profile from PR #541. The view transform would convert from the scene-linear reference space to the display reference space, and then the ICC profile would be used to convert to monitor code values.

The name "Dougs-ICC-Profile" would be what OCIO extracts from the ICC profile, for this example (assuming it was a custom profile from a monitor calibration app such as from X-Rite). As a first cut, this could simply use the Description tag ('desc') from the ICC profile since that is mandatory in all valid profiles. However on MacOS, Apple also uses a proprietary tag ('dscm') and that is what is seen in the OS System Display Preferences, so a more sophisticated approach may be needed. One could also imagine potentially wanting to append a date/time string at the end. Nuances like this could be enhanced in a follow-up PR, but the basic idea is that OCIO would generate the name using the profile itself.

The PR for this issue would include the code needed to obtain the path for the ICC profile from the OS on both macOS and Windows. On Linux, there are some options for obtaining a profile, but they are not standardized and so this would be out of scope for the initial PR. So initially on Linux, the call to automatically instantiate the virtual display would fail. However, we will provide a way for the application to manually indicate which ICC profile to use to instantiate the display, and this could be used by app developers on Linux that want to use the feature.

One unresolved question is whether the FileTransform should simply use the absolute path to the ICC profile. In other words, should it just point to the profile at the place that the given OS stores it. This should be ok given that when OCIO instantiates the new display, it would be done in the application's in-memory config instance. If the application were to then write the config, it might be undesirable to have it referring to an absolute path rather than to a file that is part of the config's search_path. However, the normal use-case for this feature is simply to add a temporary display and so we don't anticipate applications needing to write out the config. But if it did, the application would be able to make a copy of the file if it wanted to and make the necessary changes to the config before writing it.

One possible scenario where it might be necessary to write out the config is if a user were to bake in one of the instantiated views into some content that they then want to share with someone else. In this case, the application would have a valid instantiated color space and it could persist that for the user, if necessary. However, this would obviously not be a desirable workflow. OCIO is no different from ICC-based apps in this regard. For example, Photoshop users generally know to save work in a standard color space if they want to share it with someone, rather than baking in their personal monitor profile.

It is possible for a user to change their ICC profile in the OS Preference panels while applications are running. In this case, there is usually a call-back that applications may use to be notified. A notified application could then ask OCIO to instantiate a new display color space using the new profile. It would be up to the application to then delete the first display color space, if it is no longer needed. It is easier for an application to manage this rather than OCIO since it will know, e.g. that it is an updated profile for an existing monitor rather than a new second monitor being connected.

Some ICC-based applications (such as Photoshop) keep track of which windows are on which monitor and will apply the correct color management, for example as a user drags a window from one display to another. Doing this involves very window-system-specific code and so is out of scope for this proposal. However, OCIO will be able to instantiate a display for each monitor and so it will have all the pieces in place for an application to be able to implement this functionality.

Note that the proposed feature is opt-in on two levels. First, the config author would add the virtual display. Second, the application using OCIO would ask OCIO to instantiate the virtual display into an actual display. Both of these steps need to happen for a user to actually see an ICC-based display option in an application menu.

Another potential name for the feature would be "display template" since it is allowing the config author to provide a template of views that OCIO may use to instantiate an actual display.

[sobotka]

Very curious if there has been any thought to the V4 issue. Namely that with V4 ICC protocol, it is impossible to derive the native whitepoint via the wtpt tag, and as such, it makes display colourimetry extremely challenging.

[doug-walker]

Hi Troy, the 'chad' tag may be used to recover the original whitepoint of the display. Although I agree with you that there are many aspects of ICC profiles in general that are challenging. Nevertheless I think it's very useful to have a bridge to the ICC world since it is the dominant color management system out there currently.

[sobotka]

Hi Troy, the 'chad' tag may be used to recover the original whitepoint of the display.

I believe that V4 complicates the chad tag, if it is present at all.

I know Graeme has published the arts tag, but V4 has made things much worse (impossible) for gathering absolute colorimetric information.

[hodoulp]

@sobotka The feature is now completed (as described in the issue) and merged if you see some improvements you can still log an issue.