Hello,

If I have my OCIO environment variable set for Houdini, is Karma rendering in ACEScg color space in Solaris? Do I still need to manually transform color textures with OCIO transform to ACEScg?

Is ACES color management handled automatically by Hydra or is that up to each renderer?

Cheers,

Eche
Hello,

If I have my OCIO environment variable set for Houdini, is Karma rendering in ACEScg color space in Solaris? Do I still need to manually transform color textures with OCIO transform to ACEScg?

Is ACES color management handled automatically by Hydra or is that up to each renderer?

Cheers,

Color management happens when viewing the rendered image, and when reading textures. By default, textures are only transformed to aces if their filenames contain tokens indicating their source space. Otherwise, the transformation is a gamma correction only, when non-linear textures are detected.

Karma doesn't have support Aces colorspace for spectral effects--sRGB primaries always used.

jsmack
Karma doesn't have support Aces colorspace for spectral effects--sRGB primaries always used.

It sounds like you are saying that you can convert textures to ACEScg in Solaris, but Karma won't render in ACEScg color space? What would be the use case for this? Are you saying that if I suppy an ACEScg texture with values that map to ACEScg AP1 primaries, then render with Karma, the values will be clipped to Linear sRGB primaries? What would be the point of that workflow?

Houdini and Karma convert input textures from their tagged colorspace to the OCIO Scene Linear role when loading. By default in the ACES profile, Scene Linear is ACES-CG. So it should be doing all sampling and compositing in that space. I'm a little fuzzy on how karma handles its image output, but it should be a conversion from Scene Linear to whatever colorspace is specified for the output format.

I haven't done a ton of testing, but in my recent Karma project everything worked as expected with OCIO. Incoming EXR textures from Substance Painter and HDR light textures looked right by default and rendering seemed to be in the correct space (ACEScg) with an sRGB transform in the viewport/MPlay. EXR rendered to disk was definitely in ACEScg. Applying the baked ACES1.2 Houdini ACEScg to sRGB LUT got the final image into Photoshop-friendly format and it looked perfect.

Thank you!

I asked a similar question to support about how houdini determines colourspace for textures when working in ACES, here is the reply..


Texture colorspace depends on a few things:

1) If you have a colorspace name in your filename; that is used as the colorspace (eg, image-aces-cg.jpg, image-srgb.exr).

2) If you don't, it determines if the format is sRGB or Linear (sRGB: jpg, png, tga, most 8b formats; Linear: EXR, RAT, HDR). It then uses an sRGB colorspace for the format and aces-cg for the latter.

3) Linear is ACES-Cg only if the scene-linear role is set to that, which it is in the ACES-1.0.3 profile.

danwnewlands
Linear is ACES-Cg only if the scene-linear role is set to that, which it is in the ACES-1.0.3 profile.

How should the scene set to be linear?
an OCIO environment variable is enough? nothing should be done in Karma renderer to use OCIO?

Edit:

according to doc:

Set the $OCIO environment variable to the file path of an OpenColorIO configuration file (such as config.ocio).
The existence of this environment variable controls whether Houdini automatically uses OCIO in various places.

well setting the variable should be engough I guess!

I can`t seem to set my tagged colorspace to anything other then srgb lin or rec 709 lin. i have an ocio config anabled and its visable in the colorsetting.

Am i doing something wrong or is this normal behaviour.

TangheStudent
I can`t seem to set my tagged colorspace to anything other then srgb lin or rec 709 lin. i have an ocio config anabled and its visable in the colorsetting.

Am i doing something wrong or is this normal behaviour.

Where are you tagging the colorspace? Filename tokens are the only way to tag colorspace that I know of. The tokens recognized depend on the colorspaces defined in the ocio config.

The karma settings also allow for applying a transform to the output image plane. For example: render everything in rec709 and then transform the final output to acescg.

