RED IPP2 Color workflows

cameras
red
Tags: #<Tag:0x00007febcde30ba0> #<Tag:0x00007febcde30998>

(Charles Boileau) #1

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!


(Francesco Luigi Giardiello) #2

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 :wink:


(Nick Shaw) #3

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.


(Margus Voll) #4

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.


(Charles Boileau) #5

@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!


(Willian Aleman) #6

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…


(Nick Shaw) #7

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.


(Willian Aleman) #8

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."


(Nick Shaw) #9

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.


(Charles Boileau) #10

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?


(Margus Voll) #11

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.


(Tim S. Kang) #12

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.


(Nick Shaw) #13

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.


(Gavin Greenwalt) #14

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 :smiley:) 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.


(Charles Boileau) #15

“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!


(Gavin Greenwalt) #16

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.


(Charles Boileau) #17

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!


(Gavin Greenwalt) #18

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.