best image type for AE?

[m|3]

Targa (.tga) at 32 bit.

You can't go wrong with that one assuming your source was of a high enough quality.

[scrimski]

Use Tiff or Targa, avoid gif and jpeg.

[ZephyrStar]

TGA without a doubt. can handle alpha, 32 bit, can also be compressed (but I don't ever). If you're rendering from a 3d program and don't have anything higher end to composite with, (combustion, digital fusion) then TGA should work just fine.

Hope this helps!

Cheers

Chris

[davezak]

m|3, scrimski & zephyrstar, i humbly take your advice :thumbsup:

once again cg talk comes through.

TGA it is!

[Kraa]

High resolution jpegs could be used sometimes, but i have never ever used any gifs.

[Significant]

I always use .PNG. Same as .tga but with much better compression. Give it a try!

[beenyweenies]

What is the best type of image file to import for use in After Effects in your opinion?

My Jpegs turn out looking prety low quality.

the cleanest one, prefferably with transparencies. gif or png ?
thx,

As stated TGA's are a good bet, but a lot of film studios are starting to use PNGs since the compression is excellent and it reduces disc space requirements considerably.

[Khalor]

I thought this was useful, so I'm reposting. Be warned, it's long. If you don't want to read it, the conclusion is PNG is the way to go.

Originally compiled by Ryan Wieber of 'Ryan vs Dorkman' fame:
A major factor that prompted this experiment was the recent discovery that PCs without an editor specifically equipped to handle HVCproHD footage cannot read it. And Nobody seems to be providing it for free. With our new HVX200 purchased for RvD2, this essentially means that we can capture via Final Cut and have nice HD footage to play with, but there is no way to simply take those files onto my PC and work on them in After Effects. Which blows. This means we have to export into some other format that can be read by both platforms, to work with. Well, the question then becomes, what format?

Image sequences are almost always used in "the industry" as opposed to video files, for a variety of reasons that to be honest I'm not fully aware of. One factor is that if there is some corruption or data loss, you don't loose an entire video file, you loose however many image files were compromised, and you can quickly and easily re-render them back into the sequence. I suspect there are also compatibility benefits to image sequences as well. Plus, if you ever want a screengrab, just copy one of the images. Woo.

Anyway, I conducted two tests.

The first test was to take a 119-frame HD (1920x1080) shot, and export it as a bunch of (allegedly) lossless codecs and compare the filesizes to see which compressed better and worse. Here were my results:

Uncompressed AVI
No compression.
705 MB
Not an image sequence, but a basis for comparison.

BMP
Set to the "Windows" file format, as opposed to OS2. It only allowed export in 24 bit mode.
705 MB
I would guess there is no compression happening at all here.

PNG
The settings offer the option of interlacing, which I did not do. I didn't even notice at the time, but by default this format was set to "Trillions of colors"
941 MB
I was suprised to find the filesize of the sequence actually jumped up instead of down. A long time ago I had done some experiments with PNGs before and had the impression that they were very good. This puzzled me. Also, exporting as PNGs with these settings took nearly 20 minutes, while all the rest took between one and two.

TIFF
24 bit, with "IBM PC Byte Order" enabled.
706 MB
Larger by one meg. I was beginning to wonder if any of these actually compressed.

TIFF
24 bit, with "LZW Compression" enabled.
680 MB
Alright, some improvement. At least better than an uncompressed AVI.

TIFF
24 bit, both "LZW Compression" and "IBM PC Byte Order" enabled.
680
No improvement over just using LZW alone.

TGA
24 bit, with RLE (run-length encoding) compression.
707 MB
Larger by about 2 megs. A bit disappointing, but then I realized that the bit-depth in my project is 16, and so is the footage. 24 bit may be an excessively vast color space for this (and most kinds of) footage, if that mattered. Well, let's find out.

TGA
16 bit, with RLE compression.
472 MB
Aha! Significantly smaller. Could this be the best image format to use?

It was at this point that I decided to confirm the authenticity of the losslessness. Here's how. I brought the image sequence into After Effects and laid it on top of the original footage. So we theoretically have 2 frame-for-frame pixel-for-pixel identical layers, just different file formats. I set the top one to "difference" mode, which theoretically will produce a perfectly pure black image, as there should be no difference between the pixels, and thus be represented as a pixel with zero color information. To help accentuate any inconsistencies there may be, I created an adjustment layer above it with a Levels filter on which stretched the image so extremely that a pixel with even the slightest bit of luminance or chrominance pops out and becomes apparent.

For the 16-bit TGA, there was an apparent residual image during this test. In the form of a very apparent noise/grain pattern, I could see the image, meaning that there was a difference between the two. This is not lossless! Bummer. I even compared the images by just looking at them normally and switching the top on and off. There was a visually detectable difference in saturation and the shadows. Please note that the 24 bit TGAs did not have this deterioration.

I decided to try this difference test with the other formats as well. To my surprise, under the extreme scrutiny of my adjustment layer, all of them exhibit an extremely small amount of uniform noise. I then tried duplicating the original layer itself and using it as the difference layer, which is the only one that produced absolutely no difference.

I would hypothesize, though, that the rest of the formats (which exhibited the very small amount of noise) do not actually suffer from inconsistency from the original. Instead, I'm guessing that this is super-tiny differences in how After Effects is rendering each pixel (probably sub-pixel stuff) which is being magnified excessively by my adjustment layer. Please understand that to actually see this noise, I'm blowing out the image so severely that about 1% brightness becomes pure white. I'm working under the assumption that this small bit of noise is unavoidable and will occur even between images that are truly identical, and can therefore be ignored as it is merely a quirk of After Effects. There was a distinctly different (and much more noticeable) difference image created by the 16-bit TGA, indicating that it actually was lossy.

So then I realized there was one more thing I didn't try:

PNG
"Millions of colors" (as opposed to Trillions, which was the default)
363 MB
Almost half the size of the original file! I immediately ran it though the difference test to see if it was too good to be true. Success! It exhibited no noise in addition to the base difference noise found in all lossless versions.

PNGs in Millions of colors: Pixel-for-pixel 100% lossless sequence, at half the total diskspace of an uncompressed AVI (and most of the rest of the lossless image sequences). Fantastic!

Now, I said I conducted two tests.

The footage used in the first test(s) was some of the most difficult I could find, from a compression standpoint. It had a lot of out-of focus soft gradients to deal with, and it was extremely grainy, making run-length encoding very difficult (I would assume). For the second test, I wanted to give the codecs something easier to work with. So for this one, I took 50 frames from that footage and shrunk to 50%, and left it sitting inside a bunch of black space. The total dimensions of the video was still 1920x1080. This might approximate some title sequences (which are mostly black space), or an extreme example of what might happen if working with letterboxed video.

Here's what I found:

Uncompressed AVI
No compression.
300 MB
Again, a baseline for comparison.

BMP
"Windows", 24 bit.
296 MB
No real improvement.

TGA
24 bit, with RLE (run-length encoding) compression.
101 MB
Now we're getting somewhere. While this format and settings produced a slightly larger filesize in the scenario before, the run-length encoding really gets a chance to shine now, producing a filesize about 1/3 as big as the original.

TIFF
24 bit, with "LZW Compression" enabled.
80 MB
Even smaller. Much improved compression ratio over it's results in the last scenario.

PNG
"Millions of colors"
43 MB
Less than 1/6 the size of the original file! Even more dramatic results than it's victory in the last scenario.

So, in both cases the clear victor is:

PNG image sequence
Set to "Millions of colors"

Which, according to these tests I was playing with, can generally produce filesize savings of roughly 50% and up. Who knows how small you might be able to get the sizes on something like a credit sequence with only 2 colors for it's compression to handle, especially if you could manually set the colors to less than "millions" and get away with it.

So for all kinds of video, including everyday footage that you just need to save losslessly, this format of image sequence is going to save you the most disk space... in some cases, by far. At least, that's my findings.

[parallax]

I'm sorry, but any manual could have told you that. Besides, has he taken in account render time and CPU usage? IMO it is not written that professionally, or tested for that matter.
I don't deny the effectiveness of PNG compression, but not in all cases is it the defacto codec for lossless image sequences. Furthermore, it's DVCPro HD not HVCPro HD (but that could've been a typo) and he could've know that compressing it to trillions of colors is useless, before actually rendering it out in a format that is useless with 8-bits material.
The noise apparent in TGA's can have 10 different reasons, for one, field shift.
One last thing: Quicktime's can be rendered with PNG compression, there is no need in using sequences in every possible case. Sequences can be quite a hassle.

[davezak]

I thought this was useful, so I'm reposting. Be warned, it's long. If you don't want to read it, the conclusion is PNG is the way to go.

Originally compiled by Ryan Wieber of 'Ryan vs Dorkman' fame:

PNG does seem to have the advantage. i used tga all last night and was very happy with results.

file size issues sell PNG. I remember learning that they were best for flash as well..

khalor thats a keeper.
beenyweenies good to hear from you again!
thx significant & parallaw :thumbsup:

[beenyweenies]

I'm sorry, but any manual could have told you that. Besides, has he taken in account render time and CPU usage? IMO it is not written that professionally, or tested for that matter.
I don't deny the effectiveness of PNG compression, but not in all cases is it the defacto codec for lossless image sequences. Furthermore, it's DVCPro HD not HVCPro HD (but that could've been a typo) and he could've know that compressing it to trillions of colors is useless, before actually rendering it out in a format that is useless with 8-bits material.
The noise apparent in TGA's can have 10 different reasons, for one, field shift.
One last thing: Quicktime's can be rendered with PNG compression, there is no need in using sequences in every possible case. Sequences can be quite a hassle.

I don't know what manual goes into the details of PNG usage and file size, but I suppose maybe some research could have turned up this same information. I'm glad the author saved me the time and hassle, though! Also, I don't think the author was even remotely trying to imply that PNG is "the defacto codec" for anything, just that it appeared to be better. I've used it on 2 feature films, to great success. If it can work on a hollywood release, it's useful for broadcast without a doubt.

Part of what's so great about PNG is that it's a good choice for web, print, Flash, video, film etc. which makes it the single most versatile format available, and is near universal in terms of accessability and playback. Add to that the excellent compression and again, I see it as a winner.

I can't speak for rendering PNGs out of Final Cut Pro, but when rendering them out of AE on a dual-core box, I see little difference in render times, if any. Besides, if you want to be practical about it, you have to weigh the issue - cost of render time vs. cost of disc space. Render time could be more expensive, but then again when you factor in backup space, primary storage etc. you may see little difference on the cost front.

[davezak]

PNG all the way :thumbsup:

[jussing]

...but that's just me. :)

If you want to color correct your input heavily, such as multiplying light passes with texture passes, you can not, ever (until Adobe fixes it, that is ;) ), work with premultiplied alpha channels in After Effects (because its alpha calculations stink), you will need un-premultiplied alphas. And in 3ds Max, as far as I know, the only format that has the option to disable premultiplication with alpha, is TGA. So, I use TGA.

(if PNG has some advantage here, like being natively unpremultiplied, then I just don't know about it yet :) )

- Jonas

[beenyweenies]

...but that's just me. :)

If you want to color correct your input heavily, such as multiplying light passes with texture passes, you can not, ever (until Adobe fixes it, that is ;) ), work with premultiplied alpha channels in After Effects (because its alpha calculations stink), you will need un-premultiplied alphas. And in 3ds Max, as far as I know, the only format that has the option to disable premultiplication with alpha, is TGA. So, I use TGA.

(if PNG has some advantage here, like being natively unpremultiplied, then I just don't know about it yet :) )

- Jonas

The alpha channel in PNGs is, in fact, straight and not premultiplied. PNG wins! ;)

[jussing]

Haha, dammit. :) OK, I'll have to try it out, then.

But what about the imfamous PNG gamma problem?

http://hsivonen.iki.fi/png-gamma/
http://www.i-marco.nl/weblog/pivot/entry.php?id=186
http://annevankesteren.nl/2004/07/png-gamma
http://user.fundy.net/morris/?photoshop03.shtml

Most of these links regard browsers, but the problem is also present in other applications. A PNG will not look the same in different apps.

- Jonas

[beenyweenies]

Haha, dammit. :) OK, I'll have to try it out, then.

But what about the imfamous PNG gamma problem?

http://hsivonen.iki.fi/png-gamma/
http://www.i-marco.nl/weblog/pivot/entry.php?id=186
http://annevankesteren.nl/2004/07/png-gamma
http://user.fundy.net/morris/?photoshop03.shtml

Most of these links regard browsers, but the problem is also present in other applications. A PNG will not look the same in different apps.

- Jonas

While I have read about this, I've done a lot of web design in my day and never encountered it, and I've never heard of it being an issue outside of web design. That doesn't mean it isn't an issue, just one I've never encountered and I use PNGs very often.

For a motion graphics, post or film facility, this isn't really an issue at all since they have total control over their own setups. Because gamma issues affect every aspect of production, not just PNGs, any respectable facility should have this totally under control or they will have big problems! Careful calibration and facility standards should make gamma concerns a non-issue. In short, if a production facility is experiencing problems with PNG gamma they are probably experiencing it with other files/file types as well.

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.