Sent to support but amplifying for visibility here. ACES 2.0 is broken in Houdini (and Mplay) - it appears there a double transform in the viewers when using OCIO. This has been confirmed by the Redshift devs.

Is there a fix coming soon?

thanks

RT_SD
Sent to support but amplifying for visibility here. ACES 2.0 is broken in Houdini (and Mplay) - it appears there a double transform in the viewers when using OCIO. This has been confirmed by the Redshift devs.

Is there a fix coming soon?

thanks

I've reported this bug in November and no news ...

Not a good sign

Is that the reason a color looks different on my setup than it does in a tutorial video, even though I'm using the exact same RGB values as the author? I was thinking it was because of YouTube conversions, but maybe not. Here's a screen shot comparing my setup and the video (video is on the right).

makrotius
Is that the reason a color looks different on my setup than it does in a tutorial video, even though I'm using the exact same RGB values as the author? I was thinking it was because of YouTube conversions, but maybe not. Here's a screen shot comparing my setup and the video (video is on the right).

Not at all.

Your screen shots show two different color management systems in use. On the left, an OCIO config (most likely an ocio v1 config), and unmanaged color with 2.2 viewing gamma. The difference in view transforms is what causes a difference in appearance.

I'm not super up on ACES, but when using the Redshift provided config.ocio with Houdini, MPlay doesn't seem to work with it.

The Redshift Render View seems fine.

Unsure if it's directly related, but here's what I see with Houdini 19.0.498:

caldera
The Redshift Render View seems fine.

Unsure if it's directly related, but here's what I see with Houdini 19.0.498:

It's a 2.0 config. Houdini seems to support 2.0 configs partially, but builtin tone maps appear to be not functional. Basic gamma transforms such as part of the piecewise sRGB EOTF are totally wrong too, showing a very mushy curve toe, as if some kind of low res lut is being used instead of an actually piecewise gamma function.

I would stick with a 1.0 config such as aces 1.2 or 1.0.3 from the Academy.

jsmack

caldera
The Redshift Render View seems fine.

Unsure if it's directly related, but here's what I see with Houdini 19.0.498:

It's a 2.0 config. Houdini seems to support 2.0 configs partially, but builtin tone maps appear to be not functional. Basic gamma transforms such as part of the piecewise sRGB EOTF are totally wrong too, showing a very mushy curve toe, as if some kind of low res lut is being used instead of an actually piecewise gamma function.

I would stick with a 1.0 config such as aces 1.2 or 1.0.3 from the Academy.

The problem with this is Redshift uses ACES 2.0 by defualt now and there are issues mixing ACES configs. Why would you do that? Because most renderfarms will be using a redshift plugin default of ACES 2.0 (and IDK if there's any facility for you to use a custom ocio.config on a farm?). Took me forever to figure this out, but if I create a scene with ACES 1.2 and load it in a houdini environment using 2.0, you get errors on the camera node which has the ocio custom params.

Otherwise I'd just switch back to 1.2. But then I remove the option to send my scenes to a farm if production demands. Honestly the whole ACES situation is a mess. It's great if you run a completely closed system, but for small operations it's bad news.

I am a bit confused by the use of 'ACES 2.0'. If I am not mistaken there is no 2.0 version of ACES available at this point.

I think there is some mix-up of OCIO 2.0 and ACES 2.0 here

AslakKS
I think there is some mix-up of OCIO 2.0 and ACES 2.0 here

I always think of them interchageably, not helped by the fact I'd just read abbout 2.0 on ACES Central. I meant OCIO 2.0

RT_SD

AslakKS
I think there is some mix-up of OCIO 2.0 and ACES 2.0 here

I always think of them interchageably, not helped by the fact I'd just read abbout 2.0 on ACES Central. I meant OCIO 2.0

I don't find any official OCIO 2.0 ACES config. The only one I see is a demo v2 config from OCIO. Perhaps Redshift jumped the gun on releasing their OCIO 2 config, users a bound to mistake it for something authoritative.

https://opencolorio.readthedocs.io/en/latest/upgrading_v2/how_to.html#new-operators-to-support-aces [opencolorio.readthedocs.io]

There's an OCIO v2.1 config generation package on the academy github, but it doesn't seem finished.

https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES [github.com]

RT_SD
The problem with this is Redshift uses ACES 2.0 by defualt now and there are issues mixing ACES configs. Why would you do that? Because most renderfarms will be using a redshift plugin default of ACES 2.0 (and IDK if there's any facility for you to use a custom ocio.config on a farm?). Took me forever to figure this out, but if I create a scene with ACES 1.2 and load it in a houdini environment using 2.0, you get errors on the camera node which has the ocio custom params.

There's no reason to be forced to use the config out of the box. Studios have their own color pipelines and will use project or shot specific configs. Using the same config on the farm as on the workstation should be considered a requirement. It's also trivial since the config is set using an environment variable. You wouldn't use different versions of software on the farm, the environment should not be different either.

@jsmack @RT_SD thanks for the details!

It does seem the 2.0 situation isn't ideal...

I tried out the aces_1.2 config.ocio from the OpenColorIO Github and both MPlay and Redshift Render View are showing the same thing now, so that's enough to get me going.

Very much appreciated!

jsmack
Using the same config on the farm as on the workstation should be considered a requirement.

This is the entire point. If you have the resources to have a complete pipeline and farm in house, its a non-issue, use whatever config you want. But some of us indies need the flexibility to use 3rd party renderfarm services. That means sticking with the default RS ocio, which Houdini doesn't fully support. I'm not forced to but I'm shooting myself in the foot if I don't.

There is an official pre-release OCIO ACES config available from the Academy software foundation github (https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/releases)

But this is a technical reference configuration, not meant for use in production by artists. Opencolorio.org mentions an "official" OCIOv2 config is being worked on.
Though, as Autodesk led the design and development of OCIOv2, we may conclude the config shipping with Maya 2022 is according to spec... So if Maya, Redshift, Arnold are all giving similar results, and Solaris and MPlay are different...

Have been playing a bit with the Maya OCIOv2 config in Houdini and Redshift. It seems with this config MPlay matches the RS render view quite well apart from the tone mapping view transform. So with display set to sRGB and view to Un-tone-mapped, they match, with view set to ACES 1.0 SDR video, the Redshift render view clearly tone maps the image, MPlay doesn't do a thing. The log and raw views do work in Mplay.
In the OCIO config, the ACES 1.0 SDR video tone map is using a builtInTransform with a style setting. It seems this is not working correctly with MPlay.

After working this out with the Maya config, I tried the Redshift config as well, and this seems to give the same results.
Tried it in Maya as well. The Maya render view is behaving the same as the Redshift render view, so it's definitely Houdini/MPlay behaving differently.

Attached two screenshots for the comparison.

Any news about OCIO?

naim
Any news about OCIO?

I think it's fixed now.

Yep, fixed earlier this month. I tested it and it's working fine.

BrianHanke
Yep, fixed earlier this month. I tested it and it's working fine.

Is it? It's not working here. Mplay and IPR editor view both still have incorrect colour with Redshift.

Actually, if you select an AOV in Redshift render view other than 'beauty', eg 'beauty_aux', that will also be displayed incorrectly. That's a bit weird.

H 19.0.657 & RS 3.5.04

Scratch that, it is working. I forgot that you still have to set up the $OCIO env variable poiting it to the RS config.ocio file. At least its working in IPR and Mplay. Still have this weird issue where RS Render view applies a double transform to AOVs when displaying them. I can live with that.