Scene and display. Different image states.

Scene-referred describes an image’s meaning relative to a scene, not its appearance as a file on screen. The data estimate scene-element colour coordinates; the scene may be photographed, virtual or creatively modified. Do not treat it as a perfect immutable record of the physical world.

Values are often related to relative exposure. A value above 1 need not be an error or already-clipped white: meaning depends on normalisation and numeric representation. It does not by itself specify the luminance of a future display.

Linear describes the mathematical relationship to light. Scene-referred describes the image stage to which the values refer. These are different axes: linear display-referred values are not automatically a scene, and nonlinear scene-referred values are not automatically a finished master.

ACEScg uses linear AP1 components; ACEScct uses a nonlinear working encoding with the same primaries and white. Operations on the numbers differ, but merely decoding ACEScct does not perform output rendering.

Display-referred relates values to an image for a particular display and viewing conditions. The broader output-referred term also covers other media. Colour rendering has already prepared the image for some target, but it may still be transformed, adapted to another output or creatively edited.

Primaries alone do not determine that state. RGB using Rec.709 primaries can appear in calculations before rendering; a wide-primary file can already be display-referred. Processing history matters, not just the space name.

Rendering here means more than exporting a video. It decides how scene tones and colours fit a target reproduction. Luminance, gamut, viewing conditions and creative intent may matter. A primary matrix or transfer-function change does not describe the whole task.

The ACES Output Transform architecture separates Rendering Transform from Display Encoding. One shapes the rendition; the other encodes the resulting colorimetry for the display. This distinction of responsibilities is not an instruction to add duplicate transform nodes to every project.

Nonlinear operation order matters. Scaling linear input before rendering gives T(g·x); scaling linear output afterwards gives g·T(x). For nonlinear T they generally differ. The second option is not automatically wrong; it serves another purpose and requires output-range checks.

Software controls may be more complex than a simple multiplier. Do not transfer a lab label such as Gain or Exposure to every tool without checking its definition. Here the multiplier is explicit: g = 2^EV.

Source balance and chromatic adaptation require a known data state. While channel relationships remain available, a technical input error is easier to separate from a look. After nonlinear rendering or channel clipping, a similar tint need not equal the same source correction.

This does not prohibit post-rendering work. A small trim can be an intentional output adjustment. Do not promise that such a tint restores camera balance or information already lost.

Saturation is not a representation-independent magic control. Its calculation may use RGB, a luma component or another working space. Before output rendering, modified colours still pass through the selected limiting or compression; afterwards you are changing an already-prepared image.

Neither wide working primaries nor floating point guarantees that every effect handles the data safely. Check whether the next tool accepts negatives and values above 1, where limits occur, and how saturated light sources behave.

Identify image-state boundaries before arranging nodes. Input transformation, creative work and output rendering may be explicit in a manual pipeline. In RCM or ACES some of the path runs outside the clip graph. Visible boxes do not describe the whole process.

Post-rendering operations may serve a particular master. The problem is not their existence but an unknown input, a hidden duplicate transform or a tool used outside its expected domain.

A logo, interface or web photograph often already has an intended appearance, but its actual profile and purpose still need checking. This does not mean always bypassing colour management. Integrate it correctly into the managed pipeline or place it deliberately in the output stage.

In either case reconcile primaries, encoding and the luminance role of white. Transparent graphics also require attention to compositing order and alpha. An accidental second rendering can alter brand colours even when the filename is correct.

An SDR/HDR target describes more than encoding. Tone rendering, white, highlights, available gamut and viewing need decisions. Converting a finished SDR image to PQ can represent that limited material deliberately, but cannot create missing highlight detail.

PQ and HLG are different systems, not interchangeable HDR labels. A shared scene workflow can help prepare multiple outputs, but each result needs separate evaluation. It does not promise identical appearance on every device.

An inverse transfer function recovers linear values in the selected representation; it does not automatically undo a look or output rendering. Inverse rendering is a separate task. Even if a particular curve has an inverse, the recorded file may have lost information through limiting, rounding or compression.

Conversely, not every space conversion destroys data. A pure matrix conversion with sufficient precision and no clipping can preserve colorimetry, including via negative components. Separate mathematical conversion from losses in an actual pipeline.

A monitor always emits physical light. To judge scene-referred material, software must choose how its values map to that light. Flat log in a viewer is already some rendering of the codes, just not necessarily the intended one.

Identical screen pixels do not prove identical internal signals; different viewers can use different paths. Record the application, output profile, display target and measurement stage for diagnosis. This page’s sRGB preview deliberately does not simulate HDR luminance.

Mixing light and mixing already rendered images are different tasks. For an opaque background and straight RGB, source-over reduces to C = αF + (1 − α)B. With nonlinear T, T(C) generally differs from αT(F) + (1 − α)T(B). This is not a precision defect but a different operation order.

A scene element usually needs a coherent shared path before rendering. A title intended to retain a defined appearance in the finished master may belong elsewhere. Do not choose from the word linear alone: distinguish scene light from an already display-linear result.

In straight RGB, colour is stored independently of alpha; in premultiplied RGB, components have already been multiplied by it. Compositing formulas must respect that agreement. Nonlinear T(alpha C) generally differs from alpha T(C), so colour operations on associated data need suitable alpha handling.

The lab uses straight RGB and an opaque background. Alpha remains a coverage coefficient and does not pass through the sRGB curve. This is not a test of every Resolve node or media format. Inspect translucent edges and import settings in real material; division by alpha is undefined when alpha is zero.

When handing off a scene or finished result, specify state, primaries, encoding, precision and completed operations. Record view-only processing separately so the recipient does not bake it again. Preserve a version and file identifier for LUTs and configurations.

State depends on meaning and history, not extension. Scene-referred does not promise an error-free camera estimate; display-referred does not prohibit further grading. The next party must understand the supplied data and the operation they intend to perform.