VFX workflow: avoiding colour-space conversions and re-compression at DVinfo.net

Steven White · March 16th, 2005, 12:33 PM

After reading Xander's comments in this thread:

http://www.dvinfo.net/conf/showthread.php?s=&threadid=40978

I'm curious about maintaining as much data as is physically possible for compositing efforts. I figure the best way to do this is render *.m2t files to uncompressed video files.

I've read that Huffyuv does a colourspace conversion, and should therefore be avoided in such instances... but I was curious how to ensure I don't do a colourspace conversion out of After Effects when rendering to an uncompressed digital intermediate.

Xander Christ · March 19th, 2005, 09:42 PM

Just about every codec out there is designed for standard definition's color space being that it is still the "standard". I read somewhere that 90% of the US is still watching SDTV, so what's the incentive for software developers to change the codecs? As of today, zilch; distribution of HD content is still SD-broadcast or SD-DVDs. Only a few select channels broadcast in true HD; most channels are uprezzing their SD content for digital broadcast (grrrr... I can't believe I pay extra for digital cable for the 5 HD channels I get!!!)

I've rendered a number of m2t scenes into different codecs trying to find the "right one" and still nothing beats uncompressed AVI or uncompressed QuickTime. Granted, the uncompressed footage is now 8-bit RGB and not 8-bit ITU-701, but since the RGB colorspace is larger than ITU-701, no "conversion" of color is necessary. All the color data stays intact.

I bought a 1.6TB RAID last week which helps editing uncompressed HDV a whole lot. I can't play it in realtime (drops frames like crazy!!), but the visual effects sequences I'm working on are much cleaner in uncompressed space than footage that's been compressed with "lossless" codecs (I go frame-by-frame anyway, so real-time playback isn't essential). Loading and saving times are significant with uncompressed footage, but the quality gained from it is truely worth the wait.

If you want to ensure your AE files are not going through a color space conversion, always work with uncompressed files and render your files with the uncompressed codec. Just a side note: AE can't handle native m2t/HDV files, you'll have to uncompress the footage anyway.

Mark Kubat · March 21st, 2005, 11:35 PM

export as targa sequence....

Steven White · March 22nd, 2005, 09:08 AM

AE can't handle native m2t/HDV files, you'll have to uncompress the footage anyway.

Not quite true - technically it can handle them, but the render times to decompress are rediculously large. In order to make my rotoscoping workflow even possible I had to render to uncompressed anyway.

Is there any advantage to a *.tga sequence over an uncompressed avi? I get the sense that an uncompressed avi is equivalent to a *.bmp sequence, with the exception that it can store alpha-channel information, but doesn't keep the audio.

March 16th, 2005, 12:33 PM	#1
Steven White Major Player Join Date: Nov 2004 Location: Canada Posts: 547	VFX workflow: avoiding colour-space conversions and re-compression After reading Xander's comments in this thread: http://www.dvinfo.net/conf/showthread.php?s=&threadid=40978 I'm curious about maintaining as much data as is physically possible for compositing efforts. I figure the best way to do this is render *.m2t files to uncompressed video files. I've read that Huffyuv does a colourspace conversion, and should therefore be avoided in such instances... but I was curious how to ensure I don't do a colourspace conversion out of After Effects when rendering to an uncompressed digital intermediate.

March 21st, 2005, 11:35 PM	#3
Mark Kubat Major Player Join Date: Jan 2003 Location: Toronto, Canada Posts: 375	Targa sequence... export as targa sequence....

March 19th, 2005, 09:42 PM	#2
Xander Christ Regular Crew Join Date: Jul 2004 Location: Minneapolis, MN Posts: 115	Just about every codec out there is designed for standard definition's color space being that it is still the "standard". I read somewhere that 90% of the US is still watching SDTV, so what's the incentive for software developers to change the codecs? As of today, zilch; distribution of HD content is still SD-broadcast or SD-DVDs. Only a few select channels broadcast in true HD; most channels are uprezzing their SD content for digital broadcast (grrrr... I can't believe I pay extra for digital cable for the 5 HD channels I get!!!) I've rendered a number of m2t scenes into different codecs trying to find the "right one" and still nothing beats uncompressed AVI or uncompressed QuickTime. Granted, the uncompressed footage is now 8-bit RGB and not 8-bit ITU-701, but since the RGB colorspace is larger than ITU-701, no "conversion" of color is necessary. All the color data stays intact. I bought a 1.6TB RAID last week which helps editing uncompressed HDV a whole lot. I can't play it in realtime (drops frames like crazy!!), but the visual effects sequences I'm working on are much cleaner in uncompressed space than footage that's been compressed with "lossless" codecs (I go frame-by-frame anyway, so real-time playback isn't essential). Loading and saving times are significant with uncompressed footage, but the quality gained from it is truely worth the wait. If you want to ensure your AE files are not going through a color space conversion, always work with uncompressed files and render your files with the uncompressed codec. Just a side note: AE can't handle native m2t/HDV files, you'll have to uncompress the footage anyway.

March 22nd, 2005, 09:08 AM	#4
Steven White Major Player Join Date: Nov 2004 Location: Canada Posts: 547	AE can't handle native m2t/HDV files, you'll have to uncompress the footage anyway. Not quite true - technically it can handle them, but the render times to decompress are rediculously large. In order to make my rotoscoping workflow even possible I had to render to uncompressed anyway. Is there any advantage to a .tga sequence over an uncompressed avi? I get the sense that an uncompressed avi is equivalent to a .bmp sequence, with the exception that it can store alpha-channel information, but doesn't keep the audio.