OCIO 2 linear-sRGB VFX Workflow Advice

Discussions - Using ACES
,
1

Hello,
Apologies if this is a poor place for this post as it focuses on questions for a linear-sRGB color management workflow (for VFX) instead of ACES, but it is based around OCIO.

In the case of working with a linear-srgb color management workflow with OCIO 2, how should one navigate it? OCIO 1 released the spi-vfx, spi-ani, and nuke-default (OpenColorIO-Configs/config.ocio at master · colour-science/OpenColorIO-Configs · GitHub) which from what I can tell are based around linear-srgb CMWs. I also found the filmic blender config, which is also built on OCIO 1. Because of the backwards compatibility I know I can use any of these configs with OCIO 2, but I don’t know if they are the right choice.

The only prebuilt configs for OCIO 2 that I have found are the ones from Releases · AcademySoftwareFoundation/OpenColorIO-Config-ACES · GitHub, which focus around ACES, and the modified ones that ship with software like Maya 2023. In the case of the cg-config-v1.0.0_aces-v1.3_ocio-v2.0 , it does contain a linear sRGB profile with Linear Rec.709 (sRGB) , and then of course the sRGB - Texture colorspace. However, there is no sRGB gamut space with a log gamma to be used in the role of compositing_log or color_timing . Additionally, when loading this config into Maya and setting Linear Rec.709 (sRGB) to my working/rendering space, I get an error message from V-Ray saying “Unsupported rendering color space linear rec.709 (srgb)”.

The OCIO 2 config that ships with Maya 2023 doesn’t have this issue with V-Ray with their scene-linear Rec.709-sRGB space used as the rendering space, and it does have non-ACES log colorspaces (Although only the Log Film Scan ADX10 space works when I use the Maya config in a software besides Maya). However, when it comes to tone-mapping/applying a view transform, I initially thought untonemapped was correct but after learning some more I’ve heard that in linear-srgb tonemapping is for sure correct so that when turning down light intensities your scene doesn’t “lose energy” (“1D lut example” section from Chapter 1: Color Management - Chris Brejon). With this config, the views that seem to be meant for final images are ACES 1.0 SDR Video and one meant to reproduce the look of Unity’s tonemapping (Help). In a linear-srgb workflow it doesn’t really make sense to me to use a view transform intended for ACES, and the tonemap from Unity seems like an random arbitrary choice to make for tonemapping.

Overall though, it seems difficult to use the OCIO 2 configs that I’ve mentioned with a linear-sRGB workflow. I have seen good things with the Filmic Blender config, but the fact that it is an OCIO 1.0 config throws me off slightly. Even though there is backwards compatibility, I feel like I should be trying to use a current workflow, but let me know if that worry is unfounded.

I’m wondering if a good solution is to author my own OCIO 2.0 linear-sRGB config, but I don’t really know how I’d navigate doing that in terms of getting the correct transforms. However, I think all that I would need in terms of colorspaces is linear-sRGB, sRGB - Texture, Output - sRGB (inverse view transform), some sort of log colorspace for the compositing_log and color_timing roles, and a view transform with tonemapping. I would also be worried about getting error messages in V-Ray with my linear-sRGB rendering space like I did when I tried to use it as the rendering space from the cg-config-v1.0.0_aces-v1.3_ocio-v2.0 .

What advice do you have for navigating using a linear-sRGB color management workflow with OCIO 2?

2

The big difference between v1 and v2 OCIO is that v1 uses LUTs and v2 uses builtin analytical transforms.

As far as a linear-sRGB workflow you mention the working space, and the output transform. You definitely want tonemapping on the output. A great read on why this is important is Jeremy Selan’s 2012 VES White Paper entitled Cinematic Color: From Your Monitor to the Big Screen. To do physically based rendering we need to see the render in the way a camera sees a scene, which is through an s-shaped tone curve. Otherwise, when values clip as soon as they go over 1 (as they do with an sRGB gamma curve like the one applied in the native viewer for Nuke, as well as in versions of Maya prior to v2022) this leads artists to compensate by making the lights and shader colors unnaturally dim so they don’t get unwanted clipping. Making the lights unnaturally dim causes many things in the render (GI bounce, etc.) to not work properly because the light values are not realistic, meaning the physically based render is not being given physically based light values.

With tone mapping, rather than the artist needing to compensate and fight with the render, they can give their lights real-world values and the physically-based rendering gets the right amount of light to do its stuff like GI bounces. It also means that things in comp like optical effects (bokeh, motion blur, depth of field, bloom, atmospherics) also work properly because they are given the proper light values. In short, it makes the render behave more like a photo camera so artists can get photorealistic renders.

It sounds tho like what you are really wanting to change is not the Output Transform and tonemapping, but rather the working space of ACES from ACEScg to linear-sRGB. I’d be curious to understand why you want to do that? Could you say more about the motivation behind this? I believe @ChrisBrejon has made some arguments for doing that, so perhaps he can chime in here as well.

3

Why is it important for you to use a OCIO v2 config over a v1 config?
Yes, “Filmic” is a OCIOv1 config that does not work with Nuke 13/14 anymore for example, but there is the newer “AgX” OCIO v2 config that does.

Not long ago I was comparing a linear-sRGB rendering with different view transforms in my blog. 3.5. One Scene – many images – Brylka – TooDee – PanicPost

I compared STANDARD SRGB, BLENDER FILMIC, AGX, OPEN-DRT AND T-CAM and also the already old first three test candidates A,B, C for ACES 2.0.

I like to jump between between linear-sRGB and ACEScg in the experiments that I do. I find it useful to better understand the pros and cons of each working colourspace.

What is your default view transform that you use or want to use for your projects?

4

