For the sake of context, these new Arri cameras begin at around $70K.

The Car Analogy

Over in this thread on Red user (which is of general interest to anyone concerned with this topic), another poster (I don’t want to use names without permission) suggested that perhaps we shouldn’t expect Red to have too much influence on Arri’s market. Arri has positioned itself as a high-end brand, and sells to customers with the money to afford its products. Red has much more aggressive pricing, and sells largely to the low-budget market, moving a lot more units. The poster compares the companies to Mercedes and Hyundai, respectively, and makes the case that once you’ve established your brand downmarket, it’s hard to move up; how many people would buy a luxury-model Hyundai, if Hyundai decided to make such a thing?

This initially seems plausible, but… is the car analogy really the right model? Cars are a basically mature technology, with differentiation mostly based on aesthetics, brand marketing, and non-functional frills like fancy interiors. Digital cinema cameras, in contrast, are in extremely active development. There are real technical differences between them and there are real improvements from year to year. In fact, the whole shape of the market is still in flux, as demonstrated by the fact that over the last couple of years, Red appears to have sold some thousands of units to people who were previously not in the digital cinema camera market at all, but in the ENG or prosumer camera markets.

Image not to Scale

Maybe instead of Hyundai vs. Mercedes, we’re looking at Mac and Windows NT desktops vs. SGI workstations in the late ’90s. Yeah, remember Silicon Graphics? They made expensive specialized hardware for a small customer base. They were good at it. I’m sure they told themselves the same things the high-end vendors are telling themselves now. “Our customers have a lot of money, and they want the best, and there will always be a market for that.”

They got completely trashed by the rise of commodity hardware. Completely. Trashed.

Why? Because it turns out there are massive economies of scale with most technology products, both for R&D and actual physical production. If the other guy is selling 50x as many units as you are (or in SGI’s case hundreds or thousands of times as many units), it might well be the case that you can’t make a better product even if you charge 10x as much for every unit.

Is this going to happen with digital cinematography cameras? Well… we won’t really know until someone shoots them side by side, but by the numbers Red’s new $7K camera body looks like it might actually produce a better image than Arri’s new ~$70K camera body. So that’s something to consider.

Coasting… off a cliff?

There are a lot of snobs in this industry, and enough subjectivity that they’ll be able to go on justifying the use more expensive gear even if it doesn’t really work any better. That will let some vendors basically ignore Red for a while. Maybe years.

But I think eventually, if for no other reason than that workforce turnover will fill the industry with people who came up using the cheap/powerful stuff, it will be “change or die” time. Companies like Arri need to decide whether they want to get out ahead of the market on this, or try to hold onto the existing high price/low volume model for as long as possible. The latter approach (which is, unfortunately, the direction companies most often decide to take in situations like this) will mean that when these vendors do eventually try to make the transition, Red will already be firmly entrenched in the market they’re trying to move into.

There’s a lot of counterproductive elitism in the film world, and one of the silliest examples of it is that right around the time the Red One started shipping (this is pure coincidence, I’m sure), some people suddenly decided that Bayer pattern sensors (see Wikipedia article if you’re not familiar) like the ones used in Red cameras are somehow unacceptable for motion imaging.

This, of course, has essentially no basis in reality.

Bayer is virtually the only technology used in the stills world these days, from the cheapest consumer cameras to the most expensive large format digital backs. Bayer sensors are used by probably tens of thousands of pro photographers every day to shoot images that sometimes get blown up to billboard size, and as stills, tend to be examined with far more scrutiny than individual frames in a moving sequence ever will be. And yet somehow, Bayer has been presented by some people in the motion imaging world as some sort of weakness for the Red One, as if Red is somehow cheating.

The truth is, Bayer is so widely used because for a given photosite count, with proper processing, it delivers a better image than anything else. Three chip designs or striped sensor patterns deliver at best 20-25% more visible resolution using 300% more photosites; in many cases it would make much more sense to just build a higher resolution Bayer sensor.

The real reason why Bayer isn’t already widely deployed for high-end motion imaging is not that it’s somehow unacceptable for that purpose, but that high-quality Bayer processing is very computationally intensive. The Red One gets around this by recording a raw image, so this computation doesn’t have to happen in real time — but as the RED Rocket and the 1080p RGB recording modes on the new cameras demonstrate, it is now possible to build ASICs which can do such processing in real time, which allows Bayer sensors to be used even in workflows that require high-quality live output.

I expect that as a result of this, we’ll see large Bayer sensors increasingly become the dominant technology in high-end motion imaging, just as they have in the stills world. Arri’s new cameras all use them. (Though whether this will clue in the industry snobs is anyone’s guess. A friend of mine was having a chat with someone at an LA rental house a few days ago who explained they’d be buying into Arri’s new system rather than Red’s because “The Red uses a Bayer sensor, and is really only a 2K camera”, apparently completely unaware that the Arri cameras are also Bayer, and Red’s S35 cameras are 5K to Arri’s 3.5K.)

Update: David Newman of CineForm points out that processing Bayer images isn’t necessarily that computationally intensive, and that most of the computational overhead of working with Red footage is associated with the compression, not the debayer process. I wonder what implications this will have for the RGB recording modes on the new cameras. If most of the complexity is in the compression rather than the debayer, playing back Redcode RGB footage might actually be more taxing than playing back raw footage currently is, which I think is contrary to what most people expect.

As existing Red One owners, we’re pretty happy, though it’s going to be hard to decide whether to upgrade in Stage II or Stage III — as I see it, upgrading in Stage II basically means getting to keep your Red One body for an extra $9000. But if the previously announced price on the S35 Scarlet holds up, that will be only $7000 and if you don’t need anamorphic, speed ramping, or frame rates about 72 fps, will otherwise be a better camera that’s part of the new modular system and so can share accessories with the Epic X better. Our decision will probably come down to timing; it’s unclear at this point how much of a time gap there will be between Stage II and Stage III.

Absolutely incredible.

Incidentally, sorry about things being a little slow lately here at Indie4K. There hasn’t been a huge amount of Red-related news since Final Cut Studio 3. The good news is, things seem to be heating up again.

We’re also about to head into production on a round of our own short projects (we’re shooting the first of them next week) which I can actually post interesting stuff about (unlike most of the projects we work on for other people), and I expect some interesting blog material to come out of that.

So, this isn’t the huge rewrite some have been expecting. As noted here, this doesn’t even seem to be Final Cut Studio 3; Apple is just calling it “The new Final Cut Studio” everywhere.

Update: Hmm… except in a couple of the screencasts they do call if FCS3. Which suggests this branding decision may have been last-minute.

That major rewire is undoubtably still coming; when Apple axed 64-bit Carbon they implicitly committed themselves to eventually rewriting Final Cut (their last major mostly-Carbon app, other than iTunes), but it looks like that will have to wait for the next version. The good news is, the fact that Apple isn’t calling this FCS3 might very well mean that we won’t have to wait two full years for that next release. I’d assume that, if this is just an interim update, they’ve been working on the larger release in parallel with it. Perhaps next year?

Notable Features

As I see it, there are basically five features of major significance to Red users here.

ProRes 4444 – A new 320 Mb (40 MB/s) variant of ProRes that supports 4:4:4 chroma sampling and full-resolution alpha channels. You can sort of think of this as being to DPX what ProRes 4:2:2 was to uncompressed HD: a format that makes minor compromises to quality, when compared with uncompressed material, in exchange for footage that’s vastly easier to work with. Testing will, of course, be required, but it’s possible this might be a plausible — and very convenient — finishing format for indie projects, perhaps even indie features.

4K support in Color — Not much explanation required here.

Better R3D Support — Final Cut still can’t (as far as I can tell) edit R3D files natively. But it looks like you can now use CinemaTools to manage the relationship between ProRes proxies and R3D files, and more easily move from a Final Cut timeline using the former to a Color project using the latter.

Generally better Color/Final Cut integration — Not applicable solely to Red workflow, of course, but it looks like a lot of work has been done to make Color smarter about dealing with complex Final Cut timelines. It should no longer get confused with speed changes, stills, and other things that currently confuse the hell out of Color.

Automatic importing of file-based recording media — It looks like Final Cut can now detect when a drive or card is mounted, and start automatically importing media from it. There also seem to be some new features for retaining more metadata from imported file-based media, but it’s not clear if that applies to R3D files.

Cheaper Color control surface options — Again, not Red-specific, but Color now supports the ~$1800 Tangent Wave control surface, among others, lowering the price barrier to using a control surface to about 1/5th of of where it was previously.

Blu-ray & the future

Apparently, DVD Studio Pro still doesn’t support actual Blu-ray authoring. What we have instead is sort of strange and, I think, rather telling. Compressor can encode Blu-ray compatable H.264 now, and create Blu-ray discs using pre-built Apple menu templates. These templates are apparently in some sort of XML format, so anyone comfortable with a bit of XML slinging can build their own. I have a sneaking suspicion that what we’re looking at here is an early version of the file format of a new application that will eventually replace DVD Studio Pro.

More as I discover it.

Workflow

• On your transcoding/conforming machine (needs to be an Intel Mac), transcode R3D files to 720p ProRes SQ with the “quarter res” setting (“Draft” process in Redcine). You can do this from Redcine, Red Alert, Redline, Clipfinder, etc.
• Edit with 720p files in Final Cut. These files can be pretty easily edited on just about any Mac hardware you’d consider running FCS2 on in the first place, including laptops or those old G5 towers you still have kicking around.
• Back on your transcoding/conforming machine, export your edited sequence from Final Cut as XML. use Clipfinder to swap references to your ProRes files for references to _H proxies, and let Clipfinder change the resolution settings on your sequence to match. Import the newly generated XML file back into your FCP project. It will come in with the same name as your ProRes sequence, so rename it so you can tell them apart.
• File -> Send To -> Color in Final Cut with your newly imported sequence.
• Immediately save your Color project and close. Use the “looping bug” fixer in Clipfinder (in the Tools menu) on the project.
• Re-open the Color project and grade.
• Render out of Color to ProRes or Uncompressed HD and send project back to Final Cut for titling, etc. or render to DPX and handle further processing in After Effects, Shake, etc.

Notes

• We typically use Redcine to export the ProRes files. It lays everything out on a timeline for you and makes it easy to do a quick one-light grade.
• When transcoding your ProRes files, make sure they have the same names as your R3D files (except, obviously, with a .mov extension rather than a .R3D extension). Redcine might add an extra underscore to the end of file names; use a script or batch renaming utility to get rid of it, or it will cause trouble when you try to conform. (If it’s already too late, then before you process your exported XML sequence though Clipfinder, open it in a text editor and do a search/replace of “_.mov” to “.mov”).
• If you haven’t used Color before, be sure to read the section of the user guide that discusses its limitations when working with transitions, filters, still images, etc. from Final Cut timelines.

Analysis

This is basically my favorite low-cost Red workflow. It’s the first commodity-software workflow that, in my opinion really has all the essential pieces in place.

Pros:

• Fully compressed (except possibly the final output, if you choose to output in an uncompressed format) — you could plausibly finish even a feature with just a couple of terabytes of storage and you don’t even really need a RAID array.
• Transcoding to 720p files from a 1/4 resolution de-bayer is quick. It can be near real-time on a single 8-core Mac Pro.
• 720p ProRes files are very lightweight, only a little more than twice the data rate of DV, making it easy to take projects with you. Edit on your laptop, conform on the Mac Pro back at the office.
• FCP on just about any modern Mac is very responsive while editing 720p, unlike with the comparatively much heavier workload of editing R3D proxies.
• You can do a quick one-light when creating the 720p files, so your editor can look at nicer footage than R3D proxies with whatever look metadata they happen to have.
• You’re grading in an environment which provides access to the full range of the R3D data and also provides vastly more powerful color correction tools that Redcine or Red Alert.
• Only the precise frames used in your final edit ever have to be transcoded at high-quality (happens when you render out of Color).
• If you have a Mac Pro and set Color to quarter-resolution playback, you can even get real-time playback of R3D in color projects, at least if you don’t get too carried away with secondaries, and it doesn’t look terrible on a client monitor.
• No messing around with Media Manager or Log & Transfer in Final Cut.
• This workflow doesn’t require any software other than Red’s software (free), Clipfinder (donationware) and Final Cut Studio.

Cons:

• Limited to 2K finish or below. (Then again, even most Hollywood features still aren’t finished above 2K.)
• Footage is fed into Color via the equivalent of a “half res high” decode, not quite as good as decoding full 4K and scaling. (But good enough for almost any HD finish, in my opinion.)
• Requires up-front transcoding, unlike R3D proxy-based workflow.
• Because of decoding overhead, Color is not as responsive with R3D files as with uncompressed HD or DPX (if you have a RAID fast enough to handle those formats in real time).

