Please note, that the code presented below only works with older versions of RED firmware. Newer versions use the same internal format, but do some header obfuscation. I might add a decoder for that in the future, but that entirely depends on my spare time / and or real motivation. If you are a RED customer, please ask your sales representative, why RED started obfuscating their data files, thereby preventing the use of custom video file readers. (And no: the official SDK is not an option for GPL software...)

If you want to accelerate my development efforts, feel free, to use my paypal-donation link:

This page gives status updates on R3D import for Blender. (or development of libredcode) Currently, I can extract video and audio frames from stream by index (just compile format.c and format.h.)

Audio frames a RAW-PCM data, Video frames consist of JP2 files.

The later can be decoded using openjpeg. Build j2k_to_image in codec directory.

Those j2k files contain YCbCr data of the frame split into 4 planes: Y1, Cb, Cr, Y2.

I'm not totally sure how this should be mapped to the Bayer-RGB mosaic, but I assume, that

Y1, Cb -> Blue
Y2, Cr -> Red 
Y1, Cr, Cb -> Green 1
Y2, Cr, Cb -> Green 2
After some twiddling with the YCbCr-conversion formula, I came up with something like this:
b' = Cb * (1 - Kb) / 2
r' = Cr * (1 - Kr) / 2
g' = (- Kr * r' - Kb * b') / (1 - Kr - Kb)
final colors result from:
b = b' + Y
r = r' + Y
g = g' + Y
Now the interpolation process can be carried out completely on the luminance channel (avoiding screwing up the color information at the edges, leaving only some really small amount of color bleeding):
Y[4] = { Y1, (Y2 + Y2')/2, (Y1 + Y1')/2, Y2 }
Y2' = Y2 from previous row
Y1' = Y1 from next row
After initially using ITU-R BT.709, I was provided with the hint, that Kb = Kr = 0 for RED, which makes the decoding a lot simpler :)

Debayer can be accomplished using debayer.c.

Then you can do:

./format R3D-file v [index] > frame.jp2
./j2k_to_image -i frame.jp2 -o frame.raw
./debayer image-width image-height < frame.raw

gimp *.ppm

(find a shell script here that does that all in one step.)

My debayer-algorithm is rather aehm preliminary. (linear interpolation)

Just using one of the Y-planes yields pretty nice half-res results though. (written to rgb1.ppm and rgb2.ppm by debayer).

The new naive approach is on par in quality with the half-res result. (Doing anything further on trying to remove the last bits of color bleeding will most probably make things worse = more blurry).

The actually debayered result finds it's way into naive.ppm (and linear.ppm for an additional debayered version which looks a lot more blurred though. That code is commented out by default...)

The example chart from:

looks currently like that: Half-Res, Full-Res (Old Debayer), Full-Res (New "naive" approach).
(colors are a little off, since those were generated with Kb and Kr of the ITU-standard)