OCIO : Opengl vs CPU vs XPU

   1707   11   3
User Avatar
Member
219 posts
Joined: Oct. 2015
Online
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
Edited by julca - Nov. 13, 2023 02:35:51

Attachments:
OCIO_compare_OpenGl.jpg (509.4 KB)
OCIO_compare_CPU.jpg (531.0 KB)
OCIO_compare_XPU.jpg (496.9 KB)
2023_11_12_karma_ocio.zip (1.8 MB)

User Avatar
Member
15 posts
Joined: April 2015
Online
we're also having weird behaviour with ocio on h20
User Avatar
Member
7864 posts
Joined: Sept. 2011
Online
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.
User Avatar
Member
219 posts
Joined: Oct. 2015
Online
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
User Avatar
Staff
2602 posts
Joined: July 2005
Offline
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.
Edited by mark - Nov. 13, 2023 13:54:13
User Avatar
Member
219 posts
Joined: Oct. 2015
Online
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
User Avatar
Member
7864 posts
Joined: Sept. 2011
Online
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)
User Avatar
Staff
2602 posts
Joined: July 2005
Offline
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.
User Avatar
Member
219 posts
Joined: Oct. 2015
Online
mark
This should be consistent in the next daily build of H20.0.
Yes !
I confirm, thank you
User Avatar
Member
219 posts
Joined: Oct. 2015
Online
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
Edited by julca - Nov. 20, 2023 03:42:44
User Avatar
Member
7864 posts
Joined: Sept. 2011
Online
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
User Avatar
Member
219 posts
Joined: Oct. 2015
Online
hello @jsmack,

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