The computer industry will certainly push for higher resolution displays, mostly because ~200 dpi allows for vastly better text rendering. I tend to think that the technology will be in place for reasonably priced consumer 4K within the next four years or so, but that there really won’t just be much consumer demand. You have to sit almost comically close to a 50″ TV before you start wishing you had more detail than 1080p provides. Consumer 4K stands a good chance of ending up like SACD and DVD Audio; most people thought CDs were more than good enough, so these formats went nowhere. In fact, the formats that eventually did largely replace the CD — MP3 and AAC — were [I]lower[/I] quality, but more convenient.

Maybe if TVs keep getting bigger… but I think they may already be large enough that most people don’t really want something bigger in their living rooms, so there might have to be some big change in technology for that to happen. (“Screen paint” that turns walls into screens or something. Give it 20 years.)

Now, maybe I’m wrong about all this, and consumer 4K will be the big summer hit of 2014. But I suspect if Red wants to make a play for the mainstream consumer distribution market, what they should do is develop a version of the RedRay codec optimized for 1080p Internet streaming. If what happened with music is any guide, Blu-ray won’t be replaced by a higher quality physical media format, but by a substantially more convenient (and possibly somewhat lower quality) downloadable and streamable format.

I see RedRay’s primary use being on Red productions, in Red post facilities, on the festival circuit, in art house theaters and other indie venues, and possibly for wider theatrical use if it supports some sort of copy protection.

The player can output 4K, 2K and 1080p. The Red demo was a reel (material shot on the Red One, of course) compressed with a new RGB codec designed for the RedRay, with a data rate of just 10 Mb/s. That’s 4K at 1/3 of the bit rate of a typical Blu-ray disc, which would be a substantial advance in compression technology. Sufficiently substantial that there has been a fair bit of skepticism about it, in fact.

I’d like to address a bit of that here. As I pointed out in this post over on Cinematography.com, while the advances embodied in RedRay are quite impressive, they’re technically plausible. Blu-ray runs at around 30 Mb/s, but this is mostly because it can; Blu-ray discs offer room to spare. Respectable 1080p video can be delivered with the H.264 codec at as little as 10 or 11 Mb/s. See Apple’s trailer site for many examples. 4K is around 4x the number of pixels of 1080p (just a little more, actually), so this means Red’s new codec is perhaps 4x as efficient. That’s about the same improvement factor that H.264 offers over MPEG-2, the codec for standard-definition DVD. The upshot is, we’ve seen codec improvements on this scale before.

There is, of course, no such thing as a free lunch. And in the case of dramatically improved video quality at a given bit rate, the cost comes in the form of computational overhead. H.264 requires much more processing power to decode than MPEG-2, and I suspect that the RedRay codec requires so much that real-time software decoding will be impossible for the next several years, and you’ll have to use a dedicated hardware device with an appropriate ASIC (a specialized processor) to play the footage.

Fortunately, the RedRay, which is precisely such a device, is supposedly going to be priced under $1000, making it a very handy tool for Red productions and post facilities, and probably of considerable interest on film festival circuits and to art house theaters.

We have Red #404. We got it February, and have shot quite a lot with it. I’m with the camera virtually every time it’s used.

I’ve never seen the camera overheat.

I’ve never seen a Red Drive drop a frame, even in fairly jarring handheld use. We had a shoot a couple of months ago with the operator basically running through the bottom floor of a house doing whip pans — no frames dropped over about 20 takes. About a month ago we were using the camera handheld on-stage at a rock concert. I was keeping a close eye on the frame drop readout because sound becomes a real physical force at those intensity levels, but the drives held up fine. Red Drives are known to drop frames when there’s substantial mechanical vibration, such as with vehicle mounts. The simple solution is to not use them in those applications. It’s not as if Red doesn’t provide alternative recording mechanisms.

I have seen occasional boot failures — maybe one in 20 times the camera will freeze during boot. But you can tell that it’s frozen about 10 seconds into the boot process, and a quick power cycle resolves the issue. Total time lost, maybe 15 seconds.

As far as workflow goes… there have been perfectly workable Red workflows from the beginning. If you’re finishing in an HD video format, a $3500 Mac Pro tower can convert 4K Red footage to 1080p ProRes, DNxHD or uncompressed video at a rate of about three hours per hour of footage using the “Half Res High” decoding mode (which I believe is the same thing as “Standard” decoding in RedCine). On most shots this is nearly indistinguishable from doing a 4K debayer and downscaling, except that it’s about four times as fast.

Three hours per hour of footage means that you have your footage in online quality by the next morning.

For DI-style workflows, 2K DPX transcoding takes about the same amount of time (assuming you’re writing out to disks fast enough to write about 8 2K DPX frames per second — which isn’t all that hard these days).

A 4K DPX transcode might be more like 12 hours per hour of footage, but hey, two frames a second is, as far as I’m aware, a lot faster than any 4K film scanner in the world. And you could build a commodity hardware cluster which could do such transcodes in real-time for under $50K, probably, if you were so inclined, which is rather less than a 4K film scanner.

There are, of course, post houses which will provide these transcoding services if you don’t want to keep the infrastructure in-house. Though it would be a little silly for an individual or organization working with footage from high-end cameras to not keep a recent-model workstation in at least the $4000 range kicking around.

And, you can, of course, work with the footage on any Intel Mac (any Intel Mac with non-integrated graphics, for RedCine). You probably don’t want to transcode hours of footage on an iMac, but there’s nothing stopping you. And a MacBook Pro is pretty standard equipment on Red sets of checking footage on-set. You can play back 4K as 1K and output full-resolution stills. And play with one-light grades in real-time in RedCine to check if you can push the footage the way you want to.

The reason there’s so much discussion about Red workflow isn’t because there’s no practical workflow. It’s for two reasons.

One is that, because the model for the camera is to shoot in a proprietary format and then transcode, and because the camera is used for a wide range of productions, there is no one obvious workflow. This isn’t DVCPRO HD, where the standard workflow is to capture tapes (or download cards) and drop into Final Cut. You might want an HD workflow (compressed or uncompressed), or a DI workflow. You might want an offline or an online workflow. You might be happy with a workflow that requires you to transcode all the footage you shoot, or one that only requires you to transcode the shots you use in the final edit, or maybe only with one that only requires you to transcode the specific frames you use in the final edit. All of these, in many combinations, are possible, and they have different implications for quality, cost, and technical ability.

The second reason Red workflow gets discussed so much is because a lot of people aren’t happy with traditional HD and DI workflows, when they can see that Red’s compressed raw capture makes something better possible.

If you just transcode all of your footage to an HD video format, you lose the full range of the raw files before you’ve even started. You can do some grading in RedCine before you convert, but RedCine is pretty far from being a fully-featured grading environment.

You can mostly avoid this problem by transcoding to 10-bit (log) DPX or 16-bit (linear) TIFF, but workflows based around those formats require tens of terabytes of very fast storage and many commodity-priced software tools can’t work with them, so costs can quickly escalate to traditional DI levels as soon as you start to go this route.

What many people have been waiting for is the ability to work with all the data in those compressed raw files without having to transcode them into an unwieldy uncompressed format before feeding them into editing and grading tools. This has taken a lot longer to emerge than I think some people expected, which may have more to do with third-party vendors than Red itself, but has nonetheless been unfortunate for Red’s customers.

But in the last couple of months — last couple of weeks, for Final Cut — we’ve finally started to see this.

As of a couple of weeks ago, after I edit 1K or 2K proxy files (of 4K footage) in Final Cut Pro (an old capability), I can then send the edit to Color (the Final Cut Studio grading app), grade in a fairly capable environment with full access to all the data in the raw file, and then render out in any format up through 2K DPX.

And while it’s certainly nicer to do this on a $5000 8-core Mac Pro at the office, I can also do this on my $2000 laptop. I could do it on a $1200 iMac. With no external disks other than consumer-priced external FireWire 800 drives. And no software other than Red’s free tools and Apple’s $1299 Final Cut Studio.

It’s now not at all implausible to take a feature through the editing, grading and conforming processes, ending up with a 2K DPX conform, with less than $10K worth of hardware and software.

That’s the workflow everyone has been waiting for. And while there’s still room for quite a bit of refinement, it’s here now on the Mac with Final Cut, and while I haven’t kept such close tabs on the Adobe side of things, I gather things are moving along there as well (on both platforms).

The first is rewrapping R3D data into QuickTime files that Final Cut can work with natively, though Final Cut’s Log & Transfer interface. There’s some debate about this, but as far as I can tell it appears to simply create QuickTime movies that are the equivalent of the existing QT proxy files, but self contained. This isn’t actually all that useful. (Why not just use the proxies? Rewrapping all the same data is just going double the amount of disk space your project uses for no good reason.)

The second feature is far more significant. Previously if you did a ‘Send to Color’ in on a Final Cut sequence containing containing Red proxies, you got… nothing. You got a bunch of clips on a timeline in Color that Color couldn’t do anything with. After installing this update, not only do proxies (and the new QT-wrapped files) show up in Color, but Color has access to the full raw data.

This workflow lets you edit immediately without any up-front transcoding, only requires you to transcode the exact frames you use in your final edit (they get transcoded as the footage gets rendered out of Color), allows you to create anything up to a DPX or uncompressed HD final deliverable without any previous step requiring you to work with uncompressed data, and provides access to the full range of the raw image capture by the camera in a grading environment significantly more powerful than RedCine.

While other workflows have offered some of these benefits, this is the first workflow which offers all of them at commodity prices. (Previously only SCRATCH offered all of this, and not at commodity prices.)

Now, there are a few caveats:

• As is fairly typical for this kind of dual-app edit/conform workflow, Color doesn’t render Final Cut video generators, filters, motion tab settings, or transitions other than dissolves. This isn’t as bad as it might sound, because these things aren’t typically used on feature film projects, and if you’re not editing a feature that’s being rendered to DPX, you can round-trip through Final Cut (do a ‘Send to Final Cut Pro’ in Color) and handle all of this back in Final Cut.

• Color only supports up to 2K. No 4K finishing from this workflow. 2K comes in as 2K. 3K, rather awkwardly, comes in as 1.5K, which I think Final Cut’s real-time engine has some issues with.

• I believe 4K footage through this workflow is rendered at the equivalent of the “half high” setting in Red’s other apps. It would be nice to have the option to have 2K scaled from a full 4K debayer as well.

• This new software hasn’t yet been tested extensively with Build 18 footage, or formats other than 4K 2:1 and 2K 2:1. I’ll be doing some tests with 4KHD this week. 4KHD is going to be important to this workflow because 4K footage comes in at half its native resolution (see above), so if you want to finish in 1080p, shooting 4K HD will make your life easier.

The Red Final Cut Studio 2 Installer linked above comes with a 24 page whitepaper on Red FCS workflow that lays all of this out in much more detail, if you’re interested.

Ten years from now it’ll probably be possible to do something significantly better than the RED ONE (higher resolution, higher frame rates, HDR), with a body the size of a present day digital SLR, capturing to commodity storage (hours of footage on the future equivalent of a CF card), for a few thousand bucks. This is an information technology market now, and that’s the kind of progress I think we can expect to see, especially as RED’s competitors react to RED, or more companies enter the market with RED’s outlook, and we get rid of the sort of market segmentation nonsense that has plagued the market thus far.

At the same time… RED looks like it’s going to deliver an image good enough for almost any purpose, up through 4K theatrical projection. And there probably isn’t much point in going over 4K for projection, due to limitations in the resolution of human vision. The 4K RAW + REDCINE file-based workflow also eliminates a lot of artificial barriers in terms of data and tape formats as well. This means, unlike with more limited cameras, you won’t be praying for something better starting from the day you unpack your RED. Though better things will come out, the camera should have a very good useful life span, compared with products which are much more compromised out of the gate, like today’s prosumer cameras.

Also, many of the accessories you buy for your RED (PL mount lenses, matte boxes, etc.) are built to industry standards that have already lasted for decades, and will probably last for decades more. This is, again, a considerable improvement over the prosumer market, where accessories are often specific to one camera or one vendor. It will do a lot to help protect the value of a serious investment in this sort of kit.

Well, yesterday’s Red announcements will get us closer to everything I described in the first paragraph. Anyone who didn’t expect that to happen hasn’t properly internalized that it means for an industry to become an information technology industry.

But everything I said in the second paragraph is also still true. The images from the Red One held up quite well on cinema screens last Wednesday, before the new announcements. And they still do today. And they still will in 12-24 months, when Red’s new stuff is shipping. And they probably still will in 10 years; human vision isn’t getting notably better over time. To all the people freaking out about having an obsolete camera soon… why did you buy the thing? If you bought it because you wanted to make images of sufficiently high quality that they’re acceptable for anything up through theatrical exhibition, relax. You own a camera that does that, and nothing Red introduced yesterday (or will introduce in the future) will change that.

It also pays to consider the details of Red’s new lineup. First off, pricing. Red has announced the prices of its planned line of “brains”, but not of any of the other components that turn them into fully-fledged cameras. You shouldn’t be looking at that $7000 Scarlet brain and telling yourself it does everything your Red One does at less than half the price. I have no idea what the prices on the other system components are, but given that they’re shared with the Epic brains, which are designed for the high-end market, I’m guessing they’re very high quality, and not cheap.

