Topic
The RGBHDR colorMode name and its documentation appear to conflate two separate concepts: color gamut and dynamic range.
As far as I can tell, RGBHDR currently offers access to a wider P3-derived color gamut, but I have not found a way for it to express or render luminance values above SDR white. In other words, it appears to provide wide-gamut RGB, but not high-dynamic-range (HDR) RGB.
The name RGBHDR therefore seems misleading. “HDR” customarily implies an extended luminance range: for example, an image format or rendering pipeline that can represent values above ordinary SDR white, such as Ultra HDR JPEG gain-map images or floating-point OpenEXR images. These formats can encode "brighter-than-white" image content. By contrast, the P3 color space expands the gamut of chromaticities available beyond sRGB, but does not by itself imply a larger luminance range.
Since RGBHDR appears to be implemented as an alias to a P3 color space, I think it would be wise to rename it before the name becomes too entrenched. A name such as RGB_P3 would be clearer.
Likewise, the current documentation for RGBHDR says:
RGBHDR - High Dynamic Range RGB defined within the Display P3 color space. Colors are expressed with an extended dynamic range. To render these colors accurately, you must use the HDR canvas.
I believe this documentation should be revised, since I have not found a way for the RGBHDR colorMode, by itself, to provide luminance values above SDR white. A more accurate description might be:
RGB_P3 - RGB values defined within the Display-P3 color space. This allows colors outside the sRGB gamut on compatible displays.
In my testing, colors specified in RGBHDR were visibly able to access portions of the P3 gamut that lie outside sRGB, but were not able to produce luminance values above SDR white. By contrast, doing actual HDR output in p5 required making a separate WebGPU rendering pipeline with an rgba16float presentation buffer and extended tone mapping. For anyone interested, I made an experimental proof-of-concept that used these techniques to demonstrate the distinction between extended dynamic range and extended color gamut. To be clear, the current RGBHDR implementation only allows for the graphics on the left side of this sketch:
https://editor.p5js.org/golan/sketches/7n2mxXg09

This sketch compares a 2x2 matrix of gamut and dynamic range:
- SDR sRGB
- SDR Display-P3
- HDR sRGB
- HDR Display-P3
I was able to preview this using:
- macOS 15.6+
- Chrome 148+
- an HDR-capable MacBook Pro XDR display
- with the Settings display preset: "Apple XDR Display (P3-1600 nits)"
Thanks for your consideration.
Topic
The
RGBHDRcolorMode name and its documentation appear to conflate two separate concepts: color gamut and dynamic range.As far as I can tell,
RGBHDRcurrently offers access to a wider P3-derived color gamut, but I have not found a way for it to express or render luminance values above SDR white. In other words, it appears to provide wide-gamut RGB, but not high-dynamic-range (HDR) RGB.The name
RGBHDRtherefore seems misleading. “HDR” customarily implies an extended luminance range: for example, an image format or rendering pipeline that can represent values above ordinary SDR white, such as Ultra HDR JPEG gain-map images or floating-point OpenEXR images. These formats can encode "brighter-than-white" image content. By contrast, the P3 color space expands the gamut of chromaticities available beyond sRGB, but does not by itself imply a larger luminance range.Since
RGBHDRappears to be implemented as an alias to a P3 color space, I think it would be wise to rename it before the name becomes too entrenched. A name such asRGB_P3would be clearer.Likewise, the current documentation for
RGBHDRsays:I believe this documentation should be revised, since I have not found a way for the
RGBHDRcolorMode, by itself, to provide luminance values above SDR white. A more accurate description might be:In my testing, colors specified in
RGBHDRwere visibly able to access portions of the P3 gamut that lie outside sRGB, but were not able to produce luminance values above SDR white. By contrast, doing actual HDR output in p5 required making a separate WebGPU rendering pipeline with anrgba16floatpresentation buffer and extended tone mapping. For anyone interested, I made an experimental proof-of-concept that used these techniques to demonstrate the distinction between extended dynamic range and extended color gamut. To be clear, the currentRGBHDRimplementation only allows for the graphics on the left side of this sketch:https://editor.p5js.org/golan/sketches/7n2mxXg09
This sketch compares a 2x2 matrix of gamut and dynamic range:
I was able to preview this using:
Thanks for your consideration.