ACES workflow in OctaneX in C4D Tweet

[elsksa]

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.

Bit Depth and Export
There are no problem, issue or bug. Nothing is lost when exporting as 16 or 32-bit depth EXR.
When using the Filmic OCIO solution, exporting as 32-bit* EXR will default to a Linear-scene-referred** encoded EXR (without any OE/EO-TF applied).

This is normal if "it does nothing" because it should not, when exporting as such (OpenEXR).

ACES is the exact same, exporting with it as OpenEXR would mean exporting a Linear-scene-referred EXR (Linear-ACEScg instead of Linear-sRGB) and since it is in linear, it means that it is still exported without any OE/EO-TF applied and so, the appropriate ACES ODT has to be apply in post, same as Filmic which has to be re-applied in post, at least when exporting as OpenEXR.

The page is incomplete (in my opinion) but should give solid pointers to what "Linear" means: https://www.elsksa.me/scientia/digital-imaging/linear-in-digital-imagery

Photoshop or Lightroom recommended (and more appropriate) workflow
Regarding Photoshop (or Lightroom aka LR), it does not natively fully support 32-bit EXR and processing as it should and is not considered as an alternative to Nuke or Fusion which are much more reliable in that regard (and designed for VFX/CGI post-production).
This is why it is recommended (for PS/LR) to export a 16-bit TIFF with the Filmic Log Base Encoding applied, so an "s-curve" can be added in PS/LR or loading one of the provided contrast LUT from the Filmic OCIO package (if PS/LR are compatible with the given LUT format if not, a conversion to a supported LUT file format is still possible).

*is not recommended, 16-bit is for beauty. 32-bit is appropriate for data AOVs (normal, world position, etc). There are more information here:
https://www.elsksa.me/scientia/cgi-offline-rendering/the-unawareness-of-png-and-exr

** There is a section that covers the meaning of the terms "scene (or) display referred": https://www.elsksa.me/scientia/cgi-offline-rendering/cgi-color-management-survival-kit

I hope it did clarify some of the confusion and misconceptions. Feel free to ask any further questions.

[SSmolak]

Theoretically... but please see here, something is wrong with exporting via OCIO in Octane : viewtopic.php?f=85&t=78286&start=50#p404607

[elsksa]

Theoretically... but please see here, something is wrong with exporting via OCIO in Octane : viewtopic.php?f=85&t=78286&start=50#p404607

Thank you for sharing this thread. There are two reasons that could cause what you did "report":

File format
I see a PNG file named "Screen_czwartek, 23 września 2021_12h44m01s_002_.png". Are you exporting "HDR (Float 32-bit)" as PNG?

PNG is not 32-bit high dynamic range floating point. Nor 32-bit TIFF or any other supported file format other than OpenEXR. https://www.elsksa.me/scientia/cgi-offline-rendering/the-unawareness-of-png-and-exr

There is no need to export 32-bit EXR for beauty-renders. Did you try to export a 16-bit floating point EXR? Do you have a software in post to open the OpenEXR natively (Nuke, Fusion, DJV Viewer which is free, if you are interested, etc).

Display Referred Output
In this screenshot

Source: https://render.otoy.com/forum/viewtopic.php?f=85&t=78286&start=50#p404607

I see that an OCIO View has been set. I am not familiar with Octane for Cinema 4D (GUI wise) but I would suspect that a combo of PNG + having an OCIO View applied, both contribute to clamping the original scene referred high dynamic range to display referred since ITU-R BT.709 is a standard-dynamic-range encoding and signal characteristics display color-space.

Ensure the following:
• The file format is OpenEXR
• The export is set to linear scene-referred (by default, if OpenEXR is selected, out of the renderer, the OCIO View should not affect it. This is not the case in post - such as in Nuke, Fusion, etc)
• It is set to 16-bit (it is the standard bit-depth for beauty in productions)

Filmic or ACES, it does not matter. Both are exporting as Linear Scene Referred, without any OETF or output transform applied (i.e "Filmic Log Base Encoding"/the "Contrast-Looks" or the OCIO View "ACES.sRGB" ODT).

I will share this reply to the thread you have linked, in case someone else would require the steps to properly export from Octane, in "scene-referred" (which I believe are covered in the Octane Cinema 4D documentation).

Looking forward to hearing back from you.

[SSmolak]

Are you exporting "HDR (Float 32-bit)" as PNG?

