So I just picked up learning Karma and I did quite a bit of research yesterday, but I’m still not entirely clear on the correct setup.

Currently, I’m on Houdini 21 and here's my setup:

• To work in ACES, I go to Edit → OCIO Settings, set the Render Working Space to ACEScg, and the View Transform to ACES 1.0 - SDR Video.
  
• For exporting .exr files with ACES embedded, I’ve been changing the .exr color space in the same settings.
  
• One thing I’m not sure about is the viewport. Right now, I have the Display set to sRGB-Display, with Enable OpenColorIO turned on, and the View set to ACES 1.0 - SDR Video. Is this the correct setup?
  
• Also, regarding working with textures in Karma: do I need to manually change their color space, and if so, what’s the proper workflow for that?
  

So yeah, I'd be very grateful if someone could clarify this for me. Thanks!

drxaviert
For exporting .exr files with ACES embedded, I’ve been changing the .exr color space in the same settings.

Be warn that changing ".exr" in ocio config setup to ACES means all input exr textures would be considered to this space.

If you want to export only has ACES you can set it up directly in the "Karma Render Settings" node -> "Image Output" -> "AOVs (Render Vars) -> "Output Colorspace" parameter

drxaviert
Also, regarding working with textures in Karma: do I need to manually change their color space, and if so, what’s the proper workflow for that?

All textures are automatically converted based on the OCIO Settings rules you already edited.

julca

drxaviert
For exporting .exr files with ACES embedded, I’ve been changing the .exr color space in the same settings.

Be warn that changing ".exr" in ocio config setup to ACES means all input exr textures would be considered to this space.

If you want to export only has ACES you can set it up directly in the "Karma Render Settings" node -> "Image Output" -> "AOVs (Render Vars) -> "Output Colorspace" parameter

drxaviert
Also, regarding working with textures in Karma: do I need to manually change their color space, and if so, what’s the proper workflow for that?

All textures are automatically converted based on the OCIO Settings rules you already edited.

Oh amazing, thanks for clarifying this for me. I guess the way I have the viewport setup for ACES in the original post is correct as well? It's the one I'm most unsured on.

That's correct. If you've set the Rendering Working Space to ACEScg, then setting the OCIO display to sRGB - Display will convert the image from ACEScg to sRGB for the purposes of displaying in the Scene View.

ACES 1.0 - SDR Video adds an additional View transform that represents a typical final look.

Un-tone-mapped removes that View transform, resulting in the equivalent of Utility - sRGB - Texture.

Raw turns off the OCIO transform entirely, showing you the actual ACEScg code values as though they were the desired display values. This is usually only useful for troubleshooting.

I'm still hit and miss in this area so just to confirm, on Houdini side these are only ones needed to set and we are good to go?

Mirko Jankovic
I'm still hit and miss in this area so just to confirm, on Houdini side these are only ones needed to set and we are good to go?

Shouldn't it be ACEScg instead of ACEScct?

But yeah, you're right on exporting .exr. Either do it globally in OCIO Editor or set it locally in the rendersetting

Yess yes ACEScg Imeant that, just missed click You are right.

copying my comment from a reddit thread:

I was not able to get Houdini 21 to actually save my .exrs as acesCG with that alone. It used to be the case in the past because I've done it before, but it took me about 4 hours of trial and error until I was able to get it to actually write them out not as Linear sRGB.

Nothing I did would work except one thing:

The solution was to create a new renderproduct LOP, name it "renderproduct" so it takes priority over the one that comes from the karmarendersettings LOP and set it manually to acesCG.

Everything I found everywhere said this shouldn't be necessary, but it was for me.

I'm not a karma/USD expert, so everything I do is me just winging it.

I'm also rendering out via a USDrender ROP to deadline, so maybe how that's being output is affecting something.

Looks like I ran into that as well. I was rendering some fixes and noticed a slight color difference between old and new renders. Thought I was a problem, but it seems like there is something different now?

I came across this few days ago.

I noticed changing the output colorspace parameter doesn't work no matter what colorspace I choose.

However, when I open my old projects files (using houdini 21) with the 20.5 karma render setup I was able to change it and working fine.

