HLG gamma curve was designed to be compatible with SDR displays, so you can just display HDR content with HLG gamma applied on SDR monitor (which will assume it's BT.709/sRGB gamma) and get a reasonable picture.
On Thu, 26 Dec 2019 01:04:24 +0100 Aurélien Pierre <rese...@aurelienpierre.com> wrote: > Hi, > > … and that's where the image processing pipeline mixed with people's > misunderstandings backfires. > > What's HDR here ? The scene or the display ? > > The image only encodes a scene-referred light emission with 0 and 1. > That scene-referred light emission has infinite dynamic range, with a > more limited region of interest for human vision. The encoded recording > by the camera has not an infinite DR, but still has a dynamic range much > wider than any display. In this encoding, each bit can only encode 1 EV > of dynamic range. So, 8 bits => 8 EV, and bit depth => dynamic range. > Using a tone curve/gamma/OETF only redistributes the bits more evenly > over that dynamic range. > > The point you make is valid : an SDR file can be an HDR scene backed > into an SDR image adapted for SDR display. Yet we don't care, an 8-bits > file has a contrast of 255:1, a 10-bits one has a contrast of 1023:1, no > matter the scene that it actually encodes. It would appear that any bit > depth > 8 bits is to be assumed HDR until proved otherwise. > > So the issue seems more general to me than mapping "tonecurve" to > "dynamic range". The classical imaging pipeline expects 100% RGB (255 in > 8 bits) to encode 100 Cd/m² (display white point), and (18% > RGB)^(1/gamma) to encode middle grey. We can say one file is HDR is 100% > RGB encodes more than 100 Cd/m², in which case the colour management > needs to apply an highlight roll-off to tonemap the image for SDR > displays. From what I understand, PQ and HLG tonecurve are just fancy > maths tricks to optimize the distribution of bits over the dynamic range > among high bit-depths to reduce posterization. They don't tonemap > anything in themselves. So these transfer functions can't be assumed to > be linked to HDR files all the time, they are only encodings (same as > sRGB gamma, but more refined). > > Say your 16 bits file (contrast of 65535:1) encodes SDR (65535 = 100 > Cd/m²), to display it on a regular monitor (contrast of 255:1), you > simply need to rescale every pixel linearly (×255 / 65535). If it > encodes HDR (65535 = 200, 400, 1000… Cd/m²), you will probably rescale > linearly below middle grey, and roll-off progressively to compress > highlights in the [117; 255] display-referred space. > > My point here is we need to be absolutely clear about *what* is encoded > (scene-referred dynamic range), *for what* it is encoded > (display-referred dynamic range), and *how* it is encoded (OETF + bit > depth). > > Bit-depth and OETF are stored in ICC metadata of images, but the > scene-referred dynamic range should be deduced from the white point > luminance tag if provided (if white > 100 Cd/m² then HDR ; else SDR), > and I don't know for the display-referred dynamic range (if the file has > been saved with a tonemapping already or if the colour management needs > to roll-off highlights on-the-fly before sending to GPU memory buffer). > > Merry Christmas, > > Aurélien. > > Le 18/12/2019 à 07:59, Wiktor Nowak a écrit : > > Why thinking of bit depth in terms of dynamic range? Dynamic range is a > > range between the brightest and darkest part of image with no clipping. > > HDR image could be 16, 10, 8 or whatever bit depth or format with a base > > curve applied or not i think... > > > > W dniu 17.12.2019 o 14:24, Andreas Schneider pisze: > >> On Tuesday, 17 December 2019 14:12:48 CET Sturm Flut wrote: > >>> Hi Andreas, > >>> > >>> On 16.12.19 20:13, Andreas Schneider wrote: > >>>> sRGB -> SDR > >>>> AdobeRGB -> SDR > >>>> > >>>> PQ Rec2020 -> HDR > >>>> HLG Rec2020 -> HDR > >>>> > >>>> Does that make sense? I could look into that next. > >>> Where do RAW files fit into this definition? They have no color space. > >>> > >>> A 16 Bit AdobeRGB out-of-camera TIFF file might have more dynamic range > >>> than 10 Bit Rec.2020 data. Color space alone might not be a sufficient > >>> measure. > >> If you have a better idea, I'm open to suggestions! > >> > >> All TIFF files are currently set to SDR ... > >> > >> > >> Andreas > >> > > ___________________________________________________________________________ > > darktable developer mailing list > > to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org > > > > ___________________________________________________________________________ > darktable developer mailing list > to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