It’s not too hard to imagine you’re looking at another $5000 for the I/O module, a recording mechanism, the control mechanism, and the lens mount. If that’s the case, it’s not a $7000 camera, it’s a $12,000 camera. Which, while it shoots at a slightly higher resolution than the Red One, and comes in a more modular smaller and lighter package, also doesn’t have the frame rate and format flexibility of the Red One. Jim Jannard has been very clear about this, though details haven’t been posted yet. I’m guessing the Scarlet models won’t be able to shoot 2K at 120 frames/sec, won’t have an anamorphic mode, and might not support frame rate ramping. Does the Red One really seem like such a bad deal for $17,500 at that point? Especially considering that Red plans to offer some sort of sensor upgrade for the camera.

How about going in the the other direction? Red is offering that $17,500 credit to Red One owners if they upgrade to Epic. I just did an analysis of what we spent on our Red one. In total, we sent $34,347 to Red. Of that, we’d get a credit for $17,500. Another $6500 of that is the Red 18-50 zoom, which we’d keep and use with Epic (If we decide to upgrade, it’ll almost certainly be to the S35 model). Another $4650 is the viewfinder and EVF, which will also work with the Epic. And then there’s $2350 for batteries and a charger — also compatible with the new equipment via an adaptor cable You’d probably still want some of Red’s new batteries for form-factor reasons, I’m guessing, but I suspect we’d still get use out of our Red Bricks.

Add that all up, and $31K of the original $34K we sent to Red is either eligible credited against our Epic purchase, or went for gear we could continue to use after upgrading. In other words, if we upgrade, buying the Red One will have gotten us a digital cinema camera to use 18-24 months earlier than otherwise, for an additional cost of less than $4000 vs. waiting for the S35 Epic to ship and buying that to begin with. Given what the Red One has done for our business, and the skill set it has allowed us to build up, that seems like a pretty damn good deal.

If there is a group Red’s upgrade plans don’t work for, it’s Red One owners who want to buy into Red’s new modular system, but can’t afford the Epic and are willing to take a bit of a hit in terms of features going with the Scarlet.

Red doesn’t provide any sort of trade-in credit on Scarlet purchases, just a one-time 12% discount to existing Red One owners (you get to keep your Red One, of course). But there’s a simple way around this: sell your Red One. With the $17,500 credit for Epic buyers and the fact that the Red One will still offer some capabilities the Scarlet brains won’t at a much lower price than the $28,000 S35 Epic, there should still be a decent market for Red One bodies for a while. You won’t get $17,500 (now that Red is caught up on orders, anyone who wants to spend full price will just buy a new camera), but you’ll probably get enough to go a long way toward funding your Scarlet purchase.

I really love the modular concept here. Red is definitely headed in the right direction in that respect. As for the large number of “brain” options, I was initially concerned, but having thought it through, I think I might have figured it out.

I’ll leave the large-format cameras out of this for the moment, since they’re clearly specialty devices, and aren’t even expected until 2010 (and Red tends to be a bit optimistic about ship dates).

That still leaves six other “brains”. Logistically, for Red, this might not be quite as bad as it initially looks. I would guess there are only three sensors for the six cameras, and equivalent Epic and Scarlet models have the same sensors. That is, the S35 Epic probably has the same sensor as the S35 Scarlet. On top of this, you’d then have two different electronics packages, one of which can process over three times as many frames a second.

This does make the pricing structure seem rather strange, at first glance. It’s a little hard to see spending over $20,000 more just for electronics that can process frames faster.

Red doesn’t strike me as the sort of company that sets up completely artificial pricing tiers like this, so this got me thinking about just what might be going on here, and I think I’ve got a plausible answer. Mind you, I know absolutely nothing about manufacturing image sensors. But I am a bit familiar with how the CPU market works.

You’ll often see CPU vendors like Intel offering the same chip at 10 different clock speeds (GHz ratings). The reason this happens is because the manufacturing process is inconsistent, particularly for the latest and greatest chips. After each chip is made, it gets tested at higher and higher speeds until it becomes unstable. Once that happens, it gets marked at its highest stable speed, and sold as a chip with that specification. Its price reflects what fraction of chips rolling off the line are capable of reaching that speed.

What I’m getting at here is, Intel doesn’t set out to make the chip at many different clock speeds, but that’s what happens, and they have to offer products based around that natural variability.

If the same thing is true of image sensors, it could explain both the large price difference between equivalent Scarlet and Epic models, and the reason why Red offers so many models to begin with. If only one in ten chips from the factory can operate at 100 frames per second, Red would be nuts to throw out all the other nine — maybe 8 of them can still operate at 30 frames per second, so why not build a camera around that spec? That’s the Scarlet. At the same time, if you have that one chip in ten, why stick it in a camera that only operates at 30 frames/sec when you can use it as the basis for a lower volume but higher margin product? That’s the Epic.

Now, take into account that Red wanted to offer both S35 (for traditional cinema-style shooting) and FF35 (for people from the stills world), as well as 2/3″ cameras for the low-budget market, and you end up with five or six models as the minimum. But if my speculation above is correct, rather than being a liability, having two versions of the camera for each format is practically a necessity.

(Once again, I have no idea if any of this actually applies to image sensors, etc. etc.)

In my response to his original article, I pointed out that the necessity of optical low-pass filtering means that a native 1080p camera isn’t going to resolve a full 1080 horizontal lines of resolution. Johnson says:

-The IDEA of an optical low-pass filter is to fuzz or blur resolution information that is SHARPER than the sensor can even see — not to blur information that it CAN see. So the mere fact that there is a low-pass filter does not in itself prove that resolution is lost (an underperforming low-pass may not fuzz ENOUGH and create aliasing without reducing resolution at all). So, even though a REAL low-pass filter as opposed to an IDEALIZED one can reduce resolution, the mere fact of a low-pass filter does not in itself prove that resolution is reduced (at least not measurably).

In practice, it does. Nobody knows how to make optical low-pass filters with a hard cutoff. If you filter enough to avoid aliasing (which is extremely undesirable in motion imaging — far more so than with still photos), you’re going to lose detail that the sensor could have otherwise resolved as well. One way to avoid this is to oversample and then downscale digitally — as the Red One does when shooting 4K for an HD deliverable. Aliasing can be introduced by digital downscaling as well, but digital scaling algorithms can be more finely tuned than physical filters.

-Our article points out that 1.8K is MORE THAN ENOUGH for theatrical resolution, so even if the low pass filter fuzzed the 1.9K image to 1.8K (which is extreme), it’d still be sharp in excess of the standard. There is no reason to think that Sony has gaffed the design even the amount mentioned. Additionally, it is not mentioned in your refutation that Red also has a low-pass filter and that it is much more difficult to optimize a low-pass filter for a single-chip (like Red has) than it is for 3-chips like F23 has.

It’s true that the resolution “loss factor” due to low-pass filtering is higher with single-chip bayer cameras than with three-chip cameras. Bayer sensors need more aggressive filtering to avoid chroma aliasing artifacts. This is one reason I mentioned the results of actual resolution tests with the Red One.

As for the discussion about whether 1.8K is enough for theatrical exhibition… that isn’t really a technical matter that can be settled one way or the other. Johnson seems to believe it’s enough that once you achieve it, resolution is no longer worth worrying about. I’ll acknowledge that that’s often the case. As I’ve pointed out before, this is more resolution that one finds in a typical release print. But it’s not always the case.

In response to my comments about how stills photographers often shoot far more resolution than they need, Johnson says:

-Still photographers often do extreme reframing by cropping. Motion pictures almost never do this (at least not more than a tiny bit that has no practical effect on resolution). Motion images ALWAYS color correct and need rich image information and almost NEVER crop in any meaningful way — the analogy to stills is meaningless, because, in motion, color information is constantly used to adjust the image with color grading, while resolution is almost never used to do “cropping.”

I agree that it’s true that motion images are rarely cropped. But Johnson just takes it for granted that this is how motion imaging works. I believe cropping is more common in the stills world not because it wouldn’t be just as useful in the motion picture world (particularly for e.g. documentary work), but because technical limitations have made it much more difficult to do in the motion picture world. Even with film it’s not advisable. A motion picture negative is significantly smaller than a 35mm photo negative, but is (generally) presented at a much larger size. There’s much less room to crop and still maintain acceptable resolution. Having enough resolution to get away with cropping a bit is a legitimately useful feature.

Moving on to color depth, Johnson says:

We are clear now that we’re talking about quantization of the camera (not necessarily of the photosites themselves) — and you may notice that our argument isn’t diminished at all when we clean up our wording to conform to your stringent standards. Sorry that we worded it too loosely the first time, but the reality is that F23 and Genesis gather 42-bits of REAL DATA ABOUT THE IMAGE per pixel (before mapping to 10-bit-per channel or 30-bits-per-pixel) whereas the Red gets 12-bits-per pixel. 30-bits represents over a billion unique colors/luminances whereas 12-bits represents 4096. That’s a hell of a difference.

Um…. this response has absolutely noting to do with the way bayer sensor cameras produce color images. Yes, the Red only records 12 bits of color information per photosite, but the color of a pixel in an RGB image produced by processing a raw bayer-pattern image is never based on the value of a single photosite. It couldn’t be; a bayer camera can’t produce an RGB color based on the value of a single photosite, because each photosite only detects a single color.

The value of every pixel in an RGB image produced by a Red One is derived from three color channels, just as it is with an F23 or a Genesis. Those color channels each contain 12-bit linear data, comparable to the 10-bit log data contained in each color channel of an F23 or Genesis. It’s true that the channels aren’t full resolution, but the Red exceeds Johnson’s standard for resolution, so that doesn’t really come into play in this discussion.

This is absurd. You’re saying that the higher the resolution and the higher the compression, the better the image, no matter what.

I was very careful to not say that. I merely said that higher compression ratio + higher resolution don’t necessarily produce worse images. The uncompressed SD vs. Redcode 4K is merely an extreme example to make a point, namely that less compression isn’t necessarily better.

As we pointed out, the thing that you CAN quantify is how hard the scheme has to work — and you say wavelet is more efficient (that’s in general, not in the specific case) — but RedCode had better be more efficient, because Red is a LOT more compressed than HDCAMSR and it has to be a LOT more efficient just to look AS good.

Look, I’m not saying HDCAM SR compression is bad. But it was designed when processors were slower, and it was designed to be the core of a real-time workflow. As a result, it’s not at all far-fetched that Sony and Red made rather different tradeoffs regarding computational requirements vs. compression efficiency.

And there are some other factors to consider. Raw data is often more compressible than processed data — there’s no artificial detail introduced by sharpening or other image enhancement that has to be preserved by the compression engine. Additionally, we both agree that at 100% size bayer images are softer than the images produced by RGB cameras, which also makes it easier for the compression algorithm to squeeze things down a bit more.

When you combine all of these factors with a more efficient (but more computationally intensive) compression algorithm, the difference in compression ratios isn’t nearly as startling. There’s no doubt that the Red One compresses data more. But the difference isn’t nearly as significant as comparing the compressed file sizes to uncompressed DPX frames initially suggests it is.

All due respect Chris, but no, actually, this is where you’ve missed by the widest margin. Raw is indeed a good way for Red to design their camera: it’s an advantage that Red has over an imaginary Red camera that’s designed a different way, but it’s not an advantage of Red over HDCAMSR. Raw is a description of WHEN YOU DEBAYER. Bayer is a subsampled kind of sensor. F23 and Genesis don’s subsample, so there’s no question about WHEN to debayer.

Recording raw sensor data isn’t just about whether you debayer in-camera. It’s also about whether you bake-in color settings, curves, sharpening, etc. in-camera. In principle someone could build a raw three-chip (or RGB striped sensor) camera. Actually, that’s basically the Viper in FilmStream mode, come to think of it. The F23 and the Genesis don’t really have raw output modes. They don’t record sensor data, they recorded processed video images. If your on-camera settings are wrong, you’ll throw away data that you might have wanted to keep. And it’s important to note that the definition of “wrong” is not some objective technical thing that professional operators can avoid. It can change if, for instance, the director decides in the grading room to make a different sets of creative decisions than the ones that were dialed in on-set.

Finally:

The only thing we’re refuting is the phenomenon where people try to quote specs to show that Red is a technically better CINEMA camera. F23 and Genesis see and record MORE INFORMATION ABOUT THE IMAGE THAT IS IMPORTANT FOR THEATRICAL CINEMA.

The F23 and the Genesis are certainly very impressive offerings. But as this entire discussion has demonstrated, the situation is somewhat more muddled than the previous two sentences indicate. The F23 and Genesis do offer a bit more dynamic range and they are, at least at this point, somewhat more tested and robust systems — particularly taking into account all the HDCAM infrastructure out there in the world. The Red One captures more resolution and has, in my opinion anyway, a better workflow for cinema where real-time isn’t critical.

Last time around we discussed resolution and color depth. This time, we’re going to take a look at compression and the implications of raw recording. Oh, and price.

