24bit vs. 8bit. AE doesn't handles palette-based transparency, only genuine per-pixel transparency. Tools like XnView or IrfanView can do all sorts of conversions. always good to have them handy.
Actually, they are 32-bit. But regardless, that doesn't explain why the sequence I generated (from the exact same 3D app) as a PNG sequnce IS handled correctly by AE. In fact, I can't recall AE ever not seeing the transparency of my PNG sequences ... or those of anyone else.
I have XNView, (maybe INfran too, need to check), LightImageResizer, Sage, Thumbsplus, etc., etc. None of them handle the transparency as far as I can tell.
Then batch them through Photoshop....
Thanks, Myl ... but I'm afraid my Photoshop batching skills are feeable, at best. I know how to setup a basic batch of converting to PSD, but I need it to do three steps first, of course:
1) Tell it to LOAD CHANNEL AS SELECTION
2) Then INVERT the channel
3) Then SAVE SELECTION AS CHANNEL.
Can you brief me on how I would do just that?
Actually, I think I figured it out. Will let you know how it goes momentarily ...
Yep, I got it to do the batch correctly, so that is indeed a workaround. Thanks.
However, I would still like the mystery solved. I went ahead and rendered another PNG sequence from another 3D app, and it imported just fine (alpha-channel detected) in to AE. So my only guess at this point is, they broke something with PNG (or perhaps ALL image output) with the latest update to the other app.
Ok another follow-up with interesting results ...
1) The second sequence I have that I tried to batch in PS, did not turn out correctly. Investinging with a single frame inside PS revealed that it was not simply adding a selection to the "solid" parts, but actually sections within the solid parts. (To make it clearer, the animation is a zoom out from an open 3D book. Instead of making a selection of the book, it selected the book, and then various things contained on the book. Not sure where it was getting this selection from.
2) In AE, I simply moved those frames in the beginning where there would not be an alpha channel (or need of one) because the book is filling the entire frame. I then imported the remaining frames and it saw the alpha channel with no problem. I then just added the starting frames as a seperate sequence to the begininnig of the timeline, and wallla ... problem solved.
So I can only surmise that the 3D app did not -- oddly enough) output any alpha/transparency info for those first 60-or-so frames where the book filled the entire frame. Thus, AE -- looking at the first frame with no alpha info -- rightfully concluded that there wasn't any, and igores the transparency info.
The other PNG sequences did not start with object(s) filling the entire frame, so alpha info was written to the first frame for those. I can test this theory pretty easily. I could probably, now that I think about it, even just have created a frame 0000 with some alpha info, and then it would have worked (possibly.)