Does anyone know if it's possible to get a 64 bit (16 bits x 4 channels) PNG or TIFF render out of Poser 7?
Thanks
-E

64 bits? Phew, unsure. What is your end goal? Why would you need a 16 bit alpha channel?

If you are able to export 16 bits per (color) channel, then you would have less banding (in gradient-like areas) upon export; this is pretty common among "high end" exports such the ILM's openEXR file format that allows you to bracket up and down like HDR while using only half the disk space.

Some apps allow you to export 16 bit TIFFs - though in my humble experience, I haven't seen this often.

Much beyond 8-bit per channel is rare.  8-bit gives you 2^(83) or 2^(24) or 16777216 individual colors plus 256 alpha grey-levels.  At 16-bit per channel, you're talking 281474976710656 (281 trillion colors - way, way, way far beyond the human eye's ability to distinguish) individual colors with 65536 alpha grey-levels.  The numbers at 64-bit per channel might not even be printable here.  Just think about a 2^(643) or 2^(192) number of colors.  That is a 6 with 57 zeroes after it.

Are you sure you are not confusing image bits-per-pixel with 32-bit vs. 64-bit OS/addressing/size schemes?

 Poser 7, no. Poser Pro gives you export to 16bit/channel OpenEXR files.

Thanks all,  for the feedback. Boy, I can see the curiosity humming. Yes, this is a real requirement

for a render-on-the-fly application (user-personalized animated ecards). I'm one of the artists on that site that has a Photo-Inside animation...needless to say, I didn't get the UV pass out of Poser
on that one :)   
-BTW, that's in the ZEN category, titled "Contemplate This"

...but I was sort of hoping, as I'm laying out my next animation, and it would be really convenient, in this case...oh, well, the workaround isn't so bad I guess.

Doesn't OpenEXR actually give you 32 bit per channel files or am i missing something ?

openEXR is a high dynamic range 16 bit per channel file format. One of the design goals was to have high dynamic range (to match film) but to have reasonable file sizes - 32 bit becomes unwieldly at film resolution. The openEXR website can explain it a lot better though.

As I and others have noted, I can't see any practical use of 64-bit per channel images (in the foreseeable future anyway).  A 1024x1024x(64-bitx4-channel) pixel image (uncompressed bitmap) would require about 270MB of memory.  At 2048x2048, 1GB.  These aren't even reasonable print resolutions yet (I calculated 8.5x11 at 600dpi to require more than 8.6GB).

And you're doing this for ecards?  Why the requirement for anything beyond 8-bit?

Kuroyume, thank you for your enthusiasm, but please re-read my initial post.
I stated from the outset, 64 bit (16 X 4 channels).  16 bits per channel, not 64.
16 X 4 = 64.
AKA 64 bit RGB file.
If you go to any high-end 3D package, you will see the option to output various 64 bit RBG formats.

I suppose you would have to investigate the Lightfactory PhotoInside process to totally understand why this is needed, but it has to do with their render-on-the-fly UV mapping process. They give you a 64 bit map (a RGB color gradiant they use to "track" the UV pass), you integrate that into your animation, render as a seperate pass, and hand the various passes of your animation (BG, UV, FG) back to them. A user can then upload a photo, and it will be mapped, on-the-fly, into the animation, thus personalizing it. I hope this clears that up for you :) 

Oops. :)  I swear that I read 64-bits per channel.  Now you know what to use: openEXR.

Still seems odd, as you note, to require such high 'resolution' images for on-the-fly rendering.  One would think that on-the-fly would be better served by 8-bit per channel.  Maybe this is a factor of the engine they are utilizing for render (?).  Do they give a file format support list for the images?

The deep bit depth is needed only for the UV pass, and I'm sure it has to do with the sensitivity needed to replace one map with another, which is essentially what's going on with the PhotoInside process. The final output is a flash .flv file with visible compression. The whole issue is simply satisfying the requirement of their proprietary fly-render, map-tracking and replacing software. See? The UV pass bitmap that you map into your animation is a color/saturation gradient. The saftware needs to "see" this in very fine detail, in order to "know" how/where to map the user photo. The "how and where" can include not just movement but distortions, warping, exploding, reconstituting, etc etc that the animator has occuring to the UV map. 
Final formats acceptable to them are PNG and TIF. Again, only the UV pass needs to be 64 bit.
Only PhotoInside animations have these requirements. If you want to submit something not PhotoInside enabled, almost any old thing is god enuf, as long as it is video :)

just to say, i've had some pretty horrible results in color ranges that were well within what i could differentiate between.  i have at least one image i can't even post because it completely breaks down as a JPG.  it's OK as PNG, but it would have been a lot cleaner if i had an order of magnitude more steps between colors.

and 256 levels of any one color or level of transparency is actually pretty small.

re: Now you know what to use: openEXR.

Actually, I do not own Poser Pro, so... my "workaround" is to either:

a) do the entire animation in Lightwave and/or Motionbuilder, with UV pass mapped onto 3D geometry and rendered separately from the "main" animation.

b) Use Poser 7 to do the character animations that I'd rather do there (than in Lightwave), and then do the UV pass in Fusion 5 (a compositing package) where I am basically hand-teasing the UV pass to visually integrate with the rendered animation. 

Option B is what I used for the "contemplate this" title, which is quite crude, and I know I can do better. It's 6 of 1, half a dozen of the other, in terms of which method to use.