Color Management

[karl]

What do you mean by ❝"built-in color spaces"❞? What does this refer to in Octane?

By "built-in color spaces" I mean the color spaces natively understood by Octane (i.e. non-OCIO color spaces). These are the current built-in color spaces:

• sRGB
• Linear sRGB
• ACES2065-1
• ACEScg

The important thing about these color spaces is that Octane knows more than just their name - it knows all the details such as primary chromaticities, white point and transfer function, so that it can convert between any two of these color spaces with a bit of math. This contrasts with OCIO color spaces, about which Octane knows nothing except their names.

❝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.

That was just one example - my point was that we know that the built-in Octane color space "Linear sRGB" is the same as the OCIO color space "Utility - Linear - sRGB" in the standard ACES OCIO config, but without being told, Octane has no way of knowing that (or, in general, matching any built-in color space with any OCIO color space).

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.

ACES2065-1 is being used in this context as an interchange space. The renderer produces output in ACES2065-1, and that ACES2065-1 is the input to OCIO. It's not a working space because no calculations are done on the RGB values in this space and those RGB values are never exposed to the user.

• 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).

I assume you mean the flaws that make ACES2065-1 unsuitable for a working space in an RGB renderer, namely that the gamut is too wide. That's not relevant in this situation because we don't do any calculations in this intermediate space (e.g. multiplying two RGB values together). It doesn't matter at all what the intermediate space is; as I mentioned you can even use linear sRGB and get an identical result.

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.

FYI, when using the "copy to clipboard" button in the Octane viewport, the image is copied as 8-bit sRGB PNG.

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.

This is not correct - see my previous post in this thread.

[karl]

Yes, the main thing missing for full ACES support is the ability to assign color spaces to input images/colors. You can't get around this by preconverting images to ACES, because when converting images to the internal spectral coefficient representation all input images are currently assumed to be using sRGB primaries. Preconversion may give you something that looks OK but is not correct because you can't yet tell Octane that the images are ACES.

After playing around with ACES some more I realised this too. Thanks for confirming.

So this is only an issue if we are working with others who already have their images preconverted as ACES. We would have to convert those images to sRGB externally first.

Yes, but note that the inability to use primaries other than those of sRGB doesn't mean input images are restricted to the sRGB gamut: you can use a linear sRGB EXR input texture containing values outside the 0-1 range. So if you have an ACES2065-1 EXR you can convert it losslessly* to a linear sRGB EXR using an external tool** and use it in Octane.

* Except for floating point inaccuracies.
** As long as that tool doesn't clamp negative RGB values in the output image.

(Edit: It just occurred to me that for all my talk I haven't actually tested this. I see nowhere in the code where input texture values are clamped, but I will confirm this behavior.)
(Edit 2: It does work as I assumed.)