By Beam Tracer (Beamtracer) (203.109.241.109) on Tuesday, January 14, 2003 - 06:34 pm:

When you create a Quicktime movie, you can select a variety of codecs. Some have small file sizes at the expense of vision quality (like Cinepak, Sorenson, MPEG-4), while others have no quality loss but larger file sizes, like the Animation codec.

Microcosm is a relatively new codec, which you must acquire from, and pay a fee to Digital Anarchy to use:
http://www.digitalanarchy.com/product_micro.html
It is free to use the Microcosm codec to read files. There is also a demo version on their website which puts a cross through the image.

Like the Animation codec, Microcosm is also lossless, so it is great tp use for your master copies. The first difference between Microcosm and Animation (apart from the fee) is that Quicktime movies in Microcosm format are only 25% the size of those in Animation format.

This means you only need 25% of the hard drive space, and may mean you can delay the purchase of a new hard drive. It also means you can spend less on storage media like CDs and DVDs to store your animations. It often lets you burn your entire animation to a single CD-ROM, when it might previously have been necessary to segment the Quicktime across 4 CD-ROMs in Animation codec.

The other major difference between the Animation and Microcosm codecs is that Microcosm has the option to work in 64-bit mode (16 bits-per channel). This makes it very useful for video and film work.

Lightwave will happily render a 32-bit (8bpc) movie to the Microcosm codec, so you can take advantage of the smaller file sizes. However, Lightwave currently does not support 64-bit Quicktime codecs. I hope that the next revision of Lightwave will provide support for 64-bit Quicktime codecs. Anyone who would like this as a feature should contact Newtek and let them know, or use the Feature Request section on these forums.

The work-around is to render to a 64-bit Photoshop sequence from Lightwave, then use After Effects to translate it to a Microcosm Quicktime. After Effects supports 64-bit Quicktime codecs. The dramatic reduction in file size (without losing any image quality) is incentive enough to do it this way. The Microcosm Quicktime is a tiny fraction of the size of the PSD sequence.

By Dan Everson (Theosmekhanes) (66.126.123.6) on Tuesday, January 14, 2003 - 07:31 pm:

yee haaaw!

I'm really happy about this codec. In my test it does seem to take a bit longer to encode and decode but the storage gained is worth it.

I wonder if this codec is AltiVec enabled, and if it could get a bit faster with time.

I have not paid for it yet so I have only tested the 8bit per channel mode.

Do you have any real world experience with this Beam Tracer?

I would buy it today, but I wonder if Apple will ever offer anything like this built into QT. After all they are pressing into the HD and Digital Film post markets.

Realtime MPG4 based HD codec anyone?

By Beam Tracer (Beamtracer) (203.109.241.109) on Tuesday, January 14, 2003 - 08:48 pm:

Yes, I'm using Microcosm all the time. Often, when you create an animation, you do it in multiple layers so you can composit it later. This produces massive file sizes, so Microcosm is really handy.

It's not the fastest at playback performance, but that is not what I need anyway. I can always use the RAM preview function in After Effects if I want real time playback (it plays out of RAM rather than off the hard drive).

Quicktime can be at any resolution, whatever the codec, so it's already used for HDTV... not that there's much of that in the U.S. yet. There is a lot of standard definition widescreen (16:9) production, which is where I'm using Quicktime with Microcosm.

MPEG-4 is great for use of the web or CD-ROM or anywhere where bandwidth is a limitation. MPEG-4 is not a good format to make your master on, as it is a lossy codec.

Apple's Animation codec is getting a bit long in the tooth these days. The file sizes are too big. I've got no idea if Apple will replace it in years to come, but there certainly is a need for smaller file sizes while retaining full image quality.

By Chris W. (Chriswork) (24.123.214.36) on Wednesday, January 15, 2003 - 07:11 am:

Rendering directly to quicktime format is kind of dangerous IMO. If your render tanks you have to start over again, whereas rendering to frames you don't.

I prefer to render out to tiff files and then use Cleaner to transcode them into Microcosm at full size and at the same time a proxy version at half size using the animation codec. When the transcode is done I dump the tiffs.

You may not get the immediate (space saving) benefits of the Codec this way, but you can speed your renders and have a safety if problems occur.

