Community
Arnold for Cinema 4D Forum
Rendering with Arnold in CINEMA 4D using the C4DtoA plug-in.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Aces colour space

5 REPLIES 5
Reply
Message 1 of 6
paul.clements
563 Views, 5 Replies

Aces colour space

I am making RGB ID mattes in the Arnold shader but they don't seem to work correctly.

If I have a noise going into a ramp that remaps the colour to full red, full green, full blue, I would expect when viewing the red channel the other channels to not be visible...

I am finding that the other channels are still visible, when only viewing one. Am I missing something?

Many thanks,

(version 3.3.5.rc2, (6.2.1.0)

Tags (2)
Labels (2)
5 REPLIES 5
Message 2 of 6

The color management workflow in Cinema 4D is a little bit cumbersome.

There are basically three factors to consider:

  • What's the color space of your input?
  • What's the working (render) color space?
  • What's the view (display) color space?

By default, the Input Color Profile is sRGB (see Edit > Project Settings). In case of ACES this means the sRGB color space defined in the Arnold Render Settings, which I believe is "Utility - sRGB - Texture" by default. The render color space is "ACEScg", the view color space is whatever, let's say "Output - sRGB".

So the color value you see on the UI is expected in "Utility - sRGB - Texture", converted to "ACEScg", then to "Output - sRGB" for the display.

For a red (1, 0, 0) color this means:

  • "Utility - sRGB - Texture" --> "ACEScg": (1, 0, 0) --> (0.613, 0.070, 0.021)

So after the color space transform you see values in the G and B channel, this is just how the ACES color transform works.

What can you do about it? Well, you can define that your inputs are in the working color space (in ACEScg), so they are not converted. Either set Input Color Profile to Linear, or the sRGB space to ACEScg. However this affects all color inputs, so it's not ideal.

What you can do instead is to use a vector value instead of a color, since vector inputs are not transformed. For instance add a value shader, change the Data type to vector and connect it to your ramp color.

Sorry for the long explanation, hope this helps solving the issue. 🙂

Message 3 of 6

Thanks Peter, that is really helpful I will try that.

A workaround I found was to create a red jpeg (1,0,0) and set the colour space to disabled to get the correct values.

The utility shaders such as Surface Derivative which is outputting RGB values... Is there a fix for getting the correct outputs here?

It feels like we need an option to 'disable' colour management for Arnold generated colours.

Message 4 of 6

Only color inputs are affected by this, so color values you define on the UI. State shaders or the utility shader (other then the 'color' Color Mode) always output a value in the working color space. (If that's what you were asking.)

It feels a bit overkill having a separate color space option for every color input on the UI.

Message 5 of 6

Hi Peter, I have been using the value shader as you suggested and it has been working great!

However, I am now working on a scene where mograph is driving the 'display color' to create RGB mattes, and the original problem arises again.

The individual channels from the user data node set to 'display color' outputs the aces converted values, and therefore not usable as ID mattes. Any ideas of a workaround to get the correct values like how you described with the value shader?

Many thanks,

Message 6 of 6

A workaround could be to copy the value to a vector type User Data attribute and read that in the shader network instead of the display_color (via Xpresso maybe?). Not sure it's doable though and sounds a bit complicated.

I'm thinking about adding a flag to the Arnold tag to skip the color transform on the display color. It could solve this specific case.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums