Deploying Wide Color Gamut and High Dynamic Range in HD and UHD (2015)

This is an extended version of the paper with the same title that has been presented at IBC 2014. <sup xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">1</sup> Twenty years ago, Poynton presented a paper at IBC 1994 entitled “Wide gamut device-independent color image interchange.” The CCIR 709 standard had just been adopted (in 1990), and, by 1994, sRGB deployment in desktop computing was well under way. That paper anticipated commercial interest in exchange for wide-gamut imagery. As it turned out, wide gamut was not imminent: We’ve had 20 years of very stable color encoding for video in the form of BT.709 for HD (augmented recently by BT.1886, which finally standardizes gamma), and the 709-derivative sRGB that remains ubiquitous in the computer domain. Now, however, dramatic changes are under way. Wide color gamut (WCG), enabled mainly by RGB LED backlights for liquid crystal display (LCD) displays, has already seen initial deployment in consumer television. High dynamic range (HDR) cameras are commercially available; and HDR displays, mainly enabled by spatially modulated LED backlights, are on the verge of commercialization. Many industry experts agree that consumers will experience WCG and HDR as more significant than increasing spatial resolution from HD (“2K”) to “4K.” This paper revisits the topic of the 1994 paper, but now with some urgency, to address the question: How should wide color gamut and high dynamic range video imagery be encoded? The main conclusion is that the Y’CBCR technique and its variants are perfectly adequate for moderate dynamic range, but yield less than optimum performance when combined with HDR. New encoding techniques are needed. We conclude that: ▪A new high dynamic range opto-electronic conversion function (HDR OECF) (perceptual quantizer) should replace the conventional gamma function to enable HDR. ▪HDR should be encoded with at least 10 bits per component, to suppress “banding.” 10 bits Y”C <inf xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">B</inf> C <inf xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">R</inf> 4:2:0 is at this moment the accepted standard for encoding HDR, and Philips will support the developments deriving from that choice. ▪Going to 12 bits Y”C <inf xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">B</inf> C <inf xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">R</inf> 4:2:0 will bring too little perceived improvement on natural content; further improvement must come from other changes. ▪C <inf xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">B</inf> C <inf xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">R</inf> (chroma) subsampling performs worse in combination with the HDR OECF; we propose encoding and decoding constant luminance, with modified u'v' chromaticity components instead of C <inf xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">B</inf> C <inf xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">R</inf> . ▪Therefore, for the future, we propose going to 10 bits Y”u”v” 4:2:0.