Add 'xdr-video' as a new encoding option

[doug-walker]

The "encoding" attribute of a color space is intended to give a rough sense of how color values are numerically encoded in a color space. The current options are: 'scene-linear', 'log', 'data', 'display-linear', 'sdr-video', and 'hdr-video'. The encoding may be used for many purposes such as:

• Filtering color space options for display in menus
• Adjusting what type of image processing algorithm to apply to an image
• Interfacing with other systems such as OpenFX (which has a notion of "Basic" color spaces, based on the encoding)
• Creating viewing rules

There is a trend towards driving HDR displays with extended-range versions of SDR color spaces. This allows a color space to be used for HDR but with SDR compatibility. This is very helpful for apps that have an SDR user-interface being shown on an HDR monitor. In these color spaces, 1.0 is essentially the SDR white point and values extend above that to reach HDR luminance levels. Sometimes negative values are also allowed to obtain a wider color gamut.

In the current ACES config, there is a "Display P3 HDR - Display" color space which is a good example of this. Its encoding is set to "hdr-video" but that is somewhat misleading since the [0,1] range is essentially an SDR color space.

The proposal is to add a new "xdr-video" encoding to be used when describing these color spaces. This is for color spaces that are basically "sdr-video" between [0,1] but allow values way above 1.0 to drive HDR displays. Here is a comparison of the three video encodings:

• 'sdr-video': A color space for an SDR monitor/display. Values are roughly [0,1] but may extend about 9% above/below that to accommodate video over/under-shoot. Rec.709 is a good example.
• 'hdr-video': A color space for a strictly HDR monitor/display where 1.0 is obtaining HDR luminance levels. This is essentially very similar to a logarithmic color space, except it is display-referred. Rec.2100 PQ is a good example.
• 'xdr-video': A color space intended to drive an HDR display but with SDR compatibility. The 1.0 provides an SDR luminance level and values well above 1.0 are expected to obtain HDR luminance levels. The extended-range version of Display P3 is a good example.

Note: The library itself does not enforce the content of the encoding string, so this proposal is not a library change, it is just a documentation and workflow change.

[carolalynn]

Hiya - preference is for "edr-video" :)

[doug-walker]

@carolalynn , should we update "srgbx_p3d65_display"? Should it be "srgbe_p3d65_display" or "esrgb_p3d65_display"?

[carolalynn]

Ooooph. This was honestly better when we were using Display P3 in the alias too. Will the user name change to Display P3 - EDR - Display?

If so, I think my preference is for "srgbe_p3d65_display" to keep the srgb at the front, even though that is less technically correct.

Though I suppose one could argue we should break the grouping and go with "esrgb" so that folks don't choose it erroneously.

@KevinJW @KelSolaar @remia keep me honest here, what is the least gross?

[KevinJW]

https://developer.apple.com/documentation/coregraphics/cgcolorspace/extendedsrgb

suggests e at the beginning

Khronos spec says

VK_COLOR_SPACE_EXTENDED_SRGB_NONLINEAR_EXT specifies support for the images in extended sRGB color space, encoded according to the scRGB specification

And for more fun aside https://registry.khronos.org/DataFormat/specs/1.3/dataformat.1.3.html#TRANSFER_CONVERSION

scRGB annex B changes the behavior of the {R,G,B}=0.0031308 case compared with the sRGB specification. Since both calculations agree to seven decimal places, this is unlikely to be significant in most applications. scRGB annex B does not define the EOTF -1, so the formulae below are derived by extending the sRGB formulae.

Now one might also need to double check e-sRGB because the world just needs another standard, at least PIMA 7667: 2001 is nominally a legacy :-)

Anyway, they all use Extended as a prefix, so I guess I vote for the e in front.

[KevinJW]

or scRGB :-)

[carolalynn]

Solid point, let's do "esRGB"

[doug-walker]

@carolalynn, just to make sure I have this right, could you please confirm the interop ID will be: "esrgb_p3d65_display".

Regarding the user name, is your preference to change "Display P3 HDR - Display" to "Display P3 EDR - Display"?

Unlike color spaces, displays don't have an alias mechanism so this may cause some compatibility issues for people using earlier versions, but we are bumping the color spaces version of the config, so I think it is acceptable. (At least for the display color space, we could add the previous name as an alias.)

[doug-walker]

Actually, now that I have found the equations for e-sRGB in PIMA 7667: 2001, it's important to note that this is not actually what we're doing. The e-sRGB spec uses an offset so that 0.0 is about a third of the way up an integer representation. I think it was an attempt to be able to transmit negative values in an integer container. This makes me worry that using "esrgb" might add confusion since for us, 0.0 is at 0, there is no offset.

[KevinJW]

scRGB appears to be a better match for the actual transfer function maybe.

[doug-walker]

@KevinJW , I may be wrong, but my understanding is that "scRGB" uses a linear transfer function. The "scRGB-nl" uses an extended sRGB transfer function. But both encodings are intended for integer file formats and so have an offset somewhat similar to "e-sRGB" that places 0.0 part way up the encoding. So I feel that using "scrgb" would be similarly confusing to "esrgb".

As a result, my vote is to stick with @carolalynn 's original proposal above, which was to use "srgbe_p3d65_display" for the Interop ID. And we will use her preference for "edr-video", if there are no objections. So the remaining question is what should be the user-facing name. Should we stay with "Display P3 HDR - Display" or switch to "Display P3 EDR - Display"?

[carolalynn]

I'm good with those choices, Doug. I sort of think we should keep the user facing name HDR - this is technically true, and will be less confusing for folks.