Compression is easy to address. I already posted on this subject a couple of months ago. If you don’t feel like reading that entire post, the short version is that capturing a much larger image, even with a substantially higher compression ratio, is going to preserve more useful image data than capturing a lower resolution image. As a really obvious proof-of-concept thought experiment, consider the fact that the data rate of 4K shot in Redcode 28 on the Red One is about the same as the data rate of uncompressed standard definition video. Throw both of them up on a movie screen, or even a moderately sized HDTV, and there’s absolutely no contest. Similarly, a 4K image, recorded at a high compression ratio, can look substantially better than a 2K image recorded uncompressed or at a lower compression ratio. It won’t necessarily, of course. It depends on the details. But one can’t argue from principles that it will be worse. One has to actually evaluate the results side-by-side. Subjectively, Redcode holds up extremely well.

Johnson goes on to say:

Red’s literature would have you believe that all competing compression schemes are in the stone ages (they often use the word “wavelet,” which is supposed to prove that their compression, not just their vocabulary, is better), but we don’t think so — we think that other state-of-the-art cameras are also state-of-the-art.

HDCAM SR is a DCT-based compression algorithm, like JPEG. Redcode is wavelet algorithm, like (and, in fact, based on) JPEG 2000. These are well established facts. And the fact that wavelet-based algorithms are more efficient than DCT-based algorithms — and have less objectionable artifacts for image compression — is not particularly controversial. Wavelet algorithms require more computational power, which is why they’re often not used in real-time systems. But they do provide better results, i.e. higher image quality and/or smaller file size.

Johnson misses the mark by the widest margin, perhaps, when discussing raw workflow. He says:

Some people claim that the processing of F23 and Genesis “bakes in” a look that you can’t undo in post-production and therefore Red has more information about the image available in post, but this “baking in” problem is only true if you have bad settings in the camera (like, if you crush blacks down to zero in the camera settings). Actually, when the equipment is operated correctly, you have MORE information about the image in post from F23 and Genesis (which is our whole point through this article), because these cameras record MORE color (and luminance) data about the image — you get more breadth and depth, more range for color-grading from the richer HDCAMSR file. Also, the exact same “baking in” problem applies to Red’s processing software as it does to F23 and Genesis — if you have bad settings, you’ll truncate data. So, if trained professionals are handling the equipment (whether it’s F23, Genesis, Red Camera, or Red Software), then there will be no “baked in” data truncation.

I barely need to write a response to this, do I? The advantages of capturing raw data are, by now, probably quite obvious to the readers of this blog. Johnson tries to set up an equivalency here that doesn’t exist (“if you have bad settings, you’ll truncate data”). There are two problems with this. The first is that a camera recording the output of a 14-bit analog-to-digital converter to a 10-bit tape format will always throw away data. If you have everything set up correctly this shouldn’t be a big deal, but it does remain a mathematical fact.

Secondly, there’s a very large difference between baking in what might turn out to be the wrong data on set, and baking it in using Red’s post tools. In latter case, fixing things requires reprocessing some files. In the former case, it requires a reshoot. Dismissing this by saying the article is “about technical quality of motion imaging, not time and place of motion imaging”, as Johnson does in the next paragraph, is simply bizarre. This is a factor which, in the real world, can have substantial impact on the technical quality of motion imaging.

Sony has been able to build image processing software and native hardware that can fit inside the camera and do full-quality lossless processing in real time. Red didn’t build it on-board and they can’t do it in real time. That’s not an advantage for Red. Red’s image processing software has to work much harder than Sony’s because the camera only gathers one piece of data per pixel instead of three, and the processing software has to work hard to turn that subsampled data into an intelligible color image.

It is true that in some workflows, it’s beneficial to have a high-quality video image available for playback immediately, rather than after substantial processing time. Fortunately, you can do this today with Red footage via SCRATCH CINE. Sometime next year, you should, according to current announcements anyway, be able to do it with the dedicated hardware in the RedRay player, at up to 4K.

Finally, a word on a subject probably of some considerable relevance to most of the audience of this blog: cost.

We need to keep things in perspective. The cameras Johnson is comparing the Red One to cost ten times as much. Or more. The fact that the Red One is even being compared to them shows just how much Red has achieved. The fact that the Red One wins some of those comparisons is absolutely stunning. The Red One’s more significant feature, when all is said and done, is that it puts a high-end imaging tool — a tool which shoots at sufficient quality that its footage is suitable for any deliverable, right up through theatrical projection — into the hands of thousands of people who would otherwise never have access to such equipment.

I’m breaking this into two posts because the first one was getting rather long. Second post will probably be up tomorrow.

Johnson argues that the Red One is over-optimized for resolution at the expense of other criteria, like dynamic range. As part of this argument he makes the case that 2K is enough resolution for a feature. This is largely true, but there are several mistakes in the evidence Johnson presents for this. For instance, Johnson uses the fact that Kodak defined 2K as a standard resolution for DPX/Cineon files as evidence that Kodak considers 2K sufficient. He says:

Note that Kodak could have made any specs they felt were required here to fully achieve the quality of 35mm film: for example, they could have prescribed a file that has more resolution and less color information. Here’s one they could have used: 4K pixels, 3 channels-per-pixel, and 8-bits per channel — that would have actually been the exact same file size as the spec they did choose, and they even could have said the word, “4K.”

There are two problems with this. First, 8-bit 4K frames aren’t the same size as 10-bit 2K frames. If we assume a 16×9 frame, 10 bit-per-channel 2K is 30 bits per pixel * 2,359,296 pixels, or 8.44 MB/frame, while 8-bit 4K would be 24 bits per pixel * 9,437,184 pixels, or 27 MB/frame, over three times the size. Oops.

Second, Kodak didn’t define 2K as the standard resolution for digital film scans. They defined it a standard resolution, alongside, you guessed it, 4K. It’s pretty widely acknowledged that a 35mm original camera negative captures more than 2K worth of resolution. Certainly 2K acquisition and workflow can provide a perfectly acceptable level of quality. It’s more resolution than ends up making it into a theatrical release print. But Kodak didn’t declare that 2K is the end of the road, and nothing beyond it is worthwhile. It’s true that most features are currently finished at 2K rather than 4K, but in large part this is simply because it’s good enough and technically much less of a challenge… not because nobody should ever want anything better.

The resolution discussion continues, with an argument that because the Genesis and F23 capture 2K (or something close enough to it), they capture enough resolution that resolution doesn’t matter, and therefore Red’s higher resolution is not a meaningful advantage.

There a couple problems with this argument as well. The first is that it assumes (at least in the case of the F23) that three 1920×1080 sensors capture full 1920×1080 resolution. This just isn’t so. All general-purpose cameras have optical low-pass filters to avoid aliasing, which results in a loss of resolution. So The F23 necessarily resolves something less than 1920×1080. Johnson is right, of course, that the Red One doesn’t actually resolve 4096×2304, of course. Bayer-pattern sensors like the Red’s do resolve a fair bit less than their raw photosite counts might imply. But several tests have now shown the Red One does resolve about 3.2K, or about 1800 horizontal lines, which is over 60% more than the absolute maximum the F23 could possibly resolve.

This argument also seems to take it for granted that nobody would ever need more than 2K resolution even for an original camera negative (or digital equivalent). While it’s true that, as noted above, 2K is higher resolution than a release print, 4K projection is likely to be quite common in the years to come.

And consider: most still photo photographers shoot everything at the maximum resolution allowed by their cameras, even when their photos are going to end up being displayed at less than a megapixel on a web page. Few would be happy if you suddenly told them they couldn’t do this anymore. It gives them the flexibility to reframe later, to repurpose photos for higher resolution media later, to do things like masking on a large image before scaling down to the appropriate size for the deliverable. The only reason moving images aren’t regularly shot this way is because it’s technically difficult to build cameras that can do it, not because it wouldn’t be beneficial.

The discussion moves on to bit depth, noting that high-end HD cameras generally have 14-bit analog to digital converters (ADCs) and record 10-bit data (with a log curve applied, though Johnson doesn’t mention this). Moving on to the Red:

The Red [...] (still just talking about the image before it’s recorded), is so busy trying to outperform the other cameras in just the one area of superfluous resolution that it hasn’t got to the full cinema quality of the other requisite aspects. They’re using up all their photosites on resolution (so they can say 3.2K or 4K is a bigger number than 1.9K) and are truncating color information. The Red sensor only has one pixel per channel instead of three, which means it is 3-times color subsampled. The Red sensor samples at 12-bit (compared to 14-bit on the other cameras) for conversion to digital (in a seemingly unpublished bit-depth).

This seems to show a bit of confusion. Photosites are analog components. They don’t sample at a specific bit depth; bit depth is a function of digital encoding. A photosite simply generates an analog electrical signal that varies in strength according to how many photons strike that site. This analog electrical signal then goes into an ADC, and comes out as digital data with a specific bit depth. In the case of the Red One, the ADC outputs 12-bit linear data, which is recorded as… 12-bit linear data. Applying a log curve to image data puts more of your pixel luminance values “in the right place” (it distributes them across the tonal range of the image in a more useful way), so Red’s 12-bit linear doesn’t really provide an advantage over the 10-bit log of cameras like the F23. But the Red One isn’t really at a disadvantage here either. And keep in mind that the Red One is recording raw bayer data. My understanding (and I admit I’m not an expert on de-bayering algorithms) is that when generating an RGB image from a 12-bit bayer pattern, one can actually end up with a bit more than 12 bits of color data.

So, does that initial 14-bit ADC conversion benefit cameras like the F23 and the Genesis in any substantial way? Given that 12 bit encoding allows the Red One to record everything from the sensor’s noise floor (the camera doesn’t artificially clip to black below a certain point like traditional video cameras) up through its sensor-clipped highlights without any noticeable banding in images (even when you push them around in post, within reason), it seems unlikely that a 14-bit ADC would make any noticeable difference.

We are preparing for the upgrade for the i/pin upgrade program, and this will unfortunately require sending the camera back to RED for installation.

The good news is.. we have taking this opportunity to also redesign the Audio board in parallel, resulting in audio performance that is vastly, vastly, superior. We have decided to swap all existing camera audio boards at no cost during the /i pin installation ( which is also no charge to you. )

This process will start during the last week of September, in order of serial number, and we are targeting a 48 hour turnaround, and for in-person drop-ins we anticipate a 3 hour turnaround. We will give you as much notice as possible when your number comes up.

I hope everyone is happy with these changes.. the audio performance in the production samples we have received are off the charts, and of course the /i pins are something alot of you guys have been waiting for for some time.

–Jarred Land

People seem more angry at Red than at Birger here. Can we have a bit of a reality check? As a third-party developer, it was Birger’s responsibility to keep channels open with Red. This is how it always works with this sort of vendor relationship. Erik has talked about Birger having “more than 200 customers”. Let’s be generous and assume this means ~300 mounts. That’s still well under 10% of the cameras Red has taken orders for. Red’s primary responsibility is the camera, not taking the initiative to check up on what third-party developers are doing.

Given what appears to be a complete lack of communication, I suppose we’re lucky this all came to light when it did, rather than, say, after Birger had already shipped a few dozen mounts and cameras were failing left and right. That would have created a really awkward situation. Like, the sort of situation that doesn’t get resolved without lawyers getting involved.

Of course, it also would have been nice if Red had some clearly written documentation for third-party vendors explaining (among other things) exactly what parts of the camera are considered interchangeable and what parts aren’t. But it’s frankly a little hard to fault Red too much in this instance for not having such a thing, because if communication had been better (which, as noted above, is the responsibility of the third-party vendor), this issue would have been dealt with anyway.

Finally, I feel it’s rather important to note that even if the Birger mount wasn’t stuck in warranty-related limbo, we still wouldn’t have what we were told we’d have months ago. Birger has, whether deliberately or merely by drastically underestimating the relevant engineering challenges, strung its customers along with promises that its product would ship in a matter of weeks (or even days) for seven months now. It took them six months to just confirm many people’s orders. We still have no estimate of when the focus knob system and/or Bluetooth remote (the electronic focus controls that actually make this more useful than a Nikon dumb mount) might be done. And if Birger did offer such an estimate now (again, even assuming no warranty issues) would you feel comfortable planning around it?

We really wanted Birger’s project to succeed. Back in December of last year, when the Birger mount was supposed to ship in a couple of weeks, I made a post on Indie4K which concluded that “EOS lenses with the Birger mount are shaping up to be the indie option of choice for Red”. And we hung in there for quite a while, despite the fact that it was costing us money (for lens rentals) and that we weren’t using our camera for our own projects as much as we would have been if we’d had our own glass. I don’t think we were the only ones experiencing such inconvenience and expense.

Finally, a couple of weeks ago, when Erik posted the pictures of FedEx boxes (implying mounts would really ship this time), and then shortly thereafter explained the new electrical problem would cause yet another delay, we gave up and ordered a Red 18-50mm lens, and four days later we could actually shoot with our camera without renting glass. We weren’t sure it was the right thing to do, because Birger was still saying they’d be shipping very soon… but then again they’d been saying that for half a year already. When these warranty issues surfaced, though, and when another week passed with no information about the focus knob, etc. we knew we’d made the right choice.

