Hi, thank you for your replies, karu.
The intermediate color space allows Octane to convert between built-in color spaces for which it knows all the details (chromaticities etc.), and OCIO color spaces for which it knows nothing except the name (as a string). The intermediate color spaces function as a "bridge" for these conversions - to convert from built-in color space A to OCIO color space B, Octane first converts from A to the "Octane" side of the intermediate color space (using, for example, a 3x3 matrix), and then uses OCIO to convert from the "OCIO" side of the intermediate color space to B. The conversion in the other direction is similar (but Octane doesn't do this yet). Without the two halves of the intermediate color space being set, Octane would have no way of knowing that the "Utility - Linear - sRGB" OCIO color space (for example) matches what Octane calls linear sRGB.
@karu - Thank you for the explanation. Although it is still too vague for me to clearly understand it. What do you mean by ❝
"built-in color spaces"❞? What does this refer to in Octane? ❝
Octane would have no way of knowing that the "Utility - Linear - sRGB" OCIO color space (for example) matches what Octane calls linear sRGB❞ in what context? The utility is
mainly used as IDTs at texture file level, which Octane does not support yet at the moment.
whatever color space you put in is what you get out - but Octane needs to know the specific details of at least one OCIO color space because the renderer produces absolute wavelengths of light.
@karu - That's correct but only valid for input textures. All RGB renderers (AFAIK at least) are hardcoded to sRGB/rec709 primaries for the rest, such as spectra features (mostly referring to lighting). In a context without OCIO and any matrix color transform available.
The only options available for the "Octane" half of the intermediate color space are linear sRGB and ACES2065-1, because this list only needs to cover enough color spaces so that any OCIO config a user would want to use should always contain at least one color space that matches one of them. ACEScg is not included because I don't believe there are (or should be) any practical ACES OCIO configs that do not include ACES2065-1 (plus, including ACEScg in the list may contribute to the mistaken assumption that it's somehow more correct than ACES2065-1 in this context).
The color management preferences page contains the text "For the intermediate color space, ensure both selections represent the same scene-linear color space (it doesn't matter which color spaces are selected as long as they match).", and both the intermediate color space boxes have tooltips that should be helpful. Please let me know if you think this could be made clearer because you're not the only one who's been unsure about these preferences.
@karu - I think it's important to understand what the
ACES 2065-1 Color space is and for what: It is an RGB, AP0 based (Ultra Wide Gamut with non-physically realizable) primaries, scene linear color space, that encompass all other color spaces (and the CIE chromaticity diagram entirely). It has been developed to be future-proof, decades or centuries ahead of us. It is
only an interchange and archival format and
should never be used as a working space (I don't even think a spectral renderer can break this "rule" as far as I can understand spectral rendering). Digital intermediate facilities also work with ACEScc and ACEScct (also ACESproxy) which are AP1 based, like ACEScg and all being working space. I've mentioned that part in my documents and it is very important to not overlook it. This is where my "incorrectly implemented" comes from.
• Side note, ACEScg has also non-physically realizable primaries but is less of an issue compared to the ACES color space (2065-1 AP0) and I could also mention that BT.2020 is the closest to ACEScg. From what Thomas Mansencal (Color developer, @Weta Digital, working closely on ACES) has explained, ACEScg encompasses P3, which apparently requires non-physically realizable primaries, to do so.
• Side note 2, ACES has flaws which I mentioned in my previous message I think, and certainly in my documents. ACES 2065-1 AP0 is only making it worse than ACEScg (I invite you to refer yourself to my private documents for more information).
In short using icc and photoshop as before for still image, for now.
@jimho - TL;DR - Avoid Photoshop for CG image data handling and color pipelines.
I copied this to clipboard and pasted in PS
@funk - Do you know, when doing so, what do you copy to clipboard? Is it a PNG? 8bit or 16bit? Integer (2.2) or linear(1.0)? Your approach should be that you export everything to EXR in a
proper professional compositing software like Nuke or Fusion. Your Photoshop workflow will only make it more difficult than it should be.
I cannot stress enough how important it is to use proper color pipeline tools that are designed for CGI, VFX and motion-picture.
By the way, IF it's OK to do so, rather than PM each other, could you post your discussions on the forum so we can all learn from them?
@funk - I'm open to share everything but by avoiding as much as possible the misinformation. This is why I prefer to discuss this privately first. Keep in mind that there will be an official and updated Octane documentation in the near future.
We can get around this by pre converting our images (in an external application) to ACES right?
@funk - Correct, but that workflow should not be considered as a solution. Only temporarily. You can use Affinity Photo, BMD Fusion, Foundry Nuke ( which all support EXR and OCIO natively), or this tool https://gumroad.com/l/pycocs for windows only (at the moment) as well as many other tools or ways.
