Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Shake and RED

Jochen Schmidt-Hambrock

Jochen Schmidt-Hambrock

Well-known member
Joined
Dec 31, 2006
Messages
1,085
Reaction score
0
Points
0
Location
South of Munich, Germany
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
 
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

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.
 
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.
 
AngusChandler said:
Can you necessarily see more banding? What if your display is 6 bit? Or 8 bit? How many people have 10 bit displays?
Click to expand...

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.
 
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
 
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).
 
You must log in or register to reply here.
Back
Top