Colour Shift When Using ACEScc with RCM

Get answers to your questions about color grading, editing and finishing with DaVinci Resolve.
  • Author
  • Message
Offline

Dalavi Tang

  • Posts: 18
  • Joined: Wed Jun 24, 2015 2:40 am

Colour Shift When Using ACEScc with RCM

PostThu Jan 17, 2019 11:38 am

I use ACEScc as timeline colour space in RCM and I use Rec.709 Gamma 2.4 as my output colour space.

When I try to make a clip monochromatic either by de-saturating the image all the way down to zero or by checking the monochrome checkbox in mixer, I always get a colour tint in the supposedly monochrome image, verifiable on the scopes. You can even see the shift when highlighting qualification or power windows - anywhere grey will have a colour tint to it - verifiable on the scopes.

I checked if the issue persisted when I bypass output transform, and the colour shift did went away. I also checked if it persisted when I use other output colour spaces (such as Rec.2020) and it did (verifiable on scopes). It seems that RCM is not handling the transform from ACES to other output colour spaces very well.

I believe you can easily recreate the problem if you set ACEScc as timeline colour space and anything other than bypass as output colour space.

Maybe I shouldn't use ACEScc with RCM? But I don't use the ACES workflow because ACES is noticeably slower than RCM on my laptop. And I like the feel of grading and how the controls respond in ACEScc so I resorted to using ACEScc with RCM. And Resolve still does not come with a Pocket 4K IDT yet (or does it?) so using RCM seemed to be the only option if I don't want to use a LUT workflow.

It's not that big of an issue for me, as I almost only export to Rec.709 and don't have to worry about RCM spitting out different results in different output colour spaces, so basically I just grade for Rec.709. But black & white image can be tricky to get.

Hopefully it can be fixed, but even it doesn't get fixed, please leave ACEScc in RCM as an option, I do enjoy this combination.
Offline

Hendrik Proosa

  • Posts: 3053
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Colour Shift When Using ACEScc with RCM

PostThu Jan 17, 2019 12:21 pm

If you align RGB channels in one gamut and then do gamut transform, it is likely that they go out of balance, especially when there is also white point difference. A simple example, lets say you have gamut A and gamut B. In gamut B, green primary is much more saturated than in A, while R and B primaries are the same. Doing gamut transform will produce green value which is smaller than in A, because in gamut B, the same chromaticity is expressed with lower value. Thus, you get tint shift. In case of neutral axis this should be prevented if you do white point conversion, so my guess is that it isn't working as expected.
I do stuff
Offline
User avatar

waltervolpatto

  • Posts: 10536
  • Joined: Thu Feb 07, 2013 5:07 pm
  • Location: 1146 North Las Palmas Ave. Hollywood, California 90038 USA

Re: Colour Shift When Using ACEScc with RCM

PostThu Jan 17, 2019 5:09 pm

Either use aces or use rmc. Unless you're absolutely sure of what you're doing, they are not mixable
W10-19043.1645- Supermicro MB C9X299-PGF - RAM 128GB CPU i9-10980XE 16c 4.3GHz (Oc) Water cooled
Decklink Studio 4K (12.3)
Resolve 18.5.1 / fusion studio 18
GPU 3090ti drivers 512.59 studio
Offline

Dalavi Tang

  • Posts: 18
  • Joined: Wed Jun 24, 2015 2:40 am

Re: Colour Shift When Using ACEScc with RCM

PostFri Jan 18, 2019 6:34 am

Hendrik Proosa wrote:If you align RGB channels in one gamut and then do gamut transform, it is likely that they go out of balance, especially when there is also white point difference. A simple example, lets say you have gamut A and gamut B. In gamut B, green primary is much more saturated than in A, while R and B primaries are the same. Doing gamut transform will produce green value which is smaller than in A, because in gamut B, the same chromaticity is expressed with lower value. Thus, you get tint shift. In case of neutral axis this should be prevented if you do white point conversion, so my guess is that it isn't working as expected.


Hi Hendrik, I agree with you on the cause of the colour shift during CST (white point differences) and indeed choosing timeline colour spaces and output colour spaces with different white points (ACES or P3-D60 to Rec.709 for instance) will cause a colour shift, while using different gamuts with the same white point doesn't cause the issue (P3-D65 or Rec.2020 Gamma 2.4 to Rec.709 for instance).

I don't know why RCM is not transforming white points while doing CST, and I don't know if it's common not to transform the white point.

waltervolpatto wrote:Either use aces or use rmc. Unless you're absolutely sure of what you're doing, they are not mixable


Hi, Walter, I understand that RCM and ACES are two different colour management systems so they should not be mix used, I just want to use the ACES gamut and gamma because it grades well.

I also came across a 2017 post in which Dmitry also expressed concerns about the colour shift when using ACES where you commented that the colour shift is due to white point differences between gamuts.

Please correct me if I'm wrong. So RCM does not touch white point when doing CST (regardless of the timeline colour space I choose, ACEScc or P3-D60), while ACES does deal with different white points in RRT and ODT. RCM assumes that the white point throughout the colour pipeline is the same, while ACES does not assume so?

I'm not very knowledgeable when it comes to colour management so I really wish to learn from you guys.
Offline
User avatar

waltervolpatto

  • Posts: 10536
  • Joined: Thu Feb 07, 2013 5:07 pm
  • Location: 1146 North Las Palmas Ave. Hollywood, California 90038 USA

Re: Colour Shift When Using ACEScc with RCM

PostFri Jan 18, 2019 8:23 pm

Sorry if I'm blunt but just because you are not familiar/ knowledgeable with color transformation, don't mix aces with rmc.

They are designed to work independently.

The aces color space you want to work on, it's really a logarithmic mapping, you're much better off and simplify enormously if you do:

Your camera space to Alexa log c
Main color space Alexa log c
Output from Alexa log c to display space

So you have the nice logarithmic space to work in it, there is no color shift, it is mathematical so there is no clipping, pretty much all the camera can be elegantly mapped in log c and so forth.
W10-19043.1645- Supermicro MB C9X299-PGF - RAM 128GB CPU i9-10980XE 16c 4.3GHz (Oc) Water cooled
Decklink Studio 4K (12.3)
Resolve 18.5.1 / fusion studio 18
GPU 3090ti drivers 512.59 studio

Return to DaVinci Resolve

Who is online

Users browsing this forum: Bing [Bot], Google [Bot], John Spirou, pperquin, Tyler Graefe and 272 guests