R3d into Shake

[Brian D. Goff]

If I get this right, you can wrap the R3D into a quicktime film (during import into FCP) so you can "natively" work with R3D in FCP (max resolution is 2k however). Would it not be possible to wrap the R3D into a 4k quicktime and then be able to work with "native" R3D in Shake? Is there any software that can do this?

thanks

 

[paulherrin]

i'm not sure man... i haven't tried it. let me know if you get something working. apple stopped supporting shake a long time ago (unfortunately, it's still really powerful). i'm pretty sure they dropped that for motion (bad idea.) but you should check out nuke by the foundry...

otherwise, do your one light grading in redcine-x or storm (if you haven't checked it out you should) or whatever - then export to tiff or dpx or exr, and read that sequence into shake.

 

[Ben Brainerd]

I'm pretty sure that's not a viable option. The "Wrapped R3D" support in FCP is dependent on some of the newer quicktime plugins, which I'm pretty sure Shake doesn't support them. Look at how much hackery was involved in getting Color to support the new codecs. Shake, like Color, is one of those apps that Apple bought and sold more or less as-is, and with its lack of support I'm guessing no go.

Like Paul said, it's still possible to work with RED footage in Shake, just not natively.

 

[Alex MacLean]

do your one light grading in redcine-x or storm (if you haven't checked it out you should) or whatever - then export to tiff or dpx or exr, and read that sequence into shake.

yeah RCX -> DPX -> Shake is the way to go

 

[Jean Déraps]

By going the RCX->DPX route, you lose the connection (and advantages of working with) the RAW R3D file. The latest versions of Nuke (6.1 and newer) can work with native R3D files. Although Shake was (and still is) great, we'll all have to bite the bullet with Shake someday and (unfortunately) move on if we want to work with R3D files in a top notch compositing program.

 

[paulherrin]

jean, you are correct.

while you do lose the Rawness of the file, as long as you get it pretty close to what you want in your first color correction, you can save as 16-bit (tif, dpx, or exr) and still get some latitude out of the file to work with. take note those files will probably be a bit larger than your r3d file, so you'll have to store both... which can add up if you're operating on a small scale.

in any case, if it's at all feasible... the switch to nuke is quite comfortable. my only complaint is that you can't shake a node off... haha. but seriously, a couple years ago, nuke only had a better interface, but basically the same features. now... nuke is well advanced and much more powerful. they've also updated their roto tools, so that they are actually usable, and they are actually really nice.

as always, if you need any help just ask. good luck!

 

[Gunleik Groven]

While not discussing Nukes capacity, even with Nuke there are quite a few advantages as to stability and predictability to work with EXR's. And it's fast and colorconsistent.

When working in a larger environment where colorconsistency through many hands and minds is crucial, giving everyone RAW files to play with is not a very good idea...

If you are a one-man or small shop, that may differ...

Shake can also do EXRs, but I haven't tested that...
G

 

[paulherrin]

yes, shake can read up to exr 1.4, so just don't use any compressions that came in after that.

however, shake reads dpx and tiff much faster. exr's will be more accurate, but visually that is up for debate as to whether you will notice any difference. it probably depends on the image and how much you're going to be manipulating it. as a general rule, always do the bulk of your color correction with the raw file before you export.

 

[Alexander Ibrahim]

I love Shake... but if you really need to work directly with .r3d files, then you really need to look at more up to date composite applications.

At this point I think even AE is more advanced. (Not in working techniques... just technology.)

I prefer Nuke.

 

[Ben Brainerd]

Also, IMHO, I personally think working with RAW at the compositing/FX stage is generally a bad idea. Mainly because you can't render *BACK* to RAW.

As a Colorist, I get really frustrated when someone hands me a bunch of RAW files to grade most of the film and a few rendered FX shots. It makes the finishing workflow needlessly complex. My recommended workflow, if there's going to be any significant FX work, is to run the entire film off as DPX/EXR/TIFF/etc before sending it to FX. That way everything is coming to finishing in the same format, reducing hassles.

I work this way whenever possible since not every program renders RAW the same way. It's better than it used to be, but I've found that the exact same settings can, on occasion, produce slightly different results depending on what program is doing the rendering.

 

[Gavin Stokes]

Have you tried bringing the Quicktime reference movies into Shake? This should work, showing up in Shake as 16-bit material.

Let me know if it doesn't. I wrote Shake's QuickTime implementation (among other parts), so I can look into it for you.

 

[Gunleik Groven]

My point exactly, nd I think this cannot be said too often:

Unless you're a one-man-band (which I happen to be occationally, too) RAW online can be the precipe for not so good results...

Handing over well developed cineon files to VFX/grade can ensure color consistency throughout and lets everyone work in parallell.

You cannot render RAW out of the VFX session, anyhow, so as far as you go into the session with files that the compositer really is made for (be it DPX or EXR) this is a total win-win situation out of conform.

OTOH if YOU are the editor, compositor, VFX, color and general Online guy, it can be a good idea to stay RAW throughout...

 

[Gunleik Groven]

Have you tried bringing the Quicktime reference movies into Shake? This should work, showing up in Shake as 16-bit material.

Let me know if it doesn't. I wrote Shake's QuickTime implementation (among other parts), so I can look into it for you.

LOL.
Niceone... ! )

This did work last time I tested.

I Cannot remember if it got the RSXs right, though...

 

[Ian Laurie]

I tend to grade in redcine X, or more likely now, Storm, render out full res, full debayer quicktime 4444 files or DPX depending on the project (just best to start high if you ask me) and then start my keying and fx work from there. I love Shake as well.... still mourning its imminent demise.... but if you have the cash, the foundry and Nuke looks like the way to go.

 

[Ian Laurie]

Have you tried bringing the Quicktime reference movies into Shake? This should work, showing up in Shake as 16-bit material.

Let me know if it doesn't. I wrote Shake's QuickTime implementation (among other parts), so I can look into it for you.

Of course. Count on someone from red to have built in obsolescence capabilities into software that was killed off 5 years ago. Awesome.

 

[Brian D. Goff]

Have you tried bringing the Quicktime reference movies into Shake? This should work, showing up in Shake as 16-bit material.

Let me know if it doesn't. I wrote Shake's QuickTime implementation (among other parts), so I can look into it for you.

This does work, but isn't this like only 1/4 quality even if I import the F reference movie?

 

[Gavin Stokes]

This does work, but isn't this like only 1/4 quality even if I import the F reference movie?

No, you get the full 4K. I just tried it with the latest codec and it worked. What I am seeing is that it's coming in as 8-bit, however, which is not correct. I'm going to try rendering a QT-wrapped file out of RCX and see what happens.

Count on someone from red to have built in obsolescence capabilities into software that was killed off 5 years ago.

I corresponded with Graeme way before the R1 came out, to make sure Shake could extract 16-bit color depth from his codec. After Shake was discontinued, a Mac OS or FCS update reversed the byte order of all the high-bit-depth codecs and broke QT in Shake. I badgered the higher-ups for ages to let us patch it and restore its usefulness for years to come. Needless to say, our users were pretty happy when they gave the go-ahead for that final (v. 4.1.1) update.

 

[Alexander Ibrahim]

No, you get the full 4K. I just tried it with the latest codec and it worked. What I am seeing is that it's coming in as 8-bit, however, which is not correct. I'm going to try rendering a QT-wrapped file out of RCX and see what happens.

I corresponded with Graeme way before the R1 came out, to make sure Shake could extract 16-bit color depth from his codec. After Shake was discontinued, a Mac OS or FCS update reversed the byte order of all the high-bit-depth codecs and broke QT in Shake. I badgered the higher-ups for ages to let us patch it and restore its usefulness for years to come. Needless to say, our users were pretty happy when they gave the go-ahead for that final (v. 4.1.1) update.

How are you checking the bit depth of the data in Shake?

Are you looking at the info on top of the viewer window, or are you somehow processing it in Shake to reveal the actual data types?

On yet another Shake related note... does Apple no longer sell Shake licenses?

 

[Gavin Stokes]

Are you looking at the info on top of the viewer window, or are you somehow processing it in Shake to reveal the actual data types?

On yet another Shake related note... does Apple no longer sell Shake licenses?

The info on top of the viewer window shows how Shake is processing the pixel data. QuickTime doesn't provide any way to determine exactly what pixel format resides in the file; you can do queries to find out which decompressors can decode the file, and then query them to find out what kinds of pixel formats they can output. Some codecs fail to advertise those formats, and thus an application has to assume the lowest common denominator (8-bit).

My goal in working with Graeme and Rob back then was to make sure the REDCODE QT codec did support 16-bit output and advertise that support properly. It may be that this tag fell out at some point; I'll try to have a look.

Apple stopped selling Shake years ago. They sold the source code to all the big customers (Weta, ILM, etc.). I hear these guys have some pretty cool custom versions now.

 

[Gavin Stokes]

I just remembered a little-known feature I added to help me and customers debug QuickTime problems. If you activate it, Shake will dump diagnostic info about all of your system's codecs to the console.

To activate QT debug info in Shake:

1. Create a header (.h) file. The name doesn't matter; I call mine QTDebug.h.
2. Put one line in the file:

sys.printQTInfo = 1;

3. Open up the shake.app bundle (right-click, "Show Package Contents").
4. Put the file under shake.app/Contents/PlugIns/startup/ui
5. Launch Shake, create a FileIn node, and point it to a Red reference QuickTime (one of the F, H, M, or P files found in an RDC folder).

The console tab on the right (upper quadrant) will contain a list of codecs and properties. The pixel format we need for 16-bit is called "b64a"; that's why you'll see status info about it.

When you're done troubleshooting, I'd comment out the line in the header file to reduce the console spew.

Currently it does indicate that 16-bit RGB support fell out at some point. I will look into it.