- This topic has 2 replies, 3 voices, and was last updated 13 years, 2 months ago by .
-
Posts
-
Our Company did a project where we rendered 32 bit CG images out of Maya/Mental Ray to be comped-post in AE. ( The sequences/movies are multi-pass renders and average 24 second in total play time… its for interactive) I had so many headaches from this project and hope someone can shed some light……
We never really researched the entire pipeline but went right into production/post,, however as soon as I started to comp in AE, thats when my nightmare began. What I mean: I see the advantages of tweeking the image in 32bit colour space; its amazing, however working in AE CS2 was incredibly slow and I couldn’t work fast at all. It was like working with a handicap! (scrubing, rotoscoping+ much more was painful) My system isn’t the fastest nor is it slow either…..(Mac Dual DualCore (4) Intel 64 bit – 4 gigs Ram)
Does anyone have any tips or advice as to which direction we should take for future 32bit pipelines/projects? Do we need to work in another package other than AE, like: NUKE, Fusion, Shake or Flame…. or is there other ways for a more efficient backend pipeline? Could I be doing something more efficient like; …bring in CG renders and make proxies of everything or changing some specs in AE? Ok enough from me…hope to hear from some gurus on this subject.
Thanks for the help!
I just finished working a large pipeline for a doc. We handled everything in 32bit and half float openEXR. We comped in Nuke (which only works in 32bit float color space), Used Maya and MentalRay (half float files). Color correction was handled with Nuke (float), photoshop (float/half float) and final gamma in FCP (custom gamma filter in 10bit). The end product was an uncompressed 10bit 4:2:2 D5 master. Lots of time went into color and gama correction. I have not used AE in a long time. I personally don’t like that app. Nuke is really solid for me. I connect to it really well.
32 bit is great to work in, however, the files are large to contend with and the end product usually always goes out 8bit (we do half float for film record outs). Some of our working images were 10k in size! With 32 bit float we had a 3D comp that would take 20 hours to push out 1200 frames in 1080×1920 square pixels (this was done on a single dual xeon box with 4gigs of ram, we were not using our allready taxed render farm). So time can become a serious issue.
We ONLY work with zchannels in float.
If you’re recording out to film you work in float. You want to maintain highlights and rich shadows. We dither down to half float openEXR files then push it to film.
With 32bit you get more precision, which in-turn, provides better results. But you need to be careful. You can look at a blur in 32bit and it’s fantastic, then when you get to the SD 8bit master it becomes aliased. It’s ugly. So experience alows you to find the happy medium and it’s important to know what is happening mathematically between float, half-float, and 8bit images. You only get so many shades of grey.
Nuke and Shake are my primary compositing tools. They both work great. In the end I prefer Nuke. FCP has a long ways to go as a pro-app. Look into Smoke from Autodesk.
All of our 3D is half float or 8bit.—
@iraflowers 23811 wrote:
We dither down to half float openEXR files then push it to film.
Just curious – do you like to actually dither or just truncate? Wouldn’t have thought quantisation error at the bottom end of a half float image would ever become visible?
- You must be logged in to reply to this topic.