The Editblog

Pointing your RED ONE at the sun (or a really really bright light)? You just might see little spots like these:

Camera guys please chime in … but I think this isn’t uncommon with the type of sensor that the RED uses. Maybe it’s be fixed in the big, new build 16.

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?

As a post guy I don’t follow all the RED camera firmware build drama but this one is worth noting. We had a RED camera owner in the shop the other day and he mention that the new camera firmware build was going to be a big deal and the RED team was going to have to rewrite RedCine and RedAlert and the codecs and everything else. As a post guy that made me take notice! I checked the Red User site and there is a post from Jim Jannard the RED ****** and he mentions just that. From the original post:

Build 16 is a monumental change to everything RED as far as the image quality, DSP and methodology is concerned. You may be surprised at how different it is from previous builds in how it looks and works. You will have to alter your thinking just a bit. What you see on the monitor and how you make exposure decisions will change. All for the better, but it will be a change.

We all wish we had done this from the beginning, but you have to walk before you run.

We just don’t want anyone to be shocked when you fire it up. 

Alpha build is just around the corner. Depending on the feedback we get from those chosen few, the Beta build should not be long after. 

Exciting times. 

Now, back to solving production problems… ugh.

Jim

OK wow. That post from Jim didn’t mention a rewrite of the supporting apps but this reply from stevesherrick does:

1. Build 16 sounds exciting, but will there be any conflicts with existing footage? You’ve mentioned that REDCINE, RED Alert have all had to go through re-writes, and I’m wondering if we will see any issues with say mixing proxy files from footage shot on build 15 with proxies from build 16?

I didn’t see any more info on RedCine and RedAlert rewrites so it might be worth keeping an eye toward RED support for them to show up. If anyone has any more info then please post a note in the comments. Hopefully a rewrite of RedCine will squash some of the bugs that it has. 

 

 

I came across this application the other day …. can’t remember where. It’s a tool to help manage RED .R3D files. Here is the intro from the software’s website:

 

R3D Data Manager is an application designed to help you better manage your data workflow. With the terabytes of data that you will create with your RED system, R3D Data Manager helps to step in, making sure copies of each R3D file go to the right place, and accurately.

 

There’s a lot more than that to the $79 software on the site so click on over and see for yourself. Have you used R3D Data Manager? If so please leave a quick comment below with your impressions.

 

I meant to pop this link up before leaving for NAB but oh well….

This Josh Gracin music video (former American Idol contestant) was the first big RED camera job that I have seen through from pre-production all the way through to final finishing. It was a very quick turn-around with a tight delivery deadline so the plan was to edit with ProResHQ Quicktime files generated by the camera rental house DR&A and then be able to output them to tape for color grading if we couldn’t go back to the raw RED .R3D clips and pull DPX files. Thankfully we had the time to do just that. I bought a copy of Crimson Workflow and it worked very well to generate DPX files that were then conformed in our Quantel eQ using lists pulled from Final Cut Pro via Automatic Duck. The edit was color graded on our DaVinci 2K Plus and now it’s on the air! I love it when a plan comes together. Too bad You Tube quality sucks.

At this point in time in the life cycle of the RED ONE Digital Cinema camera, the real bottle neck in the post production workflow (at least for me) is the process, and even the ability, to conform an offline edit into an online edit for finishing. If you look at a basic workflow: shoot > offline edit > conform offline > online edit > color correction/grading it’s getting to that online that is causing the most pain. Now … we are living in a world where the offline to online conform is become more and more of a dinosaur. A Final Cut Pro workstation with an AJA Kona card or an Avid Adrenaline can mean that a program never has to go back to a finishing system because those machines have capable finishing tools built in. Codecs like Apple’s ProRes HQ and Avid’s DNxHD help make that possible as well. But for me and my facility, we send most of our projects to a true online. As a “creative offline editor,” I prefer to spend my time tackling the creative build from scratch and letting an experienced online guy worry about bringing the job home to make sure it meets all the broadcast standards as well as the final nit-picking of graphics and animations by the client.

