How HDR-to-SDR Tone Mapping Works
HDR-to-SDR tone mapping compresses the picture's brightness range within a conversion that also handles color and signal encoding.
Imagine a scene with a person beside a window: the face has ordinary indoor brightness, the outdoor sky is much brighter, and a reflection on glass is brighter still. An HDR picture can keep those regions distinct across a large range of light. An SDR conversion has less brightness range available, yet still needs to show a convincing face, a bright window, and some structure in the reflection.
Tone mapping decides how to redistribute that brightness. The complete HDR-to-SDR conversion also has to interpret the original signal, fit its colors into the output color system, and produce correctly encoded SDR samples. Each part affects the result. A well-chosen highlight curve cannot repair incorrectly interpreted input values.
For Emby playback, this conversion can happen in a server transcode or during presentation by a playback renderer. Both paths need to solve the same underlying problem, even though their implementations and output targets can differ.
These are the jobs in the conversion. An implementation can combine operations or perform parts in different working spaces.
Decoding gives samples; their meaning still matters
A video decoder reconstructs numerical picture samples from the compressed stream. The converter then needs to know what those numbers represent.
Many video sources store luma and color-difference components rather than directly storing red, green, and blue. Their matrix coefficients describe the relationship to color components. Signal range describes how stored code values represent nominal black, white, and color differences. Color primaries establish the meaning of the RGB color coordinates. Transfer characteristics relate nonlinear signal values to light.
Those properties work together. If limited-range values are interpreted as full-range values, nominal black and white are assigned the wrong positions. The picture can have raised blacks or altered contrast before tone mapping starts. If the wrong matrix is used, reconstructing the color components can introduce a different error. Changing the tone curve would then adjust an already misinterpreted picture.
Bit depth has a separate role. Ten bits provide more possible sample values than eight bits. They do not identify which color system or transfer function those values use. A ten-bit source can be SDR.
For a PQ source, the signal has an absolute reference-display light meaning. A normalized PQ value of 0.5 corresponds to approximately 92.2 nits for neutral gray. It does not mean half of a television's peak brightness or half of PQ's 10,000-nit reference range. The nonlinear transfer function is what establishes that relationship.
Before applying a curve defined in linear light, the converter must obtain linear-light values. For a neutral PQ gray, applying the PQ electro-optical transfer function gives its reference luminance. In a common linear-RGB processing path, the converter first restores nonlinear RGB from the luma/chroma samples using the appropriate range and matrix. It then applies the PQ transfer interpretation to those components to obtain linear RGB. Encoded luma and linear-light luminance are different quantities, so applying the PQ equation to luma alone would not perform this full color reconstruction. A method designed for a perceptual working space performs a different set of transformations.
The conversion of HLG also needs to account for its system relationship to the intended display. Assigning PQ's absolute-light interpretation to HLG samples would skip that relationship. The important question at this stage is which representation the particular mapping expects. For example, FFmpeg's CPU tone-mapping filter expects linear-light input.
Decide which brightness range to fit
There are two ends to the decision: the useful brightness range in the source and the intended brightness behavior of the destination.
A source can provide several kinds of information:
- Mastering-display metadata describes the display used during mastering, including its luminance capabilities. That is information about the mastering environment.
- Content-light metadata can summarize properties such as the maximum content light level. That is a description of the content under the metadata's measurement definition.
- Measured picture statistics come from inspecting the actual decoded pictures. A renderer can use them to adapt its mapping to the material being shown.
A mastering display capable of 1,000 nits does not require every picture to contain a 1,000-nit highlight. Similarly, a whole-program maximum describes the brightest relevant content, not the brightness of each scene. These distinctions matter because reserving output range for a peak that is absent from the current scene can change how much brightness is available to its ordinary objects.
The mapper may use a fixed source assumption, trustworthy metadata, peak detection, or a combination. If its assumed peak is too low, brighter source values can reach a part of the mapping that was never intended to preserve their distinctions. If the assumed peak is unnecessarily high, more compression may be applied than the scene needs.
The destination also needs a defined target. A conventional SDR reference-display example can use 100 nits for white and a specified display transfer function. An actual television may show SDR white more brightly, particularly in a bright room. The largest brightness number on its product sheet does not, by itself, establish the intended SDR rendering.
Reference white, black level, and viewing conditions influence the relationship between the converted picture and its appearance. The converter can prepare a conventional SDR signal for later display adjustment, or a renderer can adapt directly to a particular output. Those are different targets for the mapping.
For the worked example below, choose an 800-nit source peak and a 100-nit SDR output peak. Use 100 nits as one unit on both sides solely to make the arithmetic easy: input values run from zero to eight, and output values from zero to one. This normalization does not assign a 100-nit reference white to all HDR material.
Work through what the brightness curve does
Three simple mappings show the tradeoff clearly. Let x be the input light level in the relative units just defined.
Straight scaling uses x / 8. It fits the entire range, with the same scaling factor everywhere. An 800-nit highlight becomes 100 nits, but a 100-nit object becomes only 12.5 nits. If most of the scene sits well below its brightest highlight, the picture can become unnecessarily dark.
Clipping uses the smaller of x and one. Inputs up to 100 nits retain their light levels in this example; every higher input becomes 100 nits. A 200-nit cloud and an 800-nit reflection then have the same output value. Their original brightness separation has disappeared.
A smooth nonlinear mapping can devote more output range to ordinary brightness levels and compress the highlights more strongly. For an easily calculated example, use:
T(x) = (9/8) × x / (1 + x)
This function maps zero to zero and eight to one. For an input of one, its result is (9/8) × 1/2 = 0.5625. With the chosen output reference, that means 56.25 nits.
Illustrative neutral-gray mappings. For this example, multiply either axis by 100 to express its light level in nits. The green curve is T(x) above; these are calculated relationships, not measured Emby presets.
| Source light level | Straight scaling | Clipping | Smooth mapping T(x) |
|---|---|---|---|
| 20 nits | 2.5 nits | 20 nits | 18.75 nits |
| 80 nits | 10 nits | 80 nits | 50 nits |
| 100 nits | 12.5 nits | 100 nits | 56.25 nits |
| 200 nits | 25 nits | 100 nits | 75 nits |
| 400 nits | 50 nits | 100 nits | 90 nits |
| 800 nits | 100 nits | 100 nits | 100 nits |
All three make the 800-nit peak fit. They produce very different pictures everywhere else. The smooth example keeps substantially more brightness in the 80-nit region than straight scaling does, while retaining some separation among the highlights that clipping merges.
That separation is still compressed. Under the smooth curve, a 600-nit region becomes about 96.43 nits, while an 800-nit region becomes 100. A source difference of 200 nits has become about 3.57 nits. The converter has preserved an ordering and a distinction, but has greatly reduced their spacing.
Curve slope explains the contrast redistribution
The slope of the curve describes how a small change in input light affects the output. A flat segment gives no separation to neighboring inputs. A shallow segment gives little separation; a steeper segment gives more.
The green curve gradually becomes shallower toward its top. This is a highlight roll-off: extra source brightness has progressively less effect on output brightness. Fine texture in a very bright region can consequently become difficult to see even while its values remain mathematically distinct.
A practical mapper has to choose how much separation to retain in shadows, middle brightness levels, and highlights. Preserving more of one region's brightness differences spends part of the finite output range. A curve's midpoint and any transition into highlight compression matter as much as its endpoint.
The example's 100-nit object becomes 56.25 nits. That makes the effect on ordinary objects explicit: mapping is not confined to the few pixels above the SDR ceiling. Other curves can preserve a selected lower interval more closely or place the transition differently. The curve overview links to individual shapes and their behavior.
Keep brightness changes from distorting the colors
A neutral-gray example has equal RGB components, so a scalar curve is easy to interpret. Color introduces another choice: which quantity drives that curve, and how is the resulting brightness change applied to the components?
Consider a linear RGB color with components 2, 1, 0.5 in one fixed set of primaries. Applying the example curve independently to each component gives 0.75, 0.5625, 0.375. The original red-to-green ratio was 2; it is now about 1.33. The component proportions have changed, so the operation changes the color's chromaticity as well as its brightness.
An alternative is to derive a single brightness-related quantity, calculate a scale factor, and apply that same factor to all three components. If the maximum component 2 drives the example curve, it maps to 0.75. The factor is 0.75 / 2 = 0.375, producing 0.75, 0.375, 0.1875. The original component ratio of 4:2:1 is retained.
This calculation illustrates why a tone mapper needs a color strategy. A luminance-driven method can use a different driving quantity from a maximum-component method. Preserving linear RGB proportions retains chromaticity in that fixed color system, while perceived saturation can still change with brightness and viewing conditions.
There is also the question of which colors the destination can represent. HDR material commonly uses a wider color gamut than a BT.709 SDR destination. Conversion between their primaries changes the RGB coordinates needed to describe a color. For a color outside the destination gamut, those coordinates can include a negative component or a component beyond the output range.
Scaling the brightness alone does not necessarily bring that color into gamut. Independently clipping offending components changes their proportions and can cause hue shifts or merge distinct colors. Gamut mapping instead provides a strategy for fitting the color—for example, reducing its distance from a neutral color while trying to preserve hue.
Brightness and saturation limits interact through the destination's color volume. A strongly saturated color cannot necessarily reach the same luminance as neutral white. A conversion may therefore adjust both brightness and chroma to obtain a useful result. The different methods in ITU-R BT.2446 show why HDR-to-SDR conversion includes color processing alongside tone mapping.
A movie also needs stable decisions over time
A fixed mapping produces the same output for the same input throughout the program. That consistency can be useful, but a single curve chosen for the brightest scene may use the available range less effectively in a much dimmer scene.
Scene-adaptive tone mapping changes parameters based on the content. It can make better use of the output range, but the parameter changes themselves become visible if they are too abrupt.
Imagine a stationary face beside a window. A tiny flash in the window raises the measured peak for one picture. If that peak immediately changes the mapping for the whole picture, the face can darken for that instant, although its source values did not change. When the flash ends, it brightens again. The viewer sees pumping caused by the adaptation.
A method can moderate that response by considering the distribution of bright samples, smoothing parameter changes over time, or distinguishing a scene cut from a brief highlight. Those choices balance responsiveness against stability. Looking at one still frame will not reveal whether the conversion maintains a consistent appearance through movement, flashes, and cuts.
Turn the mapped light back into an SDR signal
After brightness and color processing, the converter has to produce samples whose encoding matches the intended SDR interpretation. Linear-light values cannot simply be written into a nonlinear video signal without the appropriate transfer operation.
Continue the neutral-gray example. An original 100-nit PQ gray has a normalized PQ signal of about 0.508. Interpreting PQ recovers 100 nits, which is x = 1 in the chosen working units. Applying T(x) produces y = 0.5625, meaning 56.25 nits in the chosen SDR display model.
For an ideal SDR reference display with zero black, 100-nit white, and the BT.1886 exponent of 2.4, the nonlinear signal needed to obtain that light is:
signal = 0.5625^(1/2.4) ≈ 0.787
The sequence is therefore:
| Representation | Value for this neutral gray |
|---|---|
| Normalized input PQ signal | About 0.508 |
| Interpreted HDR light | 100 nits |
| Linear mapping input x | 1 |
| Linear mapping output T(x) | 0.5625 |
| Intended output light | 56.25 nits |
| Normalized SDR signal for the stated ideal display | About 0.787 |
The input and output signal numbers differ because they have different transfer meanings. Writing 0.5625 directly as that nonlinear SDR signal would produce only about 25.14 nits under the same display model. The tone-mapping calculation could be correct while the displayed brightness was wrong because the output encoding step was skipped.
The real output process also accounts for black level and the selected conversion method. BT.2446 describes several methods; their processing spaces and transfer operations differ. The calculation above isolates one display-referred example so that the distinction between light values and signal values is visible.
For a conventional video output, the converter prepares the required luma/chroma representation, numerical range, bit depth, and matching color signaling. Retagging original HDR samples as SDR performs none of the brightness or color calculations. Correct labels describe the converted values; they do not create those values.
Precision matters during this work. Intermediate calculations can retain more precision than the final video format. When values are reduced to the output bit depth, rounding can make smooth gradients form visible steps. Dithering can make those steps less conspicuous by distributing rounding error. It helps represent the converted gradient; it cannot restore highlight differences that the mapping has already merged.
Relate the conversion to the playback path
During an Emby video transcode, the server decodes the HDR source, processes the pictures for the selected output, and encodes the resulting stream. Tone mapping is a picture-processing operation within that path. It changes the delivered rendition while the library file remains available as the source.
During local presentation, a playback renderer can perform adaptation as it prepares pictures for the screen. The Windows app documentation describes tone mapping at this stage. Direct Play therefore identifies the server's delivery behavior; it does not, on its own, describe every color or brightness operation performed by the app, operating system, and display.
To investigate an unexpected result, first establish where conversion happens and what output is intended. Then use the appearance to narrow the stage worth examining:
- Raised black or incorrect contrast throughout the picture: check input and output range interpretation, transfer characteristics, and display mode before adjusting highlight compression.
- Ordinary objects look sensible but bright texture disappears: examine the assumed source peak and highlight mapping. Check several frames to distinguish strong compression from time-dependent adaptation.
- Brightness looks plausible but vivid colors shift: examine primary conversion, gamut handling, and chroma processing.
- A stationary object brightens and darkens when another area flashes: examine how the mapping adapts over time.
These observations connect a visible change to the operations that can cause it. Comparing the same scene along known playback paths—using both moving pictures and representative stills—makes that investigation much more informative than judging the brightest highlight alone.