I want the best and I want it fast - debayering Magic Lantern raw footage

You might already guessed it from my previous posts - Magic Lantern raw recording is the best thing that happenend to the Canon 5D Mark III in a long time. It actually made me consider it a proper tool for filmmaking again. I love the sharpness, the colors and the resolution.

What I don't like very much is how long it takes to debayer footage with the ACR (Adobe Camera Raw) solution.

The other option is CPU-supported debayering via Resolve (I know, I already pointed that out in the previous entry). Andy and the other good people over at Cinelog actually made a huge improvement to the whole process and they're making it better as I type these words. I had a chance to try out the beta versions of the (yet unreleased) Cinelog-C LUTs, which will make it a whole lot easier to achieve even better Rec.709 results that don't require any change in saturation or mid gain.

While they're still optimizing the new LUTs for the Cinelog LUT bank, I want to present my way of working with Cinelog LUTs in Resolve Lite with this little tutorial - enjoy!

Tutorial: Working with Cinelog LUTs for ML Raw in DaVinci Resolve from superhypernatural on Vimeo.

Working with 5D3 Magic Lantern raw footage on OSX

Magic Lantern is the one free software add-on for the Canon 5D3 that offers the incredible possibility to record full-frame film in uncompressed 14bit raw. Explained in short this means the information from the 5D3's bayer sensor is directly recorded, bypassing the shortcomings of the standard h264 recording codec of the camera. We'll end up with much sharper, detailed material that doesn't fall apart when being graded. Apart from that there are more features that come with the Magic Lantern add-on, for example Zebra, Peaking or the possibility of "cropping" the sensor readout (3x magnification without any loss in pixel resolution).

In case you're interested in the details, visit the Magic Lantern homepage and / or check out the DVXUser guide to Magic Lantern raw.

Even though the Magic Lantern software add-on is for free (but you're invited to tip those extremely talented programmers via Bitcoin), it still comes at a certain price concerning storage and workflow:

As the data rate of raw video is way higher than the usual h264, reliable raw recording of full HD (1920x1080) material at 24 or 25 frames per second will only be possible by using really fast CF cards. After trying out a variety of UDMA7-compatible types of CF cards (Lexar, SanDisk, Komputerbay), I found the (rather expensive) SanDisk Extreme Pro 160MB/s the most reliable option for my camera, at least at the size of 128 GB.

That being said, even those cards delivered some drop frame errors when being formatted as ExFAT, but with the camera-internal FAT formatting, they proved to be a reliable option (don't worry, the raw video files will be split to overcome the 4GB-per-file limit of FAT). 

There are two different file formats that Magic Lantern offers to record raw video, RAW (only video information) and MLV (video & audio information). As I always need sound as sync source on my jobs, I only record in MLV. 

Once the recording is finished, the MLV files will be transferred to my Apple workstation. Don't forget, we are recording raw information directly from the Bayer sensor inside the camera (kinda like REDRaw, but without the 1:2 compression), these visual informations need to debayered before they can be taken to the NLE of your choice. The cool thing is: we're dealing with raw information, so white balance, tint etc. can all be set after the actual recording has taken place. I would call that "recording without a picture profile". 

There are a couple of tools available on the OSX platform to process MLV files: 

The MlRawViewer makes it possible to watch MLV files directly from the Finder without prior debayering. A very nifty solution on set, as it is impossible to play back the recorded files directly on camera in real time (but they can be watched in non-realtime to check the framing etc.). MLRawViewer can also be used to debayer the images properly and export them either as DNGs (single raw image sequences) or Apple PRORES files (set white balance first!), but at the moment, this process is CPU-based and takes quite a while. 

The option I am using at the moment to debayer my recorded videos is decoding the MLV files as DNG sequences via MLV Mystic and then importing these into Blackmagicdesign's DaVinci Resolve Lite 10. This free version of the popular color grading solution is able to perform a GPU-based debayering of the raw image sequences in realtime on my workstation. In conjunction with the awesome Cinelog LUTs for DaVinci Resolve, which will help to interpret the color information from the 5D3 sensor properly, we have the possibility to obtain proper PRORES422 or PRORES4444 video files for hassle-free editing (or further grading) within the NLE of choice. 

For quick jobs, we can choose to debayer directly to REC709, while staying on the Cinelog profile or exporting as Arri Alex Log C gives us the freedom to further grade the footage to our likes. 

While the method mentioned above is my personal preferred path to deal with DNG sequences out of MLV, there are other options to debayer the recorded 5D3 sensor information. ACR (Adobe Camera Raw that comes with Photoshop or Lightroom) does probably the best job in interpreting this data, but it is not really batch-able and takes a longer time. As a sidenote, the Cinelog profile mentioned before is also available for ACR. 

Some NLEs can also interpret CDNG (Cinema DNG) sequences directly, but the lack of possible white balancing within FCPX makes it a lesser option in my case. 

Here's a quick comparison between the different debayering possibilities (no color change applied) while we can also see how much resolution is being "taken away" when using the internal h264 recording:

h264 vs Cinelog Resolve vs Cinelog ACR from superhypernatural on Vimeo.

Going back to Full Frame - the return of the 5D3

My first ventures into the land of DSLR shooting were with the good old Canon 7D back in the beginning of 2010. A lot of effort was put into getting the DSLR to a level on which it would be possible to do video / film work with it efficiently.

And while the shallow depth-of-field look and the colors were appealing, moiré and aliasing made a lot of pictures I envisioned impossible. Even though, there was enough film work done with the camera to justify the expenses. 

Still, it was not pleasing enough, which made me return to standard videographer equipment later that year. The Canon XF305 I purchased in late 2010 still is my main partner for ENG work. Convincing professional codec, reliability and ease of use.

When Canon released the 5D3, I immediately hopped on board to use it for a short film that still hasn't been released. Most of the lenses and rig equipment I owned from my 7D days were compatible, so the transition was smooth. The picture quality was much more appealing than the 7D, gone were the days of moiré and the aliasing is as good as it gets for a 1080p camera. With a bit of sharpening in post, the 5D3 finally delivered lush full-frame videos. 

Because of lacks in regards to handling and versatilty, the 5D3 was mostly used for still photography after my short movie shoot. The XF305 was simply the better camera for everyday video needs. The acquisition in a broadcast standard 4:2:2 50 mbps codec gives me footage that wouldn't break apart as easily as the 5D3's h264, so there simply was no reason to pick up the DSLR for motion pictures. 

2013 was packed with on-location audio & video jobs for a variety of different production companies and TV stations. Work got a bit slower in the beginning of 2014, which also gave me some time to re-think possibilities and tinker with the tools I already had in my closet. The one thing I had heard about a lot but never actually implemented was the Magic Lantern "operating system addition" for Canon DSLRs done by extremely talented programmers. While ML adds a ton of useful tools for video acquisition like Zebras and Peaking, it also enables my Canon 5D3 to capture full HD raw video with a color resolution of 14 bit, turning it into one of the only full-frame raw video cameras on the market today. 

And while the workflow is a wee bit complicated, the results are so impressive that my focus for filmic work is back on the 5D3.

Source Timecode Integration

Ever since FCPX was released, there was one thing that bugged me: It was no longer possible to integrate source timecode easily into your edits so the producer would be able to follow your edit decisions. Until now, my workaround was to supply an EDL (via EDL-X) with every edit I put online. as a reference.


With FCPX 10.0.6, it is finally possible to easily integrate source timecode into your edits with an approach much less cumbersome than before.

First off, I might need to explain how I work and prepare material for the edit. Instead of a pool of individual clips, I create a single "daily" intermediate (which I will call DAI from now on) for each and every day of recording. This file does not only contain all of the consecutive clips recorded that day, but also consists of multiple mono audio tracks (normally four tracks - two from the camera and two from the audio recordist's device - needless to say all in sync). The resulting DAI could, for example, be an 8-track MXF or a multitrack PRORES file.
This way of working makes it quite easy for me to reference and backup weeks of production without having to deal with a multitude of audio and video files.

Now on to the source timecode integration:

Before we start integrating the TC, it should be noted that the integration of source timecode has to happen before we actually start editing as we require an individual compound clip per DAI.

Within FCPX's event library (already containing all of my DAIs), we select one of the clips and choose to create a "new compound clip". The resulting compound clip shall have the same name as the source DAI with the affix "_TC".

creating & labeling compound clip

Let's open the freshly created compound clip in the timeline and add a timecode generator to the clip start, making sure it is the same length as the original DAI.

adding a timecode generator to the compound clip

Obviously, it should also be labeled accordingly so we have a proper reference once multiple TC DAIs are edited together.

labeling the source timecode

We repeat the same procedure for every DAI we want to use in our edits and add all of those TC-DAIs to the same keyword collection as a basis for our edits. Needless to say, we will base all of our edits on these compound clips and not the original DAIs.

Now once we start to edit, we will have a clear timecode reference for us and our producer.

edit sequence /w source & sequence timecode

The moment an edit is locked and ready to go into post or final render, all we have to do is to open all of the original TC_DAI compound clips again in the timeline and disable the timecode generators by pressing <V>.

7D - Technicolor CineStyle and S-Curves in FCPX

It's been a long time since I used my 7D for filmmaking. I still use it a lot for still photography, but my documentary work isn't about bokeh shots and cinematic beauty. The Canon xf305 offers hours of 4:2:2 recordings, my DPA shotgun or a lavalier radio setup hooks up easily, in other words, it's a fast setup. The 7D is not.

But recently, together with the v2.0 firmware, I realized that a Technicolor CineStyle preset exists that improves the filmic dynamic range of the DSLR by about 2 f-stops. In case anybody hasn't dl'd it yet, check it out here on the Technicolor webpage.

To enhance the digital film shooting capabilities of the 7D, the standard h264 color space is put into a log color space which requires a specific LUT applied to the clips within the NLE (provided with the download of the CineStyle preset).

So much for the good part. Unfortunately, plug-in solutions like Red Giant's LUT Buddy do not support Final Cut Pro X yet. Thus, the footage looks pretty stale when imported into that NLE, and one would have to play around with the grading possibilities of FCPX for quite a while to get to a proper look. Thus, it's a really cool thing that colorgradingcentral.com are offering a handy "S-Curve" plug-in for FCPX that closely imitates the Technicolor CineStyle LUT together with their cineLook for HDSLR's plugin.

After applying the firmware update and CineStyle preset to my HDSLR, I immediately went out and shot some footage of my brother Mike to test the possibilities of CineStyle. As already mentioned, it's been quite a while since I shot film with the 7D, and you can't imagine the joy I had going handheld via Redrock Micro's "Captain Stubling" rig.

Here's a couple of screenshots:

CineStyle without applied S-Curve

CineStyle with S-Curve and cineLook

CineStyle with S-Curve, cineLook and a bit of Mojo

Some feedback for Apple in regards to FCPX

Posted this just now via Apple's Final Cut Pro X Feedback page, anybody who would like to support or add, please follow this link.

A list of annoying bugs and missing feature (some of them were posted here by me a year ago):

BUG #1: go to the event browser -> select a clip and specify an in / out range -> switch to the timeline (Cmd + 2) -> switch back to the event browser = no longer possible to go beyond the in / out point

bug #1.1: shuttling beyond the out-point will not work; workaround = jumping to the out-point (Shift + O) enables the "browser system" to go beyond the out-point again
bug #1.2: punching in a timecode position (Ctrl + P) = the playhead does NOT move to the specified TC position but moves one frame after the out point and not ANY further, again, jumping to the out-point via Shift + O is the (terrible) workaround
bug #1.3: deselecting the previously selected in / out area (Cmd + Shift + A) does not solve the problem mentioned above, even though no selection is visible in the event browser, the in / out points are still "remembered" by the system (selectable via Shift + I / Shift + O, also works as workaround).

BUG #2: Switching between event browser and timeline (Cmd + 1 / Cmd + 2) does NOT work occasionally, resulting in the image not changing in the viewer; this feature is sometimes required to actually compare the playhead positions between the event browser and the timeline.

BUG #3: Creating Favorites (F) with overlapping timecode areas in the event browser does not work; example: mark area in the event browser, press (F) to add a favorite from 01:20:00 to 01:30:00, now it won't be possible to add another favorite going from 01:25:00 to 01:28:00.

BUG #4: unsure whether this is a bug or a missing feature: after adding a favorite (F) in the event browser, it is not possible to immediately rename it with a keystroke. I have to click / mark it with a left-click first and then rename it (by pressing Enter, for example). Arrow keys to select it also do not without a click into Favorites first. Quite a speed-stopper.

MISSING FEATURE #1: A possibility to read and display the SOURCE timecode (meaning the original timecode from the clip) in the timecode generator plug-in is a MUST for my collaboration with certain clients, at the moment, I am using EDL-X .txt exports as source / destination reference for my clients, a clumsy workaround if it would be possible to integrate source TC via timecode gen plug-in!

MISSING FEATURE #2: Switch or at least tab between the Information tabs (Video / Audio / Info) via keyboard

MISSING FEATURE #3: When importing Canon MXF clips (from xf305 cam, thanks to the Canon importer plug-in released this year) directly into FCPX, it is not possible to see any source timecode. This is sometimes required.

Bugfixes would be heartily appreciated,

best regards,

Martin

Edit Annoyances #1

Now that I have been editing for quite a while, I found a few little annoyances that slow the editing process down:

• Shuttle issues:
I am on my Mac Pro again down in the studio, and for the documentary film project I am working on at the moment, all data is stored on a LaCie 4Big Quadra (eSATA) running in Raid 5 configuration. According to Blackmagic's Disk Speed Test, the drive speed is around 250 MB/sec read and 210 MB/sec write. The files are XDCAM HD422 with 8 tracks of audio (50mbps). When shuttling through the material at more than realtime (x2 / x4 / x6), I am sometimes experiencing delays, which is not really comfortable and slows me down.

LaCie 4Big speed

• Let it calculate the waveforms or stay away from the Video tab:
The base material I am working with are dailies that include 4 audio tracks. Originally synced on location using Avid Media composer as MXF, they include reviewed material from each and every recording day, so the files are pretty huge (between 2 and 3 hours).
If the Audio tab is selected in the information panel, every time these source clips are accessed in the Event Browser, FCPX starts to calculate the audio waveforms, which makes shuttling almost impossible due to disk access.

Calculate those waveforms!

• Switching between Event Browser and Timeline:
When switching between the Event Browser and the Timeline (CMD+1 / CMD+2), the Viewer refuses to switch to the appropriate clip / image sometimes, for example still showing the image of the clip that has been selected in the Event Browser instead of showing the timeline position I have switched to. Changing multiple times back and forth helps in that situation.