Skip to content
Snippets Groups Projects

RFC: color: expand the EDR concept to work for black levels as well

Closed Sebastian Wick requested to merge color-dynamic-range into color
3 unresolved threads

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

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Vitaly Prosyak
  • 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)

  • Sebastian Wick added 2 commits

    added 2 commits

    • 50ebf6a6 - color: expand the EDR concept to work for black levels as well
    • 937fdeab - color: adjust the docs for the new dynamic range concept

    Compare with previous version

  • Vitaly Prosyak
  • Vitaly Prosyak
  • Vitaly Prosyak
    Vitaly Prosyak @vitalyp started a thread on commit 937fdeab
  • 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 Prosyak
    • The exposure is a property when capturing a real scene. We work with output referred data only.

      What questions does this raise for youu?

    • Do 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 Prosyak
    • I 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?

    • Please register or sign in to reply
  • Vitaly Prosyak
    Vitaly Prosyak @vitalyp started a thread on commit 937fdeab
  • 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
    • It can be presented and after applying appropriate output viewing conditions which would change the 'nit to nit' behavior as you have mentioned.

    • Sorry, I don't get what you're saying.

    • 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.

    • Please register or sign in to reply
  • I'll comment on the other stuff soon.

    • 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)

    • What I'd like to see fixed before merging this:

      • fix the y-axis label in the diagram to not say "log10"
      • delete any diagrams that are not used in the doc anymore
  • Should some of the open threads be marked as resolved?

  • EDR concept got removed. Closing.

  • closed

  • Please register or sign in to reply
    Loading