Color Management

[funk]

I copied this to clipboard and pasted in PS

@funk - Do you know, when doing so, what do you copy to clipboard? ... Your approach should be that you export everything to EXR

I only did it this way to be sure I was seeing the same thing in the Octane viewport, since Octane has no render history like V-ray (with an A/B slider to compare 2 images).
When I adjusted the prefs, the result looked the same, so I pasted both into PS to be 100% sure my eyes weren't fooling me, thats all.
Octane's clipboard command copies the 8 bit tonemapped image you see on the screen.

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.

No problem

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.

Yes I understand. I definitely don't want to be forced to pre convert my textures externally

[jimho]

@funk,
if you are using photoshop,
we do not need to care about and touch OCIO and ACES, they are more than necessary, maybe animation softwares need them.

[funk]

@funk,
if you are using photoshop,
we do not need to care about and touch OCIO and ACES, they are more than necessary, maybe animation softwares need them.

You're misunderstanding why Im using photoshop in this instance. Its just so I can compare 2 images from the octane viewport "side by side".

I could have used print screen + MS paint, or any other application that allows me to paste the Octane clipboard.

[jimho]

We majorly work on still images for architectural rendering and sometimes animation,
Photoshop is enough for us and icc working well with ps for color management purpose
for animation color grading we use Davinci Resolve

[karl]

Sorry all for the delay, I was away on paternity leave

NOTE: Minor issue - While messing with other settings, I noticed that when changing prefs, you need to change the imager OCIO view to something else (eg none), then back to force the viewport to update correctly.

I'm aware of this issue and will look into it.

I was very surprised to see the output of both was identical. I think I'm starting to understand the Octane preferences a little better.
Using your analogy, my test just got Octane and OCIO speaking to each other in "English (1)" and "Spanish (2)", and the imager OCIO view can now translate to other "languages" in it's list (ACES: sRGB, ACES: Rec.2020 etc).

That's correct. It doesn't matter what language Octane and OCIO speak to each other in (i.e. it has no effect on the output), as long as they're both speaking the same language. You can interchange in ACES2065-1 or linear sRGB (as long as your OCIO context supports both), and you should get the exact same final result.

So I guess the main thing missing is conversion of input images/colors to ACES? And we can get around this by preconverting our images (in an external application) to ACES right?

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.

(edit: what about sun/sky system colors? Don't they need some kind of conversion?)

The daylight models (except for the "Octane" model) are inherently spectral so are unrelated to RGB color spaces.

[funk]

Sorry all for the delay, I was away on paternity leave

Congrats!

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.

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