Shake and RED

[Jochen Schmidt-Hambrock]

From RedCine exporting dpx into Shake should work.

But it doesn´t. In Shake´s FileIn Node I can select the dpx´s, but importing even only one of them gives me a yellow node with the very informative "Node is in Error" alert.

First time I ever tried this.....

All the best,

Jochen

[Jochen Schmidt-Hambrock]

Whupsss, got it, GOT IT!

Umlaut in the filepath.....

Jochen

[Gunleik Groven]

How do you preserve the 10 bits in shake?

Gunleik
(who've had problems with higher bitrates rendering correctly)

[Jochen Schmidt-Hambrock]

What format did you render to? (dpx, tiff...?)

Jochen
(finding his way through all this, not being able to answer your question right now)

[Steve Sherrick]

I'm curious about this too.

[Charles Angus]

How do you preserve the 10 bits in shake?

Gunleik
(who've had problems with higher bitrates rendering correctly)

As I understand it, nothing. It should figure it out.

[Stokestack]

Shake will determine the color depth in the FileIn. Downstream nodes always operate at the appropriate depth. If you read a 10-bit file, it'll be promoted to 16 bits. The status bar above the viewer shows you the color depth of your script.

Where you're likely to lose precision is in your output. Currently, greater-than-8-bit QuickTime output is broken on Intel. So render out to TIFFs or some other uncompressed format that's supported by Compressor, and use that for the time being.

Want to make sure that you're retaining the color depth you think you are (or just see the difference between various bit depths)? Use this Shake script (right-click and save):

colorDepth.shk (http://ambitiousproductions.com/public/colorDepth.shk)

1. Click on the right side of the codecTest FileOut node to put its controls in the tweaker. Press Format to pick your file format. If you're using QuickTime, press codecOptions to pick a codec. Render one frame of that FileOut.

2. Create a FileIn node and bring that one frame back in.

3. Connect the FileIn to Expand1. Click on the left end of Expand1 to put it in the viewer. Compare it to Expand2.


Does Expand1 have more banding? Then your file contains (or its codec is delivering) less than 16 bits of precision, because Ramp1 is 16-bit.

To see different precisions, set the viewer to Expand2 and click on the right end of Ramp1; then pick different settings for Bytes in the tweaker to toggle between 8-bit, 16-bit, and float.

Ramp1 has a very shallow falloff; the Expand nodes greatly amplify it (and the version of it stored in your file) to reveal loss of precision.

[P Andersson]

great script, stokestack, thanks

[Charles Angus]

Can you necessarily see more banding? What if your display is 6 bit? Or 8 bit? How many people have 10 bit displays?

Would it not be better to render a 10-bit ramp that with res 1024 and ramp from 0-100 (so one pixel is one step from 0-1024).

Render out, then bring back in; check that the brightness still brings a difference of 1 step.

That would work, no?


It's also good to be checking on what things will look like in 8 bit for eventual DVD/BD/TV delivery.

[Stokestack]

Can you necessarily see more banding? What if your display is 6 bit? Or 8 bit? How many people have 10 bit displays?

Yep, you can depend on seeing that banding. That's the purpose of the Expand nodes; they will accentuate bands to the point where they're visible on any display.

In the past I found I could see one-bit differences (in 10 or 8 bits; I can't remember) on a CRT but not on the LCD I was using at the time.

I created this script to test codecs, not to preview what various color-precision levels look like in a final image. Therefore I wanted bands that are so pronounced that I can tell at a glance what kind of precision I'm retaining through a round-trip to a file and back.

If you want to degrade a high-color script to 8 bits for preview, slap a Bytes node at the bottom and set it to 8-bit. But that's not all: Remember that your delivery medium will probably reduce your color's spatial resolution to a half (4:2:2) or, more likely, a quarter (4:2:0 or 4:1:1). So any banding will be chunkier. And then add a hearty serving of artifacts.

[Jochen Schmidt-Hambrock]

Thank you for that script, Stokestack - and your answer.

Meanwhile I´ve gone from test shots to actual shots to final cut of the project. Next steps are onlineing the original .r3d -> doing a few things in Shake -> Baselight CC -> Flame -> 2K film out.

While I´m making my way through all of this, I´ve run into another problem:

When using 32meg dpx´s (4K from RedCine), Shake is slowing to a crawl on my brand new octaMac. Somebody suggested that this is not because of Shake rendering / trying to display something, but due to the fact that Shake reads each and every dpx header - and that is not necessary.

Does anybody know how to switch that off?

Cheers,

Jochen

[dekekincaid]

Shake is very slow at dpx files. If your pipeline permits it I would look at using sgi, iff or bottom up tiff files instead of dpx. Shake can read these files as scanlines so it only opens the part of the image that it needs instead of the entire image (DOD for example).

[michael zaletel]

Greatly appreciated thanks.

-shooter