
Stock Footage Usage
#1
Posted 18 April 2014 - 01:47 PM
I was wondering, do most of you use quicktimes for your stock footage or do you convert everything over to frames sequences? And if it's frames, what format do you prefer?
We somewhat in the process of converting our stock footage to frames ( and setting up an asset management system) and have been running tests, so I was curious of what other practices might be...
thanks
#2
Posted 18 April 2014 - 04:13 PM
If it's for stock footage storage, there's no harm in keeping those as QuickTime if that's the source format anyway, but you might want to develop a way to quickly export frames so there's no incentive to ever load a QuickTime in Fusion for some quick and dirty testing. Generation could probably be a great help for that.
#3
Posted 19 April 2014 - 06:52 AM
#4
Posted 19 April 2014 - 07:46 AM

i, once, did a simple render to check - a jpeg seq - about 9 min, a png - 21min... the same comp..
#5
Posted 19 April 2014 - 08:47 AM
And you can select low compression level and it will be faster
#6
Posted 19 April 2014 - 09:08 AM
For me png is always an internet file format so it just feels "wrong" to use it in comp :-) But if you're looking for a lossless 8bit file format, you can use it of course.
#7
Posted 19 April 2014 - 09:14 AM
#8
Posted 19 April 2014 - 09:20 AM
The alpha channel of png files should not be premultiplied. I think in Fusion you need to add an alphadivide before the saver in case your image has an alpha channel...
You don't need to do that, there's a Pre-Divide by Alpha checkbox in the Format tab.
For me png is always an internet file format so it just feels "wrong" to use it in comp :-) But if you're looking for a lossless 8bit file format, you can use it of course.
It can also be int16. What's nice about it is that you can save out RGBA and include the image in an email to IM to a client or collaborator and they can see your image matted and such without any special software.
If you really want to compress down for archive, you can also try something like PNGCrush. There's diminishing returns of course.
- Chad
#9
Posted 19 April 2014 - 09:25 AM
The alpha channel of png files should not be premultiplied. I think in Fusion you need to add an alphadivide before the saver in case your image has an alpha channel...
You don't need to do that, there's a Pre-Divide by Alpha checkbox in the Format tab.
thanks, I didn't know that.
#10
Posted 20 April 2014 - 01:49 PM
I have DSLR Footage and from the Blackmagic for example. Both deliver Quicktime .mov with mp4 codex and its the format for the editor/cutter, that means you have to convert all clips before and after (without Generation). Its always an efficient workflow question ....
#11
Posted 20 April 2014 - 02:36 PM
#12
Posted 21 April 2014 - 09:50 AM
- As far as we've seen, we like png for it's file size and 8 -16bit flavors, but we have noticed that it's a bit slower than say tga as far as read/write. There's also the alpha issue that Tilt mentioned. We use this in fusion, photoshop, after effects, etc... so I would hate to have to deal with sorting the alpha right in different ways for each program.
- the compressed folder won't work. I'm not looking to store/archive the footage as much as get it stored for everyday comping usage with faster access through asset management system.
- we also work in dpx as far as conversion from footage in from clients, and back to clients. I'm more referring to 8bit stock clouds, smoke , dust, fire, etc...some with alpha some with separate mattes. dpx seems unnecessarily big file size for 8 bit stock, no?
#13
Posted 21 April 2014 - 10:12 AM
edit: DPX for stock footage seems wasteful to me for 8 bit stuff. If your stock elements have been shot with a high dynamic range (any camera nowadays?) DPX is quite nice on the other hand. It's more compatible with other applications than the camera manufacturer's native file formats (R3D) and Alexa cameras would spew out dpx anyways.
One way to save space in most file formats would be to pre-process your stock footage. If it's smoke do a slight degrain and black level adjustment so most of the image is really zero. If you only need black and white for a smoke element, you could save it as an exr that only has one channel (red for example).
#14
Posted 21 April 2014 - 10:24 AM

#15
Posted 22 April 2014 - 01:11 PM
As far as exr, we would have to set up some btach system using Fu or Ae to write those out, since ffmepg doesn't encode exr from what we can tell. The file format also isn't really made for 8bit material. We would have to go 16bit with a work around like tilt mentioned to keep file size down. seems like extra work that might not be worth it in the long run.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users