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 :)

Prometheus DI?

The film is now being color-timed by Steven Nakamura over at Company 3 in Santa Monica, which I believe is an all-daVinci Resolve facility. Don't know how much is 2K and how much is 4K. My bet is that they're working with 2K proxies just for the decision-making process, and then applying the same corrections to the 3D 4K files at the end.

There is no such thing as 4K 3D, at least not in any distributable form, because there is no 4K DCP format at this point in time. And given the VFX content of this picture, it's quite safe and logical to assume that the final finish is 2K, regardless of the live action shooting format.
 
So limiting FX to 2k, rather than 4K, is man hour limited, or render compute time limited?
 
So limiting FX to 2k, rather than 4K, is man hour limited, or render compute time limited?


Probably a bit of both, you figure that -- if quality of the final product matters to you -- a 4K effect has to be better-done in terms of attention to fine details than a 2K effect. Not every effect of course is made more difficult by working in 4K instead of 2K, but I'm sure some things have to done with a finer attention to detail. Then there's the processing/rendering time issues. etc. And remember that the amount of footage is doubled in 3D.

I'm half-joking, but I wonder if anyone has considered doing the entire left eye footage, efx and all, at 4K for the final 2D version, and then doing the right eye at 2K, and downconverting the left eye to 2K, for the 3D version?
 
I'm half-joking, but I wonder if anyone has considered doing the entire left eye footage, efx and all, at 4K for the final 2D version, and then doing the right eye at 2K, and downconverting the left eye to 2K, for the 3D version?

If the abstract I linked to previously is accurate then that's not a funny idea at all, and exactly what I was wondering. It doesn't seem odd when you consider that an RGB image takes the vast majority of it's resolution dependent information, it's detail, from a single channel. Why couldn't 3D do the same and derive detail from one side?
 
If the abstract I linked to previously is accurate then that's not a funny idea at all, and exactly what I was wondering. It doesn't seem odd when you consider that an RGB image takes the vast majority of it's resolution dependent information, it's detail, from a single channel. Why couldn't 3D do the same and derive detail from one side?


If it's a post conversion scenario, that might make some sense. But if it's dual camera stereoscopic production, there are already numerous differences between the two eyes that need to be sorted out. Adding to those differences would not be a good idea, and any differences between the two are likely to contribute to discomfort for the viewing audience.
 
If it's a post conversion scenario, that might make some sense. But if it's dual camera stereoscopic production, there are already numerous differences between the two eyes that need to be sorted out. Adding to those differences would not be a good idea, and any differences between the two are likely to contribute to discomfort for the viewing audience.

But even in production it could lead to a viable means of compression for a 3D hybrid file, where one eye is a subordinate, lower resolution layer rather than a complete and equal frame.

An alternative method of processing for a 3D codec might involve a live comparison of the two feeds and recording one complete frame as a base track and a second difference track. Let the user define a +/- factor and you could tweak it in post. The vast majority of the information in two stereo frames is redundant, is it not? The differences between tracks lie in the shadows falling off of a relatively small number of edges and their perceived location in space, right? A difference track could be as little as edge info or a full greyscale displacement map. Throw out the redundant info, and only record the unique data (+/-) on the secondary track. The savings in data storage and playback processing could be considerable.

If you were really smart you might try to create vectors of the difference track, and record that instead of actual image data. Then for playback use the vectors to duplicate and shift image data from the base track to create the difference track, but that would only account for spatial differences and neglect shadow information. That problem would also have to be solved. Then 3D file sizes would be quite comparable to the 2D file size.

I don't imagine these are original ideas. Someone must be working on similar theories already. These are just the brain farts of the uninitiated.
 
Last edited:
Back
Top