OCIO editor doesn't save state with custom config

   1358   12   0
User Avatar
Member
18 posts
Joined: Jan. 2016
Offline
this occurs in all h20 production builds for me (win11, up to h20.0.653):

I am using this OCIO config here:
https://github.com/Joegenco/PixelManager [github.com]

whilst all view transforms seem to get recognized in the OCIO editor, changing the the view transforms however has no effect and the OCIO editor does not save the state of the view transform drop down. (so when restarting houdini the view transform remains on standard (which looks identical to un-tonemapped))

for what it's worth, this happens both when pointing houdini to the OCIO config through an env variable and/or when adding the path to the houdini.env

the build in ACES config works as expected
do I need to modify the config above to make it work in houdini? any hint will be much appreciated
thanks!
User Avatar
Member
8034 posts
Joined: Sept. 2011
Offline
janjansen
this occurs in all h20 production builds for me (win11, up to h20.0.653):

I am using this OCIO config here:
https://github.com/Joegenco/PixelManager [github.com]

whilst all view transforms seem to get recognized in the OCIO editor, changing the the view transforms however has no effect and the OCIO editor does not save the state of the view transform drop down. (so when restarting houdini the view transform remains on standard (which looks identical to un-tonemapped))

for what it's worth, this happens both when pointing houdini to the OCIO config through an env variable and/or when adding the path to the houdini.env

the build in ACES config works as expected
do I need to modify the config above to make it work in houdini? any hint will be much appreciated
thanks!

It's kind of a 1.0 style config, no display colorspaces, no view transforms. The OCIO gui is designed for ocio 2.1 configs so maybe that's why it doesn't work. The viewport should respect the default view if defined in the config, try adding that manually.
eg:
default_view_transform: Un-tone-mapped
Edited by jsmack - March 27, 2024 18:43:41
User Avatar
Member
18 posts
Joined: Jan. 2016
Offline
thank you, can you elaborate a bit please?
the default seems the standard (un-tonemapped), I'd like to use TCAMv2. so the drop down is set to standard (without being able to have houdini recall changes to it) (all intended view transforms are available in the drop down)

where should I add this line to?

edit2: default_view_transform: TCAMv2
^ this line actually got added by the OCIO editor, houdini just doesn't take it into account
Edited by janjansen - March 27, 2024 18:52:51
User Avatar
Member
8034 posts
Joined: Sept. 2011
Offline
janjansen
thank you, can you elaborate a bit please?
the default seems the standard (un-tonemapped), I'd like to use TCAMv2. so the drop down is set to standard (without being able to have houdini recall changes to it) (all intended view transforms are available in the drop down)

where should I add this line to?

edit2: default_view_transform: TCAMv2
^ this line actually got added by the OCIO editor, houdini just doesn't take it into account

