OCIO profiles are still mostly non-functional in the latest cut of 16.0. Only transforms without looks seem to work, and even then only sometimes, such as mplay being somewhat broken. As all production displays will contain looks, the implementation is not usable in it's current state. Is OCIO planned to be usable in 16.0, or only in a future version?

Until then, is there a way to disable the OCIO profile being referenced? I would rather that the LUT exported by the environment be used. It seems that the exported OCIO path takes precedence.

Thanks,

Jonathan Mack

This is also a continuing issue for us. We also submitted issues with views + looks and the result was sadly:

Houdini 16.0.544 OpenColorIO support in MPlay has been changed to beta due to some critical missing features. Beta status will be removed once these features are addressed.

No word on when things might be improved. It sounds like it is still an issue in that SESI is not able to determine what should be happening due to a lack of any reference documentation. We've had to sadly resort to resuming our usage of baked LUTs since as you mentioned, a lack of looks is not acceptable in production.

Hopefully this can be addressed ASAP as OCIO support has always been the #1 requested feature from a studio perspective for as long as I can remember.

Edit:

To disable all the OCIO stuff in Mplay I think you need to ensure you have none of the OCIO env variables set. If you do then it attempts to open up with those (which also causes weird results of you have HOUDINI_IMAGE_DISPLAY_* vars set)

I discovered a hacky work around. If you make a new color space with your look transforms, you can make a view with that bogus space as the destination. As for setting the houdini environment to not export OCIO, this difficult, as tools that exist in the hou environment might rely on ocio. I'll have to figure something hout.

Look support has been added in build 550 for MPlay. The VEX functions still need this to be added, as Looks are specified on Views and the VEX function takes colorspace names.

Unfortunately the OpenColorIO.org samples don't include any Looks, so we completely missed this one.

H16 OpenColorIO support remains in beta, until we're satisfied that it's meeting users' needs.

I'm only using ACES views right now and I'm pretty happy that it's there at all.

Some functions that spit out XYZ color can now be converted to ACES, so that alone is an improvement.

is it still in beta?

Hi there,

is there any chance to change OCIO config interactively in running Houdini? What is actual implementation of OCIO in current version (roles,looks etc). Is used OCIO config saved along with scene?

Thank you

Ales

h17aup
is there any chance to change OCIO config interactively in running Houdini?

Not currently. It's entirely controlled by the OCIO environment variable(s) (along with OCIO_ACTIVE_DISPLAYS and OCIO_ACTIVE_VIEWS).

What is actual implementation of OCIO in current version (roles,looks etc).

The viewers convert from the scene_linear role to the specified Display/View. If a look is part of that transform, it will be applied. The OCIO Transform VOP is used in shading and supports roles, as well as colorspaces. I'm unsure if it supports looks.

Is used OCIO config saved along with scene?

No. From what I've gathered from most OCIO workflows is that this should be entirely controlled by the OCIO environment variables, and not saved in the scene itself.

The next major version of Houdini has some improvements to the OCIO workflow, including expanded support for OCIO in color display in Houdini, and applying colorspace transforms when loading image files.

twod
The next major version of Houdini has some improvements to the OCIO workflow

Will there be support in scene viewers and ocio displays with looks? When flipbooking/opengl rop is used, there currently isn't any control over the display used. Will this be controllable in the future? In the past I have had to disable OCIO in order to flipbook in controllable way, resorting to external software to apply the look and transform from linear to the display space.

twod
No. From what I've gathered from most OCIO workflows is that this should be entirely controlled by the OCIO environment variables, and not saved in the scene itself.

This is done larger facilities, per job, but what is very useful in smaller places, without an IT department, is that we can set it via a path per file. i.e. Nuke has a Project Settings path for ‘custom OCIO config’. So all the artists just load in the current config file.

Is used OCIO config saved along with scene?

No. From what I've gathered from most OCIO workflows is that this should be entirely controlled by the OCIO environment variables, and not saved in the scene itself.

The next major version of Houdini has some improvements to the OCIO workflow, including expanded support for OCIO in color display in Houdini, and applying colorspace transforms when loading image files.


That could be little bit problematic. If you set your OCIO file on worker machine and he will use eg. OCIO_transform node for texture input then you have to take care also same OCIO setup on the render farm otherwise it will render wrong result. Even Nuke is saving used OCIO config inside script to render same on color un-managed computers.

I would love to hear how larger facilities are solving this.

Also I've take a look on latest version of Houdini. Source color space in Texture node still has only two options Automatic and Linear. Are you planning to propagate OCIO defined color spaces there?