Welcome to our community

Be a part of something great, join today!

Register 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 :)

why is SHAKE so slow?

A

Alexander Somma

Active member
Joined
Jan 7, 2009
Messages
28
Reaction score
0
Points
0
I just imported some DPXs from RedAlert and shake takes forever to refresh when i skip frames.

Is it just me or is Shake incredibly slow?

How are you guys getting your red footage into shake?
 
Shake reads dpx in an old way.

Your DPX's are probably top to bottom. Shake likes them the old unix way Bottom to Top.

You can render out bottom to top in shake then reload and it will be quicker. I know.. a pain. Dont shoot the messenger.

oh and then GlueTools shows them upside down!

s
 
flameop said:
Shake reads dpx in an old way.

Your DPX's are probably top to bottom. Shake likes them the old unix way Bottom to Top.

You can render out bottom to top in shake then reload and it will be quicker. I know.. a pain. Dont shoot the messenger.

oh and then GlueTools shows them upside down!

s
Click to expand...

What kind of storage are you connected to for your frames?
 
I noticed a huge increase in Shake performance when I increased disk speed. Run the AJA disk speed utility and see what you're getting.

If disk speed is your issue, render out all your shots as 100% jpegs with the same name as the dpxs (except with .jpg instead of .dpx). This is fine for most things except tracking, etc. and will lower your disk throughput by a lot.

Also, use proxy's a lot. It's the little button in the top right that says "Base". You can go to P1, P2, and P3, which are all lower quality preview options.
 
Are you working with 4k DPX? These will always be slow, although changing Shake's cache allocation (in a custom .h file) will help a bit. Also use Shake's proxy settings to work at half or quarter resolution when possible.
 
Thank you all for helping out!

You can render out bottom to top in shake then reload and it will be quicker. I know.. a pain. Dont shoot the messenger.
Is this the only way? To re-render all my dpx's again from shake?
Can you explain this bottom to top thing for me? Does that go for tiffs aswell?

What kind of storage are you connected to for your frames?
Im using 3 striped disks.

If you have an 8-core machine, make sure to set max threads to 4 instead of 8.
I have an 8-core machine, and I've tried setting it to 4 cores in shake globals. It helps a little but its still way to slow to work with.

Run the AJA disk speed utility and see what you're getting.
Write: 111 MB/s
Read: 144 MB/s
Is this good enough for 4K dpx?

use your proxies to speed up your workflow.
To use proxies i just set the button in the top right to P1,P2 or P3 right?
I can see the image quality gets worse, but it doesnt change the performance at all. Could I be doing something wrong?

Are you working with 4k DPX? These will always be slow, although changing Shake's cache allocation (in a custom .h file) will help a bit. Also use Shake's proxy settings to work at half or quarter resolution when possible.
Yes I am working with 4K DPX. But 2K was almost just as slow. How do i change the cache allocation. I was thinking... where does shake cache by default? on the system drive? Because my system drive is not fast at all...

Like I said, I find an offline-online workflow is great when storage speed is an issue. For roto work, etc. a 100% JPEG is totally sufficient.
I was planning to key and comp the greenscreen shots in 4K DPX and then scale down to 2K to get the best possible greenscreen results.
 
Alexander Somma said:
Are you working with 4k DPX? These will always be slow, although changing Shake's cache allocation (in a custom .h file) will help a bit. Also use Shake's proxy settings to work at half or quarter resolution when possible.
Yes I am working with 4K DPX. But 2K was almost just as slow. How do i change the cache allocation. I was thinking... where does shake cache by default? on the system drive? Because my system drive is not fast at all...
Click to expand...

Shake caches by default in /var/tmp/Shake/cache/ wich is obviously on the system drive. Read up in the Shake manual under 'Customising Shake' about creating a .h file to customise settings.

Alexander Somma said:
Like I said, I find an offline-online workflow is great when storage speed is an issue. For roto work, etc. a 100% JPEG is totally sufficient.
I was planning to key and comp the greenscreen shots in 4K DPX and then scale down to 2K to get the best possible greenscreen results.
Click to expand...

This approach is theoretically best, but I have found that 2k DPX files generated from a 4k deBayer are very clean and key extremely well. Test, and if it works for you, then there is no need to tax your machine with 4k DPXs. You can also try 3k DPXs as a compromise, as don't forget there is not 4k of 'real' RGB resolution in the deBayered DPX.
 
Alexander Somma said:
Run the AJA disk speed utility and see what you're getting.
Write: 111 MB/s
Read: 144 MB/s
Is this good enough for 4K dpx?
Click to expand...

With a single layer -and no downstream filters/fx applied, you should probably be getting a few frames per second in playback performance.
When you move the "playhead" around, the new frame should load/cache pretty quickly - probably less than a second.

Realtime 4K DPX playback requires at least 850MB/s sustained disc read performance.

Of course, you don't need realtime playback for simple compositing (or for simple frame processing for RED footage) but if you are working with multi-layer comps, your interactivity will slow to a crawl very quickly unless you have TONS more disc bandwidth than what you have currently.
 
BOXXLabs said:
When you move the "playhead" around, the new frame should load/cache pretty quickly - probably less than a second.
Click to expand...

Thats what I expected, but every time I move the playhead, it takes like 5 seconds before the frame changes.
 
Well, I just tried some 4k DPX's of noise in my Shake system, which is similar to yours (4 core Mac Pro, 177 MB/s write, 204 MB/s read). My mileage is about what I expected - anywhere from a fraction of a second (say .2 to .3 seconds) to a second or two to load a frame, depending on what the disk is already doing.

These DPXs were 27 MB - is that about how big yours are?

Also, how much RAM do you have? I only have 2 GB, which seems to be fine for Shake most of the time, but I think less would be a problem.
 
Oh and just to make sure - your playback issue is with no filters or viewer LUTs or anything applied, right? You just file in, and watch, and you have this issue.

Because I would expect most apps to be slow applying effects to 4k plates, especially if there is more than one 4k filein, or RAM is low.
 
I have 4 gigs of ram. The 4k dpx's are 32 mb I think. I dont have any other software started and yes I'm only doing a file in.

Are you guys using bottom to top or top to bottom? Do you export the DPX's from redcine or red alert?

Are you using anything other than DPX in shake?


Anyways.. I started testing in after effects. seems MUCH faster.
 
You must log in or register to reply here.
Back
Top