Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Green Screen and DPX

Green Screen and less noise

Green Screen and less noise

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.
 
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
 
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.
 
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?
 
As if you can't tell...I'm all about the noise

As if you can't tell...I'm all about the noise

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.
 
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.
 
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.
 
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.
 
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.
 
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
 
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
 
Back
Top