ACES workflow in OctaneX in C4D Tweet

[RegSquires]

Following some tutorials online for working in the ACES colourspace and in Octane X I cannot find a colormanagement tab in the settings. Is this something deliberately missing or has the ACES workflow been updated. There seem to be viewport support for ACES and I have tried these with the output set in renders to ACES. This seems to work. I know I would then have to convert srgb tex to ACES or run them through at Gamma 1.

Also I am running C4D R23. When is the timeline for and R24 build

Macbook Pro 15" 2.9GHz 6-Core Intel i9 32GB Ram Radeon Pro 560X + Sonnet EGPU with AMD Radeon Pro WX 9100 Big Sur 11.3

[bepeg4d]

Hi,
Color management and OCIO support has been added in 2020.2 SDK, while OctaneX is still based on 2020.1 SDK.
We need to wait for stable 2021.1 SDK to have both Metal and CUDA versions on the same page.

Happy Mac GPU rendering,
ciao Beppe

[RegSquires]

Hi,
Color management and OCIO support has been added in 2020.2 SDK, while OctaneX is still based on 2020.1 SDK.
We need to wait for stable 2021.1 SDK to have both Metal and CUDA versions on the same page.

Happy Mac GPU rendering,
ciao Beppe

Thankyou. That clears things up

[bollella]

Any progress on OCIO support for OctaneX?
Thanks,
Greg

[elsksa]

Chiming in to share the important information that Octane *does not* require ACES in order to "look good" as some (many, over internet) have been fallaciously using ACES for its RRT. More information on my other replies from other forum-threads: viewtopic.php?f=86&t=78275&p=403666#p403666

[SSmolak]

Main reason that ACES is better is that you still have compressed highlights and brighter dark areas on your Live Viewer and after saving it you still have 32bit depth for editing purpose. Also Filmic Blender color space doesn't support 32 bit depth on output.

[elsksa]

Hi SSmolak, to quickly answer you:

Main reason that ACES is better is that you still have compressed highlights and brighter dark areas on your Live Viewer (...)

So does "Blender-Filmic", which I personally call "Filmic by Troy Sobotka" or "the Filmic OCIO package" since it is not Blender-proprietary and could be misleading/misinterpreted.

Scene-exposition wise, ACES does not "brighten up" the "dark areas". In CGI, generally speaking, the rendering-working-color-space is ACEScg, being ACEScg chromaticity primaries coordinates, ACEScg white-point and a linear transfer-function mistakenly known as Linear ̶G̶a̶m̶m̶a̶ (https://www.elsksa.me/scientia/digital-imaging/understanding-linear-in-digital-imagery). Octane being a spectral renderer, ACES is used slightly differently (https://www.elsksa.me/scientia/cgi-offline-rendering/octane-render-aces)

(...) And after saving it you still have 32bit depth for editing purpose. Also Filmic Blender color space doesn't support 32 bit depth on output.

Beware of the following:
• Color Space* ≠ Bit Depth
• both ACES and "Filmic" would export a scene-referred linear OpenEXR and for beauty: only 16-bit as 32-bit is almost if not never used in professional CGI/VFX studios and productions as it is most suited for data AOVs.
• Both are suitable for HDR Offline Rendering, to not mistaken with HDR mastering.

When exporting a scene-referred EXR, the RRT/ODT on the ACES workflow, is not applied and the same principle is used for Filmic: the export is without the high dynamic range transfer function (and its "intensity gamut mapping").
For non-OpenEXR supported application where "color management" is limited, using Filmic allows to export a TIFF file with the logarithmic encoding applied to it, simplifying the compatibility with non-digital-imaging professional post-production applications.

At the export, ACES would be referred as Linear-ACEScg and when using Filmic OCIO as Linear-sRGB, basically, as if Filmic was disabled/not loaded via OCIO since it is "only a view transform" as opposed to ACES being a wide gamut color encoding system and affecting primaries (in the case of an R'G'B' renderer, that is - as mentioned previously, Octane is slightly different as it is a spectral renderer - more information in the link shared previously).

It is strongly recommended to acknowledge the fundamentals as well as avoiding common online misconceptions: https://www.elsksa.me/scientia/cgi-offline-rendering/cgi-color-management-survival-kit
* A color space is composed of three components described in the link above.

ACES is wide-gamut domain which is to this date incompetently handled by the vast majority of non-digital imaging technician/colorist individuals and only a selection of post-houses have properly mastered it, to some extent. Wide-gamut involves a much more specific and careful pipeline and workflow - CGI related, from the texturing, shading to lighting and in post. The default scene or display referred sRGB "color management" aka "ITU-R Rec 709 with the sRGB EOTF specifications (pure ̶G̶a̶m̶m̶a̶ 2.2 function, which is an approximation of the piece-wise function, or the piece-wise function itself)" is capable of producing vibrant, contrasted and any other "subjective aesthetic looks" when in good hands.

While no solution is perfect (and likely never will be for many technical and philosophical reasons), Filmic remains the primary recommendation as it is much simpler, accessible to many and less prone to bold image artifacts but most importantly: better suited for individuals, as opposed to large budget productions with experienced digital imaging technicians, colorists as well as digital motion-picture scientists and engineers.

[SSmolak]

Ok, so what is difference between Filmic tone mapping and Highlight Compression in Octane Camera Imager ? In my test they both looks near the same and have the same limitations while saving to output linear file.

[elsksa]

Ok, so what is difference between Filmic tone mapping and Highlight Compression in Octane Camera Imager ? In my test they both looks near the same and have the same limitations while saving to output linear file.

In short: OTOY did not share the technical specification of their Highlight Compression implementation. However, it is a limited feature while Filmic OCIO is mathematically more advanced and uses a different approach as it does (simply said) first encode the Linear-sRGB source to a logarithmic OETF (similar concept as the "log-profile" in digital cameras) then applies a contrast-look for output referred imagery.

An other advantage of the Filmic OCIO package is that it can be applied in post and is generally speaking, "post-friendly" since it can be re-applied independently from the renderer, while Octane's Camera Imager's Hightlight Compression is limited to Octane internally and so, prevents from exporting a linear-scene-referred floating point output - in other words, the output has to be display referred as an integer file format (JPG, PNG, etc) and so, limiting what can be done in post.

When advanced compositing software are not part of the post-pipeline, it is possible to "bake" Filmic's Base Log Encoding to a TIFF file and use it in Lightroom, Photoshop with or without the provided contrast LUT files. This is a simpler workflow and a workaround solution to the software that do not support floating-point processing and the OpenEXR file format.

[SSmolak]

An other advantage of the Filmic OCIO package is that it can be applied in post and is generally speaking, "post-friendly" since it can be re-applied independently from the renderer, while Octane's Camera Imager's Hightlight Compression is limited to Octane internally and so, prevents from exporting a linear-scene-referred floating point output - in other words, the output has to be display referred as an integer file format (JPG, PNG, etc) and so, limiting what can be done in post.

The problem is that saving Filmic OCIO as 32bit EXR do nothing - it lose 32bit depth and it looks the same as saving using Highlight Compression. I compared it in Photoshop and Affinity Photo. Exporting OCIO from Cinema 4D Octane even as 32bit linear EXR flatten it to 8 bit. Maybe this is bug ? Exporting as ACES works fine.