The Editblog

There’s a post on reduser.net titled Native R3D support in FCP coming soon.

Apparently this was demoed at IBC and found in a comment on a PVC post. On the surface this title seems like a wonderful thing:

At the LAFCPUG Supermeet at IBC yesterday, Apple demo-ed RED support in FCP for the upcoming update.
FCP will be able to work with the RED files directly. It will allow you to create 2K projects using 4K RED footage. Log and Transfer will rewrap the 4K R3D in a QT (no transcode) and preserve all metadata (as well as what you add). On the (2K) timeline FCP will do on-the-fly downrez. When you send a timeline into Color all RAW parameters are available in the Primary Room in a “Red” tab. There you can edit the RAW parameter like WB, exposure, etc.

That seems like something we have been waiting for. But another post says this:

In the update, FCP will be able to import R3D files natively, via the Log and Transfer function. A bit slower than realtime to get it wrapped into a QT wrapper. It will work only in 2k, no support in 4k as of yet.
When going via Color, then everything will be transcoded into ProRes. No announcement as to when this will become available. Meta data from the Red One will be preserved.

That’s a bit more info but seems less exciting if it’s a bit slower than realtime and everything is transcoded to ProRes when going to Color. Seems there’s not much to gain and the FCP team is hacking together some type of feeble support just to keep RED/FCP users happy. And then a later post says this:

I saw the demo yesterday and this is how it works: You use the Log and Transfer tool as today except that FCP won’t transcode the files into ProRes but just copy the files to your scratch disc and importing the _M.mov reference file. Then you edit using the reference files like you do today. When sending your edit to color it will relinc the files to the r3d files which you have full access to in color. You can change almost the same things as in RedAlert. Color will have a “RED” tab in the primary section where you can set all the file parameters. The you render it out to .dpx sequence or QuickTime-files for going back to FinalCutPro. Nice in my opinion… Cutting using the refrence files are still heavy and have some issues.

If that’s true and FCP only copies the .R3D files and the _M proxy file for the edit then that is virtually worthless IMHO. Editing the proxy reference files isn’t a good way to work. If Adobe Premiere can work with the raw .R3D files than FCP should too. This seems a lot like speculation and people recalling from memory so the final version of this might be much better. Let’s hope so because what I’m reading here isn’t great. If someone is at IBC and saw something different please comment below for those of us who didn’t make it.

It looks like there is yet another major post-industry player soon to add support for the native raw .R3D RED file format, Quantel. Version 4 of the Quantel software will come along in October 08 and include a RED importer. Quantel says that key features are:

• Preview r3d file before importing
• Partial file import – set in and out points and import between them
• Import at 4K, 2K or 1k resolution (full, half, and quarter res) with different quality options
• Full use of all the RED options including exposure, colorspace, color temperature and more

That’s more support coming online for RED and it can’t come a moment too soon. This post at reduser.net is a current discussion on the state of RED post. It was started by a camera owner who saw a Panasonic HVX200 rental chosen over his RED package. That’s a DVCPRO HD P2 camera chosen over his full-blown 4K RED. Don’t take the thread at face value as there is good discussion deep within about why someone might do such a thing. At first it seems crazy but might make sense to some. A great discussion if you are currently following the RED-post-production-drama.

If you are curious about RED post production and some real world workflow on RED jobs then click over to Studio Daily and read and article I wrote outlining what we have been calling the summer of RED. It was 4 back-to-back music videos done recently by Broken Poet Productions. Director Eric Welch wanted to “kick the tires” of the RED camera and did so with two lower budget projects before using the camera on two high profile country music videos. All the details are outlined in the article. Happy reading!

There’s a lot of different storage calculators out there for calculating how much drive space you need to hold a given amount of media. Thus far all of these utilities are lacking support for RED media. Enter a guy named Alex on the reduer.net forums and a little weblink that is just that, a RED storage calculator. It’s a very simple web page so it works well on the iPhone also. In case you need one more place to calculate your RED storage Alex also has a dashboard widget for Mac OS X. This is great to have as I’ve seen a couple of cases where a production company bought 1 terabyte drives for a RED shoot and then only used about 300 gigs of space. Since one of the drives are turned over to the client in the end as the camera origination media then that half-a-terabyte will go forever unused. So calculating in advance might have saved a few $s!

I’ve been enjoying the batch processing capabilities of REDrushes and as I was asked recently about the different debayer quality options I had a general answer to what the different quality levels mean but I had not done a side by side comparison. The debayering process converts the raw RED data to an RGB image for use in the video world so the higher the quality the better the image, at least in theory. When you do side by side comparisons with the same footage there are some subtle differences in quality.

The image below is from a 4k clip converted with REDrushes and the Full Res debayer setting to a 1920×1080 ProRes 422HQ file (click on the images for a larger view):

