ACEScc and ACEScg in a single Nuke comp script

Tags: #<Tag:0x00007f3c63cb1b18>

(Joe Johnson) #1

Hello everyone!

We have just started working ACES into our pipeline and our current client has delivered us a bunch of FG element plates in ACEScg. Everything here seems fine as we have all that we need to proceed with keying and prep as we start up.

We’ve run in to something, however, where we were delivered some BG elements in ACEScc. From what I understand, ACEScc stuff is mainly for DI work, and from all the testing we’ve done, in my mind combining these two different pieces of footage in two different colors paces doesn’t seem right? I can write out the comp in ACES2065 and maintain the look of both colorspaces, but this leaves me with a BG with values below 1, and an FG with values that exceed 1.

Is there a proper way to do conversion to the ACEScc plate to ingest them in the same colorspace as my FG elements(ACEScg), or will I need to request new plate pulls from the client?

Any help on the matter would be greatly appreciated!

(Nick Shaw) #2

ACEScc is supposed to be an internal working format for grading systems. It is not intended to be written to files.

While ACEScc image data written to a 16 bit integer format should in theory preserve the values from the ACEScg original, somebody sending files as ACEScc would give me concerns that the people doing the VFX pulls don’t really understand ACES. You would certainly not want to use 10-bit DPX for ACEScc as 1024 steps is not enough for the range that ACEScc codes.

Also it is concerning that you are getting negatives from the ACEScc source. ACEScc is a pure log coding, and should not be able to code negatives at all. Sorry misread “below 1” as “below 0”. ACEScc is ranged 0-1, but once converted to ACEScg should normally include values above 1, as ACES is linear unclamped float.

As Alex says below, if when converted there is nothing above 1.0, that suggests clipping may have occurred. Are you using an OCIO to convert, either in the read node or in an OCIOColorSpace node?

(Alex Forsythe) #3

Hey Joe … Glad to hear things are generally working out for you!

ACEScc really isn’t ever supposed to be written in a file. Likewise, ACEScg isn’t really intended for interchange. The idea is that ACES2065 is supposed to be passed around to avoid just such confusion.

Understand that’s the theory and you’ve got a real world problem, I’d convert ACEScc elements to ACEScg. I’m not sure what tools you’re using, so it’s a little hard to give specific advice.

I’m a little confused about your statements regarding values above and below 1. Are you talking about after converting ACEScc and ACEScg to ACES2065? Both should have values above and below 1. Are you suggesting the background elements are all 0 to <1 and the FG elements are 0 to >1 in ACES2065? If so, it sounds like your background plates were clipped.

(Joe Johnson) #4

Thank you Nick and Alex for the replies.

Nick - I have tried using a OCIO Colorspace to convert my ACEScc BG plate to ACEScg, which gives me a result with values ranging between 0->200+. My assumption is the client delivered us files that contained the general look they wanted, so this BG plate as is will need to be redelivered to us. You’re edited statementis correct in that the ACEScc values are between 0-1, whereas our ACEScg EXRs do not have that limitation.

Alex - would it be wise for us to ask to have all the plates redelivered in ACES2065, or would having the plates delivered in ACEScc being resent ACSEcg suffce?

One of the tests we did to try and preseve the look of FG element and BG element was a quic A over B of the ACEScg element merged on top of the ACEScc element, From there rendering the output in ACSE2065 managed to keep the correct values from FG and BG element, but as stated earlier, the BG (ACEScc) element values are locked 0 to <1. So we have the problem of what I’m assuming is a Linear plate being slapped on top of a LOG plate which is an issue.

(Alex Forsythe) #5

It’s always preferred if files are interchanged in ACES2065. If that’s a problem for your workflow, ACEScg would be the next one I’d go with. Per @nick’s comment, moving files around in ACEScc get’s really tricky because of possible quantization issues. That’s part of why we don’t ever recommend putting that into a file.

Yeah … those shouldn’t be clamped 0 to 1

(Joe Johnson) #6

Thanks for the input Alex! We’ll try to get this sorted and hopefully it will all work out!

(Nick Shaw) #7

ACEScc 0-1 does map to linear 0-200+. That is a correct conversion. However “normal” images in ACEScc shouldn’t have any pixels up at 1.0. That is designed to be more headroom than you should ever need. If your plates have pixels at 1.0 which become 200+ linear, are you sure they are ACEScc?

(Joe Johnson) #8

Thanks @nick, I rounded up my ACESScc values. They do go from 0 to <1 (values peaking around 0.998…). Metadata is also telling me the plates are in ACSEcc as well as what was communicated from the client.

Hopefully we can get this ironed out with the client!