Rendering image sequence in PNG vs. TGA formats

[MARKo]

I noticed that the TGAs that Moho renders out are not compressed and are quite large. However, PNG files look just as good when you compare frame to frame. They are are also much, much smaller in size.

My question is, does anybody know of any reason not to render out to a PNG sequence as opposed to TGA? The reason I don't go with any of the other available formats is that I want to retain transparent areas so that I may composite my output in a thrid party program, such as After Effects.

Thanks!

[spasmodic_cheese]

PNG is lossless so your pretty safe!

[Lost Marble]

PNG is a lossless format, so the pixels in a PNG image are exactly as Moho created them. This is not true for JPEG. TGA is also lossless, but as you've seen, the compression in PNG gives you smaller files.

Since you wrote what your purpose is in exporting PNGs, I think I should point this out: you can also export a movie file with an alpha channel to use for compositing in After Effects. If you render out a QuickTime movie, choose a codec that offers "Millions of Colors+". The "+" is QuickTime's notation for an alpha channel. The codecs that offer this include Animation, None, PNG, TGA, and TIFF. I think it's much easier to deal with a movie with an alpha channel, rather than a whole bunch of still images.

If you prefer AVI movies, none of the built-in codecs support alpha channels. However, you can download one for free that does. It's called Huffyuv, it's lossless, and it supports alpha:

http://neuron2.net/www.math.berkeley.ed ... ffyuv.html

[Greenlaw]

Information overload time!

In my experience, when I'm rendering for compositing, it's always better to render to image sequence. There are many advantages to this over rendering to a movie file:

1. Rendering to a movie file is more memory and processor-intensive, meaning for a very heavy Moho project, rendering can be slower and more prone to crashing. (This is actually true for any animation program.) A beefy modern computer should be fine, but a lower-end computer might struggle with very heavy projects rendered at FHD or higher.

2. If the render does crash, it's easier to pick up where the render left off when rendering to an image sequence. When rendering to a movie file, this generally means you need to start over...or render to multiple movie files, which defeats the purpose of rendering to a movie file.

3. Retakes can be faster to render with an image sequence because you only need to re-render the frames that changed, not the entire thing.

4. In compositing, you have greater flexibility working with image sequence files, certainly when applying advanced techniques.

5. Tip: If you really need to render a movie file directly out from a heavy Moho project, you can render to image sequence first, load the images in a second oho Mproject, and then render the movie file. This approach can be less taxing for the computer. It's probably not necessary most of the time (Moho is actually pretty efficient in rendering,) but it's something you can do when you have trouble.

In my 25+ years of working at different animation and VFX production studios, this is how we always worked, generally for all the reasons listed above. Rendering to a movie file is typically done at the end of the compositing stage for the video editor, and then the video editor renders the final version as a movie file for distribution (broadcast, streaming, YouTube, etc.)

Regarding TGA vs PNG, I prefer PNG because the file size is significantly smaller (as Mike mentioned.) Another major advantage of PNG is that it's capable of higher bit depth than PNG (i.e., trillions of colors,) but this doesn't apply to Moho because Moho is limited to 24-bit color (millions of colors.) You'll see the difference when rendering gradients across wide areas, like skies; the lower-end rendering typically results in banding.

Also, TGA is a very old standard, and I'm not sure anybody really uses is anymore. I personally haven't used TGA since the very early 2000s.

Regarding HUFFYUV (and other movie codecs/formats,) HUFFY is another old standard. About 12 years ago, I switched to Lagarith, which was more capable and a bit more efficient for editing. (This is what I used back when I made Scareplane with Anime Studio Pro 9.) Several years ago, I switched again to MagicYUV, which has even more features than Lagarith and, unlike the other two, is still in development. By today's standard, though, none of these are great for editing or archival use because they require installing a third-party codec and may not be compatible with some modern programs. (Of the three, MagicYUV is probably the most compatible because it's supported in AVI or MOV containers.)

In the last couple of years, I switched to using ProRes because all of the programs I use on the Windows platform now support it. With more recent versions of After Effects, I use the Media Encoder option to render to ProRes 422 Standard for editorial and ProRes 444 if I need an alpha channel in an editorial (typically for chyrons and titles I plan to overlay in editing.) For my final output (my YouTube channel,) I render to ProRes 422 Standard.

Warning: ProRes files are not small, but they can withstand a high number of re-encoding passes. Also, note that 422 is visually lossless. For human eyeballs, this is good enough. ProRes 444 is lossless, but the file size is too large and impractical for my personal use. When even 422 is too big for my use, I'll fall back to HEVC (h.265,) .mp4 for final distribution. The file size is significantly smaller, it has greater color depth and accuracy than h.264, and this format can withstand at least one pass of re-encoding before degrading, which is what happens when you upload a file to a streaming service like YouTube or Vimeo.

Hope this helps.

[arglborps]

The one advantage for rendering out as movies (I use ProRes 422 HQ) instead of image sequence is that you can export the audio along with it. Then you can directly import into Final Cut Pro, no optimization needed, and it's easy to synch it with the original audio in FCP*, you can visually align it and then nudge the imported footage by single frames until the echo is gone (i.e. the two audio streams are properly aligned).

* I usually create the entire episode first as kind of a 'radio play' to make sure overall length and timing is fine and then use the exported audio from that to do lip synching etc. Then start putting in the finished animation scene by scene.