ocio 2 issues

   1972   15   2
User Avatar
Member
51 posts
Joined: Aug. 2017
Online
Hi,

we are testing to move from ocio v1 to ocio v2(.1) - all aces - and find to have some issues with that in h20. Everything seems to work fine except rendering to disk (in solaris, karma cpu/xpu). Comparing in Nuke, the file written to disk has wrong colors. This is all on just one machine (so this can not be related to any farm issues).

The colors in the viewport are fine and they are also fine when rending to mplay.

Another (maybe unrelated) issue is that the cloner always has it's color wrong (also with ocio v1).

Anybody else having these issues?
User Avatar
Member
7935 posts
Joined: Sept. 2011
Offline
ronald_a
Hi,

we are testing to move from ocio v1 to ocio v2(.1) - all aces - and find to have some issues with that in h20. Everything seems to work fine except rendering to disk (in solaris, karma cpu/xpu). Comparing in Nuke, the file written to disk has wrong colors. This is all on just one machine (so this can not be related to any farm issues).

The colors in the viewport are fine and they are also fine when rending to mplay.

Another (maybe unrelated) issue is that the cloner always has it's color wrong (also with ocio v1).

Anybody else having these issues?

Ocio v2 defines file rules that impact the output colorspace. If the colors aren't matching nuke, then nuke is ignoring the rules (nuke doesn't obey any rules afaik), or the config contains the wrong rules.
User Avatar
Member
219 posts
Joined: Oct. 2015
Online
Hello, to continue what @jsmack said, yes ocio rules also impact output file, but you can also explicitly set ouput color space inside the "karmarendersettings" LOP node on "AOV's rendervar" tab.
User Avatar
Member
51 posts
Joined: Aug. 2017
Online
Hi @jsmack & @julca,

thanks for your input. My mistake was, that the rule for exr did not say ACEScg but rec709 (I believe this came from the standard houdini rules). What is still not working are the clones. The color there is still off (and off in another way than it was with the written exrs). Does that work for you, and if so, do you have any idea what might be wrong here?
User Avatar
Member
219 posts
Joined: Oct. 2015
Online
@ronald_a, do you have scene file + screenshots of what you want and what you have ?
And also a screenshot of your "OCIO editor". Perhaps it can help to help you
User Avatar
Member
51 posts
Joined: Aug. 2017
Online
@julca: sure thing. attached is the testscene with the colorchecker texture used, a screenshot of what should be /what is (top viewport is good, botton rendergallery from cloner not so much), and the ocio config this is based on. Btw. the ocio config is basically nuke's ocio v2.1 aces studio config with the addition of rules created with houdini, so there should be nothing special about that.

Attachments:
ocio_colormismatch_cloner.zip (235.0 KB)

User Avatar
Member
219 posts
Joined: Oct. 2015
Online
@ronald_a, It's works on my side after explicitly set "ACEScg" on "output color space" parameter inside the "karma render settings" node (cf. you modified scene). It override ocio settings for output.

Other option was to change your ocio profile to set correct color space that match with the kind (pattern/extension) of your output file (be carreful as it's also impact input file)
Take also care about the ouput render folders name that is used if a specific ocio pattern was found.

An "other way" was to set the pattern "ACEScg" on you your ouput file name, ex: "myBeautifullPicture_ACEScg.exr" and if "ACEScg" is already set to OCIO config as a pattern, it auto convert them to this space without doing it by override parameter.

Hope that help.
Edited by julca - Dec. 20, 2023 11:45:09

Attachments:
ocio_colormismatch_viewport_cloner_02.hiplc (760.0 KB)

User Avatar
Member
51 posts
Joined: Aug. 2017
Online
@julca: are you talking about the cloner issue here? It seems you are talking about rendering to disk which does work after setting the exr rule to acescg. But the cloner still does not show the correct colors (as shown in the image in the zip in my previous post).
User Avatar
Member
219 posts
Joined: Oct. 2015
Online
@ronald_a, sorry What do you mean by "cloner" ?
With render Gallery, color is matching on my side.

Attachments:
renderGallery.jpg (200.2 KB)

User Avatar
Member
51 posts
Joined: Aug. 2017
Online
Is that the rendering coming from a clone?
User Avatar
Member
219 posts
Joined: Oct. 2015
Online
ronald_a
Is that the rendering coming from a clone?
Arg ! no sorry I misunderstood this point . Tell me how you make a clone and I'll made a test on my side.

Edit : Ok I see, when I render in gallery in background, you're right color are wrong. Maybye a bug.
Edited by julca - Dec. 21, 2023 10:19:35
User Avatar
Member
51 posts
Joined: Aug. 2017
Online
well, in the clone panel create a clone, point it to the rendersettings lop and set it to xpu. this will render into rendergallery.
User Avatar
Member
219 posts
Joined: Oct. 2015
Online
ronald_a
well, in the clone panel create a clone, point it to the rendersettings lop and set it to xpu. this will render into rendergallery.
Yes, same as you, wrong color.. Bug ?
User Avatar
Member
51 posts
Joined: Aug. 2017
Online
yeah, most likely. I'll do an RFE
User Avatar
Member
2 posts
Joined: April 2020
Offline
I just ran into this same issue and it took me hours to figure it out. Labeling the OCIO Editor file rules as "Input File Rules" when they actually control both inputs and outputs is just bound to cause confusion especially since it's not mentioned in the H20 documentation either.
User Avatar
Staff
471 posts
Joined: June 2020
Offline
Having this thread pop up again gives me the chance to highlight that as of *20.0.587*, clone rendering and background rendering should now both receive the proper OCIO love and match the viewport and husk-based renders.
  • Quick Links