Hi,
so the most current versions let you specify an OCIO transform for image textures. Though I‘m wondering, what‘s the workflow for getting correct colors from the „color RGB“ node as well as the shader‘s color pickers?
Cheers
OCIO color picker
Moderator: juanjgon
I suppose that you could use the color correction and OCIO configuration available in the color picker itself. I think that it has some limitations, something that hopefully will be improved in H19.0
Thanks,
-Juanjo
Thanks,
-Juanjo
- Attachments
-
- 2021-10-21 11_21_45.png (53.86 KiB) Viewed 3257 times
Hmm, perhaps I'm not understanding you, but the color picker always sends to the plugin the color in the linear color space, which is used later by Octane and updated to the selected Octane color settings. I mean, a color selected in the picker is always the same in the internal linear color space. What changes is how you see it in the color picker window on the monitor. What you need to do is match the color picker settings with the Octane settings to try to get the most accurate color from your picking.
Thanks,
-Juanjo
Thanks,
-Juanjo
Thanks for your explanation.
I was thinking though, like in a non-ACES workflow I could specify a RGB color in Photoshop and safe a texture, as well as using the same RGB values in a color picker and getting the same result. I thought it would make sense that in ACES I can also set specific RGB values in a color picker and use the utility-srgb-texture transform to convert it to ACES. Something like this is not possible, right?
I was thinking though, like in a non-ACES workflow I could specify a RGB color in Photoshop and safe a texture, as well as using the same RGB values in a color picker and getting the same result. I thought it would make sense that in ACES I can also set specific RGB values in a color picker and use the utility-srgb-texture transform to convert it to ACES. Something like this is not possible, right?
Hi chocbot, I am quickly chiming on this quote: R'G'B' itself is a color model and not a color space (that is composed of three components, detailed in the link below).chocbot wrote:Thanks for your explanation.
I could specify a RGB color in Photoshop(...) as well as using the same RGB values in a color picker
I believe that what you are referring to, is an "sRGB color picker value", likely display-referred (with the electro-optical transfer function applied, mistakenly known as "̶G̶a̶m̶m̶a̶ correction").
If you are interested, I could recommend this informational content: https://www.elsksa.me/scientia/cgi-offl ... rvival-kit
It is worth to consider a simpler workflow that does yield similar pleasing results.
In case you are unaware, the workflow could be much simpler without ACES while still having a similar "look". ACES being often overkill for the majority of individuals, uneducated about the digital imagery fundamentals. More information can be find in the link above.
Thanks, yeah I know that I didn‘t use the accurate terminolgy but I thought it was sufficient to explain my thoughts.
I didn‘t read through your text yet but am wondering, if your workflow also allows combining footage as well as renders from different renderers as easily as in ACES?
However, I don‘t find ACES particularly hard to use, now that Octane allows specifiying the input color space of textures. I‘m just missing that I can‘t do the same for the color picker, actually.
I didn‘t read through your text yet but am wondering, if your workflow also allows combining footage as well as renders from different renderers as easily as in ACES?
However, I don‘t find ACES particularly hard to use, now that Octane allows specifiying the input color space of textures. I‘m just missing that I can‘t do the same for the color picker, actually.
It does, as it has been done for many years in the past, before ACES got popular or even existed.
ACES is simple until the pipeline gets more advanced. It is indeed simple in Octane, partially thanks to the exemplary implementation in it. However, an ACES based color pipeline (non exhaustive list):
• can quickly becomes difficult in some situations (for the majority of 3d image makers who do not work in digital imagery post-production). A lot of people have a simple workflow and rather mistakenly use it as a one click "magic button" solution for its "look", which is not what ACES has been purposed for but is an aspect of it.
• suffers from core design issues
• is wide gamut and the majority of people do not know how to properly and correctly work/handle wide gamut encoded imagery. In other words, it is more prone to broken imagery.
It is a matter of appropriate choices relative to the project requirements and awareness (many misconceptions around ACES and digital imagery are spreading online, everywhere), not obligation. Everyone is free to use take their own decision.
ACES is simple until the pipeline gets more advanced. It is indeed simple in Octane, partially thanks to the exemplary implementation in it. However, an ACES based color pipeline (non exhaustive list):
• can quickly becomes difficult in some situations (for the majority of 3d image makers who do not work in digital imagery post-production). A lot of people have a simple workflow and rather mistakenly use it as a one click "magic button" solution for its "look", which is not what ACES has been purposed for but is an aspect of it.
• suffers from core design issues
• is wide gamut and the majority of people do not know how to properly and correctly work/handle wide gamut encoded imagery. In other words, it is more prone to broken imagery.
It is a matter of appropriate choices relative to the project requirements and awareness (many misconceptions around ACES and digital imagery are spreading online, everywhere), not obligation. Everyone is free to use take their own decision.