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?
|
|
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
If you have an 8-core machine, make sure to set max threads to 4 instead of 8.
-shooter
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.
use your proxies to speed up your workflow. 4k, 2k, 1080p DPX files are quite system intensive in full resolution.
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.
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.
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.
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.
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.
| « Previous Thread | Next Thread » |