From our perspective, the only thing Birger has ever actually handled at the standard I would expect was promptly canceling our order when requested.

I still hope Birger’s product eventually succeeds — I still believe that the ability to use EF lenses (with electronic focus controls) is a very compelling idea for the do-it-yourself indie crowd.

But we couldn’t wait anymore. And if someone just getting their camera asked me whether they should wait, I’d probably advise them not to as well. Seriously. Don’t sit there staring at a $25K paperweight. If you can afford the Red 18-50 lens, buy one. It’s not high-end Zeiss glass, but it’s sharp, it’s lightweight, and it’ll put a nice image on your sensor. If you can’t afford that, get a Nikon dumb mount. Maybe you’ll be able to swap it out for Birger’s Nikon smart mount in a few months. But just get out there and start using your camera!

The notion that uncompressed is always better for a professional camera shows a complete lack of understanding of the trade-offs involved with this sort of decision. Sure, uncompressed is better if all other things are equal. But all other things aren’t equal.

What particularly annoys me is the notion that the Red One is somehow less professional than cameras which output uncompressed 1080p as their final product. Modern compression algorithms are extremely smart about what data they discard. The idea that you’re better off with an uncompressed image with a much smaller number of total pixels simply doesn’t hold up to even the most cursory analysis.

Even very low bit-rate consumer formats like HDV, when shooting HD, produce much better looking images than uncompressed SD, despite having far lower bit rates. (And HDV compression for 1080p footage is something like 85:1 or 90:1 compression. RedCode 28 is 12:1, and with a much more advanced algorithm.) You’re far better off capturing lots of detail and having a modern compression algorithm figure out what it can safely get rid of than you are capturing less detail in the first place, or capturing lots of detail but throwing lots of it away immediately using more primitive techniques like downscaling or subsampling chroma.

OK, so why doesn’t Red just record uncompressed 4K bayer, instead of compressed 4K bayer?

I’m quite confident in saying that given today’s technology, the Red One is a far more compelling product because of RedCode than it would be if it only shot uncompressed data. In fact, the camera wouldn’t be nearly as significant to the market if it didn’t shoot to a compressed format.

RedCode is what allows you to shoot to CF cards and Red Drives, rather than being tethered to a RAID the size of a mini-fridge. It’s what allows footage to be downloaded in a practical way on-set. It’s what allows you to play back footage from a single SATA or FireWire 800 hard drive, and store about 10 hours of footage per terabyte, instead of around 50 minutes.

Of course, you don’t get all of this for noting. The Red One probably could probably use less power and run cooler if it didn’t have to do 4K wavelet compression in real-time. And there is some loss of image quality vs. a totally uncompressed 4K image.

But the fact is, the Red One wouldn’t be a remotely practical camera for the vast majority of the projects it’s being used on, if Red had bought into the myth that professional recording must be uncompressed. RedCode is the major factor that makes the Red One usable by low-budget indies. Without RedCode, the data situation would simply be unmanageable for low-budget indies, both on-set and in post. Without Redcode this blog, which after all focuses on the technical issues surrounding low-budget indie filmmaking, probably wouldn’t talk about the Red One at all. As it is, that’s practically all we talk about….

See major new features and menu map. Camera owners can, of course, get it in the usual place.

The biggest enhancements are related to image quality. Red appears to have rather dramatically reduced compression artifacts and noise levels. 16:9 4K is also now far more practical to shoot and worth with, with the codec errors during recording supposedly fixed, and 16:9 4K QuickTime proxies now working.

Red has also introduced a new color space, REDSpace, that allows for better WYSIWYG exposure on-camera. Or, for those who work in a more technical way, you can now directly monitor raw, so you know exactly what the sensor is capturing.

Build 16 also introduces 1080p output in playback mode, though not for live monitoring, and many user interface conveniences and fix-ups, like user buttons that are now actually programmable, and the ability to adjust a range of parameters with the rotary encoder on the EVF.

Be warned, however, that Build 16 changes the format of R3D files. There are QuickTime plugins and RedAlert/RedLine builds for the new format, but not RedCine build that can work with Build 16 footage yet. So if your workflow relies on RedCine, you’ll probably want to hold off until that shows up (possibly as soon as next week).

Update: the Build 16 compatible version of Redcine has just been posted. Get it in the usual place.

Reaction to the Epic over on RedUser.net has not been entirely positive, particularly from the low-budget indie crowd. In one sense, any negative reaction is totally irrational. Sure, the Epic costs twice as much as the Red One. But both the Epic and the Red One offer far more that what competing cameras offer in the same price range, or even at four times the price level. And, of course, Red is offering that full-value trade-in for Red One camera bodies, which is generous practically to the point of absurdity.

In another sense, though, the less than totally positive reactions were completely predictable. To understand why, don’t think about camera specs and price points. Think about mythology.

Unlike with Scarlet, I think it’s actually a bit of a stretch to say the Red One and the Epic target different markets. The Red One was marketed as an alternative to 35mm film for everything up to and including major motion pictures by major Hollywood directors. That firmly overlaps with Epic’s intended market. I think an important part of the “Red revolution” in many people’s minds was that they’d be able to buy and use the same tools as the pros at the top of the industry. Epic makes that less true; once Epic hits the market, many of the guys for whom money is no object are probably not going to be using the same camera as the indie filmmakers who put their faith in Red.

Now, given just how capable the Red One is, being bothered by this is basically irrational from any sort of practical standpoint. This doesn’t really cause any material harm to indies who can’t afford Epic, who have, obviously, still benefited hugely from what Red is doing. But it disrupts what we could call the “mythology” of Red, and that can be upsetting to people. This is, I suspect, the single largest reason why reaction the Epic has been somewhat mixed.

This sort of thing is always an issue for companies that become the focus of a mythology; reading RedUser.net over the last few days reminds me of nothing so much as reading Mac forums in the days after a MacWorld Expo; in virtually every case, regardless of what Apple announces at a MacWorld, some of Apple’s most loyal followers react negatively, usually because they’re holding the company to a ludicrously high standard and/or failing to take business realities into account.

Red (and Apple) shouldn’t worry about this stuff. People react so strongly because they care about the company and the product. In other words, this kind of reaction is generally an indication that you’re doing something right. As long as you keep building products that get people excited — even if that excitement sometimes takes the form of ardent criticism — you’re ahead of game in every respect that matters.

Scarlet is clearly going to generate a better image than the HVX, which resolves, in testing, somewhat less than 600 vertical lines. If Scarlet’s measured resolution is around 75-80% of its sensor’s pixel dimensions (which is about what the Red One is; can’t think of why Scarlet should be different), it should resolve about twice that many vertical lines, meaning around four times as much detail overall.

Now add high-bitrate raw recording. Processing the Scarlet’s 3K raw recorded image down to 1080p is going to produce something hard to tell from a 4:4:4 image, vs. the HVX’s 4:2:2 recording. So, we’ve got super-sampled 4:4:4 1080p vs. subsampled 720p 4:2:2. (Yes, the HVX has a 1080p recording mode as well, but the chips resolve a bit less than 720p, so the only real benefit is fewer compression artifacts.) Plus, you get all the advantages of raw recording, that I’ve discussed extensively in the past.

Of course, Scarlet is single chip, and three chip cameras sometimes do better in low light. But keep in mind it has a 2/3″ sensor. That’s measured across the diagonal. If you double the diagonal, you quadruple the surface area, so Scarlet’s single sensor is larger than the HVX’s three sensors combined. And that nice large sensor gets you shallower depth of field as well.

The HVX will probably still have some advantages for workflow (though it’s not impossible that by the time Scarlet ships, working with 3K REDCODE RAW in FCP will be as easy as working with DVCPRO HD currently is). And it does have a more conventional form factor, which might make some folks more comfortable. But specifically for no-budget indie filmmakers, the Scarlet is clearly the better camera, hands down, no contest. And even if Panasonic does introduce an HVX replacement by then, it’ll probably still cost twice as much as the Scarlet.

I’m still trying to puzzle out the relationship between the Epic and the Red One (which Red will continue to sell after the Epic starts shipping). The Scarlet, though, Red’s new 3K (and $3K) “professional pocket camera”… I’m pretty sure I’ve got that all figured out.

Why no interchangeable lenses?

One issue that has been raised over on RedUser is why the Scarlet doesn’t have interchangeable lenses, perhaps using low-cost SLR lenses. This notion doesn’t make a great deal of sense.

I think there’s definitely a market for a reasonably priced indie filmmaker’s camera with a photo lens mount. But it requires a Super 35 sized sensor to be practical (the widest 35mm SLR lenses available aren’t nearly wide enough for a 2/3″ sensor sans adaptor) which is substantially larger than a 2/3″ sensor. If my math is right, the Red One’s sensor has about three times the surface area of the Scarlet’s sensor, and anyone who knows anything about chip fabrication knows that costs climb very steeply as chip size goes up.

In other words, that indie filmmaker’s camera with a photo lens mount? It’s a Red One with a Nikon or Canon EF mount, which you can buy today (or soon, with EF). Would it be nice if there were a substantially cheaper and smaller camera body that did everything the Red One did? Sure. And there probably will be… if you’re willing to wait a few years.

Seriously though, this thing is nuts

Scarlet has a 2/3″ sensor. That’s already pretty nuts for $3K. I’m not aware of anything with HD resolution and 2/3″ sensors for under $10K, though I admit I haven’t been paying as much attention to the HD camera market since we jumped on board with Red.

Scarlet also has a 3K bayer sensor and records fairly lightly compressed raw data. This means it’ll probably produce a better 1080p image than any sub-$10K camera. (At least with good light… three chip cameras might do better in low-light conditions.) Maybe any sub-$20K camera (with the obvious exception of the Red One). That’s freaking insane! Oh, and it records across a wider variety of frame rates than a $50K Varicam. For $3000! This thing is nuts!

Who wants one?

The relatively slow lens may make this camera impractical for e.g. event videographers and documentary folks, unless the new sensor has higher sensitivity, of course. Record times might also be an issue, though larger CF media may solve this problem before the camera is shipping.

As a camera that can go places a full Red One rig can’t easily go, Scarlet will certainly be a great second camera for Red One owners. Perhaps even more importantly in the long run, though, every film student and low-budget filmmaker in the country who can scrape together $3K (but not $35K for a shootable Red One package) is going to buy one. And incidentally, become familiar with Red workflow…. In other words, Scarlet is a sort of “gateway drug” for higher-end Red products. This is absolutely brilliant, and I predict it will have some significant negative consequences for Red’s competitors over the years to come.

This first post is going to discuss some physical aspects of working with the camera.

A full Red rig is a bit heavier than the 10 pound body weight might lead you to expect. Red’s accessories are cast steel, and pretty heavily build. They’re solid, but not exactly light. That said, we have managed to build rigs down to 17 pounds with Red Drives (not including lens, matte box, or follow focus, which introduce too many variables). Using CF can knock that down to 14 or 15.

We’ve found the most practical way to get a lightweight rig for handheld use is to eschew all the mounting hardware on the bottom of the camera, and the bottom rails — toss two top mounts, 12″ rails, the top handle (and top handle extension) on the top of the camera, along with a universal mount out in front of the forward top mount to attach the LCD screen to. Another universal mount hangs the Red Cradle off the back of the camera, with enough space to still reach in any use the controls (you don’t really need to see the screen on the back of the camera if you have the LCD screen attached). You can simply sit the camera on your shoulder and reach your arm around to hold it there by the top handle — works pretty well.

On the other end of the spectrum, with bottom rails, lens, matte box, follow focus, etc. a full rig can easily weigh over 30 pounds. Substantially more with a large zoom lens.

As far as Red’s mounting hardware goes, we’re generally happy overall, though the bottom plate shoulder dovetail could use some work. As has been widely reported, the bottom plate + shoulder dovetail wobbles a bit on a tripod. And it’s so heavy, and provides so little padding, that unless you absolutely need bottom rails when going handheld, it’s much easier to just leave it off for handheld configurations as well. As such, we’ll probably replace these parts with Element Technica hardware. (It’s not surprising that the ET stuff is a bit better… it costs a fair bit more.) We’ll probably pick up ET’s aluminum rods as well, to cut weight down more. We’re on the East Coast, where it’s not that hard to find 19mm gear, so we’re planning to stick with 19mm to maintain compatibility with the Red Cradle and QuickPlate.

Up next: using camera features

1K Clip, 4K frame. Exposed at ASA 320, T1.3. I didn’t quite get the focus (it’s hard at T1.3), and the framing isn’t great (trying to maneuver a Red while sitting in the passenger seat of a Honda Civic is not recommended). But that shot is lit with nothing more than the car’s interior roof light, and it’s fine. There’s actually even a little more in the blacks; I crushed them a bit because it looks better. (Of course, they got slightly brighter in the linked QuickTime file; whacky QuickTime gamma issues strike again.)

