Note: All the following comments on Red workflow are true of any system that provides such a workflow.

The first point to note is that if a real-time decode of the raw r3d files is offered on any system the likelihood id that the process uses no de-bayering, but simply pixel-picks a R,G,B, pixel from the quad bayer group - this is why the real-time generated images are easy sub-values of the original 4K bayer file, so single RGB pixels from the original file can be selected in real-time with no processing.

What this means is fairly obvious, I hope. The resultant image is a proxy, with non-optimal quality.

When working from the full 4K raw file and performing real de-bayering to a 4K image most systems are again equal as the Red SDK defines the process used - for all systems.

How these real 4K images are then re-sized to smaller resolutions is something (the only thing) that can be variable system-by-system. Note: 3K is a good working resolution with a near optimal resolution (quality) vs. size ratio...

Where more options are in need of better understanding is with the camera's use of metadata that can be used to control the decoding process from the raw r3d file.

Red really needs to provide a mode with all options off, in a 10bit Log format so that all the data the sensor captured is available for post - just as with Viper's FilmStream mode. Unfortunately they don't...

I just want all the image data that was captured by the sensor so I can chose how to work with it.

At the moment RedLog is the closest to this, but white point and ISO metadata can't be turned off, which is a shame, but it's a Red SDK restriction.

But, having said that, with many DI systems now working from the raw r3d files at full resolution in real-time, de-bayering on the fly, the options for creative workflows have increased dramatically.

So, our suggestion for the best Red workflow is as follows:

Offline via a system that can work with the proxy based real-time workflow (FCP/Avid?), with no de-bayering as described above, at the best resolution you can work with easily.

Output a pull-list (edl) from the offline.

For those systems that can't work fro the raw r3d files natively De-bayer and decode the selects/circle takes only using the full 4K raw file to generate dpx files in 10bit RedLog form (or Linear 16-bit - but there's no benefit - just a larger file size! 10bit Log is visually loss less compression) with all Red metadata turned off (those that can be turned off) - these 4K files can be re-sized to what ever working resolution is required.

Use the dpx files for the online just as with a scanned 'film' project, which means any good DI system can be used for the on-line, using a LUT to view the final deliverable as required.
(Remember calibration LUTs don't care about the source data, just the deliverable medium).

This workflow also means none of the captured image data is thrown away, and the LUT used enables low-light and high-light data to be pushed and pulled as required, without restriction.

This deals with the issue of working with the proxy images generated without a full decode and de-bayer from the original raw 4K file - something most system manufacturers don't tell you about when they talk of 'real-time' working with r3d files.

For example, with a system like FCP you would actually have to post-process the project non-real-time to generate real de-bayered and decoded final images, and not output the 'proxy' ones. Not often a point that is well made.

Not that this is necessarily a problem if the final deliverable is low resolution (SD), just that you need to be aware of this requirement if you don't want to walk away at the end of the day with a project generated from the proxy images only. This is often missed from a lot of people's Red workflow descriptions.

I also have a bit of an issue with working on-line with the proxy images as I'm never sure the final real on-line image (after real de-bayering and decoding) will be 100% identical, especially if I've done intricate on-line colour correction where edge detail is critical.

But that's just me!

Again, I must state that this is based on my preferred workflow, and people may be happy with an end result that uses the proxy images only. I'm not.

So, my preferred workflow is easy - sort of.

The problem with the above Red workflow can be the time taken to selectively decode the selects/circle takes to dpx.

Most systems that do this at the lower end of the market are slow and awkward to use, and so many people are taking the proxy short-cuts.

Raw r3d On-line Workflows

However, many on-line DI systems can now mount the r3d data directly, and decode and de-bayer on the fly, working with the full range image and metadata interactively.

This negates the need to load the red files into the system, including the de-bayering and decoding to 10bit Log dpx, so creative work can be performed without any previous processes being required. This make the load time for on-line work irrelevant.

And the fact you can manipulate the image metadata while simultaneously making creative grading changes, keep total image flexibility.

Working with the correct calibration LUT for the final deliverable then means all grading can be done non-destructively, rather than grading without a LUT, which can cause major restrictions in the final look.

Hope this info helps.

If you are interested in knowing more about this, or have questions, please feel free to contact Steve directly. steve@lightillusion.com