RESOLVE FX · VIEWING CONTRACT
OCIO Display.
Name the source.
Choose how it is seen.
A config-driven Resolve 21 display/view transform. Learn why Source is a declaration, why Display and View are a linked pair rather than two output spaces, how config defaults can change, and where this transform belongs so you do not render the display twice.
.ocio · displays · views
Source Color Space
Display → View
Try “Wrong Source” in the lab, then keep Source fixed and switch only Display/View. That separation makes it obvious which error belongs to input declaration and which belongs to viewing intent.
Independent teaching approximation, not Blackmagic/OpenColorIO rendering. Demo spaces, Displays and Views are invented and use simplified transfer functions, gamut matrices and a toy filmic response. Use the lab to understand Source declaration, Display/View pairing, placement and mismatch—not to predict a production `.ocio` config.
Four native Resolve 21 Inspector captures plus an independent display/view teaching model.
.OCIO · SOURCE / DISPLAY / VIEW01THE VIEWING MODEL
Four ideas prevent most OCIO Display mistakes.
The panel is short, but the contract is not. Config identity, Source declaration, Display/View pairing and pipeline placement must all agree.
The config defines the vocabulary
OCIO Display does not carry a universal built-in set of displays/views. The active `.ocio` config defines Source spaces, display devices, Views, view transforms, shared views and metadata. A production setup should therefore record the config source/version together with Display/View; copying menu names without the config is an incomplete hand-off.
Source is an input declaration
Source Color Space must describe what the incoming RGB already means before display rendering. If a scene-linear, log, or working-space signal is declared as a display-referred space, the chosen Display/View may be perfectly valid yet the result will still be wrong. Choose Source from the real upstream pipeline, not from Viewer appearance.
Display and View work as a pair
Display identifies the target display device/role, while View selects how the image is presented on that Display. OpenColorIO allows a single Display to expose multiple Views such as Film, Log, Raw, SDR/HDR, or show-specific variants. Do not change View without understanding the selected Display, and do not treat Display as an ordinary Output Color Space.
The display transform should live in one place
OCIO Display normally belongs to the monitoring/viewing contract. If a Viewer LUT, system display transform, output CST/RCM, or another DRT is active at the same time, double tone/gamut mapping is easy to create. Before judging contrast or saturation, establish exactly where the pipeline is already performing display rendering.
02REAL RESOLVE 21 CONTROLS
Read the Inspector in causal order, not top-to-bottom muscle memory.
The native captures document labels and current menu entries; the active config is what gives those entries their actual transforms.
First lock the OpenColorIO config source.
Config Source
Chooses the OCIO configuration source. The native Resolve 21 OpenColorIO controls expose System, File and Config in this tool family; the OCIO Display capture is set to File. The mode label does not replace verifying the configuration that is actually resolved.
Record config source/version for reproducibility. Re-check Source, Display and View after changing the config.OCIO Config File
With a file-based source, this stores the `.ocio` path. Blackmagic documents Browse as loading the config file for the display transform. That file defines the available spaces/displays/views and the transforms behind them.
A workstation-specific absolute path is a weak production contract. Use a stable project/pipeline path or documented deployment.Browse
Opens the `.ocio` chooser. After switching files, familiar menu names may remain while their definitions/version have changed.
Do not validate a config merely by matching names—record the version/hash or pipeline release.Describe the real RGB state before the display/view transform.
Filter Color Space List
Enables metadata filters for the Source list. This is a UI/navigation control that helps locate a Source in a large config but does not alter pixels.
If a space disappears after filtering, clear the filters rather than substituting a vaguely similar name.Filter by Family
Narrows the list using OpenColorIO `family` metadata. Family is intended for logical UI grouping and is not a transform.
Family names are config-specific and need not match across studio/show configs.Filter by Encoding
Filters Source entries by encoding metadata such as log/scene-linear/video when provided by the config authors.
Encoding helps navigation but does not prove the correct camera/input transform for a clip.Filter by Category
Filters Source entries by categories. This is organizational metadata, not a hidden grade or conversion stage.
Categories belong to the specific config/application workflow rather than a universal Resolve vocabulary.Source Color Space
Declares the color space of the incoming signal. Blackmagic describes this control as choosing the source material color space; the capture shows entries defined by the current config.
The most dangerous error is choosing Source “by eye.” A wrong declaration changes the meaning of the entire display transform.03DISPLAY ≠ VIEW
Treat Display as the target and View as the configured presentation path.
OpenColorIO explicitly allows multiple Views per Display. That architecture is why OCIO Display is not equivalent to simply converting into a display-named color space.
Choose the target Display and the specific View inside it.
Display
Selects a display device/role from the active config. OpenColorIO defines Displays as devices/targets such as an sRGB workstation or DCI-P3 projector; active_displays may filter and order the visible choices.
`default` only has meaning together with a specific config. Do not assume default resolves to the same target on another workstation.View
Selects a viewing transform inside the chosen Display. OpenColorIO allows multiple Views per Display—Film, Log, Raw and others; active_views may change the visible list and default.
The sRGB/rec709 Views in the capture are config-defined entries, not a promise of a specific OETF/DRT outside that config.Forward / Reverse
Forward applies the Source→Display/View path. Reverse attempts the corresponding inverse transform; this is a diagnostic/inverse workflow, not a one-click “make it log again” control.
Display/view transforms may include tone/gamut mapping or other non-invertible stages. After clipping/baking, Reverse is not required to recover the original data.Decide whether this node is preview, output transform, or part of a baked signal.
Monitoring / Viewer path
When OCIO Display is used for monitoring, downstream creative grading should remain in the correct working space and the display transform should be the final viewing stage. Bypass comparisons are useful only when you understand that bypass may expose a non-display signal.
Do not judge saturation/contrast on bypassed scene-linear/log as if it were a finished image.Double-transform check
A Viewer LUT, Resolve Color Management output transform, CST, monitor LUT, or OS color management may already perform part of the display conversion. OCIO Display on top can apply contrast/tone/gamut behavior twice.
If the image looks unexpectedly harsh, simplify the chain to one display transform before changing View.OpenColorIO reference: Displays & Views ↗
04A REPEATABLE VIEWING PATH
The display transform starts with the config and ends with a single monitor contract.
Most failures are not “bad View” problems. They are identity, declaration or placement problems elsewhere in the chain.
Declare Source
This is an input declaration, not a creative choice. Metadata filters only help navigate the list.
Teaching pipeline, not a literal Resolve node graph. Display/View belongs to the viewing contract; menu metadata filters are not in the pixel path.
Related technical pages: OCIO Color Space ↗ · Color management ↗ · Fusion OCIODisplay ↗
05PRODUCTION RECIPES
Change one contract at a time.
The safest tests hold Config and Source constant while changing only the viewing target, or hold Display constant while comparing Views.
SDR workstation review
Lock the show config, declare the real Source, select the workstation display entry and the intended SDR View. Verify that a Viewer LUT/output transform is not duplicating the job. Compare the expected output state with scopes/reference patches rather than judging only “better/worse.”
VFX/CG scene-linear preview
If the input is scene-linear/ACEScg-like, Source must describe that state. Display/View performs the viewing transform for the screen; it should not become a new working space for subsequent comp/grading operations. For hand-off, keep the scene-referred branch separate from the viewed display result.
Comparing two Views
Change only View while keeping the same Display/config/Source so the comparison answers one question. Changing Source, Display and View together destroys causal clarity. Use the same reference patches and scopes before/after for technical checks.
Deliberate Reverse
Reverse makes sense when you know exactly which display/view result is on input and why it must be inverted. Work in a minimal chain, inspect a Forward→Reverse difference, and do not expect information lost through tone mapping, clipping, or later processing to reappear.
06USE THE RIGHT OCIO TOOL
A viewing transform, a color-space transform and a LUT file solve different contracts.
Choose the tool from what must be transported through the pipeline, not from whichever menu contains familiar color-space names.
Source → Display / View
Use when the config-defined display/view rendering is the job: monitoring, review, or a deliberately baked viewing result.
Technical Source → Output
Use when the signal must move between named technical color spaces. A display View may contain a DRT or other presentation behavior that a plain space conversion does not express.
Portable primary correction
Use SOP/Saturation values for exchangeable primary grading decisions, not for defining a monitor/viewing path.
External LUT / file transform
Use when a file transform or LUT is the actual contract. It does not by itself declare the Source/Display/View architecture of the show config.
07TROUBLESHOOTING
Symptoms usually point to declaration, config or placement before they point to the View.
Reduce the system to one config, one Source declaration and one display transform. Then add monitoring layers back one by one.
Image is too contrasty and saturated
Likely cause: The display transform is often being applied twice: OCIO Display plus a Viewer LUT/RCM output/CST/monitor transform.
Fix: Temporarily keep only one display path, verify Source, then re-enable other monitoring stages one at a time.
Display/View menus differ on another workstation
Likely cause: A different config/version, active_displays/active_views, or environment override is active.
Fix: Match the exact `.ocio`, deployment/version, environment, and Config Source before comparing images.
The View seems right but the image still looks wrong
Likely cause: Source Color Space is misdeclared, so the display transform receives RGB in the wrong coordinate system.
Fix: Check camera/input transforms and upstream nodes. Source must describe the current signal state, not the desired appearance.
Reverse does not restore the original
Likely cause: The display/view path contains non-invertible tone/gamut mapping, clipping, baked processing, or the wrong config/View is being used.
Fix: Test Forward→Reverse in a minimal chain and inspect a difference view. Reverse is a diagnostic tool, not a guarantee of lossless round trip.
Display default changes after a config update
Likely cause: The default display/view may depend on ordering/active lists in the config and application/environment settings.
Fix: For critical review, choose an explicit Display/View and record the config version instead of relying on an implicit default.
Family/Encoding/Category filters seem to “break” the list
Likely cause: Metadata filters hid entries; they did not alter the color transform itself.
Fix: Reset filters to No Filter and locate the intended Source. Do not solve a UI-filter issue by changing processing settings.
08PRE-FLIGHT
An OCIO Display setup is finished when another workstation can reproduce the viewing contract.
09FAQ
Practical OCIO Display questions.
How is OCIO Display different from OCIO Color Space?
OCIO Color Space converts between named technical color spaces. OCIO Display builds a viewing path from Source through a selected Display and View defined by the config as a display-oriented contract. In OCIO v2 a View may include a view transform/DRT plus display colorspace, so a simple Source→display-colorspace conversion is not always equivalent to display/view rendering.
What does Display = default mean?
It is a config/application-defined default, not a universal “correct monitor.” OpenColorIO allows active displays and default ordering, and the application environment may influence the visible list. For critical review, select an explicit target and record the config version.
Why can one Display have several Views?
Views provide different ways to present the same source on a selected display device, for example Film/SDR rendering, a Log tech-check, or a Raw bypass-like view. This is normal OpenColorIO behavior; the config defines the View list and it may differ for each Display.
Do I need OCIO Display when the project is already color managed?
Not automatically. If Resolve Color Management/ACES/Viewer monitoring already performs the required output/display transform, another OCIO Display may duplicate it. Establish the project monitoring contract first, then decide whether a separate node is needed.
Can Reverse be used to “remove” a display transform?
Only in a deliberate inverse workflow using the same config/Display/View. If the upstream result has already been clipped, tone-mapped, baked through a non-invertible stage, or modified afterward, Reverse is not required to reconstruct the original scene-referred values.
10SOURCES & BOUNDARIES
Resolve labels come from native captures; display/view semantics are cross-checked against Blackmagic and OpenColorIO.
The interactive lab is an independent deterministic teaching model. It is not a reverse-engineered Blackmagic Resolve FX/OpenColorIO implementation and does not claim production transfer functions, gamut matrices, tone mapping, or exact inverse behavior.