Can't get OCIO to show up - what am I missing?

[pokoy]

Hey all, hopefully this is solved fast.
I'm trying to setup OCIO:

- downloaded the ocio config files, copied to 'C:/OCIO'
- created the environment variable (tested both user and system)
- Name: 'OCIO'
- Value: 'C:/OCIO/ocio_cofigxyz.ocio'
- Also tested: 'C:\OCIO\ocio_cofigxyz.ocio'
- Restarted PC
- Open Project Settings in TG >> CM dialog says < No OCIO config >

What am I missing?

[pokoy]

Nevermind, the actual download was a bit harder to spot and I haven't downloaded the entire package, only a part of it.
Works now, I can immediately see that I will use OCIO from now on.

[Doug]

thanks for putting this up

i got it working and will using it also

[digitalguru]

In case anyone has the same issue:
I had a situation with Substance Painter where setting OCIO in WIndows Enviroment didn't run the way I wanted to.
Used Advanced Run  (free from https://www.nirsoft.net/utils/advanced_run.html) to startup TG with the OCIO env variable
(would be nice to set that in inside TG rather than globally for Windows)

[digitalguru]

Lucen 94: Good to hear that worked.
TG should have an option to define OCIO inside the program though.

[pokoy]

Yes, definitely, should be included with TG. I wonder what happens when you want to use a render farm since you can't access or change system folders/settings.

[digitalguru]

Shouldn't be a problem. I only set it up this way on my local machine to avoid a conflict with Substance painter. On a farm machine the OCIO variable can be set in the environment - and there's a command line switch to enable OCIO (though it can't specify a path)

But if you're rendering to OpenExr it wouldn't matter anyway as the ACES won't be baked in. So long as you've set up the scene viewing under OCIO it will be ok.

[Matt]

The way OCIO was originally envisioned (as far as I understand it), all apps were supposed to use the OCIO environment variable so they would all use the same configuration in any particular environment. This would mean that artists working on a sequence would be less likely to accidentally use the wrong colour management configuration. That's the example we've followed. It wasn't long before apps started providing ways to override this on a scene-by-scene basis, which I always thought was a slap in the face to the original purpose. Is this standard now? I think it is, and we should probably follow suit, but I want to be careful about how we do it.

[Matt]

But if you're rendering to OpenExr it wouldn't matter anyway as the ACES won't be baked in. So long as you've set up the scene viewing under OCIO it will be ok.

If the OCIO config is different on the rendering computer then it does matter. There is a colour space for reading 8-bit textures and sRGB colour parameters, and a transform from this space to the linear render space.

[Matt]

...although those differences may be subtle. But if the rendering computer doesn't have any OCIO configuration at all then Terragen will revert to its default colour spaces (e.g. its default internal render space is Rec709/sRGB Linear), so you won't have an ACEScg EXR at all.

[pokoy]

The way OCIO was originally envisioned (as far as I understand it), all apps were supposed to use the OCIO environment variable so they would all use the same configuration in any particular environment. This would mean that artists working on a sequence would be less likely to accidentally use the wrong colour management configuration. That's the example we've followed. It wasn't long before apps started providing ways to override this on a scene-by-scene basis, which I always thought was a slap in the face to the original purpose. Is this standard now? I think it is, and we should probably follow suit, but I want to be careful about how we do it.

I guess that's old 'standard v2.5_final_v2' problem where a standard doesn't necessarily mean it's going to be the same in 3 years.
Downloading OCIO and setting it up would probably overwhelm some users (the site is really confusing and I had my problems finding the right files myself), plus ACES, ACEScg and their v1 > v2 versioning.
In a studio setting with shared workflows/assets it makes sense only for the current job. When you have to go back and re-render frames a few months later, OCIO might have seen an update or the studio changed their config and when it's shared across all studio machines it's likely to cause a different look etc. Same for TG when we re-render a job a few years later.

In my view it's better to spare the user all the hassle, include a certain version of ACES with TG so casual users can benefit from it but don't have to get too technical.
Ideally, TG would keep the current workflow so anyone needing something else can override the internal presets, and use a custom OCIO setup or switch to gamma workflow.

Maybe it should go like this:
- current OCIO setup with env variables (full access and controlled by the user)
- TG OCIO preset with OCIO folders within TG install folder, (user will leave it alone, TG offers presets from that folder)
- gamma option still available

This would also help with rendering on other machines without access to system folders/settings.

[digitalguru]

But if you're rendering to OpenExr it wouldn't matter anyway as the ACES won't be baked in. So long as you've set up the scene viewing under OCIO it will be ok.

If the OCIO config is different on the rendering computer then it does matter. There is a colour space for reading 8-bit textures and sRGB colour parameters, and a transform from this space to the linear render space.

Ah yes, good point