The next image below is the same part of the same frame of a 1920×1080 Prores 422HQ file that was debayered at Quarter resolution:

It’s a bit tough to see here on the web but the quarter rez debayer has noticeably more noise. It’s not extreme but it’s enough that you probably would lose some latitude when doing a color correction, especially if you were pushing the image. It also takes a LOT longer to render the full debayer.

The other place it would be most noticeable is around edges. You really begin to see the difference in the quality levels when you apply a difference matte between the two examples (click on the images to open a larger version):

Again, it’s very tough to see in this low quality web image and it depends a lot on the monitor you are viewing on but if the light isn’t too bright on the screen and you get really close (click on the image above for a larger view) you can really see the outline and edges on the slate. Here’s an exaggerated version:

Is there that much of a loss that it’s worth the extra time and effort to debayer at full rez? It might be more of a mathmateical question for the programmers as to what you really gain from full rez and as I’m an editor and not a colorist I don’t really know the answer (maybe a colorist or two will chime in via the comments) but if you can see that much difference in the matte above then that seems to me like loss enough to debayer at full rez for the final online. For the most dramatic example render you own footage with REDrushes at the two extremes of debayer quality, slap them in the a timeline, apply the difference matte (thanks Jon) and then render the full moving image. When the footage starts moving you can see even more.

I’ve had the chance to now cut number of RED music videos in both Final Cut Pro and Avid Media Composer. I wasn’t really having a contest but Avid has won as my software of choice for cutting RED music videos. There’s a couple of things to know first. Most RED jobs that comes through our house end up being conformed on high end systems like a Quantel eQ or Avid DS with color grading done on a DaVinci. It is this kind of workflow that requires good tracking of metadata and that is something Avid excels at. There is an extra step involved in the setup, using MetaCheater to get all of the proper info into the Avid, but once it is there the media management is rock solid (something that Avid has always excelled at) and there is never a problem with EDLs.

The other thing that has made the Avid > RED editing such a pleasure is Avid’s DNxHD 36 codec. Like Apple’s ProRes, DNxHD is a compressed HD codec that is both efficient and of great quality. Unlike ProRes you have a number of choices for quality. DNxHD 36 is the lowest quality, running at 36 megabits per second, but calling it “low quality” for offline is really doing it a disservice as it looks fantastic and the low data rate makes it feel like you are cutting with DV25. Since DV has a data rate of 25Mbps you can see that DNxHD 36 isn’t that much greater. I’ve been running the high quality RED Quicktime proxies (QT reference files is what they really should be called but everyone is calling them proxies), the _H clips, through Apple Compressor, then creating and ALE file with MetaCheater and then a batch import into Avid. It’s important to run the proxies through Compressor as Avid is then able to fast import the QTs which takes a fraction of the time as opposed to directly importing proxies. This isn’t acceptable IMHO as a 4 minutes clip was taking something like 20 minutes to import at to DNxHD 36. With the recent release of REDrushes as a batch processing application of RED files this will become a much more pleasant experience once it supports DNxHD. This thread at reduser.net discusses that very issue. Couple the speed and efficiency of DHxHD 36 with the screaming performance of the new Avid 3.0 software upgrade and you’ve got one kicking offline solution for the creative editing of you RED jobs.

FreshDV noted that RED has released new versions of a number of their tools. The RedAlert release now includes REDrushes, a batch processing application which looks to be a similar workflow to running the Quicktime reference proxies through Compressor. You should get better results in image quality in that REDrushes is working directly with the .R3D files. There are options to create TIFFs, DPXs and Quicktimes. A number of Quicktime codecs are available but as of the build I have there is NO option for Avid DNxHD! I hope this is just an oversite as the codec is available in REDCine so I don’t understand why if wouldn’t be available here as well. As with most RED software releases there isn’t a lot of documentation and you wouldn’t know REDrushes is even there if you didn’t notice it in the release notes on the RED site or just happen to see it in your applications folder after the REDAlert install. It’ll be great when RED one day really buckles down and concentrates on the post software they are supplying but until then REDrushes is a good step forward for batch processing. I’m putting on a batch overnight so here’s to hoping it doesn’t crash!

Here’s a nice little morning laugh for all of the RED lovers out there. It might be a bit offensive to some (so fair warning) but it is damn funny …

I was checking my feeds this morning and saw that IndiesHD had grabbed a screen shot of a recent Twitter tweet that I made about problems we were having getting DPXs out of Scratch, via an EDL. 140 characters doesn’t leave a lot of room for details so I will try to explain …

