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
OCIO : Opengl vs CPU vs XPU
2418 11 4- julca
- Member
- 223 posts
- Joined: 10月 2015
- Offline
- luijee
- Member
- 16 posts
- Joined: 4月 2015
- Offline
- jsmack
- Member
- 8052 posts
- Joined: 9月 2011
- Offline
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.
- julca
- Member
- 223 posts
- Joined: 10月 2015
- Offline
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
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
- mark
- スタッフ
- 2643 posts
- Joined: 7月 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:
-
-
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.
Thanks for finding this.
P.S. Karma will now look much more like Houdini GL. For clarity:
-
ACEScg_ColorChecker.exr
will be assumed to be in ACEScg color space-
A_C_E_S_c_g_ColorChecker.exr
will 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 - 2023年11月13日 13:54:13
- julca
- Member
- 223 posts
- Joined: 10月 2015
- Offline
- jsmack
- Member
- 8052 posts
- Joined: 9月 2011
- Offline
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.exr
will be assumed to be in ACEScg color space
-A_C_E_S_c_g_ColorChecker.exr
will 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)
- mark
- スタッフ
- 2643 posts
- Joined: 7月 2005
- Offline
- julca
- Member
- 223 posts
- Joined: 10月 2015
- Offline
- julca
- Member
- 223 posts
- Joined: 10月 2015
- Offline
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
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 - 2023年11月20日 03:42:44
- jsmack
- Member
- 8052 posts
- Joined: 9月 2011
- Offline
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
- julca
- Member
- 223 posts
- Joined: 10月 2015
- Offline
-
- Quick Links