RED Build 16: A Camera Whose Time Has Come by Art Adams

July 4, 2008

Ah, sweet 16. How I’ve waited for thee. Finally, a camera I can work with.

It’s not perfect yet. Not by a long shot. There’s an error in the software that causes crashes attributable to “Codec Faults” and “Codec Errors”–I’m told one has to do with errors reading data off the sensor and one has to do with writing the data to the drive or card. Supposedly a fix for this will be out any day now. (I’m told that three builds of Build 16 have been released over a one week period.) But the usability improvements are long overdo and worth the pain we’ve suffered through.

Today saw a meeting of minds at Chater Camera in Berkeley: Dane Brehm (DIT/DAS), Adam Wilt (guru of all things videographical), Tim Blackmore (factotum and Adam’s cohort in crime at film company “Meets the Eye”), and myself–your humble narrator. We sought to plumb the depths of the mythical (and Mysterical) latest software update for the RED ONE camera. This is the build from which there is no return: once you install it, you can never go back. Never.

But that’s okay. (Or it will be when the bugs are ironed out.) Dane showed us why, on the next page:

REDSPACE, REC 709 and RAW: GOOD NEWS AND BAD NEWS

Build 16 introduces RedSpace, a new color space for the RED camera. From what I’m led to believe by those who appear smarter than myself, RedSpace is a brighter and more saturated version of the REC 709 setting already installed in the camera. My past efforts at using the REC 709 color space have been disappointing, mostly because the gamma curve makes the midtones too dark. As a result the monitor just doesn’t look right, which is why we’ve been told for so long to treat the RED ONE “just like film”: because you couldn’t really see what it was doing, so you’d just have to trust your meter.

That’s fine for a film stock, but I’ve not worked with many HD cameras that react to a meter the same way twice.

RedSpace is a definite improvement. The gamma curve has been brought up a bit so midtones look normal. Observation of the gray values on a waveform monitor showed that they appear to track properly both by eye and on the waveform monitor, just the way a real camera would. It appears that a waveform monitor could prove usable when viewing RedSpace.

The problem with both RedSpace and REC 709 comes when exposing an 18% gray card using a light meter set at EI 320: the histogram shows the middle gray value falling noticeably to the left of center, technically too low to be truly 18% gray. The histogram seems to be affected by the gamma curve built in to both REC 709 and RedSpace. The only way I can use a light meter (reflected) to accurately place 18% gray in the middle of the histogram is to rate the camera at EI 160.

The same thing seems to happen in RAW mode. RAW purports to show exactly what is happening to the sensor, devoid of gamma curves and knee compression. We saw knee compression on both REC 709 and RedSpace, and both REC 709 and RedSpace are affected by changing the EI of the camera. RAW is not. You can spin the EI setting all over the place in RAW mode and you won’t see any difference at all. I like that. A lot. Because it shows me what’s REALLY going on.

Once again, though, middle gray comes up significantly left of where it should on the histograms. We’ve been told that the EI sweet spot is 320, but if we go by the histogram the camera is a stop slower. If someone from RED would like to email me with an explanation of this phenomena I’d be happy to post it. Or it could be posted in the comments for this article.

Good news and bad news about the histograms on the next page:

PARADE HISTOGRAMS: A MOVING TARGET

We now have the option of seeing RGB histograms in parade view. Hurrah! One of the first lessons I learned about the RED ONE is that there isn’t much in the way of knee control, and whereas other cameras will hide the fact that one channel will frequently clip before the others depending on the saturation of objects within the scene, the RED ONE doesn’t; or at least not very well. That’s good, because if you know that only one channel is clipping you can sleep peacefully at night secure in the knowledge that RedAlert or RedCine can rebuild detail in a clipped channel using data from the other two channels. (RedAlert calls the highlight recovery feature “DRX” while RedCine calls it–wait for it–“highlight recovery”.)

The problem is that histogram clipping is affected by what color space you’re in, and doesn’t necessarily reflect what’s happening to the sensor. Not good.

If you’re in RedSpace, for example, and you clip the blue channel according to the parade histogram and the traffic light, you can flip into RAW to see what’s really going on… and find out that you have plenty of headroom according to the histograms in RAW mode. Same thing with REC 709. If you clip anything in any other color space other than RAW you will probably have a bit of headroom left over… which, on the one hand is nice, because you aren’t losing detail in the highlights. On the other hand, you aren’t using the full range of the chip either.

Personally I’d prefer that the histograms ALWAYS show what’s going on with the sensor, unaffected by gamma and knee compression. That’s not possible right now, though, so we’ll have to make do with assigning a User Button to toggle in and out of RAW mode. This works fairly well: in RedSpace, for example, we assigned User Button 3 (on the viewfinder) to toggle in and out of RAW mode. This is very helpful when judging exposure but not very pleasant for everyone else who is watching the camera output: rather than being able to assign RedSpace to one monitor output and RAW to another, the entire output chain is affected. One second the director will be watching the crisp super-saturated RedSpace image, and the next they’ll be staring at a flat gray image seemingly devoid of color. RAW doesn’t look very pretty on the monitor, but it’s the only way you’re going to be able see exactly what’s going on with the sensor. Prepare the director for that switch sooner than later.

All this and Christmas too on the next page:

There were lots of other functions that Dane showed us, most of which were pretty cool. The camera now has a built in MacBeth chart, which is interesting–except that I know how to set up a monitor using SMPTE color bars, not a MacBeth chart. Still, I’m sure I can learn. There’s a false color exposure mode where dark tones are blue and transition to orange and red as the tones get brighter, culminating in pink in the clips. There’s a gray scale chip chart reference strip that can be called up to sit next to the image in the viewfinder. Somewhere in the menu there’s a command to steam milk and brew espresso, but we haven’t tracked it down yet. There are a LOT of changes to this build.

But it ain’t ready for prime time. Yet.

Chater Camera has three REDs in-house, and only one has Build 16 on it. They don’t let it leave the shop as it’s not stable enough to trust in the field yet, but also because they want people to come in and play with it to see what all the new features are. (For which we are extremely grateful.) My great hope is that, sooner than later, Build 16 will be finalized, because it makes a VAST improvement in the camera’s usability. It’s still not perfect, but it may finally be ready for the big time.

As a DP, I want information. Accurate, repeatable information. I can now get that out of the RED. I still have to play a few games to get at it, but at least it’s available. As soon as the “codec fault” and “codec error” bugs are fixed my comfort level with the RED ONE is going to go way up.

I still want to know why the histograms tell me the camera should (theoretically) be rated at EI 160. Perhaps the noise floor is finally low enough to allow that. I hope to find that out soon. Dane has kindly given me a collection of footage shot by himself, local camera assistant Jeremy Wong and DP John Chater. I hope to cull through it in the near future.

Meanwhile, I’m getting married next week so I won’t be wading through this footage for a little while yet. Keep an eye on Adam’s blog as he got a lot of juicy “RED Porn” pictures that I’m sure he’ll show off soon enough.

I like RED a bit more with every software build. I can’t say that about everything. I’m putting RED ahead of Microsoft on this round. Build 16 trumps Vista any day… because Build 16 looks like it may actually WORK.

Eventually.