The Editblog

I couldn’t let the day get by without giving the new native RED .R3D import and editing function a quick test. My first thought after playing around with this functionality is that this is by far the best implementation of native .R3D editing and it blows the Final Cut Pro support out of the water. I won’t go into a lot of detail on setting it all up as all the info is available other places and in a document that comes with the RED Adobe CS4 installer. There’s also some initial reactions from Noah at Twenty398 as well as the best way to learn about this new workflow: a 30 minute video on AdobeTV.

Read the rest of this entry »

So Avid updated Media Composer to 3.1 a day or so ago. That’s good, more bug fixes are nice but no Tiger 10.4support! Avid has also updated their official RED support page. From the Avid email:

The Avid® + RED workflow is simplified with the release of REDrushes 3.6, as reflected in the updated Workflow Guide at www.avid.com/red.

Direct transcode to all Avid DNxHD® formats
Corrected “End” timecode in ALE files
Proper representation of “Auxillary TC1″ column in ALE file
Faster import of QuickTime-wrapped Avid DNxHD files

REDrushes 3.6 is available at www.red.com/support.
Richer metadata is available with Avid FilmScribeâ„¢ 24.1

Custom columns now available
Subclips and AutoSyncâ„¢ clips supported in the FilmScribe Master XML
Removed erroneous characters from Master XML file (Windows)
False error messages removed from XML generation process

FilmScribe 24.1 ships with Avid Media Composer® 3.1 and Avid Symphony™ 3.1 and is also available on the Avid Download Center.
More events (now up to 999) are supported in the newly posted 16Char CMX EDL template. Download from the Avid Resources tab at www.avid.com/red.

Avocoda’s cineXML (Mac OS X and Windows) enables DPX file creation via REDCINE, regardless of how the ALE file was created and allows the footage to be archived or moved before the online process.

That sounds like we can now get DNxHD 36 out of REDrushes. Here’s a thread of discussion on the subject from Reduser. Finally we get Adobe support, better Avid support, new Final Cut Pro workflow options … who would have guessed all this RED post goodness would ever come along a year ago?

Apple and RED surprised everyone yesterday with updates that allow you to re-wrap the native .R3D files as a .mov and then bring them into Final Cut Pro instead of converting the clips to ProRes or editing the proxies. The first thing that I wondered is how much of a time savings would this be since you are not transcoding to new media, merely copying the .R3D to your Capture Scratch folder as the re-wrap occurs. Here’s an unofficial speed test on the difference in conversion times using a MacPro 3 GHz Quad-core machine pulling the .R3Ds from an internal drive and creating the new media in networked fiber-channel storage.

Our test subject, a 212 MB 2K .R3D file running approximately 33 seconds:

Using the FCP Log and Transfer tool and transcoding this file to ProRes HQ took 2 minutes and 42 seconds.

The same clip importing through the Native setting of the Log and Transfer tool:

This method took only 4.5 seconds. This is an obvious difference here as the re-wrapping of the .R3D into a QuickTime is doing what was expected; basically a file copy from your source drive into your FCP Capture Scratch folder. Again, this was to be expected as it has been seen in the demos of this workflow that have occurred recently as well as what is described in the RED white paper that comes in the download from RED support to allow this new type of operation in FCP. But if you haven’t read the white paper then now you know! The file size between the .R3D file and the re-wrapped RED QuickTime files is the same, 212 MB:

So that’s the good news; the native re-wrapping of .R3D files gives editors a very fast and self-contained option to quickly get RED files into the edit without having to worry about the flakiness of the non-self contained proxy files. The bad news? They are still just as processor intensive as the proxy files. As I play around with these files, back to back with proxy files, I don’t see any performance advantages at all. To be fair, the RED white paper states that “RED QuickTime media is processor-intensive to work with in
Final Cut Pro” and that is true for the proxy files as well. A single stream of RED media can be played back quite well but as soon as you begin to pile on transitions and layers and titles you see real performance hits. Get a multiclip of any real size in the timeline and attempt multiclip playback and things grind to a halt. This has always been my problem with the proxies from the beginning. They are fine for small, quick, simple edits but when you begin doing the things that editors try to do at speed then the performance isn’t there. But it is a step in the right direction so something is better than nothing. Now if only we can get that native Adobe Premiere Pro workflow going and compare …..

Hot on the heels of Adobe’s announcement that the Premiere Pro CS4 update 4.0.1 would natively support RED’s .R3D files, RED has released the RED Final Cut Studio 2 Installer. From the RED website:

For Intel-based Apple Macintosh systems with Final Cut Pro 6.0.5 or above. The Final Cut Studio RED Installer provides the RED QuickTime Codec (v3.7.0), Log and Transfer (v1.0.0) functionality to import REDCODE RAW clips as either native REDCODE media (R3D’s) wrapped in QuickTime or the option to transcode them directly to Apple’s ProRes 422 codec. There is also a new specialized functionality for color grading native QuickTime wrapped R3D media in Color using the original RAW parameters (REDCODE plugin fro Color v2.7.0). Located in the download is a whitepaper PDF describing in detail this new, advanced way to edit REDCODE media, color grade and finish inside Final Cut Studio.

