OCIO problem in 29.19 (bug?)

[dopelessdesign]

Hello, I can not change OCIO views on Blender Octane 29.19
I can change views, but it has on effect in a viewport.
It works as it should in Octane standalone.
Can please somebody check, if you have this issue too?

It worked fine at my side in previous verisons.
Thanks

[linograndiotoy]

Sure, we'll check this.

[dopelessdesign]

I've tested it at my side - it works fine in 29.18, but does not work in 30.0 beta1. So I think there really is a bug in 29.19, that were trasfered to 30.0

[linograndiotoy]

We'll fix this.

Meanwhile, my advice would be to use the (relatively) new AOVs feature, wich definitely expands Octane's AOVs and Compositing area.

[dopelessdesign]

Thank you.

I'll try it out with AOVs feature.
It was pretty challenging for me to find a way to achieve color consistency between applications in my workflow (blender octane -> 32bit exr -> after effects -> 8bit -> photoshop) on my monitor, and setting ACES:Rec2020 in OCIO view is essential step for me.
But I'll take a look at AOVs. Maybe there is a better way.

BTW, I've seen an suggestions in latest article on color management in docs, that the OCIO view has always be set to sRGB, but I don't think, it's the case (at least with Blender). If I set it to sRGB, I get oversaturated colors in viewport (if the Monotor not in the sRGB mode), and then I become washed out image in post.

[skientia]

It was pretty challenging for me to find a way to achieve color consistency between applications in my workflow (blender octane -> 32bit exr -> after effects -> 8bit -> photoshop) on my monitor, and setting ACES:Rec2020 in OCIO view is essential step for me.

1. The challenging part comes from the very fact that this software pipeline is sort of Frankenstein-esque.

2. OpenEXR at 32-bit is technically unnecessary for outputs other than data AOV. Adbe software are notoriously known to be unreliable and poorly color managed. This makes larger files and heavier processing for absolutely no benefit.
To put things into perspective, 16-bit floating point EXR is a magnitude "more data" than what the most expensive "cinema camera" can encode, as all digital cameras are integer encoding devices (long story short). In other words, it's much, much more than enough. 32-bit exports is a myth spread from unaware individuals.

Meanwhile, my advice would be to use the (relatively) new AOVs feature, wich definitely expands Octane's AOVs and Compositing area.

3. This. Native Octane implementations of ACES or AgX and AOV compositor is incomparably more reliable in terms of signal processing than this unconventional (in the professional industry and for valid verifiable technical reasons) pipeline.

BTW, I've seen an suggestions in latest article on color management in docs, that the OCIO view has always be set to sRGB, but I don't think, it's the case (at least with Blender). If I set it to sRGB, I get oversaturated colors in viewport (if the Monotor not in the sRGB mode), and then I become washed out image in post.

It's principally VFX and post studios who [are in a capacity to] change the monitor to an other color space than sRGB.
Anyone else doing so without a deep understanding of monitor calibration, digital imaging and the equipment necessary for this technical task, is heading towards a slippery slope.

"Washed out" is too ambiguous for anyone to make a proper diagnosis, but the common cases are a mistakenly applied log-encoding (e.g. ACEScc) or double transfer function (erroneously referred to as Gamma) which is more recurrent than the former.

Some informative resources on these subjects (with more available on the website):

- Post Rendering Guidelines
- File Formats Debunk (mainly about OpenEXR)
- Color Component Transfer Functions ("gamma")
- OctaneRender® “Color Management”

[dopelessdesign]

OpenEXR at 32-bit is technically unnecessary for outputs other than data AOV.

I'm talking only about still images now. Not video sequences. And yes, I'm using AOVs in post, so I do need 32 bit exr. And the images get printed, so sRGB is not a best choice for me )

Maybe, I'll use Octane compositor instead of After Effects. I've just never used Blender Cycles compositor, as I don't like it too much, so I've ignored the Octane's one. Will take a look.

[skientia]

OpenEXR at 32-bit is technically unnecessary for outputs other than data AOV.