No ! it was saved as 32bit EXR. PNG was only PrintScreen screenshoot

[elsksa]

I almost forgot about MacOS here... which is also color managed differently from Windows/Linux. There should be MacOS-specific options in that regard. Could it be related?

I will do a scene-test later, that I will attach here (ORBX) and will also attach the expected correct rendered results that I get. This will allow you to compare and troubleshoot the issue more easily.

[elsksa]

I am a bit in a hurry and rushed it but here is a quick test.
The gif file might not auto-play automatically unless opened in a new tab or downloaded.

Note: ensure to set the path file for the ACES OCIO configuration file.

ORBX attached.

PS: ignore the "HDRI" in the file name, it was not supposed to be an HDRI since there is a known limitation: viewtopic.php?f=33&t=74112&p=380308&hilit=hdri+clamping#p380308

[SSmolak]

I am a bit in a hurry and rushed it but here is a quick test.
The gif file might not auto-play automatically unless opened in a new tab or downloaded.

And do the same with Filmic OCIO - you will have 8 bit output. I've just tested it in Octane Standalone too. Standard ACES works fine.

[elsksa]

And do the same with Filmic OCIO - you will have 8 bit output. I've just tested it in Octane Standalone too. Standard ACES works fine.

Hi SSmolak, the gif above is showing the Linear-ACEScg encoded EXR in Fusion.
"Filmic" is different from ACES, as it is a view-transform applied on top of the Linear-sRGB data.

How exactly do you want me to export from Octane with "Filmic"?
• As Linear-sRGB 16-bit EXR? If yes, then it is as if there was no "Filmic" OCIO configuration file, since, again, "Filmic" is just a view transform.
• With the Filmic Log Base Encoding applied?



While I do not need to test it because as I have mentioned before, there are no OCIO or export issues with Octane that I have encountered using both ACES and Filmic OCIO color managed Octane project which both behave as expected, I did follow your demand.

Here is a test with the "Filmic" OCIO configuration file loaded. It is needless to say (as mentioned before), Octane is exporting a Linear-sRGB EXR, without the view transform applied. Filmic OCIO is then re-applied the same way, in post.

The waveform scope on the left is showing the full dynamic range 16-bit half floating point OpenEXR.

As mentioned in a previous message, it would likely be an end-user clumsiness or it might potentially be caused or related to the MacOS-specific HDR color management.

Credits: OTOY Inc.

I do not have a Mac laptop/computer as of now and so, can not easily verify myself, however, this MacOS specific option should not affect export but instead, the frame buffer preview.


Last but not least, it could be an issue related to the compiled version of Octane for MacOS (Octane X) but I would doubt that, as we would have seen more reports from other members, including some active Octane X users I know.


Looking forward to receiving more information about your MacOS HDR support settings in Octane and how you are viewing and/or compositing in post.

[SSmolak]

At the end I found that this workflow works :

Render as OCIO for camera preview as ACES Rec.709 :

But in compositing software there is need to do some OCIO conversions. For example in Affinity Photo which support OCIO there is need to apply three OCIO adjustment layers :

First:

Second :

Third :

Like this :

Screen_niedziela, 26 września 2021_22h02m41s_004_.png (15.73 KiB) Viewed 3362 times

And 32bit Exposure for ACES REC 709 works fine :

It works for any custom ACES profile like ACES P3-D60, Rec2020 etc but the only needs is to change second OCIO adjusmtent layer for proper profile value.

[elsksa]

It works for any custom ACES profile like ACES P3-D60, Rec2020 etc but the only needs is to change second OCIO adjusmtent layer for proper profile value.

The other ACES ODT should not be used, assuming you are exporting for the web and not for a cinema theater projection. Therefore, ACES.sRGB (or ACES.Rec709) are the appropriate ODTs.

But in compositing software there is need to do some OCIO conversions. For example in Affinity Photo which support OCIO there is need to apply three OCIO adjustment layers :

It is worth to mention that this "issue" is specific to Affinity Photo, which when exporting, applies the default sRGB EOTF (from the Affinity Photo "color profile") on top of the ACES ODT. This issue has been known and reported for a while. I am surprised that it is still not fixed. This is not the case for Nuke, Fusion, etc.

PS: as mentioned, 16-bit is more than enough. 32-bit EXR is most appropriate for data AOVs, not beauty. This is not an obligation but a recommendation of a more appropriate OpenEXR export from Octane, on par with CGI/VFX production standards.