That means there is a Final Cut Pro update coming to get the app to 6.0.5. There is actually a white paper in the download (which really has been a long time coming) that details this new workflow. There it is in the whitepaper, the FCP Log and Transfer tool supporting Native RED files:

The Final Cut Pro 6.0.5 update includes a number of things. From the Apple documents:

Improved High-Precision Rendering

If you render sequences using the high-precision video processing setting, make sure to update to Final Cut Pro 6.0.5 for improved reliability when rendering still images and footage in high-resolution formats.

Extended Metadata Support for the Panasonic AG-HMC150 Camcorder

Final Cut Pro 6.0.5 captures the additional metadata for footage recorded with the Panasonic AG-HMC150 professional AVCHD camcorder.

Improved Support for the Panasonic HDC-SD9 Camcorder

Final Cut Pro 6.0.5 provides enhanced precision and reliability when ingesting files from the Panasonic HDC-SD9 camcorder.

Improved Support for Metadata Imported from P2 Cards

Final Cut Pro 6.0.5 provides support for extended metadata that is captured on P2 cards.

So that’s few other things. There’s also updates to Compressor, Color and Shake. It’s good to know the Final Cut Studio teams hasn’t been totally asleep lately. This isn’t entirely breaking news since this has been demoed in public before. And this is a wrapping of the .R3D files in a QuickTime wrapper as opposed to a drag and drop of .R3Ds into the FCP browser. And of course you can still transcode to ProRes. I think what is surprising is that it dropped today when Adobe was releasing their Premiere Pro update. According to Adobe, RED was to post a plug-in on their support site to enable native Premiere Pro workflow. As of 6:45 pm, November 20 that plug-in hasn’t been posted and instead RED posted this FCP software. Interesting developments in the RED editing world today huh?

With the release of the new RED Epic and Scarlet cameras I thought it appropriate to take a look at the prototypes that RED had under glass at NAB 08 and see the difference:

Read the rest of this entry »

Yesterday was REDmas eve. Today is REDmas day only you don’t get your presents in hand. You get a promise from mom and dad that if you behave, if you work hard, and since you don’t believe in Santa Clause, if they work hard you will get some nice, shiny, new toys sometime in the future.

If you haven’t seen the reduser.net announcements then here’s some quote from the announcment thread by Jim Jannard himself:

Scarlet® and RED EPIC® are part of the same DSMC system.

A DSMC is a camera that shoots stills and motion. Configure that camera any way you want.
Select a brain. Configure your body.

Scarlet and EPIC have “Multiple Personalities”

Select a Scarlet or EPIC “brain” and configure your body to anything you want.
Scarlet is a Professional “brain”. EPIC is a Master Professional “brain”.

And believe it or not there was a mention of post-production in these announcements but it only a quote from Adobe:

A quote from our friends at Adobe…

“RED and Adobe share the goal of enabling the most advanced tapeless post-production workflows in the industry. With native support for RED R3D files in Adobe Premiere Pro CS4, Adobe Encore CS4, and Adobe After Effects CS4, Adobe is furthering the integration of tapeless camera formats into its line of professional video products, and making post-production workflows faster, more flexible, and more efficient. RED’s Digital Cinema camera line, the new RED plug-in, and Adobe video tools provide an exceptional solution for video professionals who want to harness the full potential of raw digital cinematography while tapping the efficiency of tapeless workflows.”

Simon Hayhurst, Senior Director, Product Management, Digital Video and Audio

What does this say about Apple’s future support for RED? Probably not much other than Apple support will continue to be just as support is now, completely through the REDCODE QuickTime codec and not native support within Final Cut Pro. Let’s hope Apple proves this not to be true at NAB 2009 or sooner. To drop the Adobe quote so early in the REDmas announcements (it was one of the first posts added to the thread) seems to me to say that RED is counting on Adobe’s implementation of the .R3D file format as the main choice for independent filmmakers and camera owners who must do post on a budget.

The above chart is an overview of the announcement and where the RED ONE fits into the mix. All I can say is thank goodness for the efficiency of the REDCODE codec. But it will be nice to have a nice and fast MacPro as these higher data-rate REDCODEs come along.

There’s a lot more detail on the RED announcements available in a colorful document that has been posted on the Reduser announcement forum. There’s things like Monstro, 28K, $55,000, 120fps, and 3D. I didn’t see anything about ordering except for what happens to RED ONE owners (all 5000 + of ya) and how they get priority. And as always RED says “Everything in life changes… including our camera specs and delivery dates…” so who knows when these things will ship. They have estimates from Spring 09 to Spring 10. Whenever they do they are going to be one heck of a rig. Makes me wish I was in production sometimes!

Avid Demonstrates Support for RED Camera

