RESOLVE FX · AI SDR→HDR · STUDIO · WINDOWS / RTX
NVIDIA RTX Video HDR.
Expand SDR with AI.
Keep the color pipeline deterministic around it.
NVIDIA RTX Video HDR is an AI-assisted SDR-to-HDR mapping stage exposed inside Resolve with explicit Input/Output Color Space + Gamma, Contrast, Saturation, Middle Gray, Max. Luminance, and Global Blend. The difficult part is not finding a “magic” slider value; it is making the signal entering and leaving the neural mapping unambiguous, then validating the result through a real HDR monitoring and delivery path.
Blackmagic lists the FX as Desktop Studio with a platform note requiring Windows, a supported NVIDIA RTX graphics card and driver. NVIDIA describes RTX Video HDR as AI-enhanced SDR→HDR tone mapping accelerated on RTX Tensor Cores.
Teaching model only. It uses synthetic normalized samples to explain signal ownership and relative mapping anchors. Blend 100% mixes the conceptual incoming and mapped states. The model does not reproduce NVIDIA's neural network, Resolve OFX pixel math, real camera transfer functions, PQ/HLG encoding, or measured nit output.
5 actual Resolve captures + independent signal-contract teaching model
SDR INPUT · AI MAPPING · HDR OUTPUT · DELIVERY01SIGNAL → AI MAPPING → DELIVERY
Three contracts must stay separate: what enters the FX, what the AI generates, and how the HDR master is monitored and delivered.
The plugin is powerful precisely because it creates a new HDR-oriented appearance. That also makes it dangerous to hide inside an ambiguous managed pipeline: a wrong input description, duplicated output rendering, or SDR monitoring path can all look like “bad AI.”
Describe the signal first
The four dropdowns are not decorative presets. Input Color Space + Input Gamma must describe the actual RGB values reaching the OFX after any upstream CST/DCTL/LUT/managed transforms. Output Color Space + Output Gamma define the state leaving the AI mapping. If either side is described incorrectly, Contrast, Middle Gray, and Max. Luminance are being tuned on top of a misinterpreted image.
AI expands SDR appearance; it does not replace color management
NVIDIA describes RTX Video HDR as AI-enhanced SDR-to-HDR tone mapping. Resolve wraps that AI operation in an explicit color-state contract plus creative/target controls. The FX therefore is not equivalent to CST: CST performs deterministic conversion between signal descriptions, while RTX Video HDR generates an HDR-oriented appearance from SDR and still requires correct project/output management.
HDR monitoring and delivery are a separate system
A convincing Viewer does not prove a correct HDR master. Max. Luminance inside the FX is a mapping target, not a display-brightness control or mastering metadata. Validate HDR waveform/scopes, the real monitoring transform/display path, export tags, and required delivery metadata separately. Otherwise a correct signal can be “fixed” because it is viewed incorrectly, or the reverse.
Hardware boundary: Blackmagic’s Studio feature matrix lists Nvidia RTX Video HDR as Desktop Studio and states that Nvidia RTX Video effects need Windows with a supported Nvidia RTX graphics card and driver.
02REAL RESOLVE 21 CONTROLS
Nine visible controls: four describe signal state, four shape the HDR mapping, one mixes the result.
The five images are actual Resolve captures from the project archive. Start with the four color-state dropdowns; the creative/target sliders only become meaningful after those descriptions are correct.
AA · Input contract
The OFX must know exactly which SDR/scene state reaches the node.
- Input Color Space
Describes the RGB primaries/gamut entering NVIDIA RTX Video HDR. Use timeline is correct only when the actual node state truly matches the Timeline Color Space. A manual CST, DCTL, LUT, or other gamut transform upstream can invalidate that assumption.
VERIFYAudit the signal at this node rather than the camera name. A wrong Input Color Space changes the meaning of RGB coordinates before AI mapping and can create odd saturated colors before Saturation is even adjusted.
- Input Gamma
Describes the input transfer function / encoding. Log, HLG, ACEScc/ACEScct, and display-like encodings distribute code values across luminance differently; the RTX mapping must interpret them in the correct domain.
VERIFYIf Input Gamma does not match the actual input, Middle Gray and highlight expansion solve the wrong problem. Do not compensate for that mismatch with Contrast or Max. Luminance; fix the contract first.
BB · Output contract
RTX mapping must return a clearly defined signal state expected by the next stage.
- Output Color Space
Defines the gamut/primaries of the AI-mapped result. It is not a “pick the widest gamut” command; it is the interface between the OFX and the next processing/delivery stage. If downstream CST/RCM expects a different gamut, an extra transform or mismatch is introduced.
VERIFYDocument who owns the final display/output transform after RTX Video HDR. Do not let the OFX create an HDR-oriented output state and then have RCM/ACES/CST perform a conflicting render again.
- Output Gamma
Defines the transfer/encoding of the NVIDIA-mapped result. For PQ/HLG delivery, the chosen state must be part of the entire HDR pipeline: monitoring, scopes, export tags, and downstream transforms must interpret it consistently.
VERIFYA wide-gamut Output Color Space without an appropriate Output Gamma is not a complete HDR delivery. Likewise, PQ/HLG encoding alone does not solve gamut ownership. Treat Output Color Space + Gamma as one pair.
CC · AI mapping anchors
Contrast and Saturation shape appearance; Middle Gray and Max. Luminance define critical HDR anchors.
- Contrast
Controls contrast response inside the RTX HDR mapping. This is the Resolve OFX control scale; do not assume NVIDIA App values are equivalent. Contrast changes the distribution between shadows, midtones, and highlights after AI expansion.
VERIFYTune Contrast only after validating the input/output contract. If the image is broken by a duplicated output transform or wrong Gamma, Contrast can mask the problem but cannot repair the signal pipeline.
- Saturation
Adjusts color intensity in the HDR-oriented result after AI mapping. Increasing it can quickly push LEDs, neon, graphics, and saturated highlights toward the target color-volume boundary, especially when the SDR source is already highly saturated.
VERIFYCheck not only the Vectorscope but also CIE/target gamut, highlight color separation, and the real HDR display. If the result needs a smooth fit into the delivery gamut, use deliberate Gamut Mapping rather than relying only on lower Saturation.
- Middle Gray
Sets reference/midtone placement inside the SDR-to-HDR mapping and therefore strongly affects perceived paper/reference white and overall midtone brightness. The captured default is 50, but that is not a universal mastering prescription.
VERIFYDo not use Middle Gray as a workaround for incorrect HDR monitoring. First confirm that the Viewer/display path is actually showing the selected Output Gamma, then judge midtones with HDR waveform and the real monitor target.
- Max. Luminance
Sets the target peak luminance used by the mapping. The captured default is 1000. It is not a monitor brightness setting, MaxCLL metadata, or a guarantee that every specular must reach the chosen value.
VERIFYChoose the value from the actual mastering/delivery intent and verify the result on nit-aware HDR scopes. Raising the peak only for “wow” can stretch contrast, weaken midtones, and create color-volume pressure.
DD · Global Blend
Blend mixes two different images: the incoming SDR state and the RTX-mapped result.
- Global Blend → Blend
At 1.000 the full OFX result is visible; at 0 the input image passes through. Intermediate values can be creative moderation, but in a technical SDR-to-HDR workflow they mix two different rendering states and therefore require an especially clear downstream contract.
VERIFYDo not use partial Blend to “fix” wrong Input/Output Color Space/Gamma. If the technical conversion is meant to be complete, first make the mapping and pipeline correct; only then decide whether an intentional creative mix is needed.
03ONE SDR→HDR OWNER
Manual YRGB and managed RCM/ACES need different routing decisions, but the ownership rule is identical.
Switch the graph. In both modes, the RTX node must receive a known input state, publish a known output state, and avoid fighting a second perceptual/display rendering stage. Monitoring and file delivery come afterward.
Run one SDR→HDR mapping
Choose Output Color Space/Gamma, then establish Middle Gray and Max. Luminance before creative Contrast/Saturation. Keep Blend at 1 for a full technical pass.
The graph is decision order, not a mandatory node count. RTX Video HDR should have one explicit input contract, one explicit output contract, and one owner for SDR→HDR appearance rendering. Monitoring and file delivery remain separate responsibilities.
04BUILD IT IN RESOLVE
Four exercises cover the normal SDR→HDR pass, mixed HDR timelines, managed ownership, and failure isolation.
These are workflow drills rather than presets. Exact Output Color Space/Gamma, peak target, monitoring, and metadata depend on the real project specification.
SDR master → controlled HDR version
Build one understandable SDR-to-HDR stage without duplicating output rendering.
PrepareStart with a correct SDR master, enable HDR scopes, and prepare a real HDR monitoring path.
- 01
Identify the actual Input Color Space + Input Gamma at the RTX Video HDR node.
- 02
Choose Output Color Space + Output Gamma that the next stage or final HDR pipeline actually expects.
- 03
Set Middle Gray and Max. Luminance for the target presentation, then tune Contrast/Saturation conservatively.
- 04
Check skin, diffuse white, speculars, saturated lights, waveform/CIE, and temporarily bypass downstream output transforms to detect double rendering.
The HDR version looks natural on the real target display, scopes show no unexplained clipping, and the pipeline has one documented owner for SDR-to-HDR rendering.
HDR project with individual SDR inserts
Apply AI expansion only to SDR shots without remapping material that is already HDR.
PrepareAn HDR timeline contains genuine HDR footage plus individual Rec.709 SDR clips.
- 01
Identify the SDR shots and confirm their tags/actual signal state.
- 02
Place RTX Video HDR locally on SDR clips or a dedicated branch rather than the entire Timeline.
- 03
Align the FX output state with the project HDR working/output architecture.
- 04
Compare SDR-derived and native-HDR shots for reference white, highlight behavior, saturation, and shot-to-shot continuity.
SDR shots receive a plausible HDR-oriented starting point while native HDR footage passes without unnecessary AI remapping.
RCM/ACES ownership audit
Avoid a second display/output rendering after RTX mapping.
PrepareThe project already uses managed color management or ACES and automatically performs output rendering.
- 01
Write down the signal state immediately before and immediately after RTX Video HDR.
- 02
Compare the chosen Output Color Space/Gamma with what the project output transform expects.
- 03
Bypass the FX and project/output transform one at a time to see which stage creates the HDR appearance.
- 04
Keep one owner for SDR-to-HDR rendering and use the other stage only for a genuinely required encoding/delivery conversion.
There is no contrast/highlight jump from stacking, and every transform in the pipeline has one clearly defined responsibility.
Troubleshoot “everything clipped after RTX HDR”
Separate a wrong input contract, double output rendering, and incorrect monitoring.
PrepareAfter enabling the FX, the Viewer or scopes show an excessively bright/contrasty result.
- 01
Return Contrast/Saturation to neutral values and Blend to 1.000 so you are not diagnosing several variables at once.
- 02
Verify Input Color Space/Gamma against the actual node input rather than original metadata.
- 03
Temporarily bypass the downstream CST/RCM/ACES output stage and compare scopes.
- 04
Separately confirm that the HDR Viewer/monitor path interprets Output Gamma correctly.
The cause is isolated to one layer — input, output ownership, or monitoring — instead of being hidden with arbitrary slider compensation.
05DO NOT CONFUSE THE JOBS
AI SDR→HDR generation, deterministic transforms, gamut fitting, and manual HDR grading solve different problems.
| Tool | What it owns | Use it when |
|---|---|---|
| NVIDIA RTX Video HDR | AI-assisted SDR-to-HDR appearance expansion with explicit input/output signal contract, target peak, and creative shaping. | When a fast AI-assisted starting point is needed for SDR footage inside HDR production and a supported RTX/Windows environment is available. |
| Color Space Transform | Deterministic conversion between known color space/gamma descriptions with documented tone/gamut mapping options. | When the job is exact technical conversion rather than AI-generated HDR appearance. |
| Gamut Mapping | Fits luminance/chroma pressure inside a known signal state without AI SDR-to-HDR generation. | When an HDR signal already exists but its tone/gamut must be smoothly fitted to a target display/color volume. |
| HDR palette / manual grade | Deliberate manual placement of tonal zones, highlights, and color volume according to shot intent. | When maximum creative control and shot-by-shot supervision are required instead of automatic expansion. |
06SYMPTOM → CAUSE LAYER → FIX
Do not fix a signal-contract error with a creative slider.
The fastest diagnostic move is usually to simplify: neutralize creative settings, set Blend to a full pass, verify input state, then bypass downstream rendering and monitoring transforms one layer at a time.
01Highlights look blown out immediately+
Check Input Color Space/Gamma and downstream output rendering first. If the OFX receives the wrong encoding or its result is rendered again by a DRT/CST, sliders are not the correct fix. Temporarily bypass downstream transforms and compare HDR scopes.
02Midtones are too dark or reference white feels misplaced+
Confirm that monitoring actually displays the selected Output Gamma, then tune Middle Gray and Contrast. Do not use Middle Gray to compensate for an SDR viewing path; the master can remain wrong even if the Viewer looks better.
03Neon, LEDs, and graphics become excessively saturated+
Reduce Saturation and inspect CIE/color volume. If values must fit a smaller target gamut, use deliberate downstream Gamut Mapping/compression and watch separation rather than relying on hard clipping.
04Use timeline behaves oddly after CST/DCTL/LUT+
Use timeline inherits the project/timeline description, but an upstream local transform may already have changed the actual signal state. Set explicit Input Color Space/Gamma that match the OFX input and test again.
05The export looks different from the Color page+
Separate the OFX from delivery. Check Output Color Space/Gamma, project output transform, export tags, codec/container signaling, HDR metadata, and playback environment. RTX Video HDR does not configure those layers automatically.
06Partial Blend looks nicer but scopes become hard to interpret+
Blend mixes SDR input with HDR-mapped output. For a technical SDR-to-HDR conversion, return Blend to 1.000 and fix the mapping/contract itself. Keep an intermediate value only as an intentional creative effect.
07The FX is unavailable or shows an unsupported overlay+
Blackmagic’s feature matrix lists Nvidia RTX Video HDR as Desktop Studio with a platform note requiring Windows, a supported NVIDIA RTX graphics card, and driver. Verify edition, OS, GPU, and driver environment first.
Scopes: watch both luminance and color volume
HDR waveform shows diffuse/reference white and peaks, but that is not enough for saturated HDR highlights. Add Vectorscope/CIE and inspect signage, LEDs, neon, skin, and smooth gradients after AI expansion.
Monitoring: an SDR Viewer is not an HDR reference
A blown-out or washed-out Viewer can be caused by the display path rather than bad RTX mapping. Validate the output transform, HDR-capable display path, and real target presentation separately from the OFX controls.
Delivery: the OFX does not author the entire HDR master contract
After the image is mapped, export color tags, codec/container signaling, and HDR mastering metadata where required still remain. Max. Luminance inside RTX Video HDR does not replace those delivery-level fields.
07BEFORE YOU MASTER
Approve the source, signal contracts, mapping anchors, scopes, monitor path, and file delivery separately.
The checklist is a workflow guardrail. It does not replace a calibrated/known HDR display path, project-specific mastering specification, QC, or an actual render test on the installed Resolve/driver/GPU combination.
08FAQ
The questions that separate the AI mapping from the rest of the HDR system.
Is NVIDIA RTX Video HDR just a CST?
No. CST is deterministic color-space/gamma conversion with known tone/gamut options. RTX Video HDR is AI-assisted SDR-to-HDR mapping. Resolve adds an explicit input/output signal contract around it, but the appearance expansion itself remains an AI operation.
Can Input Color Space/Gamma stay on Use timeline?
Yes, but only if the timeline description truly matches the signal state at the OFX. After a local CST, DCTL, LUT, or another managed/manual transform, explicit values are often safer because the actual node input may have changed.
Is Max. Luminance the HDR monitor brightness setting?
No. It is the target peak used by the mapping. The display and monitoring pipeline are configured separately, and mastering metadata plus delivery signaling are separate again.
How should Middle Gray be used?
Use it to place the midtone/reference region after the signal contract and HDR monitoring are verified. Judge diffuse whites, skin, and midtones on HDR waveform and a real display rather than by Viewer brightness alone.
Should RTX Video HDR be applied to footage that is already HDR?
Usually not when the material is already correctly mastered HDR and should be preserved. The effect is intended for SDR-to-HDR expansion. Remapping an HDR source creates a new creative rendering and should be an explicit decision rather than a default pipeline step.
Should Global Blend be below 1 for more “natural” HDR?
Not as a technical rule. Partial Blend simply mixes the input and mapped result. First obtain a correct full mapping at Blend 1.000; if intentional creative moderation is desired afterward, an intermediate Blend can be used with the understanding that two different rendering states are being mixed.
Does the FX finish HDR delivery by itself?
No. It creates the image. Project/output color management, HDR monitoring, export tags, codec/container signaling, and required HDR metadata remain separate pipeline responsibilities.
Which systems can run NVIDIA RTX Video HDR in Resolve?
Blackmagic’s Studio feature matrix lists the effect as Desktop Studio; the NVIDIA RTX Video note requires Windows, a supported NVIDIA RTX graphics card, and driver. Verify exact GPU/driver compatibility against the current Resolve/NVIDIA requirements for the installed version.
Sources and verification boundaries
Visible control names and states were checked against the five actual Resolve captures stored in the project. Hardware/platform availability was cross-checked against Blackmagic’s Studio feature matrix; the AI SDR→HDR role was cross-checked against NVIDIA RTX Video SDK documentation. The interactive lab is an independent teaching model and does not reproduce proprietary NVIDIA neural-network behavior, Resolve OFX math, real transfer functions, or measured HDR luminance.
This web pass does not claim live Resolve/GPU/driver render certification. Final acceptance belongs to the installed Resolve version, supported NVIDIA environment, actual color-management architecture, HDR monitoring path, and rendered delivery file.