Hello,

I Try to understand how to well setup OCIO and my textures workflow for H20.
I really like the new OCIO editor, very clear.

But after long hours on it I still don't always understand result.


To test pattern/extension OCIO matching I prepared 4 versions of a same srgb jpg texture and 4 version of the ACEScg exr one.
So I have 8 box by render but I don't get expected result for all.

Cf. 3 screenshots commented for the 3 render engines (Opengl, CPU, XPU).






I notice that XPU and CPU doesn't match on cube (7).
Also some color conversion seems to not working : (cf. textes "behavior : Wrong").


Hope someone can explain me what happen or where I made a mistake.
Project files joined below ("2023_11_12_karma_ocio.zip")
Thank you

we're also having weird behaviour with ocio on h20

Some of your test images are not in the colorspace they are indicating. I tried to replicate the test with only correct images and tokens, but I ran into a strange issue where it seemed like texture reads were sometimes ignoring the file name token, and other times picking an arbitrary color space in some 'unknown' way since the file was not tokenized with the colorspace and it was not in the config file. It turns out the colorspace information is embedded in the image files, and perhaps the metadata is overriding the tokens/filename rules.

Thank you @jsmack,
Let me know where I made mistake and I'll correct them. At the end I only have two, sRGB and Acescg but I can made a mistake while preparing all extension/patern versions.

I don't know about metadata but it's could be a good explanation, I'm curious if that is taken into account.

I would be very happy to demystify all this stuff

This turned out to be an issue with the way Karma determined the color space of the texture. There was an inconsistent priority when looking at image metadata and parsing of the OCIO file rules. This should be consistent in the next daily build of H20.0.

Thanks for finding this.

P.S. Karma will now look much more like Houdini GL. For clarity:
- ACEScg_ColorChecker.exrwill be assumed to be in ACEScg color space
- A_C_E_S_c_g_ColorChecker.exrwill be assumed to be in Linear Rec 709 (sRGB)
Since the image data is the same between the two images, when they get converted to scene_linear, you'll see different values come through.

Hello @mark, thank you for your return.
So that's means that is read metadata in priority, then OCIO file rules if needed ?

So we will see in the next daily build,
Thank you

mark
This turned out to be an issue with the way Karma determined the color space of the texture. There was an inconsistent priority when looking at image metadata and parsing of the OCIO file rules. This should be consistent in the next daily build of H20.0.

Thanks for finding this.

P.S. Karma will now look much more like Houdini GL. For clarity:
- ACEScg_ColorChecker.exrwill be assumed to be in ACEScg color space
- A_C_E_S_c_g_ColorChecker.exrwill be assumed to be in Linear Rec 709 (sRGB)
Since the image data is the same between the two images, when they get converted to scene_linear, you'll see different values come through.

Will this affect Mantra as well? (I was doing my tests in Mantra but figured Karma CPU would use the same rules)

Yes, mantra will follow the same rules:
a) Use the OCIO file rules
b) Use image metadata
c) Fall back to guessing based on the file type/data type and other heuristics.

mark
This should be consistent in the next daily build of H20.0.

Yes !
I confirm, thank you

Hello,

Is that normal if in project/texture path if there is a named pattern, like "//server/myBeautifulProjectACEScg/tex/myTexture.jpg", texture is altered by this ?
I tought that's only the short texture named ("myTexture.jpg") that is take into account.
It make me bugged a time before I catch this

julca
Hello,

Is that normal if in project/texture path if there is a named pattern, like "//server/myBeautifulProjectACEScg/tex/myTexture.jpg", texture is altered by this ?
I tought that's only the short texture named ("myTexture.jpg") that is take into account.
It make me bugged a time before I catch this

I'm pretty sure the full path is used so that the color token can come from different parent folders rather than the file name alone.

For example you might have as different ways to organize different reps of the same texture:

asset1/textures/srgb_texture/diff.1001.rat
asset1/textures/ACEScg/diff.0001.rat

hello @jsmack,

Yes that make sense, thank you for examples.
Now I will be more careful about the names of my folders path.