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
