R 14.1 vs. IPP2: Please tell me this REDUSER is wrong!

I read the following on REDUSER.net:

Resolve's IPP2 implementation is applying the output transform after raw development, but before any grading nodes, which is backwards from the proper order of operations. This also means that philmColor LUTs (and other LUTs intended for RWG/Log3G10 input) will not work as intended if used on any node. They must be loaded into the RMD and called upon by the checkbox in the raw tab.

Please tell me this is wrong, or that an updated release will shortly fix it. IPP2 is a whole-pipeline architecture, as is Resolve. But that doesn't mean Resolve cannot properly integrate with the IPP2 pipeline. It's great that Resolve has some support for the new IPP2 elements, but really it should support the pipeline, not just the elements in a one-of, off-to-the-side kinda way.

That user is correct. Resolve 14.1's IPP2 processing is extremely buggy and isn't implemented correctly. They've included the contrast and rolloff settings in the raw development area so that the node graph's input is already processed, essentially throwing away all the latitude of your sensor data before you start grading. The best way to work with the IPP2 pipeline was already available by using Resolve's "Version 2" RED color science with RedWideGamut/Log3G10 debayer settings. Then you use the RED-provided LUTs within your node graph.

There's a major glitch right now in 14.1 that still shows dropdown menus to choose color space and gamma even when in "Version 3" mode. The whole purpose of IPP2 is to simplify the workflow to use ONLY RWG/Log3G10 as the working space.

They've included the contrast and rolloff settings in the raw development area so that the node graph's input is already processed, essentially throwing away all the latitude of your sensor data before you start grading

That is absolutely NOT correct.

1) The node graph's input WILL be already processed no matter what the settings are, since the RED RAW data needs to be translated into RGB data (or into RESOLVE's color-space) before any kind of color processing is done. IPP2 or no IPP2 is not changing the nature of this.

2) IPP2's creation purpose was to provide the easiest way to preserve all the sensor's latitude while at the same time using an unflattened exposure curve like REDgamma4. I can reassure you that using IPP2 is not "throwing away all the latitude of your sensor". Actually, nothing is thrown away.

3) If you need to use a LUT that expects a cineon-like or REDlog Film gamma then that's what needs to be set in the RED's Gamma Curve settings. What the original poster is saying over there at REDUSER makes absolutely no sense because when REDlog Film is selected in RESOLVE then the IPP2 settings for Output Tone map and Highlight Roll Off are not doing anything. So nothing is messed up for the LUT.

4) The original poster is saying that "PhilmColor LUTS" (Philm?) ..."must be loaded into the RMD and called upon by the checkbox in the raw tab". Another thing that makes absolutely no sense. RMDs can't load any kind of LUTs. Even in RED's own REDCINE software any kind of Look Up table is added AFTER the RAW data are processed.

Resolve 14.1's IPP2 processing is extremely buggy and isn't implemented correctly. They've included the contrast and rolloff settings in the raw development area

5) How is it extremely buggy? It works exactly like it does in REDCINE (where it resides in the RAW develop area as well) and it actually works really nice over here with the latest 14.1 update.

or use ACEScct and walk away happy with all the data off the sensor on tap as always

The node graph's input WILL be already processed no matter what the settings are

I should clarify that by processed I meant a color and contrast transform has been applied thus taking it out of the IPP2 working space of RWG/Log3G10

IPP2's creation purpose was to provide the easiest way to preserve all the sensor's latitude while at the same time using an unflattened exposure curve like REDgamma4. I can reassure you that using IPP2 is not "throwing away all the latitude of your sensor".

Here is a screenshot of how using IPP2 in REDCINE-X does not allow you to choose anything other than RWG/Log3G10. Previous gamuts and gammas like DRAGONcolor2 and REDgamma4 are now obsolete and have nothing to do with IPP2. And yes, a correct implementation of IPP2 will not throw out your sensor data, but Resolve's implementation does indeed make it much more difficult to retrieve that data after it's already applied the tone mapping and highlight rolloff prior to hitting the node graph.

Screen Shot 2017-11-15 at 5.45.04 PM.png (18.39 KiB) Viewed 3461 times

when REDlog Film is selected in RESOLVE then the IPP2 settings for Output Tone map and Highlight Roll Off are not doing anything. So nothing is messed up for the LUT.

Why does it even allow the settings to be changed then? This is what I refer to when I say it is buggy.

Here is the white paper on IPP2 workflow clearly laying out how you debayer to RWG/Log3G10 first, then you grade, then you apply tone mapping.

[...]Even in RED's own REDCINE software any kind of Look Up table is added AFTER the RAW data are processed.[...]