Hmm, it might be due to the config not using view transforms. Every display-view combination instead uses a discrete color space. The new style of config defines display colorspaces separately from view transforms. Normally it shouldn't matter when selecting a view but maybe Houdini is doing something differently.
User Avatar
Member
18 posts
Joined: Jan. 2016
Offline
I see (and I don't),

is there an easy, layman friendly way of either converting this existing config to ociov2, or to weave in the TCAMv2 transform into the built-in one?

thanks for your input anyway, cheers
User Avatar
Member
18 posts
Joined: Jan. 2016
Offline
to open this can of worms even wider, a bunch of questions here.

- houdini creates its own (ocio v2.1) config and places it in C:\Users\<my_user>\Documents\houdini20.0\ocio after editing it in OCIO editor, correct?

- if the above is correct, I do see view transforms and display colourspaces separately...

i understand its a big topic, but is there a houdini doc to read up on this?
does anybody on here have a config utilizing TCAMv2 and is willing to share?

I am really confused by the multiple ways these configs get read. which config is the one that is ultimately sourced in houdini? It doesn't appear to be the one in the OCIO system variable

thanks
User Avatar
Member
18 posts
Joined: Jan. 2016
Offline
I am guessing this is some kind of houdini bug(?) - or some clunky behavior in how to deal with old OCIO configs

- I now disabled my sys env variable
- copied the relevant cube files into this directory C:\Users\<my_user>\Documents\houdini20.0\ocio (same path i now see the houdini-made OCIO getting sourced from) and it all works. only problem I now have is that my OCIO for houdini isn't getting used system wide but rather only for houdini

- remaining question: is houdini able to deal with the look (!<Look>) CDL transforms in the viewport somehow?
- be great to read up how it's intended to work (and expected to be set up)

thanks all
User Avatar
Member
8034 posts
Joined: Sept. 2011
Offline
janjansen
is there an easy, layman friendly way of either converting this existing config to ociov2, or to weave in the TCAMv2 transform into the built-in one?

It's not trivial, the config would have to be redesigned.

janjansen
- houdini creates its own (ocio v2.1) config and places it in C:\Users\<my_user>\Documents\houdini20.0\ocio after editing it in OCIO editor, correct?

correct, the editor uses this location by default to save the edited config. Houdini is directed to use this config via a package file--this possibly overrides any preexisting environment variable defined location.
User Avatar
Member
18 posts
Joined: Jan. 2016
Offline
jsmack
It's not trivial, the config would have to be redesigned.
looks like houdini does indeed do that work for me


jsmack
correct, the editor uses this location by default to save the edited config. Houdini is directed to use this config via a package file--this possibly overrides any preexisting environment variable defined location.


thanks much for your input, i def learned something along the way. my take is now that houdini keeps converting the v1 OCIO I have in the sys env upon start up and thus overwrites whatever display transform I chose every time.
(I could probably use the houdini generated config now and copy it back to my sys env location to verify)

thanks again!
Edited by janjansen - March 27, 2024 21:07:07
User Avatar
Member
8034 posts
Joined: Sept. 2011
Offline
I downloaded that config and manually added the default view line and then put the path to the config in the ocio.json package, and I'm seeing the tcamv2 view preselected in the viewport on startup. Is that not what you see?
User Avatar
Member
18 posts
Joined: Jan. 2016
Offline
jsmack
I downloaded that config and manually added the default view line and then put the path to the config in the ocio.json package, and I'm seeing the tcamv2 view preselected in the viewport on startup. Is that not what you see?
I went 2 ways
- initially added the path to the config to the houdini.env file
- then tried the same path through as the OCIO varibale through a sys env variable
both ways led to the config being read, but left me unable to change the default view transform (it did add the default part to the (houdini created) config however but restarting houdini removed/changed it again for some reason). so removing the variable before restarting houdini was 'a' solution for the time being
guess i could try going through the ocio.json file instead - thanks again for your input!
Edited by janjansen - March 28, 2024 17:17:46
User Avatar
Member
15 posts
Joined: Dec. 2018
Offline
janjansen
jsmack
I downloaded that config and manually added the default view line and then put the path to the config in the ocio.json package, and I'm seeing the tcamv2 view preselected in the viewport on startup. Is that not what you see?
I went 2 ways
- initially added the path to the config to the houdini.env file
- then tried the same path through as the OCIO varibale through a sys env variable
both ways led to the config being read, but left me unable to change the default view transform (it did add the default part to the (houdini created) config however but restarting houdini removed/changed it again for some reason). so removing the variable before restarting houdini was 'a' solution for the time being
guess i could try going through the ocio.json file instead - thanks again for your input!


Have you managed to set it up correctly? Deleting before restart allows you to maintain the settings but highlights look completely clamped in the viewport.
User Avatar
Member
18 posts
Joined: Jan. 2016
Offline
EdganHomt
Have you managed to set it up correctly? Deleting before restart allows you to maintain the settings but highlights look completely clamped in the viewport.

I got the config to work eventually and am pointing straight to the config (rather than through a sys var) - Houdini does not save the default however and I never got to the bottom of it. would love to hear what I could be doing wrong
  • Quick Links