Cineform quicktime After Effects Render = tripple image, shifted color channels.
 

When rendering an After Effects composition as a QuickTime Cineform (on PC) the result is a gibberish of an image with its color channels shifted relative of each other in vertical direction. Regardless of the bit depth and codec setting. Rendering preview looks fine. Avi renders fine.

Re: Cineform quicktime After Effects Render = tripple image, shifted color channels.
 

If your using a PC, why would you render as a Cineform MOV instead of AVI?

Re: Cineform quicktime After Effects Render = tripple image, shifted color channels.
 

Dmitry, we are investigating this new bug now.

Re: Cineform quicktime After Effects Render = tripple image, shifted color channels.
 

DaVinci Resolve

Re: Cineform quicktime After Effects Render = tripple image, shifted color channels.
 

Here is a beta of a patched QuickTime component.

http://software.gopro.com/PC/CFHDCodec.zip

Unzip and copy over the component in C:\Program Files (x86)\QuickTime\QTComponents

Within After Effects use the Trillion+ and at least a 16-bit composite, and the QuickTime codec settings enable "Force 16-bit encoding". This is new. AE broke when we added support for MPEG Streamclip which does support deep pixel. This new 16-bit control always advance apps like AE to co-exist with 8-bit only apps.

Re: Cineform quicktime After Effects Render = tripple image, shifted color channels.
 

Thank you. It seems to take care of the issue

Re: Cineform quicktime After Effects Render = tripple image, shifted color channels.
 

Same situation, but CS6. Running with a patch mentioned above in this post. Render simply fails with AE complaining at the output module.

Re: Cineform quicktime After Effects Render = tripple image, shifted color channels.
 

Issues continue. Please advise.

Re: Cineform quicktime After Effects Render = tripple image, shifted color channels.
 

Here are the stills attached.
QT-MOV is the file produced by rendering QT MOV with force 16 bit and Trillions of colors.
Processing space is 32 bit in After Effects. Afterwards the same Gain-gamma -Lift are applied to both. Shadow detailed revealed in the original AVI, but is completely lost in QT mov

Re: Cineform quicktime After Effects Render = tripple image, shifted color channels.
 

This is normal. Floating point will not protect your supers (white or black extremes) when going to most codecs. A Codec must have ranges between zero (darkest black) and one (brightest white.) The source data was in YUV, which has black at 16 (Y - Luminance) and white at 235, which means can have supers. So to map YUV into RGB, without lossing data you much use studioRGB, something Vegas does by default but few other tools. For cameras that using full range YUV we automatically correct for this (Canon DSLR), but you are likely using something else. If you have supers and want to use them in After Effects, you will need to pre-gain the image in a 32-bit comp, or fix it inside the CineForm metadata (easier.) To convert to studioRGB, set the lift to 0.062 and the gain to 0.86, than way nothing will be lost.

Re: Cineform quicktime After Effects Render = tripple image, shifted color channels.
 

Thank you very much.
So what you telling me is that it is an After Effects and Adobe Media Engine limitation? In some other apps I can tell cineform to encode the full range RGB and it does so (namely VirtuaDub that I use sometimes for batch processing) without throwing away Super W/B, but, from what you are saying, its because the app itself passes the data onto the codec without truncating the signal.

Re: Cineform quicktime After Effects Render = tripple image, shifted color channels.
 

Yes, if you want supers that a below 0 or above 1, they will be chopped off by the application before the codec sees it -- particularly a RGB only application like AE. Use the floating point mode so your sources with supers can be preserved through increasing the black level and decreasing the white level, so they are within the range of integer representation. This is why black is a 64 for 10-bit files, DPX and integer TIFF files can't store supers either, so the workflow compensates for this with a lifted black and reduced white level. Another example, Cineon Log DPX have black at 95 and white at 685 (for a 10-bit file with range 0 to 1023.)