dhemberg
albedo surface textures have been converted using oiiotool to acescg; albedo files have "acescg" in the name (e.g. albedo.acescg.exr)
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.
dhemberg
All surface textures are being read via mtlx image nodes, using a vector3 signature (rather than a color signature), acknowledging that materialX is not aware of ACES. My understanding is that reading everything as vector3 circumvents any "black box" color transformation guess-ery that may/may not be happening, giving me manual control over this.
Why bother with a config at all if you're just turning off color handling? Use the token "Raw" in the file name if you want it to skip color processing. The ACES - ACEScg token should effectively do a no-op since the target space is the same.
dhemberg
I render using Karma XPU, to an EXR file. I'm not sure that there are any controls on the Karma Render Settings node that has any control over output color space. Instead, I am "trusting" that my careful grooming of input file textures is what asserts that Karma-output exrs are in acescg. Do I need to actually include acescg in the output filename in order to control this?
There's no output color correction using OCIO yet. However, karma allows adding ocio transforms to individual image planes. It's convoluted and not worth the trouble in my opinion.
dhemberg
I import my rendered exr into COPS for postprocess (I am not using Nuke). I disable "linearize non-linear images", because I am unsure how COPS deals with aces/ocio, if at all.
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.
dhemberg
I (try to) manually convert my file from acescg to sRGB using a VOP that contains an OCIO_TRANSFORM vop, where my inSpace is "ACEScg" and my outspace is "sRGB - Texture" (I ultimately want to make a png that I can share online, so I'm looking for the 'right' way to get into sRGB)
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)
dhemberg
I have a ROP File Output COP, which has "Convert to Image Format's Colorspace" disabled. By disabling this and doing the previous color conversion step, I *think* I am again circumventing black box color transforms and manually managing this, but I'm not sure.
I always disable this, it's not useful and just does a simple gamma.
dhemberg
I disable OCIO in my Composite View's display options, again because I am trying to manually manage everything so I can understand what's happening where. Allegedly this should let me see the 'raw' pixel value, but I also see a "RAW" option in the OCIO options in the display viewport, and my image looks different when selecting this option than when I totally disable OCIO.
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.
dhemberg
All this rigamarole, however, leaves me in a spot where I'm no longer confident that what I see on-screen is what I should expect to see. Prior to moving to OCIO v2, I was reasonably confident that the above was giving me a WYSIWYG workflow, but moving to OCIO v2 seems to have changed this behavior in a way I don't understand. So, I'm wondering if anyone can poke holes in what I'm describing above, or otherwise point me to a more current resource for how to properly set this up (including COPS) than what seems to exist in the Houdini docs.
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.