Compositing CG vfx into live action RED footage

[SuperFrofessional]

we shot our short at 4K for better control of depth of field. because the visual effects were going to be created on PCs, we rendered out placeholder .tif sequences at 720HD with basic "one-light" color passes. the CG characters and effects were rendered out in maya/mental ray at 720HD, and have been composited using after effects.

now it is time for final color correction (and the rest of post). though the characters have been composited into the scenes, (depth, blur, edges, etc.) they have not been color-timed to match the backgrounds.

I am assuming that our next step is to go back into RedCine and output 720HD .dpx files of the original background sequences, with no compression? then we lay our composited characters over those and color-correct the CG characters to the gray & flat color-space that the original files output at? then we color-correct the entire image (CG & live action plates) to give it the look and feel that we want?

is there anything I'm forgetting? a better workflow? are there better formats to ouput these sequences in? are there tips/tricks I should know? my goal is just to have the maximum resolution/color-space in the live action plates, so that we have more to work with in color correction.

any and all advice would be hugely appreciated. I'll of course post clips when we're done.

gracias.

 

[John Tissavary]

Here's how I do it:

Export openEXR 16(f) color corrected from RedCine or Scratch. That's 16bit floating point file format that can contain the most amount of information possible. Since R3D is a twelve bit format, it will contain all of the info, including superblacks and superwhites, if that's what you want. Per your spec, you also need to choose a high bit compositing package like Nuke or Shake which can work in floating point bit depth so that internal ops are not truncated and prone to artifacting.

In compositing application:

Import openEXR sequence of greenscreen into a 16bit or floating point bit depth project. I use Nuke, where it is possible to pipe the same node into mutiple pipelines, some software does not have this capability, but basically create one version of the comp input image to make the green as delicious as possible (2 pixel blur on green channel, color correction to minimize non green colors in greenscreen), and a second to have as good a foreground (non-greenscreen) image as possible.

Pull your keys using whatever you use - I suggest keylight or Primatte - then layer your foreground over your background with the matte channel you pulled in the keying nodes or effect.

Now there are two ways to go for color correction, based on personal preference and tools available:

1) Grade fore & backgrounds in the compositing app. Most comp apps have excellent color correction tools.

2) Render the comp to a DPX or other appropriate image sequence, also render a second sequence of just the matte channel. Import both into grading application like Scratch, Baselight, or whatever, and use the black & white matte as a holdout to be able to correct the foreground & background elements with perfect separation control.

Or, have someone with the right tools and experience do the work for you. Color correction and compositing are arts unto themselves, and take years to get good at.


Regards,

John T.

 

[Mike Harrington]

is there something wrong with your origional tiff sequence?

what format is your cg characters rendered in

cg renderers work best with linear light.....I am not qualified to explain why, but I have seen the difference with aliasing, edges ect
this is a hot topic now, and many pipelines are going so far as to remove all gamma from incoming textures, and using mostly .HDR or .EXR rendering to those formats, then in compositing using a moniter LUT and only apply the gamma at the final stage.

the reason i say this is to question why you would want to render out R3D to DPX....i realize that is the standard for most people but DPX is 10 bit log....your cg is most likely floating point linear, and if it is EXR or 16 bit TIFF has much more color space than DPX. 10 bit log is said to be equal to 13 bit lin.

if i was compositing linear footage with linear cg, i would keep it linear and use LUTS, then if you want convert to DPX after grading.

 

[SuperFrofessional]

gracias lunacie and mdharrington for the genius information. and if yall want to duke out whether I should go dpx or exr, that would be great too. the cg is being exported as tiff uncompressed from maya/mental ray. (logged 32 bits per pixel, but then says it's only using 24 (??)

thoughts?

 

[Mike Harrington]

uh....32/24

make sure you don't have 8 bit images

that could means 8 bits per color channel 3 for color 1 for alpha....32bit, and if the alpha didn't get saved, it could be only 24 bits

if you have an alpha and it still reads 24 bits then you should be ok, thats a weired bit depth from what i am used to.
but if there isn't an alpha, then you may be dealing with an 8 bit image.

just make sure it was rendered out 16 bit per color channel or higher

 

[John Tissavary]

There's really nothing to duke out...

Also, I agree about always compositing in linear light. Do not do your calcs in log space. The easiest thing, if you're getting log images, is to do a log-to-lin operation at the beginning of the composite, then all the compositing and color correction, and finally a lin-to-log operation if your output format must be in log space.

However, there is absolutely no point in having a 16 bit integer or floating point file format contain log encoded color. The purpose of log is to overcome the limitations of a 10bit file.

DPX has less color and luminance information in it than R3D (12 bit), openEXR 16 float, or Tiff 16 linear. The only reasons I can think of to choose DPX over openEXR or Tiff: 1) you need to playback in realtime on Scratch, Baselight, etc... 2) you don't have enough disk space to hold 16 bit files.

That's not the end of the story, though. If you want to really get anal, the ILM 'half' format, which is 16 bits of floating point numbers, is more accurate than Tiff 16, which uses 16 bit integer numbers. My choice is always to use openEXR 16 float, unless I need realtime playback.

And absolutely, positively do not use 8 bit files unless you want your comps crippled right out of the gate.

Here is how you figure out bpp (bits per pixel):

8 bits RGB = 24 bpp
10 bits RGB = 30 bpp
16 bits RGB = 48 bpp

I do not include alpha channel as part of my pixel bit depth calc, because it's irrelevant to understanding the robustness of color & luminance. What is important is how many integers or floating point numbers are used to describe each color component of the pixel.

Even if you're getting 8 or 10bit files from Maya, make sure that you're using 16bit for the photographed elements.


cheers,

John T.

 

[SuperFrofessional]

md and jt, I'm hugely appreciative of yall's help on this stuff. hopefully I'll have some roughs up soon and will PM yall with a link.

 

[Charles Angus]

720HD DPX is a little non-standard, no? DPX is usually 2k or 4k. I suppose it can be anything you want, but 720 is a little small. You have up to 4k to work with...

It's not an option to work with higher res for compositing, even if you intend a 720 finish?