We went to conform a music video Friday on a Quantel eQ. We were to use DPXs pulled from an Assimilate Scratch Cine system and conformed via an EDL. This wasn’t the first time “onlining” a RED job via DPXs but last time I pulled them myself with the help of Crimson. It was a simple EDL, mostly cuts with some dissolves through the bridge of the song. There was also a second EDL for the second video layer which was more dissolves through the bridge to create a desired effect. A drive was brought over by one of our local RED rental houses as they pulled the DPXs on their Scratch Cine system. Most everything came in and conformed fine with the exception of 2 shots … and pretty much all of the shots that had dissolves as a transition. To make a long story short, the good folks at DR&A just packed up their Scratch Cine and brought it over so we could get this job out and get to the bottom of the issue. It seems that the problem lied (or lies I guess I should say) in telling the Scratch system how many handles to supply when pulling the DPX files. If we wanted one second on either side of an edit we would tell it to provide 24 handles on both the ins and outs of a shot. If there was a dissolve on a shot then it seemed like the system would get confused about how much media to pull. Different tests seemed to reveal different results. What seemed like a simple thing turned into a long day of troubleshooting.

To be fair, perfecting this RED workflow is still somewhat new to all of us and the Scratch system was still being learned. We knew this video was to be somewhat of a “test” project for this particular workflow so we weren’t killed on time. The support staff from Assimilate were on the phone with the Scratch operator and there were able to do a lot of troubleshooting. Eventually we had to pull some shots one at a time and put them in by hand … so the job finally finished conforming on Monday. It awaits color grading on Wednesday.

With any new workflow bugs and glitches can be expected. I was told that Scratch is actually at version 4 so I was surprised that we had these problems. Another thing that I wonder about is maybe Scratch Cine isn’t really made to pull DPXs. Looking at the official Scratch Cine page, they really promote a tape based workflow in a lot images and documentation. But then in the FAQs it says “SCRATCH CINE is primarily a pre-post tool that is used to prepare R3D images for use in a variety of workflows.” That’s certainly what we are trying to come up with … a specific workflow that yields quality above what you get with what seems to be one of the most common ways of working with RED footage, converting everything to ProRes. With any new workflow can come frustration (and the occasional frustrated comment via Twitter!) but thanks to the patience and perseverance of the guys at DR&A and the helpful support that they have gotten from Assimilate we are going to figure this out! I wanna keep working with RED projects, as frustrating as they might be sometimes. No one ever said that life on the cutting edge was easy.

So I’m still obsessing over the two different timecode tracks that are recorded to RED camera footage and what application see which timecode track. The whole thing came up when I noticed that the RED Log and Transfer plug-in for Final Cut Pro only seems to see Time of Day code. I posted this as a question on reduser.net and one of the responses was this from the RED camera #242:

“Everything else” is probably using whatever the camera was set to display, which is what the proxies are generated with, however both TC tracks are in the R3D.

That seems very interesting and is something I had never heard, of course I don’t have a RED camera of my own but as a post production professional I think it’s important to understand what kind of timecode I will be seeing in RED footage that might come my way. Armed with that knowledge I went to DR&A, a local RED camera rental house, and we did a quick test. 2 short test shots, each one with a different timecode set on the display screen on the back of the camera.

Here are the two shots:

Shot 001 was set up to display the edge timecode on the camera.

Shot 002 was set up to display the time of day timecode.

With the shots done I grabbed the _M resolution Quicktime reference files generated by the camera and dropped them into Final Cut Pro:

This jives with what was said in the reduser.net post: “whatever the camera was set to display, which is what the proxies are generated with.” To make sure I then dropped the _H QT reference files into Compressor since this is a common was to generate ProRes files to edit with. Same result:

One file shows edge timecode and one time of day.

But bring the files into the FCP Log and Transfer window and the result is the same as the earlier post:

So again, this seems to not be the way that the Log and Transfer tools should behave. Maybe there is some unknown reason for this or maybe we need to remember that the plug-in is still beta … like most RED post-production tools.

But this problem still shows when using other RED tools to pull DPX files.

Using RedCine to pull ProRes Quicktimes and DPX files, the timecode that was selected in the camera display is the timecode that is used for the generated files, as expected:

I then used Crimson to generate the same clips. Crimson uses Redline, the RED command line utility, to pull files. These both came out with the Time of Day timecode:

This has also been noted on the Crimson forums. I see this as a problem. If you’ve edited your footage with the edge timecode that was used with the Quicktime proxies and then use Crimson to pull DPXs for conform elsewhere … the timecode isn’t going to match. I looked at these DPXs on a Quantel eQ and could only see the Time of Day code. Someone please chime in if there’s more than one timecode track in a DPX sequence that might see the other code but I couldn’t find it. With this knowledge I think it’s important for post to be in communication with a production to know what timecode to use in-camera in conjunction with how the RED post will be handled.

But what I really want to say is … What gives RED? Why does one post production tool that you provide seem to use one particular timecode track while another one uses another?  These tools aren’t particularly well documented so maybe there is just something that I am missing in the set-up or file generation. But I really think this “beta” excuse is only going to go so far. This camera is revolutionary but with the post being such an afterthought one has to question RED’s real commitment to getting post production just right.