Click over to HDHead to see a summary of a November 5th presentation by Avid on their RED support. We’ve all been grateful for Avid’s official RED support page but there appears to be more to come with Avid RED support. First is the ability to use Avid MetaFuze to help in the file conversion and preparation of offline media for an Avid edit. Second is what appears to be upcoming support for the raw RED .R3D files in Avid DS. From the HDHead site:

The RED conform in Avid DS will resemble the file based conform via AFE introduced in version 10. A Media Composer AFE will create clips that link to the the original RED .R3D files.

The Avid DS RED importer will allow the full range of RED based adjustments like the parameters in REDcine or REDrushes. Color temperature, ISO speed, OLPF processing, curve adjustments, etc. will all be available in the new importer along with an option to use the .RSX color metadata from REDalert.

This is great news for a RED > Avid conform and the native .R3D support is something that I speculated on  when Avid announced this new version of DS. It wasn’t announced with the new version back in August but I think we all knew it was inevitable.

Hot on the heels of the Rian Johnson RED debate, Avid had launched a new part of their website devoted to … wait for it … the RED camera and RED post production. There’s an overview tab, Avid resources as well as links to third part resources. Best of all there is a pdf (direct pdf link here) that goes into great detail about the steps needed to properly post your RED projects in Avid and track the metadata so you have as many options as possible for finishing.

Indie4K has posted an article that is a response to a very detailed paper written by Rian Johnson titled Red Facts: straight talk on the technical realities of the Red camera. It’s a 23 page monster that goes into way more technical detail than many may want to know. It baits in the reader with this headline:

There is a lot of hype right now about Red camera outperforming high-end HD cameras and even 35mm film cameras. We’re going to tell you why we think it’s just that — hype.

I say baits because with a headline like that he is just inviting controversy. But bait might be too strong of a word as he has put an awful lot of time and energy in writing such a detailed document. I’m certainly not smart enough to know if all of his technical details are correct. His paper has ignited somewhat of a firestorm over at Reduser and his analysis is disected and debated (somewhat one-sided of course since it is the Reduser forums) by a lot of RED camera owners and RED users. As you read over Rian’s paper and the subsequent posts about it there is a lot of technical talk about resolution, perceptual sharpness, the origins of DPX files and photosites per pixel. It’s very tech heavy and not for the faint of tech heart.  It’s funny to me that this debate even rages but not at all surprising. People often stand by their technological choice to the very end and defend it like they were defending their family honor. We see just as heated debates about one of my favorite debate topics, Avid vs. Final Cut Pro. I’ve read a lot of the pros and cons of the RED camera and talked to a number of people with varying opinions. While RED has created a great device they probably have over-hyped it as well. After all, it’s just a camera. The RED camera vs. all other cameras is really just like the Avid vs. Final Cut Pro debate … neither is really better than the other. It all depends on what you get out of it. If one particular camera or piece of edit software can perform up to your exacting standards, produce stunning images and cut them together with an elegance and ease then that is the best piece of gear, hands down.

Who is Rian Johnson? He’s the director of 2005′s Brick (which I looooove, though many hate) and the upcoming The Brothers Bloom. I just hope Rian continues to make unique and entertaining movies, either on RED, film or whatever format he chooses.

I recently posted info about a quick test I did with the newly released RED Log and Transfer plug-in for Final Cut Pro that enabled one to use that tool to directly import RED footage into the ProRes codec without ever (thankfully) touching RedCine. All seemed well (except for the fact the footage was brought in at half the resolution at which it was shot) but today I noticed something that may be a bit more troubling.

When shooting RED footage it records two different timecode tracks; what they call Start run record / edge timecode and Start time of day/ext. timecode. You can see this in the image from RedCine below:

I would say that this is a good thing since more info is better than less … but it has to be used properly. When you open a Quicktime reference clip created by the camera in Quicktime player you see the edge code:

This seems perfectly normal as that is the timecode you see when you drop the QT reference file into Compressor as if you were using it to transcode to stand-alone ProRes files (all these images were grabbed from the same QT reference generated by the RED camera from the same .R3D file):

But I got the time-of-day code when bringing the clip into the Log and Transfer tool:

Okay, not good. I wouldn’t want one timecode displayed via one method and a different timecode displayed by another. At least I can’t think of why I would want that. I can transcode the clip via Log and Transfer and then import the QT reference file from the camera and I see different timecodes:

This is not a good sceneraio. I can’t find any kind of setting in the Log and Transfer tool to look at the other timecode that has been recorded either. I’m not sure if a Scratch system can conform to the time-of-day code or not. Nor do I know if you could use this type of timecode in Crimson. I posed this question on reduser.net but haven’t seen a response at the time of writing this. It’s true that this L&T plug-in is in beta at version 0.0.1 (!) so maybe this will be addressed as it isn’t mentioned in the release notes. In the meantime, I think it’s important information to note. If anyone has any wisdom as to why this is or if I just have done something totally off the track, please post below. This L&T plug-in is very handy so I think we all want it to work right. After all they say RED is a work-in-progress … right?