I found out (which might be) a work round,


- Disable the beauty Var in the karma render output settings entirely.(Uncheck)

- go to the bottom when you can add Extra Render Vars

- add a new beauty Var there and choose the Acescg (or whatever colorspace you need as an output) You don't need to do it under the component level output since it's not going to work anyways.


I don't know if this is how it supposed to work now or it's just a bug.

I'm glad I'm not the only one with issues. I thought I was going crazy for a minute.

Please log the bug to sidefx.

Does the Output Colorspace parameter actually override the OCIO file rules though? Genuinely curious because I haven't used that setting before. I always just add "ACEScg" into the output filename of my renders because otherwise the default file rule for .exrs is to treat them as Linear Rec.709 (sRGB) when reading/writing if a colorspace pattern isn't in the filename. As far as I can tell I haven't had any issues rendering to acescg using this method and my 20.5 scenes produce the same results in 21.

Not saying there isn't some new change or bug in 21 but I haven't had problems relying on my slightly customized file rules and specific naming of my textures and output files. That said, I never feel totally confident talking about ocio stuff so hopefully someone who knows what's up can chime in.

I was under the impression that the OCIO config options for pattern matching to colorspaces for .exr/.png etc. were only for reading files, not writing.

The entire section is called "Input File Rules"

It seems really bizarre to have a global setting for the entire application that applies to any file Houdini writes

I was under the impression that the OCIO config options for pattern matching to colorspaces for .exr/.png etc. were only for reading files, not writing.

Same! But before I knew I could set the colourspace in rendersettings I tried this and got the results I was expecting. I started doing this a few versions ago and just stuck with it. Why not give it a shot just to see what happens!

Update:

Changing the output colorspace parameter now working.

I tried Daily Build 21.0.473 and everything is smooth.

I believe it's was a bug.



Thanks SideFX Team.

That’s really weird, I’m having a scene containing mtlx unlit surfaces only (mograph work) and, after trying both the general OCIO rules only as in 20.5 as well as adding the ACEScg to the Output Colorspace and updating to a daily built, I can’t get the same luminance or hue in Resolve.

I'm also not able to export correct ACES colour space normally. Very strange, never had this issue in the past before 21. I copied above approach and created a renderproduct lop and only changed Output Color Space, left everything else to do nothing. Used Scene Linear (ACEScg) on the read node (obviously also changing color management in settings) in Nuke and I'm pretty sure it's correct now.

Hi guys,

consider I'm still learning Karma/Solaris.
I had same issue while rendering .exr images with H21.0.44: no matter what config, my .exr output was always linearRec.709 back to Nuke.
Took me some time to understand.
First Hint was in Karmarendersetting LOP I tried to setup an OCIO output filter ACESCG on "C" plane using "data" as input Space and it didn't work at first... So I switched input Space from "data" to "linearRec.709" and back to nuke I get a beautiful AcesCg image !
Hmmm... Means my input image is linear and I Have to "burn in" AcesCG space! What the... :S
I went back to the OCIO Settings to double check: it was still set to "AcesCG rendering space", but my result implies that the internal rendering space is "linearRec.709"...
Starting to think SideFx did a little joke...
Until my eyes falls down on the .exr type image rules: Factory default set to "linearRec.709"
My first thought was it was only for converting input textures; for instance in materials, lights... But now I understand that it's clearly an I/O rule !
That's why I still got the error with my first attempt with the image filter: the render space works truly in acesCG, starting from the (acesCG space) "data" I ask to convert with the filter to acegCG space, means... "do noting" (it was already in acesCG) and then ROP write .exr still following the OCIO general rules... in linearRec.709 space !

So my correct AcesCG setup is super simple: nothing to do on the Karmarendersetting LOP, no filter on the output image - just switch OCIO Setting to AcesCG render space and modify .exr rule from linearRec.709 to AcesCG ! (it will affect both input and output .exr, so keep in mind that if your Input .exr textures are linear you can either convert them to acesCG in Nuke Or change the color space back to linearRec.709 in your MtlXTexture nodes)
Hope I'm clear enougth and s'cuse my French