Final Cut Pro is the most popular pro video editing application in the world; it has something like 50% of the market, while everyone else splits the other 50%. Plus, it helps sell high-end hardware, and having real creative pros doing important things on the platform has significant value to the Apple brand.

Apple is unlikely to walk away from all of that.

But the thing about Apple under Jobs — at least since they got OS X on track and the iPod started taking off — is that they’re sort of fearless. They’re willing to launch themselves into markets against entrenched competitors, or launch products that nobody knows if there’s a market for. They’re willing to scrap highly successful products and replace them with products they know critics (and even some existing users) won’t like, but that they believe are better. They’re willing to fundamentally re-think things that nobody else really questions.

In general, they’re willing to do things that they know people will complain about loudly — but this gives them the flexibility to sometimes make exceptional products.

I suspect this is precisely where they’re headed with FCP. We’re going to get the OpenCL and Grand Central Dispatch goodness that everyone wants. But we’re not going to get an app with a strict superset of Final Cut Pro’s functionality. Instead, we’re going to get an app that Apple believes is better overall for the tasks video editors perform, even if some features are cut. And we might also get a significantly overhauled UI; something that results from a process of sitting down and questioning every assumption about how editing interfaces currently work.

In short, I think they’ll come up with something really interesting… that will probably cause a bunch of people to totally freak out about how Apple has ruined everything and make forceful public declarations about how they’re leaving the platform. Meanwhile, people actually willing to embrace the thing might discover it has a bit of that iPad ‘magic’.

I have no inside information; this is all merely based on watching Apple (and reaction to Apple’s products) closely for the last 10 years.

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 Nehalem Mac Pros are the stars of the show for your Mac-based HD video needs, for obvious reasons. But we’re also pretty excited about the new Minis. With FireWire 800 and NVIDIA graphics, these seem like they’d be perfectly good systems for everyday editing tasks, probably even cutting 1080p ProRes HQ (with external storage, obviously). And the base configuration, bumped up to 2 GB of RAM, is just $650. Not a substitute for a Mac Pro, clearly, but a small video production shop built around three or four of these and one ~$5K Mac Pro seems like a pretty plausible approach.

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.

That is all.

The situation with the iPhone is very interesting. At first glance, in this market, it appears that Apple is going up against well entrenched, serious competitors. Upon further examination, however, one realizes that most of the players in this space are, frankly, amateurs compared with Apple.

Am I crazy? No. I’m completely serious. Apple’s established competitors in the cell phone market (or the vendors they license software from) mostly have backgrounds building simple embedded software systems for very limited devices. A company that has been developing operating systems for desktop computers for a few decades is in a far better position to tackle the challenges of building a real platform for today’s mobile devices, which are no longer all that limited.

Does anyone really see Nokia or Motorola or even Palm developing a platform that can match OS X? Creating and maintaining a desktop-class OS is not at all trivial. None of Apple’s competitors really has any serious experience with it except for Microsoft, and Microsoft has its own problems.

The iPhone provides by far the best user experience of any handset on the market. As a desktop operating system developer, Apple brings far more to the table on this front than companies which have previously only designed UI for simplistic embedded devices.

I’m using a four year-old Nokia Series 60 phone simply because I don’t particularly consider anything I’ve seen recently to constitute much of an upgrade. I’ll probably be buying an iPhone.

The people who sit around counting the number of bullet points on spec sheets are seriously missing the point, just as they did with the iPod.

Apple’s major recent successes practically all revolve around taking technologies that are out there, but that regular consumers don’t quite get, and turning them into mass market technologies. They played a fairly large role in doing this with WiFi, and they did it with the iPod. Apple didn’t do anything in these instances that was technically much different from what others were doing. What they did was package the technology to make it palatable to regular people, and create a use case for it that regular people understood.

The analysts complaining that the iPhone doesn’t support syncing with Exchange mail servers are completely out to lunch. This isn’t a device for business users or geeks. It’s the first smart phone for the iPod demographic, which is a far larger market.

It’s really dangerous to underestimate Apple here. In many respects, those underestimating Apple are making the same mistake those who underestimate Red have made. As I posted about back January, Red is doing things that people didn’t believe could be done, by bringing a sort of IT mindset to a market which hasn’t yet adopted one. In many respects, by bringing a few decades of desktop OS experience to the smart phone market, Apple is doing something similar, and the consequences for the market are likely to be similarly significant in the long run.

Various pundits have recently been proclaiming the failure of the Apple TV, some even going so far as to compare it to the Zune. This is, frankly, nuts. It shows a fundamental misunderstanding of the market into which Apple TV is selling.

People’s media libraries will increasingly reside on the hard drives of their computers, and they’ll want access to that content from their living rooms. These are predictions that are nearly impossible to disagree with. The implication is that the eventual market for products like Apple TV is in the hundreds of millions, at least. However, this market is presently extremely immature.

Is there another consumer electronics market that has emerged in the recent past, that we could possibly use as a guide for what to expect here? Well, there’s the iPod. Let’s see a graph of unit sales for that.

The Apple TV came out about five months ago. I’ve marked the five month point on that graph. You’ll notice Apple hadn’t sold a lot of iPods by then. In fact, Apple now sells more iPods in two days than they sold in the first six months it was on the market.

Of course, you’d expect things to ramp up faster for the Apple TV. It’s part of an established media platform (the iTunes ecosystem), and it was available for Windows from the start. But even the most successful new markets tend to start off with slow growth. Eventually they reach a tipping point, and growth snowballs. It’s extremely unwise to write off a product selling into a new market before that market has had a chance to reach a tipping point. Particularly when there are strong reasons to believe the market will, eventually, tip.

We’ll know the Apple TV is failing if the market for products in its category starts taking off, but the growth is centered around other products, with the Apple TV getting left behind. Or if, four years from now, when all the content and infrastructure is in place, the market still hasn’t tipped, we can call the Apple TV and its competitors failures. Personally, though, I’d consider both of those scenarios unlikely. This is a market with serious volume potential, and Apple is in a stronger position than anyone to become the leading player in it.

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.

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.

A few points:

• The codec was designed both for low file size and low CPU utilization.
• Performance scales almost linearly when adding processors/cores
• There’s a “half-resolution decoding method”. Might mean ProRes is wavelet.

Update: Looks like the info comes from this Apple white paper.

You can get a nice summary of the announcements here. It’s going to take days to sort through the implications of all of this. The really big news for Red fans, though, is that FCP will apparently support 4K and direct editing of Red footage.

Of the announced features of Leopard, the only really significant one for our market is ZFS, for reasons I’ve discussed in the past. While it certainly would be great, though, it’s by no means necessary.

Leopard will also allow for GUI applications to be compiled 64-bit, which will have some benefit (though mostly from the fact that on Intel, it lets you use more registers). But we probably weren’t going to see major 64-bit apps (like, perhaps, the next versions of the Final Cut Studio apps) come out until fall anyway. Shake, incidentally, is already 64-bit. It gets around the limit on GUI applications in Tiger by rendering in a separate non-GUI process.

As far as the broad conclusions people are drawing from this announcement (and particularly the fact that Apple claims the delay is a result of reallocating resources to the iPhone), I honestly think they’re a bunch of nonsense. A short-term reallocation of resources doesn’t demonstrate a de-emphasis of the Mac platform, and ultimately Apple’s efforts in other markets will only benefit the Mac.

There’s a reason Microsoft tries to go after such markets; they believe if other platforms get a foothold there, it puts them in a stronger position to challenge Microsoft on the desktop. Apple understands this as well. The relationship between the Mac and Apple’s consumer devices is not one of competition, but of synergy. The “iPod halo effect” represents only the barest beginnings of this.

It’s also worth noting that Apple’s efforts in these consumer markets have direct applicability to our industry. Apple is one of the companies building the future of media distribution. Apple TV and the iPhone will probably end up being more important to content creators, long term, than Leopard. Some of the folks reading this blog are probably going to be selling HD movies via iTunes to Apple TV customers in a year or two.

And, frankly, it’s hard to believe this entire delay is really due to the iPhone; that might, to some extent, merely be a convenient excuse. Apple has been pretty good in recent years; the last big slip was when Mac OS X 10.0 slipped from September 2000 to March 2001. But software release dates slip all the time.

Is Apple neglecting its Mac-based pro customers? I doubt it. They’ve just started shipping the fastest Xeon workstations on the market; those quad 3 GHz chips apparently are in short supply, and other major OEMs don’t seem to be offering them yet. And they’re probably going to have some pretty cool stuff for us on Sunday.

This post is background for an upcoming post on building a cheap RAID to hold all those hours of 4K footage you’ll be shooting in a few months.

There’s tons of information about ZFS around the web, but much of it is fairly technical, and as far as I’ve seen there’s almost nothing that explains in concrete terms what makes it different from what we’ve got now, and why it’s so important to IT production workflow.

Basically, ZFS is a much more flexible way of handling data storage than what traditional file systems provide. Traditional file systems work with discrete volumes, which may span one disk, or, with RAID, more than one disk.

With ZFS, instead of having inflexible volumes, you create “storage pools” across multiple physical disks. Pools are flexible; if you create a pool spanning four drives and need to add a fifth drive, you can do that without having to recreate any of the file systems in the pool. You can even remove a drive from a pool, assuming there’s enough space to store all the data without it. With a simple command, ZFS will rearrange your data so the drive you specify is no longer necessary, after which it can be removed.

Drives in the pool can be used for any combination of striping, mirroring, or RAID Z (which is sort of like RAID 5), plus there’s support for hot spares.

With traditional RAID setups, though, if you want to add drives or rearrange things, the whole array has to be backed up and reformatted, or you have to use pricey volume management tools which could take many hours to move your data around, during which time your storage is unavailable. With ZFS, none of this is necessary.

Once a pool is created, file systems can be created and rearranged within that pool extremely easily; it’s nearly as easy as creating or rearranging directories presently is. As many file systems as you’d like to create can share a storage pool.

ZFS also has built-in pervasive checksumming features so it’ll automatically detect if your data gets corrupted (and recover it, if you’ve set things up with some amount of redundancy). And because of its architecture, the data on disk is always in a consistent state, eliminating the need for file system repair utilities and the speed hit associated with journaling.

Right now your options for using ZFS are buying ludicrously expensive Sun gear, or downloading OpenSolaris x86 and trying to piece together a system that will work on your own. (I spent some time trying to figure out what hardware would work for an OpenSolaris-based storage server… it’s not easy to find good information.)

Having support in OS X will make things a lot easier. Up next: discussion of how you can leverage ZFS in OS X to get most of the benefits of enterprise-class storage at a fraction of the price.