1. Introduction
This section is not normative.
CSS Color 4 adds Wide Color Gamut (WCG) color spaces to the Open Web Platform. By design, these are all Standard Dynamic Range (SDR) color spaces. This specification defines additions to support High Dynamic Range (HDR).
While WCG specifications have been broadly stable for some decades, HDR standards are less mature and have undergone frequent revision in the last decade.
1.1. Value Definitions
This specification follows the CSS property definition conventions from [CSS2] using the value definition syntax from [CSS-VALUES-3]. Value types not defined in this specification are defined in CSS Values & Units [CSS-VALUES-3]. Combination with other CSS modules may expand the definitions of these value types.
In addition to the property-specific values listed in their definitions, all properties defined in this specification also accept the CSS-wide keywords as their property value. For readability they have not been repeated explicitly.
2. Controlling Dynamic Range
2.1. Defining Dynamic Range
Dynamic range is the difference in luminance between the lightest and the darkest colors. Dynamic range is measured in photographic stops. One stop is a doubling of luminance.
function DynamicRange( high, low) { return Math. log2( high) - Math. log2( low); }
In Standard Dynamic Range (SDR), the media white (the color of a normal white background, or of white text on a dark background) is the lightest possible color.
For SDR, luminance is treated as relative to media white. Making the screen brighter does not change the dynamic range, because the darkest color also gets brighter.
In High Dynamic Range (HDR), brighter colors than media white can be displayed. For example, if media white on an HDR display is set to around 200 cd/m² it might be possible to display highlights at 1000 cd/m². Typically, the brightest colors can only be displayed on a small part of the display, and for a limited time. This is because of energy usage and heating considerations.
For HDR, luminance is treated as absolute, rather than being relative to media white. Using a brighter screen increases the dynamic range, while the luminance of media white remains constant.
2.2. Introducing Headroom
This section is non-normative
The luminance level which an HDR display can produce varies greatly.
The amount by which peak white is greater than media white is termed the HDR headroom, and depends on the level of media white, user preference, and viewing conditions.
It is typically expressed in photographic stops. Thus, standard dynamic range (SDR) by definition has an HDR headroom of 0 stops, because the brightest white is media white.
In dim viewing conditions, with media white set to 100 cd/m2, this gives four stops (16x) of HDR headroom.
The Web platform does not currently directly expose the level of headroom of a display, because it depends on viewing conditions and real-time, unquantized headroom information would be a tracking vector (for example, detecting that a user moved outside and that it is a sunny day).
It is not always desirable to use the maximum available level of HDR headroom. CSS provides a way to control, in broad terms, how much headroom is desired; and this level can vary by element and over time.
2.3. The dynamic-range-limit property
Name: | dynamic-range-limit |
---|---|
Value: | standard | high | constrained-high | <dynamic-range-limit-mix()> |
Initial: | high |
Applies to: | all elements |
Inherited: | yes |
Percentages: | n/a |
Computed value: | see Computed Value for dynamic-range-limit |
Canonical order: | per grammar |
Animation type: | by dynamic-range-limit-mix() |
Tests
- standard
- The highest luminance color that is displayed is the same as media white, i.e. the CSS color white.
- high
- The highest peak luminance that is displayed is much greater than media white, i.e. the CSS color white; the precise level is not specified.
- constrained-high
- The highest peak luminance that is displayed is somewhat greater than media white, i.e. the CSS color white, such that a mix of SDR and HDR content can be comfortably viewed together.
2.4. Mixing Dynamic Range Limits: the dynamic-range-limit-mix() function
This function takes two dynamic-range-limit values, converts them internally to a value in stops above media white, and alters the display to the result of mixing them by the specified amount. The actual calculated result is not exposed.
dynamic-range-limit-mix() = dynamic-range-limit-mix( [ <ident> && <percentage [0,100]> ]#)
Tests
If the sum of all percentages is 0%, then the function is invalid.
2.5. Computed Value for dynamic-range-limit
If the specified value is standard, constrained-high, or high, then the computed value is the specified value.
If the specified value is dynamic-range-limit-mix(), then the computed value is determined by the following algorithm:
-
Let v1, ..., vN be the computed values for the parameters to be mixed.
-
Let p1, ..., pN be the mixing percentages, normalized to sum to 100%.
-
Define the contributing percentages as:
-
Let p1_standard,...,pN_standard be the percentages for standard in v1,...,vN
-
Let p1_constrained_high,...,pN_constrained_high be the percentages for constrained-high in v1,...,vN
-
Let p1_high,...,pN_high be the percentages for high in v1,...,vN
-
-
Compute the weighted sums as:
-
p_standard=(p1_standard*p1+...+pN_standard*pN)/100.
-
p_constrained_high=(p1_constrained_high*p1+...+pN_constrained_high*pN)/100.
-
p_high=(p1_high*p1+...+pN_high*pN)/100.
-
-
If p_standard, p_constrained_high, or p_high equals 100%, then the computed value is standard, constrained-high, or high, respectively.
-
Otherwise, the computed value is dynamic-range-limit-mix(), with parameters standard, constrained-high, and high, in that order, and percentages p_standard, p_constrained_high, and p_high, omitting parameters with a percentage equal to 0%.
Tests
dynamic-range-limit-mix ( high10 % , dynamic-range-limit-mix ( standard25 % , constrained-high75 % ) 20 % , dynamic-range-limit-mix ( constrained-high10 % , high30 % ) 20 % )
is
dynamic-range-limit-mix ( standard10 % , constrained-high40 % , high50 % )
3. Specifying Predefined and Custom Color Spaces: the color() Function
The color() function allows a color to be specified in a particular, given color space (rather than the implicit sRGB color space that most of the other color functions operate in).
In this specification the color() function is extended to allow predefined color spaces for HDR, in addition to the predefined SDR spaces from CSS Color 4 § 10. Predefined Color Spaces and the relative color syntax from CSS Color 5 § 4 Relative Color Syntax.
Its syntax is now as follows:
color() = color( [from <color>]? <colorspace-params> [ / [ <alpha-value> | none ] ]? ) <colorspace-params> = [<custom-params> | <predefined-rgb-params> | <predefined-polar-params> | <predefined-rectangular-params> | <xyz-params>] <custom-params> = <dashed-ident> [ <number> | <percentage> | none ]+ <predefined-rgb-params> = <predefined-rgb> [ <number> | <percentage> | none ]{3} <predefined-polar-params> = jzczhz [ <number> | <percentage> | none ]{2} [ <hue> | none] <predefined-rectangular-params> = <predefined-rectangular> [ <number> | <percentage> | none ]{3} <predefined-rgb> = srgb | srgb-linear | display-p3 | a98-rgb | prophoto-rgb | rec2020 | rec2100-pq | rec2100-hlg | rec2100-linear <predefined-rectangular> = jzazbz | ictcp <xyz-params> = <xyz> [ <number> | <percentage> | none ]{3} <xyz> = xyz | xyz-d50 | xyz-d65
4. Predefined color spaces for HDR:
In addition to the SDR color spaces defined by CSS Color 4, the following HDR color spaces are defined for use in the color function.
Serialization of values in these new color spaces is identical to the description in CSS Color 4 § 15. Serializing <color> Values.
4.1. rec2100-pq
The rec2100-pq [Rec_BT.2100] color space accepts three numeric parameters, representing the red, green, and blue channels of the color, with each having a valid range of [0, 1] regardless of the actual bit depth (10 or 12 bits per component).
The Perceptual Quantizer (PQ) electro-optical transfer function is used [SMPTE-ST-2084],[Rec_BT.2100]. PQ assumes a reference viewing condition where the screen surround is at 5 cd/m².
ITU Reference 2100 is used for HDR 4k and 8k television.
In contrast to SDR color spaces and some HDR color spaces, the PQ values are absolute rather than relative.
add a diagram showing SDR and HDR dynamic ranges on a log scale
It has the following characteristics: (The display primaries are the same as [Rec.2020]):
x | y | |
Red chromaticity | 0.708 | 0.292 |
---|---|---|
Green chromaticity | 0.170 | 0.797 |
Blue chromaticity | 0.131 | 0.046 |
White chromaticity | D65 | |
Transfer function | Perceptual Quantizer | |
White luminance | 203 cd/m² | |
Peak white luminance | 10,000 cd/m² | |
Black luminance | ≤ 0.005 cd/m² | |
Image state | display-referred | |
Percentages | Allowed for R, G and B | |
Percent reference range | for R,G,B: 0% = 0.0, 100% = 1.0 |
For narrow-range PQ video in a non-reference viewing environment, or for HLG (in any viewing environment), the black level should be adjusted using the PLUGE test signal and procedure specified in [Rec_BT.814] Annex . For PQ values in CSS, which uses wide-range, the black corresponds to code point 0.
color(rec2100-pq 1.0 1.0 1.0);
color(rec2100-pq 0.58 0.58 0.58);
This color represents a mid grey, like a photographer’s "18% reflectance grey" card, at 17 cd/m².
color(rec2100-pq 0.34 0.34 0.34)
add other examples, including encoding of sRGB red, green, blue and P3 red, green, blue.
Linear-light RGB signals are converted to PQ encoded as follows. An absolute luminance scale is used, so the luminance of diffuse (media) white is required to scale relative luminances. The maximum encodable value (peak, small-area white) in PQ is 10,000 cd/m². Media white is 203 cd/m² [Rpt_BT.2408].
var Er; // the red, green or blue component, [0, 1] for SDR, [0, 70ish] for HDR var Yw= 203 ; // the absolute luminance of diffuse white, cd/m² var x= Er* Yw/ 10000 ; // absolute luminance of peak white is 10,000 cd/m². const n= 2610 / ( 2 ** 14 ); const m= 2523 / ( 2 ** 5 ); const c1= 3424 / ( 2 ** 12 ); const c2= 2413 / ( 2 ** 7 ); const c3= 2392 / ( 2 ** 7 ); xPQ= ((( c1+ ( c2* ( x** n))) / ( 1 + ( c3* ( x** n)))) ** m);
xPQ is the "gamma-corrected" (OETF-adjusted) signal [0, 1].
PQ encoded values are converted to linear-light as follows:
var xPQ; // the red, green or blue PQ-encoded component, [0, 1] const ninv= ( 2 ** 14 ) / 2610 ; const minv= ( 2 ** 5 ) / 2523 ; const c1= 3424 / ( 2 ** 12 ); const c2= 2413 / ( 2 ** 7 ); const c3= 2392 / ( 2 ** 7 ); var x= ((( Math. max((( xPQ** minv) - c1), 0 ) / ( c2- ( c3* ( xPQ** minv)))) ** ninv); var Yw= 203 ; // the absolute luminance of diffuse white, cd/m² var Ea= x* 10000 ; // absolute luminance, [0, 10,000]. var Er= x* 10000 / Yw; // luminance relative to diffuse white, [0, 70 or so].
4.2. rec2100-hlg
The rec2100-hlg [Rec_BT.2100] color space accepts three numeric parameters, representing the red, green, and blue channels of the color, with each having a valid range of [0, 1] regardless of the actual bit depth (10 or 12 bits per component).
The Hybrid Log-Gamma (HLG) electro-optical transfer function is used [ARIB_STD-B67],[Rec_BT.2100]. HLG can be used with displays of different brightness in a wide range of viewing environments, with user control of the overall brightness level. A value of 0.75 represents "diffuse" or "media" white while an "18% reflectance grey" card has a value of 0.38. [Rec_BT.2390].
It has the following characteristics: (The display primaries are the same as [Rec.2020]):
x | y | |
Red chromaticity | 0.708 | 0.292 |
---|---|---|
Green chromaticity | 0.170 | 0.797 |
Blue chromaticity | 0.131 | 0.046 |
White chromaticity | D65 | |
Transfer function | Hybrid log Gamma | |
White luminance | ||
depends on viewing conditions | ||
Peak white luminance | 12 times reference white | |
Black luminance | depends on reference white, see text | |
Image state | scene-referred | |
Percentages | Allowed for R, G and B | |
Percent reference range | for R,G,B: 0% = 0.0, 100% = 1.0 |
For narrow-range HLG video (in any viewing environment), the black level should be adjusted using the PLUGE test signal and procedure specified in [Rec_BT.814] Annex 4. For HLG values in CSS, which uses wide-range, the black corresponds to code point 0.
color(rec2100-hlg 0.75 0.75 0.75);
This color represents a mid grey, at 26 to 104 cd/m².
color(rec2100-hlg 0.38 0.38 0.38)
Linear-light RGB signals are converted to HLG encoded as follows [Rec_BT.2390]:
var E; // the red, green or blue component, [0, 1] const a= 0.17883277 ; const b= 0.28466892 ; // 1 - (4 * a) const c= 0.55991073 ; // 0.5 - a * Math.log(4 *a) // handle negative values var sign= E< 0 ? - 1 : 1 ; var abs= Math. abs( E); if ( abs<= 1 / 12 ) { Edash= sign* Math. sqrt( 3 * abs); } else { Edash= a* Math. log( 12 * E- b) + c; }
Edash is the "gamma-corrected" (OETF-adjusted) signal.
The reverse conversion (HLG encoded to linear light) is as follows [Rec_BT.2390]::
var Edash; // the red, green or blue encoded component, [0, 1] const a= 0.17883277 ; const b= 0.28466892 ; // 1 - (4 * a) const c= 0.55991073 ; // 0.5 - a * Math.log(4 *a) if ( Edash<= 0.5 ) { E= ( Edash** 2 ) / 3 ; } else { E= ( Math. exp(( Edash- c) / a) + b) / 12 ; }
add black level lift Β as defined on same page?
4.3. rec2100-linear
The rec2100-linear [Rec_BT.2100] color space accepts three numeric parameters, representing the red, green, and blue channels of the color, with each having a nominal range of [0, 1] regardless of the actual bit depth (10 or 12 bits per component).
The color with red, green and blue all at 1.0 represents HDR Reference White with an absolute luminance of 203 cd/m².
color ( rec2100-linear1 1 1 )
color ( rec2100-linear9.852 9.852 9.852 )
represents a white highlight with an absolute luminance of 9.852 × 203 = 1,999 cd/m².
color(rec2100-linear 1 1 1)
A linear-light electro-optical transfer function is used.
It has the following characteristics: (The display primaries are the same as [Rec.2020]):
x | y | |
Red chromaticity | 0.708 | 0.292 |
---|---|---|
Green chromaticity | 0.170 | 0.797 |
Blue chromaticity | 0.131 | 0.046 |
White chromaticity | D65 | |
Transfer function | Linear | |
White luminance | 203 cd/m² | |
Peak white luminance | 10,000 cd/m² | |
Black luminance | 0.001 cd/m² | |
Image state | display-referred | |
Percentages | Allowed for R, G and B | |
Percent reference range | for R,G,B: 0% = 0.0, 100% = 1.0 |
4.4. Jzazbz
The Jzazbz color space [Safdar-PUCS] accepts three numeric parameters, with Jz representing the Lightness (similar to L in Lab) while az and bz represent the redness-greenness and yellowness-blueness opponent-color axes (similar to a and b in Lab).
CIE Lab uses a lightness scale with a [0%, 100%] range, relative to media white, and has been experimentally extended to L=400%. In contrast, the Jz axis in Jzazbz, which has a [0, 1.0] range, uses an encoding similar to Perceptual Quantizer, and can represent a dynamic range of more than 13 stops.
It has the following characteristics:
x | y | |
White chromaticity | D65 | |
---|---|---|
Transfer function | Perceptual Quantizer | |
Peak white luminance | 10,000 cd/m² | |
Black luminance | 0.001 cd/m² | |
Image state | display-referred | |
Percentages | Allowed for Jz, az and bz | |
Percent reference range | for Jz: 0% = 0.0, 100% = 1.0 for az and bz: -100% = -1.0, 100% = 1.0 |
Note that unlike Lab, a D65 whitepoint is used. Thus, for most RGB spaces (which also use a D65 whitepoint) no chromatic adaptation step need be performed.
color(jzazbz 0.22207 -0.00016 -0.00012)
4.5. JzCzHz
Similar to LCH, which is the polar representation of Lab, JzCzHz is the polar form of Jzazbz. Jz is identical to the value in JzCzHz and represents the Lightness, while Cz represents the Chroma or colorfulness and Hz represents a hue angle, measured from the positive az axis, towards the positive bz axis.
color(jzazbz 0.17542 -0.1179 0.1092)
and here is the same color in the polar form
color(jzczhz 0.17542 0.1614 132.50)
4.5.1. Converting Jzazbz colors to JzCzHz colors
Conversion to JzCzHz is trivial:
- Hz = atan2(bz, az) // but convert to degrees!
- Cz = sqrt(az^2 + bz^2)
- Jz is the same
4.5.2. Converting JzCzHz colors to Jzazbz colors
Conversion to Jzazbz is trivial:
- az = Cz cos(H) // convert to radians first!
- bz = Cz sin(H) // convert to radians first!
- Jz is the same
4.6. ICtCp
The ICtCp color space is defined as Constant Intensity ICTCP signal format in [Rec_BT.2100] and accepts three numeric parameters, with I representing the Intensity (similar to L in Lab, but covering a luminance range up to 10,000 cd/m2) while CT and CP represent the yellowness-blueness (tritanope) and redness-greenness (protanope) opponent-color axes (similar to b and a, respectively, in Lab).
It is based on human visual system LMS cone primaries; the Hunt-Pointer-Estevez (HPE) XYZ to LMS transform is used, normalized to a D65 whitepoint. A crosstalk matrix is then applied, to reduce the gamut hull concavities of BT.2020 RGB, thus reducing interpolation errors. The crosstalk also provides improved lines of constant hue and improved uniformity of Just Noticeable Difference (JND) MacAdam ellipses.
It has the following characteristics:
x | y | |
White chromaticity | D65 | |
---|---|---|
Transfer function | Perceptual Quantizer | |
White luminance | 203 cd/m² | |
Peak white luminance | 10,000 cd/m² | |
Black luminance | 0.001 cd/m² | |
Image state | display-referred | |
Percentages | Allowed for I, Ct and Cp | |
Percent reference range | for I: 0% = 0.0, 100% = 1.0 for Ct and Cp: -100% = -1.0, 100% = 1.0 |
Although [Rec_BT.2100] defines ICTCP by a conversion from linear-light BT.2100 RGB [Rec_BT.2100], this conversion proceeds via LMS and thus, any other color space can also be represented by applying an XYZ to LMS transform.
Note that unlike Lab, a D65 whitepoint is used.
Also unlike Lab, which has primarily been tested with lower-intensity reflective colors, ICTCP has been tested with high-chroma, self-luminous, and high intensity (HDR) colors. This makes it suitable for color difference measurement (deltaE ITP) and for gamut mapping of SDR and HDR colors.
color(ictcp 0.58069 0 0)
5. Compositing SDR and HDR content
Compositing should take place in CIE XYZ, as it is a linear-light space without gamut limitations. Implementations may chose to composite in a linear-light RGB space instead, which will give the same result provided out-of-gamut values (negative, or greater than 100%) are correctly handled and not clipped or gamut mapped until the final transfer to the device color space.
Relative HDR, using the HLG transfer function, must map SDR media white to the same luminance as is used to display the 75% HLG value. [SMPTE-ST-2084]
For further details, see also tables 3 and 4 in ITU Rpt_BT.2408-0 [Rpt_BT.2408]
Absolute HDR, using the PQ transfer function, should map SDR media white to 203 cd/m², the same luminance as is used to display the 58% PQ value. [SMPTE-ST-2084] However, implementations may chose to incorporate a color re-rendering step (OOTF) to account for non-reference viewing conditions.
6. Serializing <color> Values
6.1. Serializing values of the color() function
This section extends CSS Color 4 § 15.5 Serializing values of the color() function
The serialized form of color() values is derived from the computed value and uses the color() form, with ASCII lowercase letters for the function name and the color space name.
The component values are serialized in base 10, as <number>. A single ASCII space character " " must be used as the separator between the component values, and also between the color space name and the first color component.
For the predefined HDR color spaces, the minimum precision for round-tripping is as follows:
HDR color space | Minimum bits |
---|---|
rec2100-pq, rec2100-hlg | 10 |
rec2100-linear, jzazbz, jzczhz, ictcp | 16 |
(16bit, half-float, or float per component is recommended for internal storage). Values must be rounded towards +∞, not truncated.
Do the PQ-based color spaces require tone-mapping (OOTF) for display in different viewing environments?
Privacy Considerations
The reason that numerical values of HDR headroom are not directly exposed by the Web platform is because doing so would expose the current viewing conditions, which would be a privacy violation.
Security Considerations
No Security concerns have been raised on this document
Accessibility Considerations
Some individuals may have a sensitivity to very bright colors, so user agents should provide a mechanism to limit the maximum luminance at user option. The toe and knee procedure in section 5.4.1 Mapping to display with limited brightness range of [Rec_BT.2390] is suggested as suitable.
The dynamic-range-limit property could also be set to standard or constrained-high in a user stylesheet.