@Derek thank you for all of the helpful information, and correct, I want to develop a workflow with linear-sRGB as the working space. My reason for doing so is to develop diversity in my understanding of color management, as in Chris Brejon’s blog he has pointed out some instances where ACES (in fairness, subjectively) produces images that end up not looking as good as images produced in Lin srgb, to quote “I cannot honestly say one color space is better than the other. They give different results and ACEScg is closer to spectral rendering” (from lower on this page: OCIO, Display Transforms and Misconceptions - Chris Brejon). Essentially, I want to be able to work confidently in both color spaces, similarly to what @TooDee mentioned about doing experiments between the two to understand their pros and cons.

@TooDee , the reason I think that I want to (but I am not knowledgeable enough to know whether or not it is a valid concern) work with an OCIO 2 config for Lin-sRGB is because it is more modern, and @Derek ‘s mentioning of v2 Configs using “built in analytical transforms” over LUTs sounds as though it would be a more “precise” workflow. I was not formerly aware of AgX, but it seems like a good candidate based on it being OCIO 2, and in your tests I liked the way that the image looks. Correct me if I’m wrong, but since all of the images you used had a linear srgb working space, and the configs you compared are linear sRGB based, is the major difference between them just the view transform? If that is the case, then I the answer to your question for which view transform I’d like to use is probably AgX. I do like the look of filmic blender, but I was not aware that it didn’t work with Nuke 13/14 (why is this the case?), and as I mentioned would prefer an OCIO 2 based config.

Thanks to you both, looking forward to learning more from you.

5

Hopefully someone can correct me if I muck this up, but I’m thinking you could get sRGB-linear to be the working space just with a matrix transform. The ACEScg color space in a OCIOv2 config is a matrix transform going from ACEScg to AP0:

- !<ColorSpace>
    name: ACEScg
    family: ACES
    description: |
      ACEScg working space
    isdata: false
    categories: [ file-io, working-space, basic-3d, advanced-3d, basic-2d, advanced-2d ]
    encoding: scene-linear
    to_scene_reference: !<MatrixTransform> {matrix: [ 0.695452241357, 0.140678696470, 0.163869062172, 0, 0.044794563372, 0.859671118456, 0.095534318172, 0, -0.005525882558, 0.004025210306, 1.001500672252, 0, 0, 0, 0, 1 ]}

Using this handy tool from @Thomas_Mansencal you could get the matrix for Linear Rec.709 (sRGB) to AP0 and make it into your working sRGB linear color space:

  - !<ColorSpace>
    name: sRGB Linear
    aliases: []
    family: Utility
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Convert from sRGB to Linear ACES2065-1
    isdata: false
    encoding: scene-linear
    allocation: uniform
    from_scene_reference: !<GroupTransform>
      name: sRGB to Linear ACES2065-1
      children:
        - !<MatrixTransform> {matrix: [0.4392881394, 0.3821871003, 0.1785724518, 0.0000000000, 0.0901044212, 0.8142801792, 0.0955885379, 0.0000000000, 0.0176580256, 0.1088646254, 0.8734242981, 0.0000000000, 0.0000000000, 0.0000000000, 0.0000000000, 1.0000000000]}

Then you would redefine the appropriate roles to use that linear sRGB color space:

compositing_linear: sRGB Linear
rendering: sRGB Linear
scene_linear: sRGB Linear

Note, I have not tested the above.

6

Hello,

Sorry for the late reply. Got buried under work.

You should be able to set the working space of your OCIO config by simply setting the role “scene_linear” to whatever colorspace you wish. You can do that in a simple text editor, such as notepad.

When I wrote back in the day (two years ago ?) that we switched our working space to “lin_srgb” , the motivation was simple : avoid clipping at all cost. But I have also teached and worked in several studios where their choice was different and went for “ACEScg” as a working space.

Furthermore, I would not choose a color management workflow based on if it is supported by OCIOv1 or OCIOv2. I would pick it mostly based on the quality of their picture formation. Under this lens, AgX and TCAM are very good contenders. Even Filmic is a very good option in my opinion.

I know a few studios that are stuck with OCIOv1 because of Rv. But we have worked relatively well with OCIOv1 for many years (and still do!).

About the Filmic OCIO config not working in Nuke 13 and 14, I am pretty sure that we should be able to modify the config in order to do so. Anyway the integration of OCIO in Nuke is arguably improvable.

I hope that helps a bit @conlen . As always the best is to test yourself and see what best suits your needs. I generally take a couple of weeks at the beginning of a project to choose the CMW.

Regards,
Chris

2 Likes
7

Hi Derek,
Don’t know of any other way to contact you so asking here, but I found your StudioX ACES configs and have a question. In your config, you have “Shot Looks” using LUTs. I see you are using environment variables for the shot look path and lut, which I have not encountered with OCIO yet. Is there a way to affect this environment variable outside of the config so you can use a single .ocio file for a project with multiple shots, or do you need a copy of the .ocio file with the LUT_NAME line modified for every single shot of the project?

8

Those are called context variables. I’m using these in a fairly simple way that is not connected to environment variables, but rather declares the context variables directly in the config. We then would have a per-show config for shows that have a show look. Otherwise we use the global ACES config. Artists define the OCIO environment variable, which by default is set to point to the global config, to instead point to that show-specific config.

It’s possible however to do per-shot luts with fall backs. In that case you would use the context variables together with environment variables for the shot like in this example. Another option would be to have a show look in a config (as I explained above), and shot grades as ASC-CDL files that one could just apply in Nuke with an OCIO CDL node. YMMV.

Let me also add that for OCIO specific questions, a great resource is the listserver https://lists.aswf.io/groups

1 Like
9

Thanks Derek! I hadn’t heard of lists before, I joined it.