This gives me the benefits of the quality the codec produces, but also allows me to maximize my display speed in AE.

In terms of file size savings using the codec, it's pretty impressive.

I'm working on a gig now where the film was transfered to .tiff sequences (2K resolution) and takes up roughly 130GIG.

The Microcosm transcoded quicktime movies (at the same res) add up to 75GIG, and there is no noticeable difference between the two.

Even if you're only going to use it to help you archive your work more efficiently it's woth the $99 IMO.

By Daryl Cornutt (Dfc) (24.90.251.91) on Wednesday, January 15, 2003 - 11:20 am:

If your rendering a QT movie out of LW and it tanks at frame XXXX...there is no "need" for you to start over. Why would you have to do that?

simply tell lightwave to render QT file starting at frame XXXX. Then take the 2 clips..your first one..and the 2nd one..and butt end them in your video app. It's the same process whether your rendering single frame or video. When the render tanks on a QT movie..it doesn't erase what was rendered prior.

You only have to pick up from where you left off.

At least..that's how I do it.

By Beam Tracer (Beamtracer) (203.109.241.109) on Wednesday, January 15, 2003 - 02:27 pm:

Rendering to image sequences provides safety. However, don't forget that you can render to both a Quicktime and a sequence in Lightwave.

After the render is over, you can check that the Quicktime is OK. If it is, you erase the image sequence. This saves you the effort of creating a Quicktime in your compositing application.

By Chris W. (Chriswork) (24.123.214.36) on Thursday, January 16, 2003 - 07:51 am:

Hmmm. For me, when a render to quicktime quits mid-stream the file is turncated, and can't be accessed by players.

How are you taking a quicktime file that isn't complete and get it to read into qt player?

By Dan Everson (Theosmekhanes) (66.126.123.6) on Thursday, January 16, 2003 - 12:18 pm:

Yup, uh huh.

This sounds like superstition to me.

First, LW is the only App that craps out on rendering. It is also LW's crappy QT support that causes the file corruption.
I have never had that problem with QT rendered out of AE. It simply cuts the file at the stopping point and trims the project to continue from that point. The clips are then assembled in FCP.

The use of sequence.#_files is barbaric. Stop the insanity!!

"Crap"

By Beam Tracer (Beamtracer) (203.109.241.109) on Thursday, January 16, 2003 - 02:53 pm:

I wouldn't call it barbaric. I'd just like the same options available for Quicktime as with image sequences... 64-bit option, same alpha channel options, bug-free performance when rendering to frame rates other than 30fps.

I've had professional people claim to me that newer versions of Quicktime will save a useable file, even if the machine crashes. My personal experience is that this isn't so. I think Quicktime still needs to write an "end of file" flag or the file will be corrupted.

Regardless, Quicktime is much easier to deal with after the render than image sequences. The new codecs are much more efficient than any compression found in image files (not that you get the option for LZW compression with TIFF files anyway). Do people really waste disk space by archiving image sequences?

Having the option to render to QT simultaneously as to an image sequence saves you having to go to another application to convert your sequences and saves you time.

By Beam Tracer (Beamtracer) (203.109.241.109) on Monday, February 03, 2003 - 06:12 pm:

FEATURE REQUEST.

On the Lightwave 'Feature Request' forum, I have posted a request for Lightwave to support '64-bit' (16bpc) Quicktime codecs, such as Microcosm.

This enables an efficient workflow between After Effects and Lightwave. It's not only a rendering issue, so don't forget this feature would allow the importation of Quicktimes from After Effects to Lightwave, without having to reduce the depth before Lightwave can import it.

If you feel that Lightwave's abitity to handle 64-bit Quicktime codecs is an important feature you think should be included, please post a message on the thread (linked below) in the feature request section:
http://forums.newtek.com/discus/messages/2/36681.html?1044317115

By kenneth woodruff (Kenneth) (12.236.254.153) on Tuesday, February 04, 2003 - 11:25 am:

"LW is the only App that craps out on rendering."

I don't think we live in the same world. =)

By ted devlin (Eblue) (12.149.3.2) on Tuesday, February 04, 2003 - 12:38 pm:

kenneth,
so, you're saying that there's other programs crap out on renders?
couldn't help it, one good turn... and all that ;)