This statement highlights the crux of the confusion with Resolve's implementation of IPP2. Looking at page 887 of the latest Resolve manual, the Grading Order of Operations is specified. Three major categories are described: Operations that take place before nodes (Camera RAW is first), Operations that take place within nodes (OpenFX is in here, many steps before LGG, Contrast/Pivot, Custom Curves, Hue/Saturation, and LUTs), and Operations that take place after nodes (including output LUTs and display LUTs).

IPP2 has a three stage pipeline the first is Primary RAW development (Conversion to RWG with Kelvin and Tint controls and Encoding to Log3G10 with ISO and Exposure controls). Implicitly there's also an input LUT that handles OLPF compensation as well. That first stage of the IPP2 pipeline delivers precisely what Camera RAW needs. The second stage is known as Grading, and includes controls for CDL curves, LUTs (aka Creative LUTs), Contrast, and Curves. For all intents and purposes, that's a Node. It could be implemented as an OFX Plugin named "IPP2 Stage 2", and it could contain all the controls described in the document 915-0190 Rev-B RED OPS, IPP2 Image Pipeline Stages.pdf. Smarter people that me might know whether the interpretation of the CDL curves is isomorphic to Resolve's "Resolve Color Management Input to Timeline Color Space Conversion or ACES IDT" or not. If so, then the IPP2 "creative LUT" could slot into Resolve's "Input LUT", and then we just have the problem of having some extra Contrast and Curve functions as a mini-node before Edit Sizing and Input Sizing. No biggie. But...if we cannot pun the CDL and creative LUT operations to what Resolve thinks its doing in the second and third stages of its pre-node operations, we're already in trouble.

But the real trouble is the third stage of the IPP2 pipeline. Again, if there were an OFX plugin called "IPP2 Stage 3" with the appropriate controls for tone mapping, output color space, highlight roll-off, HDR user nits limit, and output gamma, everything would be fine. Or if it were explained that yes, setting these values in the Camera RAW panel doesn't actually have any effect until after the output sizing operation of the "Operations that take place after nodes", we could all sleep at night. But I don't see that in the documentation, and I don't see that it any response from BMD about how IPP2 is actually implemented in R14.1.

where's the advantage to useing this in place of my current ACEScct workflow?
speed?
ease of use for folks who are not comfortable with scene refered workflows?

where's the advantage to useing this in place of my current ACEScct workflow?
speed?
ease of use for folks who are not comfortable with scene refered workflows?

Looking at page 137 of the current manual (which delineates how scene-referred workflows touch the three stages that are also relevant to IPP2), it looks like the pieces really are there, but they are not fully connected into a coherent UI. If BMD can connect the dots between IPP2 and RCM so that I can actually load a creative LUT (better yet, flip through creative LUTs) and select preferred contrast/highlight LUT using nice pulldown menus instead of hunting through the extremely lengthy (and many) options of the RED IPP2 LUT folder, I'd be a much happier camper.

Looking at page 137 of the current manual (which delineates how scene-referred workflows touch the three stages that are also relevant to IPP2), it looks like the pieces really are there, but they are not fully connected into a coherent UI..

thanks, i am somewhat famailiar with scene refered gradeing haveing been using ACES in Nucoda since early 2014 or so, then in Resolve later

I can actually load a creative LUT (better yet, flip through creative LUTs) and select preferred contrast/highlight LUT using nice pulldown menus instead of hunting through the extremely lengthy (and many) options of the RED IPP2 LUT folder, I'd be a much happier camper.

is using a "creative lut" the only / biggest advantage?

i don't go near those anyway, prefering cleaner maths when useing transforms generaly, but aside from "creative luts" is there any other reason to explore ipp2?

[...]
is using a "creative lut" the only / biggest advantage?

i don't go near those anyway, prefering cleaner maths when useing transforms generaly, but aside from "creative luts" is there any other reason to explore ipp2?

Well, I just tried re-approaching DR 14.1 with a more open mind, and Davinci RCM. And aside from the creative LUTs (which I cannot fathom--where on earth do I enter the "Creative LUT" info that the checkbox acts upon?!), I cannot seem to make the output tone map nor the highlight rolloff features work at all. It's true, I'm using just a single-screen, not a separate, calibrated monitor for output display, but gosh...should it be hard or easy to use IPP2 the way I use it in RCX? I want it to be easy! And I want it to be consistent. I shouldn't need to ever think about "this is Resolve's way of implementing IPP2 (and woe unto all who might fail to set one particular parameter in a way that wrecks it, or woe unto another who fails to set one particular parameter some particular way and thereby wrecks it).

With this implementation of IPP2 with red files being transformed before you can access the data, how do you make pre and post gamma curve transform exposure adjustments? This just throws out a huge amount of image flexibility.