OctaneRender™ 2020.2 (XB1) is out! + 2021 roadmap updates! Tweet

[funk]

I'm looking into the possibility of allowing an OCIO config per scene. It gets a bit complex because you can load one scene into another scene... but it is likely this will be in a future 2020.2 XB release. The per-scene config, if set, would override the global setting. Note that generally OCIO seems to be intended to be used with the system-wide "OCIO" environment variable specifying the same config for all applications and all projects, rather than having to set it up for each application or project, but that workflow might not be for everyone.

I have a question: If you chose an OCIO config for a specific scene, and then exported an ORBX file, would you expect a copy of the OCIO config itself to be embedded in the ORBX file or just a filename reference?

Great! I think the global setting + per scene override is the best way to do it. Thanks.

I know you are embedding LUTs into the ORBX, so it would make sense to do something similar for OCIO. I dont understand the technical side of things, but the ACES configs are huge, so this could be a problem (?). You probably only need to embed a small part of the config though.

It's probably more important for cloud/rndr rendering, if the user actually wants to save out LDR images which need the lut/ocio baked into the final image. I don't work this way, but some do.

Saturation makes sense and is easy to get working when using OCIO (unless there's something I've missed). We should be able to get this in for XB2. Other things like gamma are problematic, because the current built-in Octane tone mapping requires the color to be clipped into a 0-1 range in the sRGB gamut (and can introduce hue shifts), which would defeat a lot of the purpose of using OCIO in the first place (nicer tone mapping for extreme highlights, outputting in wide-gamut color spaces, etc.).

Yeah I was afraid of that. I basically use gamma as a contrast control. Maybe you guys can start looking at some alternative image processing that doesnt require clipping. This would also be useful with your color correction node, allowing it to be used on HDRI images plugged into the environment.

Another question: Would it be helpful if there was an option to enable all the tone mapping controls even when using OCIO, BUT enabling that option meant that the clipping that the built-in tone mapping does couldn't be undone, so you wouldn't be able to do all the nice HDR stuff that some OCIO configs enable?

I think it would still be useful, but I'm sure you'll get questions about it... Just make sure the tooltip explains the cons of enabling it

[enricocerica]

Doesn't work with a quadro K2000M, no GPU found, even with the latest studio divers. I know it's an old video card but I use it sometimes to make tests.

[mojave]

Doesn't work with a quadro K2000M, no GPU found, even with the latest studio divers. I know it's an old video card but I use it sometimes to make tests.

Kepler devices with CM 3.0 such as this one are not supported by this build, we will try our best to bring it back before the final release but it is unlikely we will be able to do so.

The reason is because in order to support the new Ampere architecture we must update to the latest CUDA and cuDNN which discontinue support for this compute model.

I will add a note about this in the initial post.

[divasoft]

Chromatic Aberration guys, don't forget please. They have long been implemented in all other renders.

[jimho]

regard to color management,
the main purpose of color management is to keep the image same looking when they are transfered between different softwares,
there is an issue which exist for long time, hope it could be resolved:
the color for exr files.

when we export an octane rendered image, we have 2 choice png and exr,
when we export png the tone mapping works well means the exported image is in right color and tone when loaded into photoshop.
the probleme is from the exr.
for example:
if there is a scene rendered when the gamma is set to 1.5 in camera imager,
as mentioned above,when exporting in png, the color is correct,

when export in exr, if we choose tonemapping, it will be much lighter than it should be(in this case each time I have to set the gamma 0.4545 times to it in photoshop,the 0.4545=1/2.2, means there is an extra 2.2applied)

if choose linear it will be darker than it should be(and this time I have to set the gamma as 1.5 manually in ps, means the gamma which we set in the camera imager is missed)

can this be fixed,so that we donot need to fix it each time manually?

personally I don't really need too complicated color management things in octane, if the image can be correctly transfered to post-softwares, they can deal with it...

ps. my display is proper color managed and there is a display color profile attached, not sure if this is a reason that there is extra 2.2 applied when the exr is tonemapped...

[Jolbertoquini]

I have some feature requests regarding OCIO

....

Hi Guys,

I was testing and getting something really good with ACES 1.2 what I did basically octane use linear workflow with ACES and I use ACESCG for preview converting from linear render, at AE I can get the exr 16 bit as linear with a lot range to play and full control inside AE as in octane same output and etc. really interesting maybe I need try more again but I had great color result and dynamic range in terms of highlights.

Best,
JO

[Kalua]

I am curious about <<Chaos Texture Tile System>> and <<UV Distortion Map Textures>> features. Is there any preview of them??

Yes we showed these in my GTC talk. I can grab some images

Thanks! I revised your presentation and just saw it, just didn't remember it. Most welcome hardcoded feature.

[enricocerica]

Doesn't work with a quadro K2000M, no GPU found, even with the latest studio divers. I know it's an old video card but I use it sometimes to make tests.

