OTOY Forums

I'm trying to learn the free version of Blender Octane, and I'm trying to figure out how to render a multilayer EXR sequence in Rec.2020 ST2084 1000 nit to bring into Resolve and export an HDR video.

I searched the manual (which seems a few years old), and the only instances of HDR I could find were referring to HDR images, not the TV standard. I also searched for 2020 and I had a lot of results because the manual talks about Octane 2020.2, but nothing about Rec.2020.

In the Render tab there is a setting called "Final image render" that has choices of Octane Default, LDR and HDR, which I suspect is also for HDR images, not so much the TV standard. And the Octane Output section, for color space has two choices of ACES and sRGB, that's all. No Rec.2020.

Does this mean that this version of Blender doesn't support and HDR Rec.2020 workflow?

More importantly than the answer (written further down): any render output is (should) never conformed to a display specification unless if used "as-is" (akin to S.O.O.C. photos from digital cameras), meaning from the render to direct-consumption without any post roundtrip.

A renderer is technically compatible with virtually any "color space" and is rather restricted in its render-viewer (frame buffer) capabilities, nowadays, ("SDR" support and a "partial HDR" support on any compatible macOS).

All internal calculations (rendering) are not bound to a given color space: Octane is a spectral renderer, it supports more than the "default sRGB (linear and non-linear)" and OCIO.

Short answer and universally applicable:
OpenEXR export* > conformation in post (here, to Rec.2020) > Resolve.

*OpenEXR is "unrestricted", virtually infinite dynamic range and any color space encoding.

Thanks for your reply. So basically what you're saying is to just render the way Octane recommends, which is to set the color to raw, and then switch to Rec.2020 in compositing, correct?

I'm a bit confused as to how the Rec.2020 HDR pipeline is supposed to work. To clarify, I'm not a professional working in VFX, I'm just learning this stuff on my own, so I don't have the knowledge someone would get from working at even a small VFX house.

So in standard Blender, I see that there are four options as far as the target display device: sRGB, P3, Rec.1886 and Rec.2020. Since Blender can't output a real Rec.2020 preview (at least not on Windows, I still have to try it on my Mac), I work in sRGB, and before rendering, I switch it to Rec.2020, which obviously looks awful because it's not real Rec.2020 even if I set the preview window on my HDR TV set. But when I bring that animation into Resolve inside an HDR project that I monitor via a Decklink card with real HDR, it looks great.

What threw me off a bit is that in the Octane version of Blender, I can't find Rec.2020 anywhere.

Renderous wrote: Fri Jul 04, 2025 3:01 am So basically what you're saying is to just render the way Octane recommends, which is to set the color to raw, and then switch to Rec.2020 in compositing, correct?

That's one colloquial way to put it (vulgarized, oversimplified, informal, in other words).
On “set the color to raw": in post-production, “raw” has no technical or mathematical definition besides implying “as-is” from a given source to a given destination, synonymous of “signal unchanged” in the context of texture files or render output (therefore the source defines the specifications).

The term "raw" is subject to avoidance as it's an ambiguous undefined colloquial term. In essence, Octane renders "spectrally" (unknown specifications) then internally converts to known Linear-sRGB specifications for viewing (viewport) and encoding (i.e. OpenEXR, or sRGB IEC61966-2.1 for JPG and similar formats). Raw is solely utilized in a figurative manner, an umbrella term, conceptually universal (hence commonly found in camera, imaging subjects).

Renderous wrote: Fri Jul 04, 2025 3:01 am I'm a bit confused as to how the Rec.2020 HDR pipeline is supposed to work. To clarify, I'm not a professional working in VFX, I'm just learning this stuff on my own, so I don't have the knowledge someone would get from working at even a small VFX house.

As all individuals are or were at one point. It's worth to emphasis on the fact that "HDR" is still in its early wide-adoption era, not properly supported if not, at all, in most programs and destinations (viewing medium).

Renderous wrote: Fri Jul 04, 2025 3:01 am So in standard Blender, I see that there are four options as far as the target display device: sRGB, P3, Rec.1886 and Rec.2020. Since Blender can't output a real Rec.2020 preview

"Rec.2020" when written as such, is ambiguous similarly to "Rec.709". This leads to such bewilderment, as experienced by many. Furthermore on the latter aforementioned, "Rec.709" is expected to be both "BT.709" and "BT.1886" with a D65 "white point" reference (all three indispensable primary components defining a "color space"). This post clarifies on this very topic.

When developers of image software of some sort designate an option as "Rec.709", it's unsure if the meaning of it implies the chromaticity primaries coordinates ("gamut"), the transfer function and which one (EOTF, OETF, mistakenly known and referred as "Gamma") and so forth. "Rec.2020" is prone to an identical equivocacy as any color space is technically defined by primarily its three components and secondarily its contextual nature.

Renderous wrote: Fri Jul 04, 2025 3:01 am (at least not on Windows, I still have to try it on my Mac), I work in sRGB, and before rendering, I switch it to Rec.2020, which obviously looks awful because it's not real Rec.2020 even if I set the preview window on my HDR TV set. But when I bring that animation into Resolve inside an HDR project that I monitor via a Decklink card with real HDR, it looks great.

In Blender, the Display Device lists “does not enable HDR” by itself. A checkbox under does, currently only on macOS, similarly Octane checkbox in the macOS-only preferences, which once enabled, bypasses OCIO. The Display Device option is merely the "tri-components" of a "color space", excluding the "luminance scale".

Octane is allegedly processing “HDR” through Apple’s Metal API at OS level (fair to assume so).
Blender is likely supporting “HDR frame buffer” the same way and as for the rest, is processing the signal through its own OCIO config-file, which Octane does support as well (OCIO) and for both: solely in “SDR” at this time.

Renderous wrote: Fri Jul 04, 2025 3:01 am What threw me off a bit is that in the Octane version of Blender, I can't find Rec.2020 anywhere.

Octane is "self color managed", the native Blender "color management" is ignored. The same goes to any Octane plugins in any 3D DCC.

CAVEAT:
“HDR” is best to ignore at the moment, this is particularly more relevant for neophytes and uninformed individuals unfamiliar with the convoluted post production, especially given that “color management” is not as universally standardized and properly developed as much as how it’s being portrayed.

This reply is already lengthy enough despite simplified and shortened (further strongly recommended reading on the attached URLs as hyperlinks) and the core subject of HDR with its inherent misconceptions hasn't been touched upon yet (and deserves its own page write-up).