15 replies to this topic

[French_Fry]

Hey guys,
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

[SecondMan]

Never ever do I use QuickTime for anything during actual production. I typically use EXR for everything now, although TGA is still an old favourite for 8 bit stuff.

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.

[Ater]

Why TGA and not PNG for "8 bit stuff"? I know that TGA is commonly used, but why?

[xmare]

png is SLOOOOOW to compress and decompress
i, once, did a simple render to check - a jpeg seq - about 9 min, a png - 21min... the same comp..

[Ater]

With slow compress I agree, but didn't notice slow decompress...

And you can select low compression level and it will be faster

[Tilt]

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 and then in the Loader you need to select "Post-Multiply by Alpha". If you're just staying inside Fusion this might not be necessary but it's really important if you intend to use those PNGs in Photoshop for example.

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.

[ChadCapeland]

You can also store the sequences in compressed folders. If you don't expect to use the footage often, just zip them up into an archive format that you think will be relatively easy to decompress later.

[ChadCapeland]

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

[Tilt]

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.

[Eagle1]

Interesting, so what is now the best format for work in Fusion for comp?

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 ....

[Yuri V. Nemets]

We're working with DPX, no matter where did the material came from. First stage - editing in FCP, second - DaVinci, third - FlatPass out of DaVinci in DPX.

[French_Fry]

Cool! Thanks for all the feedback!

• 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?

I was wondering if there were some flavors of jpeg2000 that would work..one of those jp2 or j2k . We done a few tests, and specs are looking good as far as bit depth, file size, etc... we haven't test read/write speed yet. But I'm also worried about compatibility with our different software apps.

[Tilt]

TGA has only run-length encoding as a compression scheme so it'll be almost useless for grainy/noisy stock footage. Have you tested exr? If you've expanded your search to lossy formats (jpeg 2000), have you tried wavelet compression in exr?

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).

[French_Fry]

we haven't tried exr yet. we couldn't get ffmepg to kick those out for some reason. But that is on our list to-do. Thanks!

[French_Fry]

So right now, we're really liking png format. The alpha encoding hasn't seemed to be a problem on what we've tested. They do encode slow, but the decoding isn't as slow I first thought. We've been playing with pngcrush and some of those encoders ( pnggauntlet and pngwolf). They're really really slow in encoding (which is fine because we can batch things) but seem to decode rather fast, faster than any other format beside jpeg. I'm sure part of that is due to the small size. We'll keep doing some tests to see.

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.