Kepler devices with CM 3.0 such as this one are not supported by this build, we will try our best to bring it back before the final release but it is unlikely we will be able to do so.

The reason is because in order to support the new Ampere architecture we must update to the latest CUDA and cuDNN which discontinue support for this compute model.

I will add a note about this in the initial post.

Yes I know, it's an old technology and the driver doesn't seem to be at the last level compared to the other recent cards. It's not crucial, if you could do something, fine otherwise I'll live without
Thanks

[karl]

regard to color management,
the main purpose of color management is to keep the image same looking when they are transfered between different softwares,
there is an issue which exist for long time, hope it could be resolved:
the color for exr files.

when we export an octane rendered image, we have 2 choice png and exr,
when we export png the tone mapping works well means the exported image is in right color and tone when loaded into photoshop.
the probleme is from the exr.
for example:
if there is a scene rendered when the gamma is set to 1.5 in camera imager,
as mentioned above,when exporting in png, the color is correct,

when export in exr, if we choose tonemapping, it will be much lighter than it should be(in this case each time I have to set the gamma 0.4545 times to it in photoshop,the 0.4545=1/2.2, means there is an extra 2.2applied)

if choose linear it will be darker than it should be(and this time I have to set the gamma as 1.5 manually in ps, means the gamma which we set in the camera imager is missed)

can this be fixed,so that we donot need to fix it each time manually?

personally I don't really need too complicated color management things in octane, if the image can be correctly transfered to post-softwares, they can deal with it...

ps. my display is proper color managed and there is a display color profile attached, not sure if this is a reason that there is extra 2.2 applied when the exr is tonemapped...

EXR files are not supposed to be tone mapped, as EXR is explicitly a scene-linear format. See https://www.openexr.com/:

The purpose of format is to accurately and efficiently represent high-dynamic-range scene-linear image data and associated metadata, with strong support for multi-part, multi-channel use cases.

Octane provides the option to export an EXR file using the sRGB color space for backwards compatibility; this may be part of users' existing workflows and we didn't want to break them. However, in the 2020.2 release this option has been moved to the bottom of the list and tagged as not being scene-linear. Ideally, it shouldn't be used.

Photoshop is presumably seeing that you're loading an EXR file, and assuming that it's in a scene-linear color space, and so applying another gamma transform in order to display the image. This is a reasonable assumption for any EXR viewer to make. If you want to export an EXR from Octane using tone mapping, and then display that EXR in another application the same as how it appeared in Octane, you will need to find an application that doesn't assume EXR files are scene-linear (or is happy to send a scene-linear image directly to the display), or manually apply an additional ~0.4545 gamma to the image to cancel out the conversion from scene-linear that the viewer is doing.

[jimho]

EXR files are not supposed to be tone mapped, as EXR is explicitly a scene-linear format. See https://www.openexr.com/:

The purpose of format is to accurately and efficiently represent high-dynamic-range scene-linear image data and associated metadata, with strong support for multi-part, multi-channel use cases.

Octane provides the option to export an EXR file using the sRGB color space for backwards compatibility; this may be part of users' existing workflows and we didn't want to break them. However, in the 2020.2 release this option has been moved to the bottom of the list and tagged as not being scene-linear. Ideally, it shouldn't be used.

Photoshop is presumably seeing that you're loading an EXR file, and assuming that it's in a scene-linear color space, and so applying another gamma transform in order to display the image. This is a reasonable assumption for any EXR viewer to make. If you want to export an EXR from Octane using tone mapping, and then display that EXR in another application the same as how it appeared in Octane, you will need to find an application that doesn't assume EXR files are scene-linear (or is happy to send a scene-linear image directly to the display), or manually apply an additional ~0.4545 gamma to the image to cancel out the conversion from scene-linear that the viewer is doing.

Thanks for your explainations,

but it seems not improve anything in terms of user experience, and it sounds pretty strange to many of us.

1, exr tonemapped, the term is from octaine's UI which is there for many years till today, but you say here, it is a wrong term which is not supported, it is otoy who have the responsiblity to use a correct term, we just follow that, anyway we just refer to the exr's exporting option no matter what name it is called;

exr.JPG

2, if there is anything not recomended,probably you may name it unrecomended, put to the bottom should not have this funtion
3, if most viewer will translate the "tonemapped" EXR incorrectly can you make it "correct" ;means make the "0.4545"builtin for your "tonemap" option?
Can we suggest if you provide anything, provide it correctly or just do not provide it, neither donot provide it in a halfway?
It is nothing to do with how photoshop etc softewares translate exr, you, the software maker need to take this issue count in, when you coding this tonemapping, it just mean the current tonemapping for exr is not in a rightway. Can you fix it?

In short, it is still good to provide an exr option that keeps same looking with the viewport, just to adjust the way how you do the tonemapping i.e. builtin the gamma upon the linear exr, for better user experience.