We’ve got more from yesterday’s testing. I’d post it now, but transcoding it would tie up my MacBook Pro all night. I’ll probably have a bunch of it up tomorrow, though; we’re expecting a package from Apple which should solve that problem once and for all.

1080p version (have a high-end machine) or 1K version.

That’s Pierce, by the way.

More footage soon.

First, what wasn’t in the box. We didn’t get our EVF (didn’t really expect to). More surprisingly, we didn’t get our AC adaptor or our right handle; those seem like odd candidates for being out of stock. I can see the lack of an AC adaptor getting us into trouble in some situations (remember, while the charger can power the camera, it can’t power the camera and charge batteries at the same time), so hopefully that won’t take too long.

To address some of the quality issues that people have raised over on RedUser: overall we’re very pleased. The camera body is, as has been widely reported, built like a tank. We didn’t actually toss the camera on a tripod, but the shoulder dovetail seems totally solid, and we don’t seem to have the issue people reported earlier with drives not sitting securely in the cradle; ours lock in nicely. We do have one issue, though. The left handle won’t attach. We just don’t seem to be able to get it to tighten enough to grip the rod. Maybe we’re doing something wrong, though.

A couple of parts do have some flaws in the anodizing of the sort that have been reported, but it’s minor stuff (on the parts we got, anyway) and really doesn’t bother us. In general I think this anodized surface is going to scratch really easily (indeed, some of our parts had minor scratches out of the box), but again… not a big deal.

In terms of form factor and weight, Red’s parts seem to provide a fair bit of diversity. First, a few disclaimers about weight: these weights don’t include a lens or matte box, and might be off by a pound or two because our methodology consisted of me stepping on an electronic bathroom scale with and without the camera, and doing some subtraction. (We’ll probably buy a package scale and post more accurate numbers once we get the rest of our package together.)

We managed to build rigs ranging from 26 pounds (base production pack + top mounts with 12″ rods + top handle and extension + LCD + battery + drive) down to about 16 pounds (everything listed above, but no drive, nothing on the bottom of the camera, and the QuickPlate, mounted off the back top mount, substituted for the cradle).

We could probably knock a couple of more pounds off that last configuration by getting rid of everything except one top mount and the top handle on the top of the camera. This plus some sort of light shoulder pad that screwed directly into the threaded holes on the bottom of the camera body could be a really interesting ultra light-weight configuration. Anyone know of a shoulder pad like that? Only problem with this arrangement is figuring out how to get the EVF or LCD positioned in a useful place… we’ve got some ideas on that score, but nothing firm yet.

We were a little confused by the fact that the top handle + extension combo doesn’t reach quite far enough that it can be directly bolted to the two top mounts. It seems slightly crazy to have to have to use a universal mount to secure one end of it just because it isn’t a half an inch longer. Assuming this is accurate and we weren’t doing something wrong (can’t see how we could have been), Red (or someone) should sell a little piece that screws in between the handle and extension and fixes this issue.

Overall everything has a very solid feel to it, and while it looks like there might be some third-parties that will manage to out-do Red for rod and support systems for the Red One, Red’s stuff seems like a sold enough offering and a pretty good value.

Update: Pywl over at RedUser points out that the top handle probably doesn’t reach because we have the top mounts on backwards, and that the wingnut head should pull out which should let us tighten the handle more. I don’t have the camera here right now to check, but it sounds like those are two issues to cross off the list.

We’ll be paying a total of $27,662 after our $2500 accessory credit. Notably, the above order doesn’t include lenses or CF cards. We’re planning to buy a Birger mount and use Canon lenses (we’ll rent or borrow PL-mount lenses until the Birger mount shows up), and we don’t see much point in buying 8 GB CF cards when 16 GB cards will probably be shipping in a month or two.

We’ve made a fairly large decision about our Red package. We’ve decided (or at any rate are presently leaning heavily toward) forgoing Red’s lenses (and other much higher-priced cine glass) in favor of getting Birger’s Canon EOS lens mount.

I’ve discussed some of the tradeoffs with cine vs. photo lenses before. So, why have we decided to go in this direction? Well, largely it’s just a cost/benefit analysis. We can’t afford a $100K Cooke S4 set. Nor do we want to rent all the time; one of the major attractions of Red, for us, is that we can own a complete package. We can afford Red’s glass, so that’s what we’re putting up against the SLR option.

With SLR lenses, for the price of just a Red 18-50mm zoom, we can get the Birger mount, plus several primes and zooms. For the price of the 18-50mm zoom + the price of the 50-150 zoom, we can buy practically every current-model EOS lens we can ever imagine wanting to shoot with. The SLR route just provides much more flexibility. For instance, buying the two Red lenses, we’d be stuck at f/2.8. Going the Canon route, we can walk into B&H and buy one of these, and get a lot more light onto the sensor for night exteriors.

The Birger guys have managed to come up with some pretty neat stuff. Their mount will be able to feed lens metadata into the camera, once Red enables this feature, for instance, just like Red’s lenses (or other lenses with /i technology) can. This will solve the problem of figuring out what your aperture is set to on EOS lenses (which have no physical aperture controls or indicators). The camera will simply tell you.

Perhaps more interesting, the Birger mount can control focus as well as aperture, using the built-in focusing motors of EOS lenses. And this is were we get what I think might be a little glimpse of the future. If you read my previous post (linked above) about the benefits of real cine glass, you’ll see that a lot of them are related to the mechanics of focus pulling. If electronic focus pulling turns out to work smoothly, a lot of that goes right out the window. Lenses won’t need perfectly calibrated physical focus markings, because a bit of testing will produce an electronic table mapping specific physical distances to specific electronic settings. Lenses won’t need extended focus scales either, of course, because they can be moved with electronic precision regardless of how close together their focus marks are physically. This opens the door up to achieving great results with very low-cost mass-produced glass[1].

Electronic focus control has boarder implications than just eliminating the need for some costly precision mechanical engineering, though. It also opens the door to all sorts of new capabilities. Birger’s system will be controllable via Bluetooth. Imagine figuring out your focus marks using Red’s “magic focus assist”, and then programing them into a laptop and cueing them at the appropriate times with a couple of key presses. Or imagine a “smart” autofocus system based around range-finding equipment, which could rack focus to track an object through space far better than any human focus puller. Birger has dropped hints they’re already working on something like the latter, due in the second half of 2008.

Given all of this, it seems like EOS lenses with the Birger mount are shaping up to be the indie option of choice for Red.

Footnotes:

[1] We see this in a lot of places. Advances in electronics or information technology can sometimes eliminate the need for costly high-precision engineering. Consider the analog video systems of a couple of decades ago. Noise or distortion could creep in anywhere; power supplies had to provide clean power, every cable had to be perfect and well-shielded, and every electronic part had to be made with the highest possible precision. In today’s digital systems, none of that is true anymore; once a signal is digital, the electrical (or sometimes optical) paths that carry it only need to be good enough that the receiving system can tell a one from a zero. As long as that’s true (and for systems with digital error correction, sometimes even when it’s not), a bit of electrical noise somewhere doesn’t have any impact on the image.

Or, to use another glass-related example, consider that it used to be important to have matched color across a set of lenses; otherwise odds were you’d never get shots to match perfectly in post. Modern digital color correction has essentially eliminated the need for perfectly matched lens color.

If you haven’t yet, read part one of the workflow primer, which discusses RAW acquisition and wavelet compression, both essential to the desktop workflow equation.

As things stand now, there are three ways to do something useful with Red footage, once you get it onto a computer. The first is to feed it into Assimilate’s SCRATCH, which has native support for REDCODE. I’ll discuss that workflow if I ever get a chance to play with a SCRATCH system for long enough to have anything useful to say about it. Until then, though, I’m going to focus on the other two methods of getting Red footage into apps in a usable format, and on where things are headed in the future.

1. Red Alert!

Red Alert! is Red’s interim RAW processing app. It’s sort of like Adobe Camera RAW, but for RED footage. One sets white balance, exposure, what curve to apply to the image (linear, Rec. 709) and all the other stuff one doesn’t have to set in-camera, because the camera is shooting RAW footage. Red even lets you tune the debayering algorithm, to get a smoother image or to try to extract more detail.

Red Alert! can review footage with the chosen settings and (this is the important bit) render it in a couple of ways, at 2K or 4K. If you’re feeding your footage into a traditional DI pipeline, you can render out DPX or TIFF files. A TIFF or DPX file stream, though, will run around at least a couple of hundred megabytes a second, though, and that’s at 2K, which makes this workflow a little heavy for anyone without a fairly serious post budget. So, this post (and this blog, for that matter) is going to focus a bit more on the other workflow.

2. The REDCODE QuickTime codec

RED has another way to get footage into apps in a usable format, one that’s relatively undeveloped now, but will probably be the anchor of low-budget in the future. Red has developed a QuickTime component which understands REDCODE. The camera, of course, doesn’t record directly into QuickTime files, but the Red QuickTime component works around that in a neat way: QuickTime reference movies. What are QuickTime reference movies? They’re tiny MOV files that simply contain some metadata, and a pointer to a Red footage file (a .r3d file). These reference files are generated automatically by the camera with recent firmware builds. One can also generate them in Red Alert!, in which case they’ll reflect the RAW processing settings one has chosen in Red Alert! The camera and Red Alert! generate reference movies for multiple resolutions, so you can feed 2K, 1K or 0.5K into QuickTime apps.

This approach allows one to work with REDCODE data without having to recompress it or convert it to formats that take up much more space. And, of course, since you’re working directly on the original RAW data, you have access to everything the camera captured (more on that later).

It does presently have some limitations, however. REDCODE is an acquisition codec, and optimized with that in mind. It’s intended to provide maximum quality at a given bit rate. Unlike, say, Apple’s ProRes, it’s not designed to be light on your editing system. One needs a fairly fast system to back the 1K reference movies in real-time, and I haven’t heard reports of the 2K versions playing back reliably in real-time even on very high-end machines (contact me if you’ve heard differently).

Another limitation is that the QuickTime proxies currently can’t spit out 4K at all, and they use a lower quality debayering algorithm than the best Red Alert! has to offer.

Finally, one can’t really edit directly with REDCODE footage at the moment using the QuickTime reference movies. REDCODE RAW is read-only (it makes sense that you can’t render out in a RAW format), so you can’t set REDCODE as the codec of a Final Cut Pro timeline. This means you have to drop REDCODE footage into an FCP timeline set to use another codec… which means you have to render everything before playing it back.

The good news is, it’s probable that all of these issues will disappear as the workflow matures. More code optimization (and, of course, the ever-increasing speed of computers) will no doubt make real-time 2K (and even 4K) playback of REDCODE footage a reality on the desktop. Red will almost certainly offer more options for how to decode data though QuickTime reference movies, allowing this pipeline to be used for everything form low-quality previews, for full-quality 4K footage to be feed into compositing programs, etc. And, of course, native REDCODE support has been promised in a future version of Final Cut. Presumably this last will require a version of the REDCODE codec that has been modified to support encoding (I would guess to an RGB variant of REDCODE which can be mixed with REDCODE RAW footage in a timeline).

As this workflow matures, it should be possible to do an offline edit with real-time performance (but from reference movies — so there’s no need to waste lots of space and render time on separate proxy files), and then go back and do a full-quality conform, by swapping out one set of QuickTime reference movies for another.

Until that day comes, the QuickTime proxy movies still provide a fast way to convert Red footage into other formats, like ProRes, so one can offline (or even online, for many deliverables) in those formats. This function of QuickTime proxy movies should become obsolete when REDCINE ships, however, as it will be able to directly export to different QuickTime formats, and should offer more options when doing so (like full quality debayer).

Just to clear up one common misconception — Final Cut Pro will not be limited to 8-bit when working with REDCODE footage. Yes, Final Cut only does 8-bit for RGB. However, it offers a full 32-bit 4:4:4 YUV pipeline. A codec can work around the 8-bit limitation for RGB by simply appearing to FCP as a YUV codec — and Gramme Nattress has mentioned in several places that Red’s QuickTime component does precisely this.

I should have a post later in the week about what a practical low-budget indie workflow for RED footage would look like as things stand right now.

By the way, the second part of the Red workflow primer should be up this weekend.

I’ve been over a lot of this previously in the blog, but the info is pretty spread out here (and even more difficult to piece together from reading posts on RedUser), and there’s much more information out there now about how everything works. Red is different from most other cameras people are familiar with, and I’m going to do a lot of comparing and contrasting along the way.

Ready? Here we go.

1. Capturing

Red has a single large bayer-pattern sensor.

OK, so what’s a bayer-pattern sensor? Most digital imaging systems use one of two methods of capturing images.

More is more?

The approach most common in professional and prosumer camcorders is to split red, green and blue through a prism, and record them onto three separate chips. This approach is beneficial, because it allows a camera to sample all three colors at every point in the image. However, there are also some serious drawbacks to this approach.

