Green Screen and DPX

[Mark Allen]

simple note. For Greenscreen work, just use dpx. It's a whole different world to anything else.

We're doing a challenging greenscreen project over here at Allucinari and tried a few options - avoiding dpx because of the file size. Finally we tried it (again) and realized we had wasted all the time not using it. It's not just better on a technical weird numbers level. It's quite obviously visually better.

(Evaluated using After Effects Keylight.)

(Added later for those who might not read the whole thread: tiff and dpx are of similar impressionistic quality, tiff's are larger files thus my preference to dpx. It could be proven that tiff's are technical even better, but the extra 10mb per file has to be taken into consideration for our work-flows. If someone does do tests and it seems to be much better, I'd switch to to tiff.)

[Joel Kaye]

We're doing a challenging greenscreen project over here at Allucinari and tried a few options

Thanks for the tip. It is looking like building a system capable of handling uncompressed footage may be the way to go. With hard drives so cheap now it's not that bad an option.

What other codecs did you test? Did you test Cineform? I think one of their claims to fame is it's supposed to be a good codec for compositing.

[Chris Kenny]

Of course if Red does full-quality 4K QuickTime reference movies at some point (not playable in real-time, obviously), you'll be able to feed the footage right into your compositing app at full quality without going uncompressed. Well, into compositing apps that can read QuickTime files anyway, like Shake. Pretty amazing low-budget compositing workflow there!

[Jeff Kilgroe]

I'm hoping that day comes sooner than later, Chris!

We're going to be testing this at LART. Here's a question for Mark Allen... How did EXR files hold up, assuming you tried EXR? IMO, DPX definitely seems the way to go, especially working in Shake or Nuke.

[John Tissavary]

[QUOTE=joelnet;112170]Thanks for the tip. It is looking like building a system capable of handling uncompressed footage may be the way to go. With hard drives so cheap now it's not that bad an option.

What other codecs did you test? Did you test Cineform? I think one of their

The best file format I've ever used for _ANY_ vfx work is OpenEXR (http://www.openexr.com/).

There's none better - 16 & 32bit floating point options, flexible number of channels (I've used OpenEXR with over 60 channels, all but RGB for controlling the image in compositing). And it also supports Nvidia's Cg language so image data can be processed directly on the gpu - something Scratch & Redcine are already doing so wonderfully.

Not sure if RedCine has EXR out, but Scratch does.

cheers,

john tissavary

[Jeff Kilgroe]

Yes, REDCINE does output OpenEXR. ...Hence one of the reasons I asked Mark if they tried it. :)

I just got a R3D greenscreen clip to play with, but won't get to it until tomorrow when I have access to systems other than my G5 quad here at home.. Left my MBP at the office.

[Anders Holck]

I'm very interested in getting some r3d key footage to test.
Please send me a PM if you have something you can share.

[Mark Allen]

Yes, REDCINE does output OpenEXR. ...Hence one of the reasons I asked Mark if they tried it. :)

I just got a R3D greenscreen clip to play with, but won't get to it until tomorrow when I have access to systems other than my G5 quad here at home.. Left my MBP at the office.