I'm talking only about still images now. Not video sequences. And yes, I'm using AOVs in post, so I do need 32 bit exr.

16-bit and 32-bit in floating point follow the same principles regardless.
32-bit is **only** beneficial on **data** AOVs. Therefore, light AOVs are "non-data" in that sense, thus 16-bit. While Z-depth, normal, deep, etc. are considered "data" AOVs. If storage and optimization is "absolutely not a concern", then all the above isn't much pertinent but on a technical level, valid.

And the images get printed, so sRGB is not a best choice for me )

That's a common misconception.
sRGB "is fine", and Octane is a spectral renderer; its internal calculations are not limited to sRGB chromaticity primaries "gamut". What's more concerning is in post, particularly with Adbe software in the mix, as color management is persistently questionable and must be carefully double check with the necessary knowledge of it all. Hence why a "real" (proper) compositing software is a more appropriate choice, including Octane's own compositor as the image pipeline is by design suited for CGI post (32-bit support and precision, linear operations, associated alpha, native OCIO, AgX, ACES, OpenEXR and so forth).

Maybe, I'll use Octane compositor instead of After Effects. I've just never used Blender Cycles compositor, as I don't like it too much, so I've ignored the Octane's one. Will take a look.

Depending on what's done in post, both the Octane compositor and Blender's are great within their respective capacities.
For anything more sophisticated/advanced, Nuke and Fusion remain the primary (but paid) choices; they are PS, AE, Resolve altogether (capable of doing nearly-if not all-these ones do, and even more with custom tools and knowledge).

Octane compositor received more updates and has peculiarly interesting features such as OSL support (and all the native textures for the matter). Developers thoughtfully specified which "modes" are "linear" and "non-linear" to suggest "dos and donts" (via the "SDR" designation for "non-linear" operations).

[dopelessdesign]

If storage and optimization is "absolutely not a concern", then all the above isn't much pertinent but on a technical level, valid.

In my case storage - is one of the last concerns as renders (even 32bit exrs) take maybe 10-20% of the overall project disk space.

That's a common misconception.
sRGB "is fine", and Octane is a spectral renderer; its internal calculations are not limited to sRGB chromaticity primaries "gamut". What's more concerning is in post, particularly with Adbe software in the mix

I do understand, how the octane render works. And you are absolutely right, that it's a slippery way including adobe software in a workflow. Bud I did found a way, that works in my enviroment, how to get the same (at least same enough to become desired results) colors from the start to the finish of the projects, leaving monitors in same wide gamut mode.

For anything more sophisticated/advanced, Nuke and Fusion remain the primary (but paid) choices

Sure, Nuke is a better soulution in many ways. But I don't think it's worth an investment for a small agency, just to composite still images. As far as AE (that I have installed anyways) is doing it's thing (and it's doing it pretty well), I'll stick with it ))

But as I've told, I'll definitely take a look at octane's compositor. Last time I've tried to use Blenders compositor was mayby 12-13 years ago, and I'm pretty sure, things have changed since then )


Btw. I appreciate you're spending your time trying make my (and not onlt my) life easier. Maybe it looks, like I'm trying to defend my point of view (and maybt I am )) ), but your input is very valuable - I'm sure, it'll do good in one or another way.

[skientia]

These are merely (strong) suggestions and recommendations. In the end, an individual is making a choice for oneself, freely. As recurrently emphasized, what matters is awareness (being aware, while conscious of the unknown, yet to be acknowledged information) as you've wonderfully expressed.

Nuke is a software that needs no introduction but its pricing, even if more accessible than in the past, is still a road block for many. It may very well be not suited for everyone. In no way the ultimate solution.

Hence the benefit of Octane's own compositor, the most straight forward integration (most workflow efficient) of post within the renderer and for any external compositing, Fusion is more accessible (at no cost through the free Resolve, although the integration of a software within another software is another slippery slope), or Blender compositor, truly free and no limitations (unlike free resolve).

"Good luck!" and good catch on what is seemingly a bug.