Hmm; I think this might leave me more confused than less.
jsmack
OCIO 2.1 changes out colorspaces are detected, so I'm not surprised you might see a change in how your input is treated.
...
Depending on your config, that may do nothing. The token used in the template config is "ACES - ACEScg", so "acescg" won't match anything unless you made your own config with that colorspace. OCIO 2.0 introduced aliases, so it's possible to have an alias to that space called "acescg", but I think these are not working correctly in Houdini in my experience.
I suppose this begs the question "how are people expected to work with ocio/aces then?"; if OCIO working/not working properly hinges on some correct token to be in every file name (which seems incredibly tenuous to begin with), and new versions of OCIO change the naming convention of this token, how are artists - both at big studios and hobbyists - expected to work with it? Renaming the files in a texture library to suit the whims of an OCIO config seems totally impractical. (I realize this has nothing to do with sidefx).
Is there a resource that explains - from start to finish - how one should set up their pipeline to work nicely with OCIO/ACES?
jsmack
Why bother with a config at all if you're just turning off color handling?
I suppose that's a reasonable question; let me explain where my head's at. I'm trying to work in Solaris, with Karma XPU, with MaterialX. I've been laboring on a personal project for about a year and a half that's sought to use this workflow. Frequently, when I ask other questions to either sideFX or on the forums about various ins and outs of USD/Solaris/Karma/XPU, I'm told "this is in beta", "this does not work yet", "this has not yet been implemented", "this is not reliable", "this is not worth it", etc. These answers collectively have painted a picture to me that I should not take for granted that OCIO and ACES 'just work' in Houdini.
Separately, I asked a question
here [
www.sidefx.com] a while back about using ACES in Karma/Cops, and a response (by you!) that stuck with me was "your images are in acescg by fiat/they are in acescg because you know it to be true". This implies to me that if I'm very careful and observant about what's happening with my images every step of the way, and keep careful accounting of what colorspace everything is in at every step, then I can more or less guarantee that what is written by Karma *has to be* in aces.
So, to answer your question: my habit of disabling color space management and managing it myself is rooted in a lack of confidence that there is any other way to do it. But of course this is fraught with its own problems, and I would LOVE to learn that all of this works well in H19.5/Karma, and that embracing ACES/OCIO is simply a matter of following some clear instructions. Is this the case?
In any event, the insight you offered that this whole pipeline hinges on me divining the correct token to include in my filenames - and that this token may have changed, and may be causing my images to suddenly appear different - is a very good clue, and makes me suspect I have NOT successfully disabled color handling. So I'm trying to get to the bottom of which path I should take: either wholly embrace color handling (again, with Karma XPU, with MaterialX as it exists in H19.5), or continue to not trust it and manage it all on my own, in my head, by fiat.
jsmack
COPS reads follow the same OCIO rules defined in the config as other reads in Houdini. Disabling linearize is useful for manual handling of color spaces. If the file is named correctly, you shouldn't have to though.
This implies that my output from Karma needs to have "acescg" (or some permutation of this token that matches my config) in my output filename before reading it into COPS, if I want COPS to be using OCIO, is that right? OR I disable this, tell COPs not to do anything fancy, and then I manage the colorspace transform myself, yes?
jsmack
The operation for converting to the display space is actually missing. You want an OCIO Display-View transform that contains the "look" of ACES, as well as the display transform. (I think this is what you're after, maybe you don't want a tone mapped image. The display-view transform is what you see in the renderview)
Hm, interesting; this implies that the "operation for converting to the display space" is missing from this particular config, which is again confusing because this config is described thusly:
The "display" section there implies I should be able to, um, display my images? But when I drop down an OCIO Transform VOP in COPS, I do not see any obvious display transforms, which is why I picked the "Texture-sRGB" one (apparently incorrectly)
jsmack
Correct, when viewing display referred values, color correction should be disabled in the viewer by setting it to Raw. Disabling OCIO may apply the viewers default 2.2 gamma, so you probably don't want that.
Yikes, ok this is very helpful, because that is hella confusing/unexpected.
jsmack
I don't think it's possible to get wysiwyg with the renderview/cop viewer by applying a transform in cops with OCIO 2.1 You'll need to use a standalone commandline tool such as hoiiotool or ocioconvert to apply the display-view transform. If you're feeling adventurous, you can edit the config and add a colorspace that implements a display-view transform. This would allow using a colorspace transform in legacy software that lacks display-view transforms.
Hm, is it possible that I waylaid myself (or jumped the gun) by trying to migrate to OCIO 2.1? Maybe I need to retrace my steps with some more basic questions:
- ACES and OCIO are two different things (YES/no)?
- Does setting the path to a .ocio config file set both OCIO version AND ACES version simultaneously (YES/no)?
- Are there compatibility issues between Houdini 19.5 and OCIO (YES/no)?
- Are there compatibility issues between Houdini 19.5 and ACES (yes/NO)?
- Is there a recommended OCIO and/or ACES version that is considered stable/good to use (i.e. a "studio driver" version rather than a "game driver" equivalent)?
I really do want to understand this and use it effectively, it just seems like it changes rapidly and unexpectedly, or I'm not reading the right documentation or something...I'm consistently confused by it. But I'm trying hard not to be!