Colorspace error in Nuke 13.2

[vivimage]

Is there an existing issue for this?

• I have searched the existing issues and added correct labels.

Description

Current Behavior

A concise description of what you're experiencing.

Traceback (most recent call last):
  File "/studio/tools/nuke/nuke13.2/plugins/nuke_internal/callbacks.py", line 72, in onCreate
    _doCallbacks(onCreates)
  File "/studio/tools/nuke/nuke13.2/plugins/nuke_internal/callbacks.py", line 46, in _doCallbacks
    f[0](*f[1],**f[2])
  File "/home/ivanov/Documents/VSCodeProjects/ayon-docker/addons/nuke/ayon-nuke/client/ayon_nuke/api/lib.py", line 2037, in set_context_settings
    self.set_colorspace()
  File "/home/ivanov/Documents/VSCodeProjects/ayon-docker/addons/nuke/ayon-nuke/client/ayon_nuke/api/lib.py", line 1873, in set_colorspace
    self.set_viewers_colorspace(nuke_colorspace)
  File "/home/ivanov/Documents/VSCodeProjects/ayon-docker/addons/nuke/ayon-nuke/client/ayon_nuke/api/lib.py", line 1446, in set_viewers_colorspace
    if viewer_process not in v["viewerProcess"].value():
TypeError: 'in <string>' requires string as left operand, not NoneType

Expected Behavior

A concise description of what you expected to happen.

It should work as expected

Steps To Reproduce:

from ayon_nuke.api.colorspace import get_formatted_display_and_view
view_profile = {"view": "{context};sRGB","display": "{project_code};ACES"}
formatting_data = {"context": "01sh010","project_code": "proj01"}
display_and_view = get_formatted_display_and_view(view_profile, formatting_data)
print(display_and_view)

Run this code inside nuke 13.2

Additional context:

ayon-nuke/client/ayon_nuke/api/colorspace.py

Line 186 in 2c525a8

view.strip(), display.strip(), path_like=False

If in this line

create_viewer_profile_string(
                    view.strip(), display.strip(), path_like=False
                )

change to path_like=True

it works without error

Relevant log output:

[jakubjezek001]

Thank you for reporting the issue. We might be looking into it at some point but for now no client was reporting the issue. I would like to encourage you to create PullRequest with the fix if you are having it solved.

[ralphmeijerambassadors]

Did you ever managed solve this issues? We are running into the same issue. I'm suspecting it has something to do with how the color transforms are configured in the settings but I wasn't successful to find the issue so far.

[BigRoy]

@ralphmeijerambassadors The issue description describes in "Additional Context" how @vivimage ended up fixing it. Any chance you can confirm the relevant change?

I also saw this PR the other day #60 which also influences how colorspaces from Nuke are parsed and collected and may be relevant to issues in this area too.

However, aside of the community reports here I haven't heard much others about issues in this area so more knowledge on how to reproduce it exactly is more than welcome. In this case @vivimage seems to describe it's Nuke 13.2 specific?

[ralphmeijerambassadors]

I digged a bit further and it was what I expected. I configured the viewer with the wrong transform. It's a bit trial and error to find the right names but I managed to fix it. Thanks!

[BigRoy]

I digged a bit further and it was what I expected. I configured the viewer with the wrong transform. It's a bit trial and error to find the right names but I managed to fix it. Thanks!

For completeness sake (and me not knowing anything about Nuke or the Nuke integration). Could you clarify where you tweaked that and how did you find it?

Is it something that should be captured differently in the code and could e.g. be auto-fixed or logged with more clarity? If so, details would be greatly appreciated.

[ralphmeijerambassadors]

I filled in the correct transform in the Nuke settings:

I guess having a dropdown based on your ocio would solve the issues for getting the correct names and formatting. I think I've seen another post related to this where a developer explained that might be a harder than it seems since the ocio needs to be parsed with the correct names. I don't think it's impossible though.

[BigRoy]

Thanks!

I guess having a dropdown based on your ocio would solve the issues for getting the correct names and formatting. I think I've seen another post related to this where a developer explained that might be a harder than it seems since the ocio needs to be parsed with the correct names. I don't think it's impossible though.

The trickiest bit here is that the OCIO file may live on your network share or on your machine - but not on the AYON server (which may be in a very different location or network) and hence it cannot parse such a file to display the info needed. Unless the OCIO woud always be server from the server itself, or we 'attach' it manually in some other way but that is also not fool proof unfortunately.

However if this is what causes that issue I think we should definitely work towards generating a much better error log, etc.

[jakubjezek001]

I was just testing the issue at latest ayon-nuke 0.3.1+dev and all seems to be working as expected