But getting RED projects to that online step can grind the whole process to a screeching halt. Now many people are thinking, “hey, I finish RED jobs all the time.” From my understanding, observations and study, the best finishing currently available in mid-March 2008 is on an Assimilate Scratch system. Edit lists pulled from your offline can be brought into Scratch and then conformed from your original raw .R3D files generated by the RED camera. That’s as good as you could want. Unfortunately, if your market is anything like mine, there aren’t a lot of Scratch systems out there. Another solution, and probably the most popular at this point, is finishing right from Final Cut Pro. Maybe you edited right off of the Quicktime reference files created by the camera or Red Alert! or maybe you converted all of your footage to ProRes but either way once you have moved beyond the raw .R3D files then you never really go back to them except for the occasional reframe or tweak in RedCine. At this point you do have a lot of options. Out to tape with ProRes and color correction from that. Export uncompressed Quicktimes for finishing on another system. Export tiff or targa sequences for finishing on another system. Or maybe a trip into Apple’s Color (good luck with that one!). Oh, and there are a whole host of color grading options right inside FCP as well.

But still, getting back as close as you can to the .R3D files for the final finishing and, more importantly, color grading means there is that much more quality and latitude in the image to work with. If you can get your edit back to the .R3D files then you can generate DPX sequences of your edit that can go to any number of systems for the final finishing. Second to the .R3D files, DPXs are a great choice. RED provides a free tool in RedCine to allow the editor to take the .R3D files and generate DPXs (and many other file formats) from them.

But once you have all your edit decisions from the offline approved and ready to go, how do you get the edit decisions from the offline into RedCine to make files of only your offline edits? That’s where the bottle-neck hits. There currently doesn’t seem to be any easy, reliable and bullet-proof way to do this. RedCine can import an XML. Final Cut Pro can export an XML. This seems like a no-brainer but they are different flavors of XML so it’s not that simple. There is a utility floating around written by Ian Bloom called RedTrip that can convert the FCP flavor to the RedCine flavor. It works pretty well but it isn’t bullet proof. Depending on how your files are named, where they are on your hard drives, what kind of name and characters are in your directory names and what kind of things you might have done in your offline edit then RedCine might not be able to load a RedTrip generated XML. It should be noted that the RedTrip creator is a working Director of Photography and not a RED software engineer who wrote the RedTrip program for the good of the RED community so there’s probably only so much development and support he can do! Though he does a lot at the Reduser.net forums. Also, RedTrip is end-of-life as he works on a better, more intuitive product. I’ve seen a bit of what he is working on and it will be a lot better. This whole problem will get better as there are also several other developers out there working on tools to help with this very bottle-neck. (If you need a beta tester then please let me know). NAB 2008 is only a month away so I’m sure we will see solutions introduced there, if not sooner. The product is still new so some of these bottle-necks are understandable. But I know a lot of people who are holding off until this issue is solved.

So if you have to online a RED edit and you have to get back to the .R3D files in RedCine, at this point, the best and most reliable way seems to be a “by hand” method. Take your edit decisions and timecode numbers and clip names from the offline, load clips into RedCine and then export whatever format you need. Clip by clip or batch by batch. It won’t be fun as RedCine is quite a bear to work with but it might be the only choice. It might take a long while as RedCine is prone to crash and if you have a large edit then there will be a lot of back and forth between your offline tool, your media drives and RedCine. Of course how one might charge a client for this type of conform is another question indeed. I don’t even think I’d call this step a true “conform.” A RedCine-rebuild might be a better term. In fact, that’s the term I’m going to coin right now: the RedCine-rebuild! That might just become a new step in the RED camera workflow.

shoot > offline edit > RedCine-rebuild > conform offline > online edit > color correction/grading

If you’ve got a magic solution to this RED post-production bottle neck, hit the comments below and let the world know. You might just be a hero to many.