First, off, as a general rule, the less glass is in your optical path, the better; having a prism in your optical path can introduce certain types of artifacts. Second, it’s nearly impossible to make three chip systems with chips over a certain size; it’s just too hard to make prisms for them. Having a large sensor, of course, is essential if you want to get shallow depth of field, an essential creative tool. Finally, most of the best lenses in the world (for shooting narrative features, anyway) are designed to work with 35mm motion picture film cameras. A lens designed to project light onto a single film plane doesn’t work with a three-chip system. (Well, there are messy workarounds, but they’re beyond the scope of this post.)

Less is more.

Presumably for the reasons mentioned above, Red decided not to go with a three chip design. OK, but if you only have one chip, how do you record three colors? There are some exotic approaches like the Foveon X3, but by far the most common approach (used, for starters, by nearly every digital still photo camera on the market) is to use a technique patented by Dr. Bryce E. Bayer in in 1976: the bayer-pattern sensor.

A bayer-pattern sensor is a light-sensitive chip (obviously) with a red, green or blue color filter over each of its photosites (see the illustration at the link above; it’s much easier than trying to understand a written description). For any given photosite (a photosite is an individual light-sensitive element), the camera captures color data for one channel. (It’s slightly more complex than this, because the filters don’t actually eliminate all other wavelengths, but that explanation will do for our purposes.)

What you’re left with is a single channel of image data that, if you looked at it directly, would look like a grayscale image with a checkerboard pattern all over it at the pixel level. This is a RAW image.

2. Recording

Red has a fairly unique approach to recording, which has many implications for workflow.

Your data, RAW and uncut

One of the things that makes Red nearly unique among motion picture cameras is that it takes the RAW bayer data from the sensor (see above), compresses it (see below), and stores it still in its RAW form, a feature it shares with many higher-end digital photo cameras.

Sliming down

Shooting 4K, Red is capturing a RAW image with a resolution of 4096×2304 (actually, cameras can currently only capture 4096×2048, but Red is going to enable the full resolution in a downloadable firmware update). Red’s analog-to-digital conversion happens at 12 bits. If we multiply out 12 bits * 4096 * 2304, we find that every frame Red captures should take up 113,246,208 bits, or in slightly more convenient units, 13.5 MB. That means shooting at 24 frames a second, Red can generate 324 MB of data, every second.

What do you do with it all? Just to record it you’d need at least six hard drives in a RAID 0 array (probably more like 8-10). And even if those were 1 TB drives, the largest currently on the market, you’d still fill the entire 6 TB array with less than an hour of footage! While there are some situations where this kind of setup might be practical (and Red can work with it, sending uncompressed data out through an optional optical port), it’s not very practical for most shooting.

Red’s solution to this problem is REDCODE RAW, a compression algorithm designed specifically for the Red camera. The camera takes that 324 MB of data and applies about 12:1 compression, squeezing it down to around 27.5 MB/s — less data than uncompressed standard definition video.

RedCode RAW is a wavelet compression algorithm. In terms of image quality, this means it can deliver much better quality than what can generally be expected from the other major class of image compression algorithms, DCT algorithms. If you’ve ever seen a JPEG, watched MiniDV footage, or watched a DVD, you’ve seen an image compressed with a DCT algorithm. Wavelet algorithms have much less objectionable artifacts (no visible blocking, for instance). This comes at the cost of higher computational cost, but processors are fast enough now that this is no longer a problem.

Wavelet algorithms also have another property that makes them particularly interesting for Red’s application, which will be discussed in the post workflow section.

It’s a data world

Red records footage as files on compact flash cards. Later, it will be able to record directly to a disk-based digital magazine called the RED DRIVE, or to various other sorts of sold state memory.

The important point here with respect to workflow is that capturing footage through a deck (or using the camera as a deck) is, with Red, an obsolete notion. Footage isn’t captured in the typical sense; one simply attaches the recording media to a computer with a standard interface (the CF cards can be read in a normal CF reader, the RED DRIVE will connect over USB or FireWire), and copies footage files over like normal data files. This clearly has a huge number of benefits, which are so obvious there’s not much point in elaborating on them here.

3. Post Workflow

RAW diet

Anyone with experience shooting RAW on a digital SLR camera is aware of the benefits that feeding RAW data into your image processing pipeline can have. Sharpening, white balance, and a host of other parameters can be tweaked in the comfort of your office, looking at a nice big reference monitor, instead of being “burned in” when you shoot. Red shares all of these advantages, and even provides a bit more flexibility. For instance, since Red uses exclusively digital gain, you can actually choose your ASA after the fact (sort of; I’ll do a future post on this subject). Red’s software also allows the user to tweak the parameters of the algorithm (called a demosaic or debayering algorithm) which converts that bayer checkerboard pattern (see above) into a normal RGB image. Do you want a smoother image, or do you want the algorithm to extract more detail? You decide.

And, of course, none of the changes you make change the actual data in the original REDCODE files (which have the entertaining file extension ‘r3d’). They’re just stored as metadata (data about data), and can be discarded or modified at any time.

It’s also possible to decode the RAW data differently depending on whether one wants a higher quality image, or an image that can be decoded with less processor power (e.g. for real-time playback).

Catch the wavelet

Remember I said wavelets have another interesting property relevant to post workflow? Wavelets make it very easy to extract fractional resolutions. For instance, if you have a 4K wavelet-compressed image, and you want to extract a 1K image from it, this can be done with relatively little processing power — vastly less than decoding the entire 4K image and scaling it down.

Playing back 4K in real-time is something that isn’t possible on widely available computing hardware at the moment, and there’s not much point in it anyway, since almost nobody has hardware that can actually display a 4K image. This makes the fractional resolution decoding enabled by wavelet compression extremely useful, particularly combined with the ability to decode RAW at varying qualities (see above). Between these two factors, data suitable for almost any purpose — from an on-set rough edit, to outputting digital dailies, to a 4K final conform, can be extracted directly from the original REDCODE RAW data files.

And that’s a good place to stop for today, because the next subject, namely how that REDCODE data gets fed into an actual post pipeline and what one can do with it there, is sufficiently complex to merit is own fairly long post.

If the technical branch of the AMPAS, sometime in the next five years, doesn’t present RED with something heavier than a piece of paper, then they’re fools, and inattentive to boot.

Shooting with RED is like hearing The Beatles for the first time. RED sees the way I see. Someday I hope to find out exactly how Jim and his team made something so technologically advanced seem so organic, so beautifully attuned to that most natural of phenomena, light. But for now I’m just glad I’ve got my hands on the damn thing, because it’s actually making the film(s) better because of it emotionality. At the same time, I am still figuring it out, still trying to discover its secrets, still interacting with it. For me, this is Year Zero; I feel I should call up Film on the phone and say, “I’ve met someone.â€? Is it perfect? Not yet. But the flaws are fixable (the heat issue, which is being worked on; buttons that should be recessed; power cable from the rear of the camera), and anybody who doesn’t embrace the flashcard–regardless of time restraints–is an idiot.

But the best news of all is: If my lame hyperbole could adequately describe the image, it wouldn’t be RED.

– Steven Soderbergh

Red workflow is — as one might expect for a camera that has only been on the market for three weeks — still fairly immature. That said, at least five distinct workflow possibilities have emerged. These are:

• Traditional DI finish
• Native SCRATCH workflow
• Desktop offline/online workflow
• Desktop online native workflow
• Desktop online non-native workflow

Traditional DI Finish

This one is fairly straightforward. After being downloaded, Red footage is simply processed into 2K or 4K DPX or TIFF sequences, and fed into precisely the same sort of DI pipeline used for DPX or TIFF sequences scanned from film. This will probably be the most common workflow, at least initially, for higher-end feature productions, because it’s extremely comfortable for them.

The one missing piece in this workflow right now seems to be that RedAlert (the stopgap application Red has given to camera owners to process RAW footage while the fully-fledged RedCine app is being finished) doesn’t currently transfer most of the metadata from REDCODE RAW files into DPX sequences. I’d expect this to be fixed soon. (If it hasn’t been already.)

This is Indie4K, though… the extremely high costs associated with this approach (a 100 minute feature with a 10:1 shooting ratio can be expected to take up dozens of terabytes) will probably make it mostly off-limits to low-budget indies.

Native SCRATCH

Assimilate has been on board with Red from the beginning — we saw them handing out cards and Red’s NYC NAB screening event last year. It’s not hard to see why. The two companies have fairly similar approaches to the market. They’re both new players in established markets, who have nothing to lose by offering products and prices that actually reflect the state of technology, rather than old market segmentation schemes.

Anyway, Assimilate now has native REDCODE RAW support in a beta version of its SCRATCH software. Though probably still out of the price range of many indies, this option is a lot cheaper than a traditional DI workflow, and brings all the benefits, well known to fans of dSLR photography, of working with original RAW footage.

Desktop Workflow

Since there are three possibilities here — and since they’re going to get discussed in more depth, being more relevant to the primary audience of this blog — desktop workflow options will get their own post, which should be up within the next few days.

Update: Here’s a mirror with a bunch of the footage.

A few more news items:

• The camera body is up to 10 pounds due to a new sensor cooling system and more robust construction.
• The Premium Production Pack has been canceled. You now buy the Basic Production Pack and add the individual aditional components that you want.
• It sounds like Red is planning a bunch of firmware upgrades over time.
• Should Red be rated at ISO 320 or 500? It’s your call.

(See here and here.)

Since REDCINE is being rebuilt and won’t release for a week or two, RED Alert! will be the mini-app of choice. At some point we will post it with sample footage. Be advised that it is a Mac app only (REDCINE will be both Mac and PC). You will need RED Alert! and the REDCODE node (you will put the REDCODE node in HD/Library/Quicktime folder). This mini-application will open .r3d files (REDCODE RAW), allow you to view the file, select DI mode or Standard mode, and output to Quicktime wrapped files in 2k, 1k, and .5k for ingest into FCP or viewing in QT. You can also output to DPX 2k, DPX 4k, 4k TIFF, 2k TIFF, in Linear, REC 709, or Log. You can make some corrections prior to output. We will help you choose settings depending on what you are trying to accomplish.

Also see screenshot.

That’s great news, and it hopefully means this blog should have more to report on than it has in recent weeks. We’re also moving into our new office space on Monday (finally; this has gotten pushed back a bunch of times), so Indie4K should be swinging into high gear over the next week, with regular podcasts (at last) and more info about what we’re working on.

This is the camera I’ve been waiting for my whole career: jaw-dropping imagery recorded onboard a camera light enough to hold with one hand. I don’t know how Jim and the RED team did it — and they won’t tell me — but I know this: RED is going to change everything.

Soderbergh will be shooting his next two movies with Red prototype gear, including Red’s 18-50mm zoom lens. Filming starts in Spain July 24th.

• Jim will keep talking to suppliers over the next week to nail down the schedule.
• A new schedule, broken down by serial number, should be posted next Friday.
• Some beta cameras will soon be placed in production environments (major motion pictures) for intensive field testing.
• “We plan to move as quickly as possible to production cameras. We are not looking at next year. We are not looking at the end of this year to begin production.”

So, it doesn’t look like the delays will be all that bad, and I assume other aspects of the camera are progressing even though shipment is on hold for the moment due to supplier issues. Plus, as I’ve mentioned before, just because the first cameras will come later, doesn’t necessarily imply later cameras will be pushed back; Red could simply ramp up production faster.

Anyway, this isn’t great news, but it’s not terrible. And a minor delay doesn’t interfere with our plans so much, though I realize others might find it more inconvenient.

BTW, we should have a new podcast up next week, with a new format and all three members of the Indie4K team.

First off, as people who read this blog probably know, Red has run into some last minute delays. Jim Jannard posted a bit on that tonight:

I wish I had good news. The reality is that we are close to knowing where we are, but not quite. I still expect to announce the new schedule on June 15th, but I have to say that the last 5% of the project is the most difficult. We have had obsticles that we did not expect. Keep your fingers crossed.

Other new bits of info:

• The 18-50mm zoom will be marked with T-stops (starting at T3), settling a long and tedious debate.
• Red will ship a 50-150mm lens (also T3) later this year.
• It looks like there’s some new grip hardware. Or maybe that’s just stuff we’ve seen, configured differently.
• Jim has posted the text of a Peter Jackson interview about Red from the New Zealand magazine ONFILM.

Choice quote from Jackson:

If you shoot at 4K, but want a “film lookâ€?, then you finish at 2K and add some grain. It’s easy. It looks like film. However, if you finish and screen at 4K. the result is like shooting in 65mm, like the old epics used to do. It’s pretty exciting, and will have a major impact on indie filming — but we could see no reason why you couldn’t use these cameras for any type of movie. I’m seriously considering using RED for The Lovely Bones.

First off, it’s useful to be a bit more precise about exactly what level of support exists for REDCODE in Final Cut Pro.

All versions of Final Cut Pro will see REDCODE footage through QuickTime reference files (see QuickTime link above). You should be able to cut footage at 1K and 2K (more on 4K later) even in FCP 5.x. So, what’s the big deal with FCP 6? An updated version of FCP 6 (note: not 6.0, but an update that will come later) will add two important things to the mix.

