SakeTami
IanHubert
IanHubert

patreon


Doing Better Greenscreens (Creatively & Technically)

Getting into reasons our greenscreen shots might not look as good as we'd like (along with some technical stuff you should know!) I'm hoping I didn't botch the technical stuff too much :P
Also!
As I mention in the video, I'll be releasing a more tutorial-oriented breakdown of a linear workflow (the biggest exciting thing that's changed my work in the past 6 years, probably!) hopefully before the end of the month.
Also Also!
New Dynamo Dream episode coming on the 1st! "Prepare for Execution"

I'm thinking of listing it as episode 1.5 (ideally to be watched after Salad Mug, for new viewers), because in hindsight I think it sets up a lot of things pretty well, and adds enough narrative momentum that I can burn some of it saying "and now let's see what this weird guy in space is doing"- but a friend said that "1.5" would make them assume it was skippable- so we'll see what happens.

Doing Better Greenscreens (Creatively & Technically) Doing Better Greenscreens (Creatively & Technically)

Comments

Hey, I need your help. I'm using your techniques to composite a character shot on green screen into a 3D world. The problem is that when I add volume to the scene, the alpha layer of my green card plane casts a shadow on the ground. No matter what I do, I can't get rid of the shadow when the volume is active. I tried increasing the number of light and volume bounces, but nothing works. Do you have a solution for this? Thanks a lot.

itay oz ari

I appreciate you using stills from "Days of Heaven." One of my all; time faves. Cheers!

Smoking Monkey Films

Automatic log conversion is a shortcut from using cst’s Davinci resolve preferences Color management Change to Davinci yrgb color managed Click custom Davinci wide gamut intermediate 10000 nits Input slog 3 Output rec 709 scene or (your pref output) Unclick white point adaptation And vwoillah all log footage is automatically converted no more need for cst’s per clip in the color page.

Leon Cuttem

Repo man!!!

KP

Oh! Sorry, which textures specifically? The ship in ASPIS was mostly just some bare-metal image covered in little cut out bits from this one: https://www.textures.com/download/MetalAircraft0087/106460 There's also some metal grating in there, which was easy to model! Just subdivided a plane a bunch, double tapped "i" to inset each face individually, then extruded them all down.

Ian Hubert

I think I just your name for the rotoscoping in the new episode from Ian… then I believe you:-) well done!!!

Fransoa

Does someone knows the films Ian is showing in his video? It looks so inspiring...

Fransoa

You could use this workflow, but instead of using the Color Space Transform, add a File Transform effect and import one of these Black Magic LUTs: https://cinecolor.io/products/blackmagic?srsltid=AfmBOopf_X8ehfZBDpYzz1iOSjLM1AvtM0N65rtcN5dRhI2w2ftfq2MM

Hayden Mason

https://youtu.be/7gDhUxey33M

Hayden Mason

This was great, really looking forward to the linear keying workflow because this has been such a plague and I feel very isolated, naked and afraid while trying to figure out how to get Blackmagic footage out of log AND back again after keying WHILE in after effects. If there's any way you can attempt to show how to do this specifically in AE that would be really a giant life saver for many many people. The topic is not widely covered. So yea. AE and Blackmagic. Thanks!!!

Austin

How did you know this is what I needed????

Lord Cadaver

Yeah I was kinda rambling off topic with the Blackmagic thing. I just like weird sensors :P I agree about the OLPF. Reminds me of another recent phenomenon, which is that resolution is sorta outpacing optics, especially with so many DPs shooting on vintage glass now. So the lens itself is almost acting like the antialiasing filter.

Zeke Faust

Oh man, I'd never heard of Sigma's Foveon sensor before. That's some seriously cool tech. And yeah, that would handily address this issue. It's not clear to me how Blackmagic's RGBW filter arrangement has anything to do with this particular problem, though. It's not strictly a bayer pattern, but it still only captures a single "channel" (for lack of a better word) per photosite locale, so it's still effectively subsampled from the get-go and has to synthesize the missing color data with guesses. I am excited about RGBW for other reasons, though (e.g. better colorimetric accuracy). Regarding this particular problem, I'm personally most excited about how antialiasing filters are becoming more and more common. Some people complain about how it makes the image "blurry", but what they don't realize is that the "sharp" result they get without antialiasing filters is effectively fake, and the blurry result is a closer representation of how much data the camera sensor is actually capturing in the first place. And a good antialiasing filter gives you the opportunity to compute actual full color data within provable error bounds.

