Blackmagic Forum

Hi,

If I have an EXR sequence with ACES AP0 primaries and Linear gamma encoding and want to colour map it into Alexa LogC there appears to be a colour shift when comparing it to the source files viewed in LogC. It looks like a colour temperature shift.

This is visible in both Davinci YRGB (via colour transform ResolveFX) and colour managed workflows (where you pick the input colour space and gamma and the timeline and output CS is LogC).

If I take in the same ACES EXR sequence into Baselight and do a colour space conversion there to LogC, the images match.

I'm not sure if there is something with the ACES RRT within Resolve where the white point is set to something like a D60 sim but has anyone else encountered such a discrepancy ? I've tried on both V14 and V15.

Thanks,

C.

cemoz101 wrote:This is visible in both Davinci YRGB (via colour transform ResolveFX) and colour managed workflows (where you pick the input colour space and gamma and the timeline and output CS is LogC).

If you are using ACES, you can't have LogC timeline, you either have ACEScc or ACEScct as working space. Are you using YRGB color managed by any chance with ACES as input space and LogC as timeline and output space? In this case you are probably seeing the difference RRT makes as you already guessed.

Can you upload example exr and original reference?

Hi Hendrik,

That's what I thought... :/

Yes, I tried in 'normal' Davinci YRGB (non colour managed) using a Colour Transform ResolveFX as an input transform on the first node.

I also tried it in DaVinci YRGB colour managed having ACES/Linear set as the CS and Gamma on the input with Arri LogC as Timeline and output colour space... in this scenario, I use a LUT as the output transform so to say.

The whole point of colour management is that you should be able to mix and match ACES, non-ACES, scene referred and display referred...

I'm also under the impression that you cannot change the version of ACES, so we are all tied down to version 1.0.3.

I could upload something but single frames are around 15MB... probably too big for the forum.

Thanks for the reply!

C.

cemoz101 wrote:... The whole point of colour management is that you should be able to mix and match ACES, non-ACES, scene referred and display referred...

I thought the benefit of using ACES was following a predictable and transferable deliverable or digital intermediate.


Sent from my iPhone using Tapatalk

ACES is intended scene redered and you can add material with transforms to ACES you use.

Could you just work in ACEScc and then deliver what ever would you need ?

If you are not using aces project, you will not get the render transform, thus you will get difference. What are you trying to achieve with not using aces but still using aces exr-s?

In case you only use LogC timeline you can use linear exr-s with alexa wide gamut. There is no real reason to use aces exr-s in non-aces project, maybe only if you want to have a common ground for them. But as you already discovered, aces exr-s open up a new can of worms where (rightfully so) people would start using them in true aces project and you get discrepancies.

I would assume vfx pushes them out like this or scan.

Sent while walking

cemoz101 wrote:The whole point of colour management is that you should be able to mix and match ACES, non-ACES, scene referred and display referred...

If you can handle it you can ride on all kinds of funky workflows. But you are forgetting that RCM is missing one component of ACES color pipeline, the Reference Render Transform or RRT, which is applied to ACES2065-1 to produce OCES (color rendition for idealized display). Which is then fed into ODT to produce final output. Without RRT you will not get identical result from RCM.

Amen.

Hi Folks,

Thanks for the input.

The scenario is you have a bunch of ACES AP0 linear EXRs VFX plates and you want to convert them to ARRI Linear WCG EXRs. You should not need to have an ACES workflow to do this, the primaries and the gamma encoding of both ACES AP0 and ARRI WCG are public and documented.

To not be able to do this conversion correctly within a grading system (colour managed or not) is frustrating.

Thanks again!

C.

cemoz101 wrote:The scenario is you have a bunch of ACES AP0 linear EXRs VFX plates and you want to convert them to ARRI Linear WCG EXRs. You should not need to have an ACES workflow to do this, the primaries and the gamma encoding of both ACES AP0 and ARRI WCG are public and documented.

This should work without problems, you are right that you don't need ACES project for this as you are simply doing gamut conversion. How exactly are you comparing the resulting exr-s when you see a color shift and what and where is the reference (how exactly are you viewing the source files in LogC)? The description about what you are doing in Baselight is vague, what exactly are you doing there?

In Resolve, I am using Davinci YRGB Colour managed. The input colour space on the ARRI source footage is tagged as Alexa LogC. The Aces EXR is tagged as ACES AP0 Linear. The timeline and output colour spaces are LogC since I don't want the RCM DRT applied on output.

In Baselight, I use a telecine style setup, which is pretty much the same as how I setup the project mentioned above (without a DRT applied).
Working colour space as it is called in BL is the common (timeline) colour space to how you want source footage mapped to. So it doesn't matter if it is ACES, display referred or scene referred from different sources (gamut and gamma encodings).

