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

Mixing M-X footage with original M-sensor footage

David Mullen ASC

Moderator
Joined
Apr 20, 2007
Messages
7,832
Reaction score
7
Points
38
Website
www.davidmullenasc.com
Since the new M-X sensor has new debayering software for it, what happens when you send footage shot on multiple cameras, some with the new M-X sensor and some with the old sensor, to the same post house using RedRocket for debayering, transcoding, downsampling to 1080P, etc.?

If they've upgraded the RedRocket for the M-X sensor, how does it handle the old sensor footage? Does it automatically detect the difference?

What happens if the final color-correction goes back to the original R3D files but now edited so that M-X and original sensor footage are intercut freely?
 
Thanks for posting this in a new thread David.

I asked the same question in one of the long and noisy threads and was afraid it would get lost.

Jim stated that you just have to process the footage through REDCINE-X and it will apply the NCS. The noise floor will be different for each camera, but the colors will match.

I am hoping to do this test in the next week or so as I have footage shot on both sensors.

It's a great question because the old R1's far outnumber the M-X sensors right now and it really becomes an interesting choice if you have explosion scenes or something where many cameras are required.

Another reason testing is so important!

David
 
I guess then the question is whether it's obvious to the post house when they are looking at files from an M-X camera versus an M camera, so they know which way to process it. Or is it automatic? Or do I need to carefully separate the back-ups and folders and what not and clearly label the non M-X footage?
 
I heard that B30 can handle equally M and M-X footage.


OK... here it is. This build works with both Mysterium and Mysterium-X sensors in the RED ONE. Includes FLUT Color Science and a ton of other goodies. Use with REDCINE-X 104 and above.

Have fun!

Jim

http://www.red.com/support
 
Yes, Build 30 works for both cameras and RedCine-X 104 works for both cameras... but that still doesn't tell me whether I need to separate the two types of footage for processing, whether the person doing the transcoding has to pay attention to the two different types of footage, or whether RedCine-X automatically processes the two types of footage automatically.

I'm shooting in Chicago and all the transcoding will be done in Los Angeles and I have no way to monitor the process, so I need to know if it's anything to worry about when I have a big stunt day and suddenly the post house is getting footage from two or three cameras of both variety.
 
It's fully automatic - the software in the SDK applies the correct colour calibration data to the raw data dependent upon the camera type.

Graeme
 
As a RED tech, I would still insist on marking the downloaded footage, on any logs and on the backup drives, as being either M or M-X derived.
 
Erm, PS, I've definitely asked for my username to be changed to my real name a couple of times, so I'm sorry that hasn't happened yet. WORKINONIT.
 
RED CINE X doesn't seem to indicate anywhere if it is M or MX footage but handles both fine quite transparently

It could be useful to use camera slate letters to designate CAM A. B. C etc and let the post house know only footage from CAM A will be originated on MX for example then each file can easily be identified as being MX or not

At least they'll know this footage can be pushed further without getting too much noise... but besides pushing M footage too far and getting grainy result there is not much risk mixing footage

it seems to be a pretty similar raw file that the RED ONE produces for M or MX as preMX software like redAlert can open B30 MX 4K RC36 footage... without FLUT science and all the cool new stuff but it can at least decode an image using older science...
 
As Graeme pointed out... SDK apps knows what was shot on either camera, but it might be a good idea to show which sensor it was inside any app using the SDK.

Update: Just checked with the boys and we are adding a feature that tells you which sensor shot each clip when you open in an SDK supported application. That should help.

Jim
 
Last edited:
Jim, how do you guys move so quickly? Canon announces their pre-announcements which only leads to more announcements about pre-announcements announcements. Thanks for just taking care of business like a normal human
 
pre-announcements which only leads to more announcements about pre-announcements announcements.

Richard... in all fairness, we do some of that too. :-)

Jim
 
Richard... in all fairness, we do some of that too. :-)

Jim


Now that you mention it, Jim :) What's going on in Scarlet and Epic labs at the moment? :) What's the status? :bigear:

Pleeeease?
 
Back
Top