RFC: color: expand the EDR concept to work for black levels as well
The current EDR system can not represent dynamic range extended in the blacks. If the black level is darker we have a higher dynamic range between black and SDR maximum white which is not the SDR range any more. Mapping to that range while assuming it's SDR results in wrong contrast. At the same time the extended dynamic range in the whites is relative to the range between the black level and the SDR maximum white so even the EDR is wrong if we have a different black level.
The proposed fix is to define both the SDR maximum white and minimum black levels relative to the dynamic range of the content for surfaces and the viewer for outputs.
Merge request reports
Activity
- Resolved by Sebastian Wick
- Resolved by Pekka Paalanen
In general, the change looks fine to me, there are some questions to the comments. I am using currently min luminance 0 in color_utils.c LINE 1163. With this change, the value would be changed. The luminance compression algorithm from BT2390 uses min & max absolute luminance divided by max absolute luminance (10000)
- Resolved by Sebastian Wick
Could you please take a look again? I think the previous version was really bad to understand but this one should be clearer.
- Resolved by Sebastian Wick
- Resolved by Sebastian Wick
447 the luminance, or the values as is. 448 449 Default black and white levels for a HDR video mode output may be possible to 450 approximate from EDID denoted maximum/minimum luminance if the compositor wants 451 to default to fixed cd/m² numbers for the black and white levels, but that 452 assumes certain viewing conditions, e.g. average office environment. Using a 453 percentage of the video signal range for the default levels is not recommended 454 because of monitors differing wildly in their maximum luminance, assuming the 455 video signal encodes relative and not absolute luminance. Quantization effects 456 or artifacts due to framebuffer pixel format and the pixel bit depth in the 457 video signal may also factor in. With low bit depth it might be better to settle 458 for brighter overall image than to risk losing details in the SDR range. 459 460 `Figure 3`_ shows five ranges described by the black and white levels relative 461 to SDR. Note that the diagram is missing absolute luminance units since the 462 absolute luminance of SDR levels depends on the viewing environment. I would rephrase this statement to following that relative luminance is linearly proportional to absolute luminance with scaling factor dependant on exposure (shutter speed, lens aperture, and solid-state digital camera's image sensor) parameters. Or maybe remove this statement since it sounds to me controversial and may raise more questions
Edited by Vitaly ProsyakDo you agree with the fact that relative luminance is linearly proportional to absolute luminance?
The exposure is a property when capturing a real scene.
Right, and then using absolute luminance and exposure parameters the relative luminance is calculated which is part of pixel value. This is my understanding.
We don't care about absolute luminance of a scene. The only absolute luminance we kind of care about is the output luminance. There is lots of processing going on to create the pixel values that we simply don't care about, the only relevant thing a pixel value has in terms of tone mapping is the relative luminance (and again, even PQ has that!). The relative luminance of pixel value then gets transformed into some absolute luminance via the output.
And no, relative and absolute luminance are not proportional, absolute luminance = black level + (relative luminance * (white level - black level)). The relationship is linear but not proportional.
I don't think that my two previous comments are relevant. I deleted.
Regarding :
absolute luminance = black level + (relative luminance * (white level - black level))
I am glad that we can use absolute and relative luminance interchangeably. The above is generic denormalization formula which does mapping from one range to another( for example from [0-1000] to [0-10000] then do TM) and this is exactly what I have done into color_utils.c method EvaluatePqPrefix LINE 564 and then normalize back from [0-10000] to display range [0-400]) Method EvaluatePqSuffix LINE 599.
Great, that finally, we are at the point you can review my code related to EETF.
The major point is following that ICC profiles, metadata uses absolute values, if we use EDR then we need mapping or use absolute values.
The question should be resolved.
Edited by Vitaly ProsyakI am glad that we can use absolute and relative luminance interchangeably.
That is true only if we know the black and white levels in absolute units. Generally we do not. We know the black and white levels only relative to the SDR black and SDR white levels, which in itself are unknown in absolute units (they vary and depend on things we do not know about).
Why do you say that ICC profiles use absolute luminance?
If you measure a monitor to produce its color profile as an ICC file, does it actually contain absolute luminance?
471 The black and white levels determine the dynamic range size and position 472 relative to the standard dynamic range. 473 474 Content provided by Wayland clients have their own black and white levels per 475 ``wl_surface``. Content levels are calculated similarly to output levels. 476 477 Content black and white levels are all chosen by the content creator. If content 478 is encoded with relative luminance, calculating the levels does not require 479 mapping to absolute luminance. If content is encoded with display-referred 480 absolute luminance the display as well as the viewing environment should be 481 specified which can be used to determine the SDR black and white levels of the 482 content. 483 484 The use of SDR relative black and white levels to describe content dynamic range 485 means that content encoded with absolute luminance cannot be presented with 486 absolute luminance (nit-for-nit). This is intentional to avoid assuming a The use of SDR relative black and white levels to describe content dynamic range means that content encoded with absolute luminance cannot be presented with absolute luminance (nit-for-nit).
The content encoded with absolute luminance can be presented and after applying appropriate output viewing conditions which would change the 'nit to nit' behavior as you have mentioned.
Ah, I see. Yes, the point here is that an EOTF with absolute luminance encoding doesn't correspond to the actual absolute output luminance because we essentially transform the values to another viewing environment.
You want to explicitly mention that we do some viewing environment adjustment which changes the 'nit to nit' behaviour? Seems fine to me.
- Resolved by Pekka Paalanen
I went through this proposal, and it all makes sense to me. I was happy to find the document updated too.
The log10 wording I understood intuitively, but I wondered if it could be more clear. If only we could use mathematical notation in ReST...
Did you forget to delete the old diagram you replaced?
In the new diagram, with the axis values as is, I think you should drop the "log10" from the label because the values are already powers of ten and not just the exponent.
@swick, I recall you saying you wanted to revisit this still, what were your concerns?
mentioned in issue #3 (closed)