[OCIO] increase compatibility with Redshift.

Question

[OCIO] increase compatibility with Redshift.

Closed this issue 2 years ago · 6 comments

Update

A thread has been opened on the Redshift forum

https://redshift.maxon.net/topic/44651/ocio-colorspace-discovering-process-is-too-obscure

Original issue

(Info initally provided by Saul Espinoza)
When parsing config, Redshift will be looking for the "sRGB EOTF" colorspace to perform some transformations when needed.
The discovery process is hardcoded and not very clear yet but seems you need a colorspace named with at least "sRGB" in the name
and then a specific transform. (probably does a regex on values or on transform name ?)
Saul recommended to try first the true EOTF with

- !<ExponentWithLinearTransform> {gamma: 2.4, offset: 0.055, direction: inverse}

But let's also try the power function to see if its looking for the ExponentTransform or for the "2.4" value.

-!<ExponentTransform> { value: [ 2.2, 2.2, 2.2, 1 ], direction: inverse }

Answer 1 · 2022-10-27T20:29:03.000Z

Trying to reproduce the error in katana.
Even with the proper color space setup[ on the RedshiftRenderSetting I got some errors.

Error message related seems to be :

[INFO plugins.Redshift]: Loading OCIO config using .\ocio\config.ocio
[INFO plugins.Redshift]: 	OCIO env var defined. Using it instead
[INFO plugins.Redshift]: 	Full path: .\ocio\config.ocio
[INFO plugins.Redshift]: 	Ok
[INFO plugins.Redshift]: Creating OCIO processors between rendering and view/srgb spaces
[INFO plugins.Redshift]: 	Rendering space: Linear sRGB
[INFO plugins.Redshift]: 	Display: sRGB
[INFO plugins.Redshift]: 	View: AgX Punchy
[WARN plugins.Redshift]: 	Failed to find a suitable sRGB color space in config!
[INFO plugins.Redshift]: 		Proxies with textures in 'sRGB' color space may not render correctly.
[INFO plugins.Redshift]: 		Physical sun/sky, black-body and hair shaders may not render correctly.
[WARN plugins.Redshift]: 	Failed to create rendering to sRGB processor
[INFO plugins.Redshift]: Loading OCIO color space transforms for texture sampling
[INFO plugins.Redshift]: 	Unable to find a suitable sRGB-linear color space. Common texture linear color space will be: "Linear sRGB"
[INFO plugins.Redshift]: Render command finished. Returning to Katana a non-zero render result.

But not sure it's the error message mentioned by Saul, seems like something else.

Answer 2 · 2022-10-29T12:29:56.000Z

Manage to reproduce the issue in C4D 2023 :

Steps

Set OCIO var with config
Open C4d
RenderSettings > Renderer > Redshift
Add new light > Dome light
Small log window open mentioning an OCIO error, I then open the corresponding log file.

14:22:03   2581MB DEBUG: OCIO: Loaded Config 'Z:\packages-dev\AgXc\ocio\config.ocio'
14:22:03   2592MB ERROR: OCIO: Could not determine common color-spaces for config 'Z:\packages-dev\AgXc\ocio\config.ocio'
14:22:03   2594MB DEBUG: OCIO: Could not open OCIO config at ''

First fix

By adding the colorspace mentioned by Saul the error disappears:

In the config.ocio
Change OCIO version header to 2
Add the "sRGB - curve" colorspace :

  - !<ColorSpace>
   name: sRGB - Curve
   family: Displays/SDR
   equalitygroup: ""
   bitdepth: unknown
   description: sRGB - Curve
   isdata: false
   allocation: uniform
   from_scene_reference: !<GroupTransform>
     children:
       - !<ExponentWithLinearTransform> {gamma: 2.4, offset: 0.055, direction: inverse}
       - !<RangeTransform> {min_in_value: 0., min_out_value: 0., max_in_value: 1., max_out_value: 1.}

But this fix is only for v2 config and I must maintain v1 compatibility

Answer 3 · 2022-10-29T12:39:21.000Z

How Redshift detects the "sRGB" colorspace : RnD process

test-1

An interesting point is that the built-in RS config doesn't expose a colorspace with this transform. The sRGB colorspace is defined using a BuiltinTransform in a display_colorspace.

So here is what I added to AgXc:

view_transforms:

# needed to validate the config
- !<ViewTransform>
    name: Un-tone-mapped
    description: |
      Convert the scene colorimetry directly to display-referred with no tone-mapping.
      This is often described as a "linear workflow." It is intended only for diagnostic purposes.
    from_scene_reference: !<BuiltinTransform> {style: "UTILITY - ACES-AP0_to_CIE-XYZ-D65_BFD"}


display_colorspaces:

  - !<ColorSpace>
    name: sRGB
    family:
    description: |
      sRGB monitor (piecewise EOTF)
    isdata: false
    categories: [ file-io ]
    encoding: sdr-video
    from_display_reference: !<GroupTransform>
      children:
        - !<BuiltinTransform> {style: "DISPLAY - CIE-XYZ-D65_to_sRGB"}
        - !<RangeTransform> {min_in_value: 0., min_out_value: 0., max_in_value: 1., max_out_value: 1.}

But still not working tried to :

modify roles,
strict_parsing key
name: Redshift_3_0
super rminimal version with only 3 colorspaces

Nothing works, I don't understand how is the redshift config picked.

test-2

Another weird point, I tried the Substance Painter default config, and this one works fine, it's a v1 config where the sRGB colorspace use a simple FileTransform.

So I did tried to just copy their sRGB colorspace into AgXc and now it works!

  - !<ColorSpace>
    name: sRGB
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Standard RGB display color space
    isdata: false
    allocation: uniform
    allocationvars: [0, 1.125]
    to_reference: !<FileTransform> {src: srgb.spi1d, interpolation: linear}

So further test to determine why this is now working (tests in order) :

The LUT name doesn't seems to matter.
The name of the colorspace doesn't seems to matter ! (renamed to sbaba !? ), so perhaps it is using the roles ?
It still doesn't work with <ExponentTransform>
(bumping config version to 2)
It doesn't work with <ExponentWithLinearTransform> now (used directly, no group transform )??
It works with <ExponentWithLinearTransform> IF used in a GroupTransform
It doesn't work with !<BuiltinTransform> {style: "DISPLAY - CIE-XYZ-D65_to_sRGB"} (in group transform) ??
I renamed the colorspace to sbaba -> sRGB - testttt, still doesn't work.

Minimal working config

Upon testing this is the configs with the most basic setup that doesn't raise errors :

OCIO v1

OCIO: Reference ColorSpaces: LinearSRGB:'mango' SRGB:'pineapple' Raw:'coco'

ocio_profile_version: 1
environment: { }
search_path: LUTs
strictparsing: true

roles:
  color_picking: pineapple
  data: coco
  default: pineapple
  scene_linear: mango

displays:
  sRGB:
  - !<View> {name: Default, colorspace: pineapple}
  - !<View> {name: Disabled, colorspace: coco}


colorspaces:

  - !<ColorSpace>
    name: pineapple
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: sRGB
    isdata: false
    allocation: uniform
    allocationvars: [0, 1.125]
    to_reference: !<FileTransform> {src: baba.spi1d, interpolation: linear}

  - !<ColorSpace>
    name: mango
    family: Colorspaces
    equalitygroup: ""
    bitdepth: 32f
    description: Open Domain Linear BT.709 Tristimulus
    isdata: false
    allocation: lg2
    allocationvars: [ -10, 7, 0.0056065625 ]

  - !<ColorSpace>
    name: coco
    family: Colorspaces
    equalitygroup: scalar
    bitdepth: 32f
    description: Passthrough means no transformations. Also know as "raw".
    isdata: true
    allocation: uniform
    allocationvars: [0, 1]

OCIO v2:

ocio_profile_version: 2

search_path:

environment: {}

roles:
  color_picking: scene-linear Rec.709-sRGB
  data: coco
  default: sRGB
  scene_linear: scene-linear Rec.709-sRGB

shared_views:
  - !<View> {name: DefaultCoco, colorspace: coco}

displays:
  sRGB:
    - !<Views> [ DefaultCoco ]

view_transforms:

- !<ViewTransform>
    name: ROCK
    description: skip
    from_scene_reference: !<BuiltinTransform> {style: "UTILITY - ACES-AP0_to_CIE-XYZ-D65_BFD"}

display_colorspaces:

  - !<ColorSpace>
    name: sRGB
    family:
    description: |
      sRGB monitor (piecewise EOTF)
    isdata: false
    categories: [ file-io ]
    encoding: sdr-video
    from_display_reference: !<GroupTransform>
      children:
        - !<BuiltinTransform> {style: "DISPLAY - CIE-XYZ-D65_to_sRGB"}
        - !<RangeTransform> {min_in_value: 0., min_out_value: 0., max_in_value: 1., max_out_value: 1.}

colorspaces:

  - !<ColorSpace>
    name: scene-linear Rec.709-sRGB
    family:
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Scene-linear Rec.709 or sRGB primaries
    isdata: false
    categories: [ file-io, working-space ]
    encoding: scene-linear
    to_scene_reference: !<MatrixTransform> {matrix: [ 0.439632981919, 0.382988698152, 0.177378319929, 0, 0.089776442959, 0.813439428749, 0.096784128292, 0, 0.017541170383, 0.111546553302, 0.870912276314, 0, 0, 0, 0, 1 ]}

  - !<ColorSpace>
    name: coco
    family:
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Raw (no color processing)
    isdata: true
    categories: [ file-io ]
    encoding: data

Answer 4 · 2022-10-29T16:30:41.000Z

How Redshift detects the "sRGB" colorspace : Results

Redshift need 3 colorspaces to work : "LinearSRGB", "SRGB", "Raw"

config version does not matter (but affect which transforms you can use of course)
Roles matter for LinearSRGB and Raw, as you can see in the minimal working examples, colorspaces names doesn't matter but roles does.
For the sRGB colorspace, roles does not matter, still picked up if not mentioned in roles.
For the sRGB colorspace, the transform matters, picked transform are :
- <FileTransform> solo
- <ExponentWithLinearTransform> {gamma: 2.4, ...} IF only in a GroupTransform (gamma value matter)

Answer 5 · 2022-10-30T09:53:56.000Z

Try you to make a look into the shipped OCIO files for Blender addon to see how a custom config is adapted to use in RS.

Answer 6 · 2022-10-30T09:58:16.000Z

Nice tip thanks ! Seems to be using the !<FileTransform> {src: srgb.spi1d, interpolation: linear} as in the substance config for the sRGB colorspace. So that make it clear why this transform is being used to identify the sRGB colorspace, because the Blender config has it.