it is a good point that LW has spotty Quicktime support. PC and Mac.
i don't render in Quicktime, because it is compromised by issues like the one mentioned, this is just one of many little gotchas that whittle away at the advertised list of features in LW. I haven't launched into an email client to let newtek know this because... everybody knows this. But, I keep hearing "nobody's complaining" in all the wrong places. we're not complaining bc we trust newtek is doing something about the obvious problems. Or worse, we don't expect to be listened too.

lets do one release, just one release where features are put on the back burner, and the app is re-written to address:
design/interface flaws,
bugs,
tightening the various pieces of the app (Lscript, MD, and Particle FX to name a few),
and platform specific integration/acceleration issues.

fix the problems/bugs. That should already be the first priority, but it isn't.

By Ted Lee (Tedlee) (66.156.19.41) on Tuesday, February 04, 2003 - 02:56 pm:

I agree. Newtek needs a time out in the feature race to address some core issues...

1. Platform Parity in features and performance
2. Bug Fixes!
3. More Bug Fixes
4. UI overhauled where needed.
5. Even more Bug Fixes!
6. Re-write the manuals, and test them on someone who is completely new to LW to see if they understand half of what is being discussed.

Don't get me wrong, I love LW... But I'd be lying if I said it didn't need improvements in the above areas...

By Michael Linde (Mlinde) (4.64.198.19) on Wednesday, February 05, 2003 - 01:06 pm:

For those of you who output color-perfect, z-depth perfect, no-edit animations, I guess rendering to Quicktime is a need. In my production workflow, I find it easier to render to sequential stills. Here are my reasons:

1) Edits/corrections. My client decides that the animated character in frames 1500-2100 should be blue-skinned, not green. If I'm in QT land, I have to (a) re-render the entire sequence, or (b) render a second movie, bring it into an editor, cut and paste (and hope I am right on the frame counts). If I work with sequential stills, I render a new set of image, and my compositor links up to them seamlessly.

2) Color correction. I must be color-weak, because often my lovely computer-viewed animations look like !@#$ on the TV monitor. Some parts are fine, others are terrible. Sure QT has some color correction, and sure, I can color correct a QT movie in my compositor. But what if I just want to CC a segment that's too hot? Easier with image sequences.

3) DOF games. I like tweaking DOF, and if I output to QT, I can't tweak on the fly. If I ouput to image sequences, I have access to the z-buffer, and can play with DOF to my hearts content.

4) multi-pass/layered renderings. Show me the joy of rendering 4 or 5 QT movies and compositing them in various ways to get different FX. I'll show you the joy of using an image saver, and outputting a separate alpha file I can use or not, I can output multiple color versions, all in the same render. Compositing is an advantage, not a chore.

I think QT is a good tool for "proof" renders, when I'm working on motions, or lighting FX specific to the animation, but I don't consider it the best choice for final output. And I've had programs other than LW crash and kill QT movies, so the "LW's crappy QT support that causes the file corruption" is crap itself.

On the original topic, Microcosm, the codec sounds cool. I'll check it out...

By Beam Tracer (Beamtracer) (203.109.241.109) on Wednesday, February 05, 2003 - 02:31 pm:

The intention of this thread wasn't to justify whether or not we should use Quicktime. The aim was to alert people to the fact that there is a new, more efficient, Quicktime codec, and that Lightwave should be able to read and write any 16bpc ('64-bit') Quicktime codecs. Currently we cannot use 16bpc Quicktime codecs with Lightwave.

There's more discussion on the "Feature Request" thread linked to above. Anyone who wants to let Newtek know that they would like to have the option to use 16bpc QT codecs in Lightwave should let their voice be heard on that thread.

The issue is input-output, not just rendering. Lightwave has some compositing features that some compositing apps don't. Say you've already acquired a movie file, but you want to run it though Lightwave to take advantage of a particular Lightwave filter that may not exist on your compositing app. For example, Bloom and Corona. You could set your existing QT movie to be the backdrop, and then apply the Corona filter to this. You should be able to load your QT movie directly into Lightwave without having to unnecessarily convert it to an image sequence, or reduce its bit-depth. Using a filter like Corona with an 8bpc file format is guaranteed to create unwanted artifacts.