Pekka Paalanen wrote: > The only question is, do color management and HDR support conceptually > make sense as independent features, or would implementations always > support both with essentially the same effort?
In my view, you can certainly add an HDR extension independently of a color management extension, but it would either be a hack to get things working (i.e. make all sorts of general display colorspace assumptions or approximations) or if less hacky, would start to encompass general color management concerns. A Color Management extension on the other hand adds a bunch of non-HDR related stuff, but HDR then slots in as a sub-case of handling differences in display characteristics. > "Supporting HDR" here means only that the compositor is able to process > HDR content from clients, it does not include the capability to drive > HDR monitors. IOW, a compositor that only converts HDR content to SDR > is a valid HDR implementation from protocol perspective. It merely > advertises all outputs as SDR. True, but once you allow for a display to be labelled HDR and have an associated color profile, there isn't that much to handling HDR like any other display. > The big question here is: does a HDR video, with reasonable defaults if > not explicitly defined, allow to programmatically manufacture a custom > ICC profile with the HDR primaries? Yes, this works. Some HDR TV calibration already takes this approach. > What I mean is, if a compositor implements color management, is there > any good reason to not implement HDR luminance mapping as well? At > least the implementation would not differ, just the parameters or > tables. That is why I suspect supporting HDR will be easy on top of a > good color conversion implementation. I agree. > Harish Krupo <harish.krupo....@intel.com> wrote: >> Out-of-gamut pixels are handled completely separately compared to >> out-of-dynamic-range pixels. Out of gamut can be solved either clamping >> the color after conversion or by using a nearest approximation of the >> color available within the colorspace. >> Out-of-dynamic-range OTOH, requires applying tone mapping to adjust the >> luminance ranges. Adapting the luminance range is just another aspect of mapping one color space to another. One mechanism for achieving this is to use a relative colorspace description of the spaces and then use an orthogonal luminance mapping (such as tone mapping for HDR -> SDR). > I thought that some of the rendering intents of color management do the > same as HDR luminance mapping. Do they not? Only few parameters more to > adjust the ranges of the mapping curves. Standard ICC intents generally do not, because most of them work around a Relative Colorimetric assumption. Absolute Colorimetric in theory could support this, but in practice is not a mechanism that would work the way you want for HDR handling (i.e. it would work for SDR->HDR, but would clip HDR->SDR, and would have the side effect of not aligning the white points, which you probably don't want it to do.) But I think it should be relatively straight forward to augment the standard ICC CMM linking parameters with some HDR options. (In terms of implementation I would hope that lcms's plugin architecture would help facilitate this, or at worst it could be patches and the changes fed back upstream to Marti). The two options I would imagine adding would be SDR->HDR brightness (i.e. what the SDR white brightness should be), and for HDR->SDR what the HDR diffuse white is and possibly a tone mapping strategy. (The technical details of this can be guided by something like the ITU-R BT.2390-2 EETF). > It is also likely that color management will need a wl_output extension > object of its own, so if HDR information can be integrated in that, it > would be simpler to use. Yep. > There is no need to ensure at the protocol level. If the compositor > advertises HDR support and there exists at least one HDR output, the > player should always produce HDR frames if possible, especially if it > is cheaper for the player than SDR. The compositor will take care of the > SDR conversion if necessary, and there won't be glitches if the window > moves between HDR and SDR monitors as there is no need for the client > to catch up. In a color managed implementation, the player just need mark the source with the video ICC profile and HDR intent information for default handling by the Compositor. If it wanted to do the HDR handling itself, it would download the output ICC profile to figure out its conversion from video source to output space, and then mark the buffer as being in the primary output colorspace so that the Compositor knows it doesn't have to do anything. Cheers, Graeme Gill. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel