This is why you shouldn't use log gamma all the time

Replay: Shooting in log gamma modes is often par for the course in todays shooting environments. But should it always be the 'go to' mode that we choose, or are there sometimes better options?

Recording what's widely referred to as “log” is becoming a fairly standard part of — well — any sort of shooting that will be graded. In the main, that's a great idea, but there are circumstances where it can be slightly counterproductive or at least something of a zero sum game.

We're not going to go into the mathematics today, but so we can get a proper understanding of what's going on, let's recap why we shoot log in the first place (if this is old news, skip two paragraphs down.) For now, though, don't worry about “log” meaning “logarithm”, or about what a logarithm is, because most cameras only vaguely follow the mathematics anyway. What we need to understand is that we are recording a very wide range of brightness — the entire range the camera can capture, often so that a given amount of change in brightness is encoded using the same number of numeric digital values at all points up and down the scale.

If we display those pictures on a normal monitor, things look flat and dull, because the normal monitor can't output nearly as much brightness as was in the original scene. The sun on a monitor isn't as bright as the real sun, so the pictures need more contrast to look reasonable. This can be done either by passing them through a fixed colour and contrast manipulation process, which is what happens in conventional TV cameras, or by giving them to a colourist, who'll adjust the results by hand, though often basing that work on a similar predetermined manipulation (a lookup table, or LUT). The upside of this is that the colourist can work with all of the information supplied by the camera.

So now that we know what log does, here's the problem that it creates.

Log workflows

Log workflows involve, in effect, adding quite a lot of contrast to that original recorded image. When log shooting was first widely introduced, possibly around the time of the Viper digital cinematography camera with its Filmstream mode, it was constantly reinforced by Grass Valley that it had to be recorded uncompressed, in full RGB. It also very certainly had to be recorded in 10-bit, otherwise, that large addition of contrast would make compression artefacts and quantisation noise (that is, colour banding) too obvious. Early productions struggled with the cumbersome disk recorders, made out of mid-2000s technology to handle the 180MB/s torrent of data.

Those stern requirements were only partially valid, as the existence of very successful compressed log workflows now attests. Probably, at the time, the cautious approach was aimed at discouraging people from trying to record Filmstream material to the original HDCAM tape format, which would certainly have been easier and cheaper. HDCAM was essentially created to allow high-definition news gathering and then developed further for cinema use. It was essentially a 1440 by 1080 pixel, 8-bit, 3:1:1 subsampled, 120-ish megabit codec which was always of highly dubious suitability for work that would be graded, let alone full blown log recordings. Adding that much sort-of-contrast increase would make the compression artefacts and lack of resolution too obvious.

The workflows that now work so well use far better technology: higher bitrates and smarter codecs. ProRes 422 HQ is almost one and a half times the bitrate of HDCAM, and the mathematics involved are a lot more modern. HDCAM was released in 1997 and therefore represents, probably, the bleeding edge of 1995 technology, and that's more than twenty years ago at a time of the most rapid change. Record ProRes 4444, and we're putting down double the HDCAM bitrate for the same number of frames per second. Formats like these (including AVC Intra, DNxHD and others) do a perfectly respectable job of recording log pictures.

Arri log transfer function

The problem with log and the solution

The problem comes when we start trying to combine log recordings with some very constrained devices, such as DSLRs. Most of them use low-cost, or at least low-power and small-sized flash card formats. They don't try to record at rates above a few tens of megabits per second and there's a limit to how clever their codecs can be given similar concerns over size, weight, cost and power consumption. Cameras such as Sony's A7s mirrorless stills camera, which has a sensor of absolutely spectacular sensitivity and dynamic range, or JVC's LS300, both offer log modes and record to SD cards by default. In log mode, these cameras are at their best by far when used with external recorders. Similar concerns attend older cameras like the Sony F3, which was advertised as a B-camera for the F35 and was therefore fairly clearly always intended to be used with external recording.

So, should we record non-log modes — usually, modes designed for display on Rec. 709 monitors — when making low-bitrate recordings? There's probably an argument that the limits imposed by a low-bandwidth recording might be at least as restrictive as the limits imposed by non-log origination, but it's incredibly dependent on circumstance. If the little DSLR is being used as a B-camera, then it probably makes sense to shoot for the closest possible match with the main unit. Conversely, if we're shooting a documentary and we want to use the DSLR because it can be used discreetly, that might be a reason to shoot the whole show in, if not 709, something more contrasty than a true log. Hybrid approaches can, with care, be developed; one is represented, arguably, by Sony's Hypergamma curves.

Either way, shooting material to flashcards the size (and only a few times the cost) of a postage stamp is a circumstance that should provoke some extremely careful exposure decisions, regardless of the intent of the cinematographer, and it may not always make sense to reach directly for log recordings in absolutely all circumstances.

Header image from film 'Cross', graded at Online Creative.