The input colour space is automatically set by BL for the ARRI source material since it knows it is an ARRI source file. The input colour space is set as AP0/Linear for the ACES EXR in Baselight.

Then you basically check between both the ARRI source and the ACES EXR files on both systems. Baselight matches, Resolve doesnt.

As I said before, the primaries and gamma encodings of the majority of camera manufacturers and ACES is publicly documented and this is simple maths. For this not to be possible within Resolve is again frustrating.

Furthermore (and besides the point here), the fact that you are bogged down to a 'DaVinci' look in RCM on the output transform makes the colour management function a little limiting. In a scenario where a DP wants the starting point to be through an ARRI 'DRT' since the dailies were transcoded with a simple ARRI LUT but you want to work in a colour managed workflow (especially if the output will have multiple deliverables sRGB, Rec 709, P3, HDR's various flavours), you simply cannot do this with RCM without accepting the 'Davinci' look.

C.

Ok, tested some things. The exr-s generated by Resolve seem to be fine, problem is in how exactly is the white point handled. My tests are done in Nuke, but should give an overview of what is happening.

To match an ACES2065-1 exr (AP0 gamut and linear), exr from Resolve must go through transform (I used OCIOColorspace node) where Linear (transfer function) D65 (white point) AlexaV3LogC (gamut, it is Alexa Wide Gamut) data is transformed to Linear (transfer function) ACES (white point) ACES (gamut, it is AP0) data. What is important that Bradford matrix must be off, meaning that color appearance must not be compensated for. Reference for Bradford matrix states that if on, colors will appear the same under new illuminant, if off, they will have the same XYZ values. If we are doing technical change, we want the same XYZ values.

So it all comes down to how you are comparing things, probably somewhere in the chain this appearance compensation is taking place and you get color shift.

What makes it all strange, at least in Nuke, is this: if I export an exr from Nuke as Input - ARRI - Linear - ALEXA Wide Gamut, and then import it back as such, it matches the 2065-1 exr perfectly when using proper IDT-s for both. But the exr from Resolve needs this white point conversion although imho the Resolve exr is totally correct (why on earth should an AlexaWG exr have ACES white point?). And this is where I get a little headache... My guess is that the handling of ACES files in Resolve differs from Nuke, but I can't really say that any of them is wrong

That's interesting, thanks Henrik for looking into this. I don't have Nuke within my reach, but I know that OCIO is pretty solid.

I suspect what we are seeing might have something to do with the ACES 'white point'.

See forum here : https://acescentral.com/t/d60-sim-for-7 ... rgb/1264/4

One of the reasons also why I'm not a fan of ACES is the fact that different people can be on different softwares and the ACES library versions might not match, rendering different results.

I also had another post about why we cannot select the version of ACES within Resolve. This should also be an option.

Thanks again!

C.

So it might be that VFX people used some older version of ACES just ?

cemoz101 wrote:I suspect what we are seeing might have something to do with the ACES 'white point'.

I asked about this in Nuke group in FB, maybe someone can chime in about this. It seems to me that the ACES implementation in Nuke (which is purely OCIO based) is applying the Bradford matrix behind the scenes. Whether it is by the ACES specs or not, I don't know, but this is where Resolve and Nuke conversions seem to diverge. I wouldn't be surprised if there is some kind of invisible trap (maybe by design) hidden in using color space not from Output group as an ODT, but without doing this it would be impossible to avoid RRT.

I got an answer from Deke Kincaid which I interpret in the lines of "both are right", Nuke and Resolve that is, but Resolve does not conform to additional ACES stuff outside actual ACES project and this produces this difference. Nuke applies Bradford matrix behind the scenes in ACES project because this is how ACES works, Resolve does not apply it when not in ACES project. Makes perfect sense actually.

That's interesting and it does make sense.

Thanks for spending the time and digging into this!

C.

No problem!

I found a discussion about this same topic in ACESCentral forum:
https://acescentral.com/t/color-primaries-shifting-and-negative-values-ocio-confusion/892/13

Scrollig down a bit, there is a post by Nick Shaw that illustrates it very well:

AWG has D65 white. On the input side you will see the same result with an OCIOColorSpace node with in set to Input - ARRI V3 LogC (EI800) - Wide Gamut and out set to **ACES - ACES2065-1**as you will with a Colorspace node with in set to AlexaV3LogC for transfer function (which Nuke confusingly calls “colorspace”) and primaries and D65 illuminant, and out set to Linear with ACES illuminant and primaries, and the Bradford matrix checked.

That is because the ALEXA ACES IDTs include chromatic adaptation, although I believe they use CAT02, rather than Bradford.

The CAT02 adaptation method also explains why matrix defined in OCIO is a bit different than matrix in Colorspace node in Nuke, which applies Bradford matrix.