Yes, we tried openEXR at my lead artists' suggestion. It didn't compare to DPX. Neither did Tiff nor (not surprisingly prores). [Again... added later and clarifying... tiff's QUALITY was the same, but the file size was so much larger, that was the comparison disadvantage of tiff.] We didn't try cineform. Is that an option? I will look into it.

I am not a scientist, so I'm totally willing to accept that my non-scientific tests were lacking. If someone would like to open my eyes to openEXR with some instructions that may clue that I did something wrong (user error), i'd be happy to try it out. 8 mb for openEXR vs. about 38mb per frame for dpx means there is an obvious advantage of openEXR.

[Mark Allen]

I'm very interested in getting some r3d key footage to test.
Please send me a PM if you have something you can share.

If there is a way of making the r3d files smaller, that would be a possibility but anyone testing would need to sign an NDA as everything I do usually is NDA for at least six months.

Is there a way to shrink down r3d?

I could maybe send out a series of frames as a few codecs as well.

[Jeff Kilgroe]

EXR in most cases is more heavily compressed than DPX, but EXR does have various incarnations and options and is intended for HDR imagery. All the info can be had at www.openexr.com . In REDCINE, the only OpenEXR parameter I recall was 16bit float color space. I need to play with the EXR output to see which version it's producing.

This is a good area for testing though -- I wonder how REDCINE goes about its EXR creation and if there are any issues in transcoding from the demosaic'd bayer wavelets to the EXR scheme and if there's any room for improvement. I'm kinda thinking that this is just a basic implementation of OpenEXR support as it only supports 16bit float (OpenEXR "half" mode). Not that support of the 32bit modes would provide any extra data, but may be useful to some for compatibility.

[Gavin Greenwalt]

I'm a bit confused how a 16bit Tif could be inferior to DPX? Is it because of the Lin -> Log -> Lin Curve being slightly off?

Do we need to shoot some grayscale chip charts to figure out what the actual LUT that should be applied is?

[Mark Allen]

I'm a bit confused how a 16bit Tif could be inferior to DPX? Is it because of the Lin -> Log -> Lin Curve being slightly off?

Do we need to shoot some grayscale chip charts to figure out what the actual LUT that should be applied is?

Hmmmmm... someone who is more of a scientist should probably do some greenscreen testing.

[Jeff Kilgroe]

I'll run some tests sometime today -- new version of REDCINE to work with too. :)

What gamma curve was used for export? I could see where Tiff, Cineon or EXR could be inferior to DPX if you stuck with REC 709. These would be better suited with a linear light export, or at least that's my thinking. What about filtering options?

As for shrinking R3D, the best bet is to just place the R3D file into a zip file. It might help a bit, maybe. Perhaps sharing some REDCINE frame output for analysis? Release multiple versions of the same set of 12 frames or so as DPX, EXR, TIFF and with different output settings.


I'm a bit confused how a 16bit Tif could be inferior to DPX? Is it because of the Lin -> Log -> Lin Curve being slightly off?

Possibly. Or other factors in the output conversion. Could even be (don't anyone take this personally) ...operator error. But it's not like we were given a technical manual. :)


Do we need to shoot some grayscale chip charts to figure out what the actual LUT that should be applied is?

Probably some RGB ramps too, a Macbeth or two or some specific color chip charts. Structured greenscreen and bluescreen tests.

[Mark Allen]

Jeff, if you'd like to give me some export specifications, I could run a few frames like that.

A quick note about charts and structured tests: One thing that I tend to believe is that sometimes perfect scenario tests don't give a good sense of reality. I don't know if I've ever been on a green-screen shoot where there wasn't some kind of rush and you didn't get to light the screen or the people just how you wanted for some reason - the way the actors ended up moving wasn't quite as expected so the light balance shifted - the costumer delivered a shiny gold outfit or a shiny metal armor outfit - whatever it is... and I think sometimes the solution for this real world situations is different than the structured situations.

About the Tiff's - I had tested linear light and rec709. I might have done something wrong, but I didn't have much luck with linear light and the rec709 performed nearly exactly the same as the dpx such that the additional 10 mb per frame didn't seem to make any sense and that's when we said "okay it's dpx." Now, the main point though was to say this.... there will be a tendency to want to use prores because of convenience (or some other format) - but it DOES make a difference to use the dpx or tiff. so, eventhough it's harder and bigger files... it is going to make a real difference. Any difference between dpx and tiff would be a tweaky difference which to the end user and your basic workflow will be relatively minor. prores or similar vs. dpx... it is worth the extra hassle. If you can't use dpx, tiff is fine and perhaps even "better," it's just going to be bigger movies.

About zipping an R3D. Not surprisingly, the zip file is exactly the same as the compressed file. (1.7 GB)

[Mark Allen]

I'm a bit confused how a 16bit Tif could be inferior to DPX?

Again - I was taking into consideration file size.

[Gavin Greenwalt]

oh ok. I thought you were implying that it was producing worse keys--Yeah the extra 6 bits are probably of slightly dubious value.

In regards to the charts, that tends to be something you do in pre-post along with distortion charts and the like. Once you understand what LUTs you need to apply it is something you can reuse, much like a printer profile.

[Philip Powell]

We shoot a ton of green screen/comp work and it's one of the major reasons we're looking at a Red.

But the best way to approach the whole process has always been a bit of an unknown for me.

I'm also curious on the shooting/Redcine end, how have you found the noise level to be? Does processing it at a lower ASA reduce the noise level much ?

For me, when it comes to keying (using Keylight) it's a lot about the noise getting the noise level down. Once you start having to push "Screen Strength" up very much to kill the noise, you start running into nasty looking keys.

I know the Red is appears to be low noise. But I can remember pulling some keys on what appeared to be clean footage from a Viper. And while it was better than a 900, it was still noisier than I would have liked or thought.


I also would love to do some testing on some green screen shots as well.

If anyone has some they are able to share, please just PM me.

[Mark Allen]

The blue channel is a bit noisy, but it's possibly the easiest material to key that I've worked with. It's abaolustely better than F900 material. And it doesn't have the grain of film which is always difficult to work with. I shot a hair spot on greenscreen with it... I don't think I would have even attempted a greenscreen hair spot on the F900. Still finishing that up though, will post when it's done (next year).

If I were in a position to do any testing, I would be inclined to bump up the level of the greenscreen more and risk the spillage in exchange for not having to increase the screen gain up.

By the way - we always treat our edges as separate keys from our fills. Usually for the edges we're just taking nearly the default and just cleaning up the screen - then we run a different key under that with which we fill in all the see through and bad part of the first key. The trick is making sure you don't have a double image edge or your underneath fill key isn't going beyond the edges of your softer beauty key. This applies no matter how many pieces you chop your character into (if any).

[Antoine Baumann]

Surely more R3D files are most welcome, including green screen.

so people able to share can PM me as well.

antoine.

[Jeff Kilgroe]

I finally got around to playing with my greenscreen clip a bit. Unfortunately, I can't come to any conclusive results with it. It's not lit well at all, it's noisy and the focus is soft.

I believe fxphd has some r3d clips for members that have some greenscreen. Other than that, I'm hoping LART will resolve some of these questions.

Mark, increasing your intensity on the greenscreen will help. Spill is just one of the evils that has to be worked around and the best solution is to have your talent/subject far enough in front of the screen where spill becomes less of an issue or even a non-issue. It also helps to have adequate and proper lighting throughout your scene.

I don't know what to expect from RED and how it will handle greenscreen at 320~500 ASA. When shooting the HVX, I typically had the screen lit to 60~65 IRE as that gave the best results in most situations. Closer to 60 was best, but it would depend on the subject and if I had my 35mm adapter on. White balance is a serious consideration, you'll want your lighting a consistent type or hue between the screen and your subject so once the white balance is set, you have the proper green background as well as the proper colors for your subject. With RED, we're choosing the white balance in post as we "develop" our R3D files, but the same principle applies... It pays to have good lighting on your greenscreen and on the subjects in front of it, even if you have to go rent or buy more gear. A properly lit scene will save tons of time in post.

[Philip Powell]

Again, assuming a brightly lit Green Screen, where the goal is least amount of noise. Wouldn't it be best, assuming it's practical to shoot/process at the lowest ASA as you could ?

It seems to me, although I never heard it come to much conclusion, one way or another that, to help the blue channel out, there was some discussion of shooting at a higher color temp and magenta filters. Long thread but interesting.

http://www.reduser.net/forum/showthread.php?t=4950&highlight=magenta

I've also wondered about use of DPX files for comp work. While not a big as Tifs, they are still fairly large, and if you start layering them, core matte, edge matte, a few effects etc, I could see where a lot of even newer PC/MACs are gonna start to slow way down.

[John Tissavary]

Yes, we tried openEXR at my lead artists' suggestion. It didn't compare to DPX. Neither did Tiff nor (not surprisingly prores). [Again... added later and clarifying... tiff's QUALITY was the same, but the file size was so much larger, that was the comparison disadvantage of tiff.] We didn't try cineform. Is that an option? I will look into it.

I am not a scientist, so I'm totally willing to accept that my non-scientific tests were lacking. If someone would like to open my eyes to openEXR with some instructions that may clue that I did something wrong (user error), i'd be happy to try it out. 8 mb for openEXR vs. about 38mb per frame for dpx means there is an obvious advantage of openEXR.


If your openEXR file was 8mb then someone did something wrong, no doubt. I'm getting 20mb for 4k out of Scratch. I also don't use a log curve - it's not intrinsic to the format as it is with dpx.

Since openEXR is a 16 or 32 bit float file there will be less quantization, more bits & decimal places to describe the pic.

I've pulled a lot of keys from film scans on major features using just about every file format out there, and I can tell you that there is no advantage to using DPX/Cineon over openEXR, in fact it's quite the opposite if you're doing any image manipulation.

There's no magic to this, it's pure math: greater decimal point accuracy = less quantization of data = increased image fidelity.

OTO, there's probably no _perceptible_ difference in quality between openEXR & DPX, it's just that if you start throttling the image it'll hold up to more abuse as an exr.






regards,

jt

[Gavin Greenwalt]

I've also wondered about use of DPX files for comp work. While not a big as Tifs, they are still fairly large, and if you start layering them, core matte, edge matte, a few effects etc, I could see where a lot of even newer PC/MACs are gonna start to slow way down.

Except that keying is goign to happen in linear space and HDDs are rarely the bottleneck in a large comp (the footage is precached into RAM pretty early on in the render cycle with a well written application).

As a result applying a DPX Log -> Lin Curve and a 12bit -> Native internal processing depth conversion operation will actually be one more operator in the stack and a flat file will have a smaller hit to the CPU.

[Mark Allen]

Let's do this.... If you feel there is a good way to do keying (which the RED camera is and is going to be pretty fanastic for) - present the workflow. I have no ego personally when it comes to technical things. I'll never own a patent like others in my family. Never rebuild my car... etc. So - I want to be shown the best methodology. If someone wants to share a methodology from start (r3d) to finish - I'll try it. I think I probably user errored the EXR I'm guessing. Let's start there - how would I export it from redcine or redalert. how would I set up AE?

[Philip Powell]

To me, there's some great keying software out there and it works well most of the time, but most of time I spend with keys, fixing problems, relate to noise. The less noisy my backing, the less time I spend trying to NOT destroy semi-transparent edge detail.

For me it would start with shooting.

While the Red is not noisy. I would ask how I could shoot to make it have the LEAST conceivable amount of noise as possible.

I would light and expose for a nice bright neon green, (Rosco) while shooting/processing at the lowest possible ASA.

It would seem to me this would be the way to start, based on my understanding of how the Red works. But I would have to get my hands on one to know for sure.

[dino g]

i can tell you, since this stuff was shot with RED #0031 our camera, that it was light perfectly and everyone that sees the footage from RED and at the higher end post houses here in LA/Santa Monica is blown away at the quality and perfection.

mark did an awesome job on the front end, so that is certainly not the issue.

[John Tissavary]

I'm using Scratch, not RedCine, and I think the settings are _slightly_ different. But, the basic idea is to select 'openEXR 16bit (f)' as your output format. In Scratch there's a LIN and LOG setting for this, but doesn't appear to be that way in RedCine, so I'm not sure what to do to ensure the colorspace is correct for your workflow.

You _can_ use a log exposure curve if you really want to, but it's not necessary for a floating point file format as there's more than enough data available for your >1 and <0 image information w/o tossing data bits for the rest of the image like DPX/Cineon does.

[GlennChan]

This has been hashed out in the LART thread, but sometimes it is difficult to avoid shadows landing on the greenscreen. How Red footage fares with such a situation will be interesting... though considering there's so little noise... I'd expect it to do very well.

[bsales]

Hey Mark and everyone.

My understanding about Keylight in AE is that it's definitely optimized for video gamma(2.2) - in Shake you can set the gamma space it's operating in. I think the gamma would effect your keys more than the file type. AE also makes some bad assumptions when you import files about what the gamma should be. The best practice is generally to set "Preserve RGB" on import and then modify your gamma using effects. DPX files are generally assumed to be log and OpenEXR are often video(2.2) gamma or linear.

I did a project recently with 35mm Cineon scans (DPX) and we went from log to linear in AE to composite, but I had to temporarily add gamma to get a really good key in Keylight.

[Stephen Williams]

This has been hashed out in the LART thread, but sometimes it is difficult to avoid shadows landing on the greenscreen. How Red footage fares with such a situation will be interesting... though considering there's so little noise... I'd expect it to do very well.

Hi,

Very often you will want to key the shadow as well, especially if you have green set pieces, matching the final composite.

Stephen

[John Tissavary]

Hi,



Very often you will want to key the shadow as well, especially if you have green set pieces, matching the final composite.

Stephen

I completely agree.

In my experience it's pretty rare to be able to pull a key off a single keylight or primatte operation. I

n primatte, of course, you can keep adding operators until you're done, but in Keylight I usually create several keylight nodes with their own masks to pull the best key possible - isolating shadows and other inconsistencies from edges or whatever.

Really, it's more standard procedure than not to have to create complex sets of keys to make it work.

cheers,

jt