Just wondering if the new IPP2 will be included in a future releases of ACES.
I know that Guardians of the Galaxy was graded in ACES. Does anybody know how this was done? Did they use Ipp2?
Thanks!
Hi!
Yes they did use ACES and yes, they are now supporting it even outside REDCINE X. RED released new 3x3 matrix tables to help converting RED WG RGB/LOG3G10.
You can find them here:
Hope it helps 
I would not say that IPP2 could be incorporated into ACES. While RED Wide Gamut RGB and Log3G10 form part of IPP2, and can be used as an intermediate colour space, and transformed to ACES, the full IPP2 pipeline includes REDās own gamut mapping algorithm, tone mapping and output transforms, and as such could be said to be a RED specific alternative to ACES.
If you are not using REDās gamut mapping, tone mapping and output transform, you are not really using IPP2, and if you are not using the ACES RRT and ODTs you are not really using ACES.
1 Like
I have been using RED Wide Gamut RGB and Log3G10 in resolve (in a way they are applied by default)
with ACEScc workflow without any ipp2 LUT on top of it.
Generally you can then build your own looks there and adjust contrast and roll off as you like
without RED lutās. It seems that most of the magic happens on cam side and WG and Log3g10 do read it fine to my eye.
Iām not sure if that is the correct way to do it but i personally like it more this way as i have more control over the whole process and those luts do not limit as much especially if you think artistic side in mind as pre made luts tend to jump with larger steps that you might want some time in precision work.
1 Like
@Margus_Voll Can you explain your workflow in Resolve?
Can I assume that Ipp2 or not Resolve is still managing Red footage the same way it has always done it? (straight from raw?). You usually do not need to apply an IDT in Resolve when working with Red footageā¦
Thanks!
I donāt know if IPP2 is treating RED footage differently, however, because RAW footage have no color space attached to it, there is no need to have an IDT for the footage to be taken in ACES. In other words, itās a property of raw regardless the camera or the softwareā¦
Although Raw does not have a colour space as such, it still has to be transformed into a given colour space by the use of a matrix during decoding.
In some cases (including R3D) the SDK gives the option of using a matrix which transforms directly to ACES during the decode. In other cases the decode is done to a known colour space, and an IDT is used to go from that to ACES.
I believe that the changes made with IPP2 also include some changes to the deBayering, intended to improve the image. However My understanding is that these are currently only implemented in the REDCINE-X beta, so will only affect the result in Resolve if you transcode the R3Ds in that, before bringing the footage into Resolve.
1 Like
When I bring ARRI raw, Panasonic Vericam 35 or RED raw into Resolve under ACES, I still donāt need to set up an IDT, which was confirmed a while ago by your comment in another thread here, where you clarified the exceptions. The same goes when using raw in Scratch.
Nick wrote:
"That is correct. Raw footage can be decoded directly to ACES, without the need for an IDT. In this case, most raw decode parameters are disabled, as they are irrelevant. You can still alter some, such as Kelvin, Tint and ISO.
The exception seems to be Sony Raw, where Resolve does include a Sony Raw IDT. However I have found I get better results (matching other implementations) on F65 Raw media when I use my own DCTL S-Gamut3.Cine
IDT. See my other post on this subject."
That is correct. Although because we canāt see what is going on under the hood of Resolve, it is possible that an IDT is being used, but set automatically and invisibly for you, based on the type of Raw.
But it does not matter to the user if a direct decode to ACES is used or a decode to something else, with an automatic hidden IDT.
So by this logic we could assume that the IDT is accessing the RAW (no pun intended) ācolor spaceā of the RED. The IPP2 is just a āsubā variant of this āfullā colorspaceā¦ Correct?
This is how i feel it is now but again just my subjective feel not any science to back it up for that statement.
@nick Probably can comment on this one more.
As i never have used IPP2 based luts with ACES then i assume this is so.
Every camera sensor has its own native color space - the unadulterated integers describing the sensor voltage response beneath its three component color filter arrays. Each manufacturer has (rather, shouldā¦) properly characterized the three component spectral sensitivities throughout the sensorās dynamic range to define what this native space is, then applies some sort of 3x3 matrix to fit those numbers into their respectively defined color spaces.
ACES specification presents, as an ideal, to independently characterize these spectral sensitivities and unmix them into an ACES scene linear representation of the captured world.
So to directly answer your question - yes, every color management system, including REDās IPP2, ACES, etc., is tonal mapping (ie, converting) into P3, Rec709, etc.
Red Wide Gamut RGB is a colour space which encloses all the āCamera RGBā (i.e. un-matrixed sensor RGB)colour spaces of the various RED sensors, and can be transformed to from any of them without clipping. So yes, it is a slight variant on any one the the Camera RGB spaces.
I have finally upgraded one of my machines to a recent enough OS, and installed Resolve 14.3. I can confirm that the IPP2 colour science is included, and selectable as āVersion 3ā in the Raw tab. While this is greyed out in ACES mode (most of the IPP2 controls such as Contrast and Highlight Roll Off are not relevant) it appears that the selection made here prior to switching to ACES (or the selection made by default, based on the camera firmware when shooting) does affect the result in ACES. So if you have selected v3, you will be using the new deBayer.
And thereās nothing wrong with that. You should use what works best where it works best. Also just to nitpick but IPP2 includes so many things, like ACES, that you have to distinguish which aspects of IPP2 youāre talking about. The new color debayer is included in IPP2 which means the color will improve whether you debayer to Red Wide Gamut or ACES.
My current workflow is to debayer to RWG\Log3G10 (or as I call it RWGcc 
) which will work in any container: EXR, TIFF or DPX. If I need the footage for CG work Iāll convert to ACEScg, do any texturing, lighting, rendering and compositing in ACEScg until I need to grade. Then depending on who wants the footage Iāll give them ACES AP0 if they want to finish in ACES or Iāll output to RWGcc again if thatās how they want to finish or Iāll do some hybrid.
ACES is useful. RWG is useful. Even when Iām in a mostly ACES workflow Iāll still use my own non-standard RRT\ODTs if Iām grading. Theyāre all tools. I wouldnāt say that someone who uses a customized RRT\ODT isnāt āReallyā using ACES, theyāre definitely really using ACES even if they are only using a subset of the standard where it fits into their pipeline. Even if youāre using ACES containers, you still want to convert to a log space to perform saturation for instance. Convert in and out of linear\AP# where appropriate. Convert in and out of AP0 ā AP1 where appropriate. Convert between ACEScg\ACEScc where appropriate. There is no one ārealā ACES workflow.
āACES workflow Iāll still use my own non-standard RRT\ODTs if Iām gradingā curious to know more about thisā¦ Do you do a reverse RRT/ODT and apply something new or are you using a LMT?
Thanks!
Nothing fancy, you could just view it as an āalternateā RRT \ ODT or an āinverse arbitrary IDTā. Both are equally correct\incorrect ways of thinking about it. I prefer to think of it as an alternate RRT\ODT. I either back out to a manufacturerās wide gamut and then use their existing pipeline (you can then use IPP2 with Alexa footage or Arri Wide Gamut to Rec709 with RED footage), a third party gamut targeting such as Rec2020 FilmConvert ā Rec709 film emulation or else Iāll just perform a straight matrix transform from AP0 to Rec709 and then use saturation curves to soft clip the out-of-gamut colors back into the output space.
ACES is useful as an intermediate workspace and as a well defined box to hold data, but Iām not religiously attached to using its prescribed ODTs or trying to ātrickā the ODT into outputting what I wanted in the first place with an LMT. Better to just skip the ODT entirely in a lot of situations and write your own output pipeline that serves the same purpose as the RRT\ODT but without fighting the ODTās tendencies to do something other than what you want. I do the same thing with IPP2 footage as well even if I never touch ACES. Sometimes Iāll use REDās luts, sometimes Iāll just handle the OoG values using my own arbitrary special sauce rather than trying to bend the RedWideGamut values before running it through REDās somewhat unpredictable black box.
I might be wrong, but I believe I saw in a Siggraph talk years ago that Sony Pictures Imageworks also has their own custom ACES output pipeline that combined the RRT\ODT into a non-standard output without an ACES spec ODT anywhere in the pipeline.
I really wish I knew how to build these customs RRT/ODTs for myself. Thereās allot of technical knowledge Iām lacking and it seems like Iām missing a whole bunch of possibilities with ACES. Do you grade in Resolve?
That being saidā¦ To change RRT/ODTs doesnāt that take out the āstandardizationā part out of ACES?
Thanks!
It does, however once you apply an ODT youāre already baking in a non-ACES, potentially irreversible, transform anyway. RRTs are also breaking linearity and scene referred chroma as well. So you still get the nice predictability and standardization of ACES where it matter: ingest and exchange but arenāt quite as restricted on burning out display specific deliverables.