TangheStudent
I can`t seem to set my tagged colorspace to anything other then srgb lin or rec 709 lin. i have an ocio config anabled and its visable in the colorsetting.

Am i doing something wrong or is this normal behaviour.

If you are talking about MaterialX, that doesn't support ACES yet. Your best bet will be to convert everything to ACEScg before loading into Solaris. https://www.sidefx.com/forum/topic/81944/ [www.sidefx.com]

but so with materialx x using acescg work only if i convert the textures before importing in solaris, instead in principled shader work automatically right?

Piledriver
instead in principled shader work automatically right?

If you don't use file name tokens, they'll have to be preconverted with the principled shader too.

sorry i'm new to karma/mantra what are name tokens?

Piledriver
sorry i'm new to karma/mantra what are name tokens?

With OCIO, colorspace can be inferred from the file name of images. For example an image called diffuse.acescg.exr may be converted to the working space from the named color space "acescg" in the config. OCIO 2 adds some new ways to define rules based on other criteria, with file name tokens being one example of such a rule.

Not all OCIO compatible software will respect the file name tokens, but mantra and karma do.

Hi pals, I'm at least a little sorry to re-ignite this somewhat-aged thread. But here I am!

I recently upgraded my OCIO setup to the latest from the OCIO website [opencolorio.readthedocs.io], which is to say OCIO v2.1, for Aces 1.3, using cg config (cg-config-v1.0.0_aces-v1.3_ocio-v2.1). This upgrade has changed how my image outputs look, and I'm trying to retrace my steps to make sure I understand how this is supposed to work.

• I'm using Karma (XPU, materialX) in Houdini 19.5
  
• I have $OCIO defined in my houdini.env, describing the path to my aforementioned cg-config.ocio.
  
• albedo surface textures have been converted using oiiotool to acescg; albedo files have "acescg" in the name (e.g. albedo.acescg.exr)
  
• Other surface textures have not been converted; height, normal maps, specular roughness, etc. are sRGB jpg/png
  
• 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.
  
• All IBL/DomeLight textures have been created in acescg space, and have "acescg" in the filename (e.g. ibl_acescg.exr)
  
• 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?
  
• 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.
  
• I do my postprocessing: exposure adjustment, color grading, bloom, diffusion, etc.
  
• 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)
  
• 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 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.
  
• I write out a PNG
  

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.

Thanks!
--a

OCIO 2.1 changes out colorspaces are detected, so I'm not surprised you might see a change in how your input is treated.

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.

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!

dhemberg
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).

Studios write their own configs to suit their needs. OCIO was designed with studios in mind. The template configs are just that, templates, no really meant to be used as-is except for demonstration purposes. The concept of OCIO does hinge on file name tokens. That's by design. However, OCIO 2.1 adds to this by allowing for defining file name rules in the config itself. This would allow for designating all jpgs as sRGB for example. At my studio, we're still using OCIO 1.X configs and don't use file name tokens. We only use images that are already in ACEScg space.

dhemberg
Is there a resource that explains - from start to finish - how one should set up their pipeline to work nicely with OCIO/ACES?

No, but if you spend years reading the docs, wikipedia articles on color science, github repos for the source code to OCIO, and just using it in production you'll pick it up eventually.

dhemberg
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.

Just don't worry about it. Load that config, and forget color space is a thing. It more or less, just works.

dhemberg
Separately, I asked a question here 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.

What I meant by that was that Karma doesn't have any color science yet that depend on the working colorspace. (not quite true, there are color temperature controls on lights that assume srgb). This means that if you use acescg textures, or convert the input images to a working space of acescg, then your output will be in that working space.

dhemberg
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?

If you understand the limitations, yes. It's much better to be able to view your images in Houdini than relying on Nuke to be able to do so.

dhemberg
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.

You can also put no token in the file name and just make sure all the images are already in ACEScg space, or rely on custom rules that define the space by extension or something else. Using ocio transforms in the shaders is also reasonable, but can get annoying. Again, only needed if your input images are srgb or some other space than ACEScg.

dhemberg
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?

Yes, if you want to read a image that is not in ACEScg space into COPs and have it converted automatically using OCIO, then it will need a filename token or other rule in the config. Since COPs also has ocio transform tools via the VOPCOP, you can also disable the conversion if desired.

dhemberg
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:

It's not missing, but 2.1 configs typically elide an explicit output display colorspace, instead breaking it up into components: display colorspaces and output transforms. Because Houdini is missing a tool for applying a display color space in VOPs, an external tool is needed to do the conversion.

dhemberg
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)

Correct, but the OCIO transform vop only shows colorspaces. There would need to be a new node "display transform" to do display color spaces. You can add the display transform as a color space to your config to make it more like a 1.X config and still use this workflow with COPs.

dhemberg
Yikes, ok this is very helpful, because that is hella confusing/unexpected.

With OCIO disabled, legacy color management is used.

dhemberg
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:

Perhaps, OCIO 2.1 is still kind of experimental. It only recently was released.

ACES and OCIO are different things. ACES is the Academy Color system developed by the Academy of Motion Picture Arts and Sciences. OCIO is a library for color management, originally developed by Sony Pictures Imageworks.

dhemberg
Does setting the path to a .ocio config file set both OCIO version AND ACES version simultaneously (YES/no)?

I'm not sure what you mean. A config file has an OCIO version, the ACES version is determined by the colorspaces defined in the config file. It's possible to have looks defined in the config to view with different ACES versions.

dhemberg
Are there compatibility issues between Houdini 19.5 and OCIO (YES/no)?

No, but I did find some bugs, and the O part of IO is somewhat lacking.

dhemberg
Are there compatibility issues between Houdini 19.5 and ACES (yes/NO)?

Not really applicable?

dhemberg
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)?

That's up to you. I find the 2.X system much more flexible and designing configs around that system is much easier. You don't have to memorize matrix math to implement the colorspaces. You can just pick them by name.

dhemberg
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!

it's not that rapid, I think I've been using OCIO 1.X style configs with ACES 1.1 for almost ten years.

jsmack
Studios write their own configs to suit their needs. OCIO was designed with studios in mind. The template configs are just that, templates, no really meant to be used as-is except for demonstration purposes.

Oh this seems like an important insight (and wasn't at all obvious to me; I presumed these downloadable configs are meant to be gospel). So the way a studio might work is - rather than relying on some token in the filename for the desired colorspace of the file itself (e.g. "ACEScg") - checking for a particular disk location or a different naming convention to handle this (e.g. 'all files with "diffuse" in the name located within a "model/textures" folder should be presumed to be in ACEScg.]..or whatever). This makes a ton more sense to me.

jsmack
A config file has an OCIO version, the ACES version is determined by the colorspaces defined in the config file. It's possible to have looks defined in the config to view with different ACES versions.

...

There would need to be a new node "display transform" to do display color spaces. You can add the display transform as a color space to your config to make it more like a 1.X config and still use this workflow with COPs.

Ahhh, ok I'm starting to get it; because these configs are intended to be mutable, and because I can mix and match various ACES version colorspaces in a single config, I can basically build my own setup to give myself a way to 1) use color management (rather than sidestepping it as I am now) while 2) navigating any bugs in, say, COPS or hypothetical changes that MaterialX might offer as it matures.

Thanks for taking the time to explain all that!