Nathan Vegdahl

Damn it, you've nerd sniped me! Now I feel like I need to put on a fedora and say "well, aaaactually...". ;-) The inverse square law isn't a myth, at least not any more than the subtended solid angle equations are. The subtended solid angle is indeed how you compute light falloff for perfectly diffuse emitters. But part of why that math works out is *because* of the inverse square law applying to each point on the light's surface. As a counterexample, if we take your mile-wide light but make it emit its light in parallel rays (like a laser) then there's no light falloff with distance at all, and the subtended solid angle equations break down. The cause of light falloff with diffuse emitters is because the light rays from each emissive point spread out over distance, making the energy density decrease the further away you get from the point. And that energy density drop is accurately described by the inverse square law. In other words, you're 100% correct that the light falloff of perfectly diffuse emitters are accurately described by the subtended solid angle they occupy. But it's not correct to say that the inverse square law is a myth--it is in fact part of why that subtended-solid-angle math works in the first place. In reality, of course, light falloff is more complex than any of this. Lasers are one example. But also, in some circumstances light can actually *increase* in intensity with distance as well, within certain localized areas. Caustics is one example of that. The real take away is that light falloff is complex, and all of the math we've discussed here so far are approximations to some extent. (Okay, taking my fedora off now.)

Nathan Vegdahl

hey Ian i been at this for a while now what texture did you use to make the inner part of the blue taxi and the a single point of time in space how did you make the floor textures

Mamadou Mboup

Rotoscoping (especially AI rotoscoping) has a VERY long way to go before it can match up to greenscreen. With a greenscreen, you can extract tons of fine edge info, semitransparent pixels, and of course you don't have to worry about light wrap from the background. Rotoscoping certainly gives you more flexibility, but takes longer and often produces a worse result

Zeke Faust

I am just wondering why still working with greenscreen when rotoscoping has been so improved the last days also via AI. so go in the outside shot the video and rotoscope it...That is my workflow:-)

Fransoa

Allow me to out-nerd that. Light doesn't fall off by distance square - that is myth. Light falls off in relation to the subtended solid angle of the light source, as seen from the point being shaded. This is quite nicely *approximated* by distance square... until you get really close, and the light almost subtends the entire hemisphere as seen from the shading point. Imagine a mile wide light, two inches away. Moving that to one inch away will *not* change the arriving light much at all .... where's a 1 inch square light 1 foot away will subtend almost exactly a quarter of the subtended angle when it's 2 feet away. Not exactly.... but veeery close. The smaller subtended angles we're talking about, the closer it gets to "distance squred". Thanks, I'll be here all week - try the veal. :)

Zap Andersson

This is also why I'm fascinated by alternative CFA solutions like Blackmagic's symmetrical RGBW sensor or Sigma's now defunct Foveon sensor in its original form, which took advantage of the silicon's light scattering properties to allow you to make a "3D" true 444 sensor with a real color sample at every photosite position. I guess it's just a case of cost/benefit and established techniques being 'good enough', which to be fair, they kinda are.

Zeke Faust

I can't speak from experience on this, but that certainly makes sense to me that after you reach 10-bit color, your biggest enemy is going to be bit rate. Having said that, I assume there's a similar thing where once you hit a certain bit rate, then chroma subsampling becomes the main issue. And the thing that's devious about chroma subsampling (and I suspect you know this Zeke, just saying it out loud for the onlookers who might not know) is that when you're talking about doing chroma subsampling on full-resolution footage from a modern digital camera, it's actually even worse than you would think. Basically, with the exception of sensors that have sufficiently strong (physical) anti-aliasing filters, modern camera sensors all have a kind of subsampling fundamentally built into them: bayer filters. But that bayer subsampling is fundamentally misaligned with the chroma subsampling of video formats, and thus chroma subsampling in the video format actually leaves you with *even less* of the actual, real color data than you would think. It's throwing away a bunch of the real color data while also holding onto a bunch of the synthesized guesswork color data from the debayering algorithm. (Incidentally, this is one of the reasons I can't wait for RED's patent on raw video codecs to expire, because with an actual raw codec you get almost the same space savings as 4:2:0 subsampling without throwing away any of the real color data, simply because none of that fake synthesized debayering data is created in the first place.)

