Howdy, what's the status of being able to set OCIO colorspaces for MaterialX images? The Houdini docs say Hydra doesn't pick up the File Color Space metadata from the MatX image node. So, when rendering with Karma using a variety of MatX images (sRGB, linear, data), how is each one being interpreted? Just curious what's going on under the hood. Thanks!

Update: I emailed SideFX support about this. Karma handles MaterialX texture colorspace as follows:

- float, vector2-4 images are treated as data (Linear, no conversions).
- color3-4 images are treated as "auto", which selects either Linear or sRGB based on the file format (sRGB: png, jpg, tiff, tga; Linear: exr, rat, hdr, pic)

So essentially it takes care of everything automatically! In my tests that's what it looked like, just wanted to confirm.

BrianHanke
Update: I emailed SideFX support about this. Karma handles MaterialX texture colorspace as follows:

- float, vector2-4 images are treated as data (Linear, no conversions).
- color3-4 images are treated as "auto", which selects either Linear or sRGB based on the file format (sRGB: png, jpg, tiff, tga; Linear: exr, rat, hdr, pic)

So essentially it takes care of everything automatically! In my tests that's what it looked like, just wanted to confirm.

Yeah, it doesn't use OCIO spaces at all with that type of conversion. It's a simple gamma curve or not.

Not ideal, but end result is close enough. I was mostly concerned about data textures getting gamma'd somehow. Seems like that's not an issue.

I wish they had ACES profiles built in.

Yuri Serizawa
I wish they had ACES profiles built in.

Would be nice. MaterialX apparently supports OCIO 100%, so hopefully the Houdini implementation will too eventually.

Yuri Serizawa
I wish they had ACES profiles built in.

That would be a nightmare in a VFX pipeline setting. Instead of being obviously wrong when an environment hasn't been configured correctly, it would merely be subtly wrong--leading to delays in discovery and confusion when elements don't match. Shipping with the standard ACES configs would increase installer size considerably. It's undesirable for each app to manage its own color. OCIO is meant to be globally configured so all compatible apps share the same color configuration.

BrianHanke
Would be nice. MaterialX apparently supports OCIO 100%, so hopefully the Houdini implementation will too eventually.

Houdini already does support OCIO, the issue is materialx nodes expressing color settings in a way that doesn't translate via hydra.

So is this an issue with MaterialX or just SideFx's node implementation of it?

Ashen
So is this an issue with MaterialX or just SideFx's node implementation of it?

The issue is with Pixar's Hydra/USD

Good to know. Are there any rumblings about it being fixed in an upcoming release?

here's a simple script to convert all in one directory on Windows with default install location.

I'm working on some MaterialX HDAs here and revisiting this topic a bit.

It seems that the MtlX Image node controls color space solely via file name. For example, image.raw.exr, image.ACEScc.exr, etc. all provide the expected color transforms.

You can use the Karma OCIO node to set color space via drop-down menu, but unfortunately it adds it on to the transform that takes place based on the file name. So, the only way to use the Karma node to go from texture_paint to scene_linear, for example, is to use a "raw" input file: raw -> texture_paint -> scene_linear. Otherwise you'll get "automatic transform based on file extension" -> texture_paint -> scene_linear.

Well, that ended up being a bit hard to explain! Hopefully it makes sense. Ideally I think it would be great to have the color space dropdown built into the MtlX Image node. I was trying to make an HDA for that, but with the color transform behavior seemingly hardcoded I guess there's no way around having to just name the files appropriately. Which probably is a good idea anyway, just not totally flexible.

BrianHanke
I'm working on some MaterialX HDAs here and revisiting this topic a bit.

It seems that the MtlX Image node controls color space solely via file name. For example, image.raw.exr, image.ACEScc.exr, etc. all provide the expected color transforms.

You can use the Karma OCIO node to set color space via drop-down menu, but unfortunately it adds it on to the transform that takes place based on the file name. So, the only way to use the Karma node to go from texture_paint to scene_linear, for example, is to use a "raw" input file: raw -> texture_paint -> scene_linear. Otherwise you'll get "automatic transform based on file extension" -> texture_paint -> scene_linear.

Well, that ended up being a bit hard to explain! Hopefully it makes sense. Ideally I think it would be great to have the color space dropdown built into the MtlX Image node. I was trying to make an HDA for that, but with the color transform behavior seemingly hardcoded I guess there's no way around having to just name the files appropriately. Which probably is a good idea anyway, just not totally flexible.

File name control of colorspace is an OCIO feature, it's not part of MaterialX. You can control the behavior with an OCIO 2.X config. The example 2.0 configs contain a filename token file name rule, but it can be disabled or defined by extension or other rules.

Understood, I was reviving this mostly to see if my concept of the workflow was correct. Sounds like I'm doing it right, so I'll go ahead and make an RFE with SideFX.