The first of those is RT support. As folks familiar with FCP know, in order to get real-time features, a timeline has to be using a “blessed” codec — one which Apple explicitly supports for RT. In this FCP 6 update, REDCODE will be such a codec. Until that update ships, you’ll be able to play back and make straight-cut edits in FCP on a timeline that uses REDCODE, but anything more than than (transitions, filters, etc.) will require rendering.

The second big thing that will come in that FCP update is an FxPlug plug-in that brings many of the features of REDCINE right into Final Cut Pro. (For those unfamiliar with FxPlug, it’s Apple’s newish plug-in architecture for Final Cut Pro and Motion, which opens up many more possibilities than the previous plug-in mechanisms for FCP and allows for vastly higher performance.) This plug-in will allow for fine control over the “development” of RAW footage, and can actually share look files with both REDCINE and the camera (more on that in another post).

It’s unclear exactly what the implications of not having Red’s FxPlug will be. This is an important question for people looking to cut Red footage in FCP prior to the release of the update that adds explicit support. FCP will certainly still be useful for an offline edit (it was used like this on the Peter Jackson short, Crossing the Line), but will it be possible to get decent results for your final conform? Since the REDCODE codec will apparently be giving data in a full float color space to FCP, the data you’ll need to get your image to look the way you want it to should be in the image data presented to FCP, but will you be able to massage it to look the way it should without a tool designed for this task?

Another thing that’s presently unclear is whether Apple’s new Color app (previously Silicon Color’s Final Touch) will be able to work with footage directly from a REDCODE timeline. My guess is that it will, but that you’ll have to render a clip that has had its look tweaked with Red’s FxPlug (or probably any clip that has had any FCP filters applied to it), since Color doesn’t, as far as I’m aware, have support for FCP plug-ins.

What about 4K? Well, that’s a mixed bag. Some apps in Apple’s toolset support it with no problem, like Shake. FCP doesn’t officially support it, but can be coaxed into doing it. Color only supports 2K. Motion, I believe, technically supports 4K, but you have to have the right video card. As of right now, plan on finishing at 2K with this workflow. This is not, mind you, a major problem, as there’s almost no venue where 4K is actually beneficial at present (more on that in a future post).

Ultimately, based on the information I’m familiar with and a bit of speculation, here’s how I expect a typical Mac-based workflow for a Red feature to go, once the FCP 6 update with additional REDCODE support hits the streets:

1. Shoot 4K REDCODE RAW.
2. Download to a RAID attached to your editing system. (See many previous posts on storage.)
3. Bring preview-quality footage at 1K or 2K into FCP via appropriate reference movies. (See previous post on QuickTime REDCODE support.)
4. “Develop” as desired using Red’s FxPlug.
5. Render VFX or CG shots out of Shake, Maya, etc. as REDCODE RGB at 2K and bring them into FCP timeline.
6. Edit, with full RT support, etc.
7. Re-link FCP project so it points to reference movies that specify full quality 2K footage. Change timeline resolution if it was previously 1K.
8. Open clips from the timeline in Color, grade them, and render back to the FCP timeline.
9. Output to desired format via Compressor or QuickTime conversion (much more on creating appropriate deliverables in future posts).

If this is accurate, it’s a fairly straightforward workflow, that should allow for 2K deliverables to be produced with a reasonably priced workstation and a fairly moderate amount of storage. That’s pretty impressive, given the speed of Red’s development program and the fact that they were also working on some other stuff (like, you know, the camera) at the same time. It’s interesting to see an upstart like Red coming out of the gate with a better post workflow than most major vendors do. (I didn’t see Sony shipping an HDV QuickTime component the day its first HDV cameras shipped.)

Anyway, this is basically the workflow we plan to use, so expect lots more details about it in the future.

What do we know? Well, we’ve known for a long time that the camera would ship with REDCINE, a program for doing “one light” color correction and exporting footage to other formats. But working with 4K (or even 2K) uncompressed requires far too much storage for low-budget indies to reasonably manage, and there was never a really obvious choice for a high-quality compressed format. (Well, except, possibly, for CineForm, which I admit I don’t give the attention it deserves, since I’m Mac-based and CineForm was until recently Windows-only.)

The ideal case for low-budget indies is a fully-compressed workflow starting with native REDCODE support in commonly used applications. And the way to get that is through supporting REDCODE in QuickTime, which Red has been discussing for a long time. Until NAB, though, we didn’t really know how that would work. Now we know a lot more. And the news is good.

Actually editing online at 4K is presently unreasonable on commodity hardware, and there wouldn’t be much point, as you couldn’t monitor 4K anyway. At the same time, rendering out proxy files to edit, and then doing a conform process once editing is done, is a big hassle. Fortunately, there is a solution here. As I’ve discussed before, REDCODE is a wavelet codec, and one of the interesting properties of wavelet codecs is that they make it possible to extract fractional resolutions very efficiently. That is, if you have a 4K file, you can easily extract 2K, 1K or even .5K footage directly from it, without having to decode the full 4K data and then scale it down.

The question on a lot of people’s minds has been how you’d take advantage of this neat ability for QuickTime apps with no REDCODE-specific support.

We now know Red’s answer: reference movies.

What’s a reference movie? A reference movie is a tiny little QuickTime movie consisting of a pointer to a file containing REDCODE data, and instructions on how to decode it. If you’ve got some 4K REDCODE RAW data and you want to work with it in a QuickTime app at 2K, instead of loading that file into the app directly, you point the app at the appropriate reference movie, which will tell the REDCODE QuickTime component to extract 2K from the 4K file, and pass that to QuickTime. To get 1K data, you point the app at a reference movie that instructs the REDCODE codec to pass 1K data, and so on.

While this is a little less clear, I would expect reference movies will also be able to specify what quality image is to be passed, so if you’re just editing you can get the results of a wavelet fractional resolution decode (which is fast), or if you’re doing a final conform (at, say, 2K), you can get the results of decoding the full 4K and using a high-quality scaling algorithm to produce 2K (which is slower).

Another important piece of the workflow puzzle is the fact that the REDCODE QuickTime codec will support both REDCODE RAW and REDCODE RGB interchangeably. This is very important for a compressed workflow. Remember, you can’t output to REDCODE RAW on a computer. A RAW format encodes unprocessed sensor data, which isn’t at all like the pixel data that comes out of a rendering pipeline. What this means is, a compressed workflow starting with REDCODE RAW is going to necessarily need to mix RAW and non-RAW clips. The fact that Red is supporting both RGB and RAW variants seamlessly within what appears (to QuickTime) to be a single codec, is what enables this.

Finally, while REDCODE uses a 12-bit linear color space internally, different apps will work best with data presented in different color spaces. In Shake, for instance, you’ll probably want to bring in REDCODE data as 16-bit RGB. In Final Cut, in contrast, you’ll want to bring in 32-bit YCbCr (which is still 4:4:4 in FCP, by the way), because Final Cut doesn’t support RGB at anything above 8 bits. The REDCODE QuickTime codec will also accommodate these requirements, converting between color representations as appropriate. (Which isn’t nearly as problematic in these larger color spaces as it is in an 8-bit world.)

Where do these reference movies come from? They’ll be generated automatically by the camera, and they’ll be sitting on your digital magazine, along with your actual footage. I’d assume there will also be a desktop utility which you can point at a REDCODE file to generate an appropriate reference movie as well.

When you put all of this together (and assuming I’ve understood it all correctly; this is basically synthesized from a large number of posts over on RedUser.net), you get a solution which lets the large number of QuickTime apps out there work with REDCODE RAW and RGB data in a flexible, largely transparent way.

Up next: 2K and 4K workflows on the desktop.

Information is still a little hazy on some workflow issues, so this is the first post in a series that will continue as more information comes out.

Everyone is focused on using Red for digital cinema, and certainly that’s the most exciting application of the camera This blog is, nominally, about digital cinema, and I’ll get to that soon. Odds are a lot of people are also going to be shooting broadcast material with the camera, and this has gotten somewhat less attention. So, let’s start there.

First off, for broadcast delivery, you might not want to shoot 4K RAW. Why do I say this? The two standards for HD broadcast are 720p60 and 1080i60 (or PAL-country equivalents). Shooting REDCODE RAW on-board at 4K, you can only go up to 30 frames a second.

For some material, like narrative work, it’s possible you’ll still want to shoot at 24 fps and add appropriate pulldown to conform to these standards. In that case, you’ll probably want to shoot 4K RAW. But for other sorts of material, you’ll probably want to shoot in a format which captures 60 or 50 frames a second, which means shooting at 1080p or 2K.

If that’s the case, your workflow becomes:

1. Shoot 1080p60/1080p50 RGB (won’t be enabled when the camera first ships) or 2K RAW @ 60/50 fps.
2. Process footage into Apple ProRes or Avid DNxHD 1080i or 720p through REDCINE. Or, if using Final Cut, through the new “Log & Transfer” interface. (The tapeless equivalent of “Log & Capture”.)
3. Edit material online in ProRes or DNxHD.
4. Go out through a Kona card or similar to the appropriate tape format, and hand that to your client.

If you’re going out to a tape format which uses a codec your editing environment has native support for (e.g. DVCPRO HD in Final Cut), you might want to change this a little, and convert directly to that format from REDCINE, and then output over FireWire. This results in a final product that has only been through two generations of compression (REDCODE and your delivery codec) rather than three (REDCODE, your editing codec, and your delivery codec).

What determines whether you should shoot 1080p RGB or 2K RAW? That’s a rather complicated subject that I’ll address in another post.

Up next: how do to a 2K (or possibly even 4K) DI on your desktop, and higher-end DI options.

Also, apparently some 1K video clips should be posted later today or tomorrow.

Update: 1K clip here.

Red lenses

• Red’s 18-50mm zoom should be shipping fairly early. This is good news. It’s the obvious choice for anyone on a budget who doesn’t already have PL-mount glass. (A future post will discuss some of the tradeoffs involved in using Nikon or Canon glass).
• The 18-85mm zoom Red announced previously will still ship, it has just been delayed.

Workflow

• Final Cut Pro 6 won’t support REDCODE natively on the day it ships, but in an update. It sounds like the update won’t take very long, though.
• There will be an FxPlug (which almost certainly means GPU-accellerated) filter in FCP for applying curves, etc. to REDCODE RAW footage.
• There’s also a FCP workflow for Red that involves transcoding to ProRes while ingesting.
• It looks (from some presentation materials I’ve seen in the background of NAB photos), like the standard rate for REDCODE RAW at 4K has dropped to 25 MB/s from 27.5 MB, so you should now be able to store a bit more for the same price.

Footage

• Red has posted some frame grabs from the Peter Jackson short here and here. Looks good. No 4K material and no motion yet, but that should apparently be coming in the next few days. (Probably any video clips will just be a couple of scenes, not the entire short).
• Jim Jannard explains how to shoot bad looking Red footage. No surprises there; the same list applies to any camera. A useful reminder that having great tools is only half the battle.

Hopefully we’ll know soon.

Red is also planning to give estimated shipping dates for reservation holders, and maybe announce some new accessories.

(By the way, I’ve made some change to the site design. If things look off, your browser probably has old images or stylesheets still cached. Hit reload a couple of times.)

As I’ve described previously, the traditional model for making a low-budget feature without external funding is to blow lots of money on film stock and camera rental (Kevin Smith funded Clerks by selling his comic book collection and running up $20K in credit card debt), and then try to find someone to buy your movie. Realistically, the chances of your first movie being a big hit are low, and you probably won’t be able to afford to make a second one.

Filmmaking is high risk, with potentially high payoff. The major studios mitigate against this risk by making many movies; many losers can be offset by one big winner. But an individual filmmaker can’t really afford to do this. What’s the alternative?

Instead of thinking in terms of one project, start a company. Take the money you were going to spend on making a single film. Instead of paying for camera rental, film stock, etc. buy a Red, and an editing workstation, and a studio monitor to do color grading on.

In other words, convert the one-time costs of making a low-budget movie into a capital investment. And don’t just use this equipment for the high-risk feature film business; amortize your costs across multiple markets. Do event videography. Shoot industrials. Shoot commercials, if you can get them. Rent your camera package out, and go along as an operator or DoP or DIT. Provide post production services. Once you own the equipment, there are a huge number of ways that you can get it to pay for itself, if you’re sufficiently creative and talented.

If you sell a movie… great. Have a party. If you don’t, though, you’ve still got a profitable business, doing something that’s a lot more fun than pushing paper or (and I speak from experience on this one) sitting in front of a computer writing code.

Of course, the idea of a video production company that offers services to outside clients and also works on its own projects isn’t so revolutionary… what film-quality digital acquisition changes is the level of projects that companies with this structure can undertake. “Real” feature films haven’t been in the potential repertoire of such companies, because there just hasn’t been a large amount of overlap between the resources (equipment and the skills) required for these markets. This is changing with respect to equipment, and that will allow sufficiently motivated people to learn the skills.