Nathan Vegdahl

Ian, awesome video! Now, apologies in advance for being "that guy". Your math on light falloff was off. Light falls off according to "energy = 1 / d^2" (one divided by distance squared). That means its brightness is quartered every time the distance *doubles*, not every additional meter you move away from it. It's still a fast falloff, just not *that* fast. We wouldn't be able to make out the sun in the sky if light quartered every meter. (Having said that, I'm now wondering if it might have actually been *me* that mis-spoke at some point and gave you bad info here...) Nerdy aside for no good reason: additionally, even the "correct" inverse-square law of light falloff only applies with complete accuracy to point lights. For area lights it's a bit more complex. Inverse square is still generally a decent approximation, but the full math to work it out is more complex and depends on the specific geometry of the light among other things. Nerdy aside 2, also for no good reason: there actually is a kind of light falloff that's more like "quarters every additional meter", and that's the way that light falls off when it passes through things like fog, hazy water, etc. In other words, volumes (also known as "participating media" if you put your fancy pants on). If I recall correctly, that light falloff is described by something like "energy = (1 / (1 - density))^-distance" (one divided by one-minus-density, all raised to the power of the negative distance). And depending on the density, that will indeed quarter the light every meter. Volumes soak up light *super* fast.

Nathan Vegdahl

*Oh and still, any of this process of bringing sequences into Resolve from Blender and grading it on it's own or to match will still be super helpful. Seeing it done in somewhat real time really helps! but nw if not part of the plan.

Stephan

Thanks Ian! That actually helps a lot. I should note, as I'm doing this stuff of the side of my desk, and only on occasion, I'm probably running on about 60-70% dunning-kruger... I'll just anticipate being corrected at every turn. It sounds like what I needed to know, that you've been able to share is that there is more for me to learn about EXR's and their ideal use as well as how to grade them in Resolve. It sounds almost like log footage in that they're designed to carry as much information as possible, which means all I'm missing is understanding how to make the most of that info in Resolve. *I did see there were some resources when I searched for how to bring AgX into Resolve and retain the look that was in Blender. The one that looked most promising was a github link (by Juan Pablo Zambrano), wherein they have a DCTL file that can be used to apply a lut to the AgX sequence in Resolve. Unfortunately it looks like importing DCTL files is locked to the Studio version of Resolve, so it won't work for me. But ultimately, with the info you shared, I think I'm more interested in figuring out how to grade with the EXR's in Resolve to get a good look rather than just running off of the look I had in the viewport in Blender. Though there is something to consider there, when I've been adjusting textures & lighting in Blender to look a certain way.. maybe I should try to stick with that but I think knowledge on how to grade the footage will still solve that. I can render some jpgs or pngs as references and then grade accordingly in Resolve. Thanks again!

Stephan

I would be a fun idea to let us download a log shot of yours for us to make a cg shot. then u make a video giving tips on what could be improved

alex

Ooooo! Yes okay! Nathan actually made us a tool for EXACTLY this problem (it can reverse engineer IDTs with surprising accuracy)- I'll cover it!

Ian Hubert

Awesome video Ian, I'm looking forward to the in-depth linearization tutorial. I just bought a used camera off ebay, that doesn't have an official aces idt, so that would be super useful.

Jeffery F

Oh! Thanks yeah that'll be a great thing to touch on. It sounds like I don't have much to add* that you don't already know, but effectively: proper linear data doesn't look great on monitors, so it has to be interpreted to look good for our eyeballs, and AgX is a preview tone-map for doing that in the viewport. There are formats that can bake that preview tone-map in, if you like it, but since the benefit of EXRs is they can store the linear data, that preview is ignored when it's exported out of blender. Meaning, yeah, you'd have to figure out a way to import that same AgX transform as a LUT in Resolve, so you can do that same transform/interpretation on the linear data. Doing a google search for "AgX in Resolve" shows a few promising links, but you've probably already checked those? THAT SAID- since the benefit of EXRs is their ability to hold linear high-dynamic-range data, if you have a look you like and no longer *need* that data, I don't think there's any harm to just saving to a different image format (pngs or something) that'll save the image with the look burnt in. *there's some dunning-kruger and I'm not sure if I'm still overly confident on the first hump or if I've finally paid my dues and actually kind of have my head wrapped around this :P

Ian Hubert

Thanks for this Ian! Every video of yours is like a masterclass lesson :D I am guilty of compositing in log myself sometimes, but not with greenscreen. When I have to comp 2D/3D elements over a background live-action plate shot in log, I convert the elements in the same log format and try to see if they match in log before doing a rec709 CST and check if it works. In my head it's somewhat similar to matching the footage grain in the red, green and blue channel first, but deep down I know it's probably compositing blasphemy hahaha

Armando Marchetti

This was great. Thanks! Good timing. I was just having to bring some footage into resolve this week and was wondering if I was doing it right. I'm looking forward to the full technical breakdown for the rest of it. If I could ask you to cover one additional thing, and this may be relevant for the next video (..or maybe not), can you consider including some info on how to bring rendered scenes in Blender into Resolve? Specifically, I'm wondering about AgX. Since that came in and has sort of replaced filmic, I haven't quite been able to get consistent info on how to manage colour once it's brought into Resolve. I've found at least when rendering as EXR's, the colours are wildly different in Resolve from Blender. Do I have to normalize the rendered scene as well? If so, how do you do it? Or is this just a view transform thing? (do i even know what a view transform is? who knows..) I'm curious for both matching live action footage as well as just colour grading fully CG scenes. Re. AgX, part of the issue I've had is that when researching online, it seems like there's not really very consistent info on how to bring it into Resolve for editing. Any info would be much appreciated! Thanks again for the great videos. Looking forward to episode 1... .5

Stephan

thanks for the video i always had this question about the keying how to fix bad dark edges and flickering hair how can you match your green key into the scene using blender and how would you do it

Mamadou Mboup

Green screening Air Traffic Control was a nightmare and a half.

Blake Rizzo

THANK YOU SO MUCH FOR THIS

Blake Rizzo

And that would literally just come down to the bitrate of the compression? Damn- honestly I figured the subsampling/bitrate was kind of DEFINING the compression, not a whole separate thing, but that makes sense for sure. Choose the highest bitrate possible! And yeah!!! I'm going to cover that stuff in the proper linearization tutorial next week! I think I *finally* have my head wrapped around it enough to make a good video (oh man. Watching a single point in space, and the shots where I didn't turn off tone mapping stand out SO much).

