Adding P3-D65 (aka DisplayP3) gamut support

[hpd]

Problem Statement
Many devices used in the ACES, OCIO and USD ecosystems for content authoring and display have screens that use the P3 primaries and D65 white point. In the Apple ecosystem, this gamut is generally referred to as "Display P3". Thus far, the ACES OCIO config has colorspaces designed to support textures authored with either the sRGB gamut or the ACES AP1 (aka ACEScg) gamut, with a couple of different transfer functions. It also has a colorspace for handling linear content with the P3-D65 gamut. It has not had colorspaces that support textures authored with the P3 primaries, D65 white point and sRGB transfer function.

As such, it would be5 valuable to the community of users of the ACES OCIO config to add colorspaces that directly support textures authored with the P3-D65 (aka DisplayP3) gamut.

Proposed solution
Add colorspaces the support the following combination of primaries, white points and transfer functions

• P3 primaries, D65 white point, sRGB transfer function

The colorspaces would be named

• sRGB encoded - P3-D65 - Texture

In order to provide the most flexibility to different pipelines and authoring ecosystems, these colorspaces would have the following aliases

• srgb_p3d65
• srgb_encoded_p3d65_tx
• srgb_displayp3

As a related, but somewhat separate issue, the proposal would put these colorspaces in the following family:
Input/Texture
Given that that may end up being a separate Issue, the colorspaces would live in the Utility family.

These colorspaces would be in the following category
texture

[doug-walker]

The aliases look good. For consistency with the other spaces, I think we should remove the first dash from the name and use a capital E, as follows:
name: "sRGB Encoded P3-D65 - Texture"

I will take an action item to add the color space to the built-in transforms in the OCIO library.

[KelSolaar]

@doug-walker : I started to work on that in #100.

[doug-walker]

At the Configs WG meeting we discussed also adding a display color space for Display P3. I took the action item to summarize all of the changes proposed for the next configs release.

For the CG config:

displays:
  Display P3 - Display:
    - !<View> {name: Raw, colorspace: Raw}
    - !<Views> [ACES 1.0 - SDR Video, Un-tone-mapped]

For the Studio config:

displays:
  Display P3 - Display:
    - !<View> {name: Raw, colorspace: Raw}
    - !<Views> [ACES 1.0 - SDR Video, ACES 1.0 - SDR Video (D60 sim on D65), Un-tone-mapped]

For both configs:

display_colorspaces:
  - !<ColorSpace>
    name: Display P3 - Display
    aliases: [displayp3_display]
    family: Display
    categories: [file-io]
    encoding: sdr-video

colorspaces:
  - !<ColorSpace>
    name: sRGB Encoded P3-D65 - Texture
    aliases: [srgb_p3d65, srgb_encoded_p3d65_tx, srgb_displayp3]
    family: Utility
    categories: [file-io, texture]
    encoding: sdr-video

For both configs, updates to aliases and categories:

  - !<ColorSpace>
    name: Linear P3-D65
    aliases: [lin_p3d65, Utility - Linear - P3-D65, lin_displayp3, Linear Display P3]
    family: Utility
    categories: [file-io, working-space, texture]
    encoding: scene-linear

And in addition we should add the texture category to additional color spaces in the CG and Studio configs. I will create a separate issue for that.

[KelSolaar]

So, because the displays are driven from the Reference config and aces-dev, we don't have a process to add a new display. Three solutions:

1. Fork aces-dev temporarily and add the ODT there.
2. Come up with something not super elegant and contrived to get it injected from the spreadsheets.
3. Come up with something dirty hardcoded into the generator (but that could be removed if 1. is rolled officially at a later point).

[doug-walker]

I think any of those options are fine as a temporary solution. I guess for option 2 you would need the built-in added to the library? Please let me know if that's a blocker and I will prioritize it.

(I know HP contacted Alex and Scott to propose adding Display P3 to ACES but I don't know where that stands and I assume it won't be ready in time for this.)

[KelSolaar]

We would certainly need a builtin I reckon, it would not hurt irrespective of the chosen solution!

[nick-shaw]

displays:
  Display P3 - Display:
    - !<View> {name: Raw, colorspace: Raw}
    - !<Views> [ACES 1.0 - SDR Video, ACES 1.0 - SDR Video (D60 sim on D65), Un-tone-mapped]

Why only SDR views? Display P3 on e.g. recent MacBook Pros can support HDR as well, as I have in my config?

[doug-walker]

It's a fair point @nick-shaw . The implementation of the built-in transform in OCIO is intended to match what's called kCGColorSpaceExtendedDisplayP3 on the Apple side which is a color space they use with values above 1 for EDR display. So we could potentially have added the 1000 nit ACES view transform. Currently our displays are classified as either SDR or HDR, so having one that is potentially both may require some more thought and testing.

We're about to close this issue since the support we discussed with Apple during the configs meeting is complete. Perhaps you could log this as a feature request for the next version of the configs?

[nick-shaw]

Certainly OCIOv2 in Nuke supports a mix of SDR and HDR Output Transforms in Display P3 on my 2023 MacBook Pro, using my config. But I realise that is very limited testing. I have logged a feature request. I hope I have done this correctly.

[doug-walker]

This is now implemented, Display P3 is available as a texture space and a display color space in the new configs. (Nick has opened a separate issue for his request.)