Ian Hubert

I'm wondering now if Magic Mask or Rotobrush would've been a better solution for that Single point in Space shot, since it's generating details from training data rather than trying to extract them from pixels! Dang I shoulda tried that! Anyway Between bit depth, chroma sampling, and compression, in my opinion compression is the thing that affects a good key the most. With 10 bits, you have 1024 shades per channel, meaning that each channel can support a maximum black-to-white gradient of 1024 pixels wide. Now, normally gradients are a lot subtler than that. BUT, the camera's sensor noise is usually more than enough dithering to eliminate any banding. But if a shot is compressed, with huge blocks of the image chunked together, with multiple frames interpolating over time in the case of inter-frame compression, then it doesn't matter what the bit depth or color sampling is! As an aside, in addition to your great list of common keying mistakes, I consistently see beginners make the same two technical errors in keying: 1 - They try to do their entire key in 1 node/effect, rather than multiple stacked effects with different settings. You'll almost NEVER have a shot where a single keying node is enough to deal with the entire shot, as each area generally needs its own settings. 2 - They don't denoise the shot before keying. Noise is great as a built-in dithering solution, but it's a double edged sword: Noise, even subtle noise, can destroy your key with edge chatter and color interference. Neat video is the king of noise reduction, used at the highest levels of VFX, but Resolve's built in denoiser is pretty solid as well. Removing the noise before the key is critical to set yourself up for success later in the comp. 3 (bonus) - Another common mistake is not using a separate comp/node chain strictly for the alpha component. Treating the alpha channel and the color channels separately allows you to be much more flexible with your key. Doing so lets you make all sorts of color corrections and filters to get the best result (for example noise reduction!! Or, using a subtle Hue curve to bring a fickle color back from the edge of being keyed). Then, since the RGB component is in a totally separate branch, it's unaffected by these corrections, with the despill being the only thing happening to it.

Zeke Faust

Hey Guvernor did you know that someone has created a youtube playlist of your patreon only videos. Just a heads up fellah.

Benja Min

AH! That's a good idea!

Ian Hubert

Call it ‘Episode 1, Act 2’.

Justin Harrison


More Creators