#ALPHA CHANNEL
8 messages in this thread
That's my question as well. Those Alpha Channel buttons in the Yost IPAS
Boutique #1 .IXPs (Flare, Hilite, Glow, Blur, etc.) appear to be utterly
useless. Here's why: the instructions SAY that they will look at the Alpha
Channel of the item above them in the Video Post queue, assuming that said item
is 32-bit (has an Alpha channel) and that Use Alpha is On. This is apparently
not the case. Apparently they instead look at the ACCUMULATED Alpha of ALL the
Video Post queue entries above the .IXP entry whose timelines overlap at that
frame. In other words, they look at the Alpha channel of the CURRENT
COMPOSITED IMAGE being built, as it has been composited through the various
layers!
The problem is, ANY PIXEL THAT ISN'T BLACK in the accumulated composited
image is going to have an Alpha value greater than 0, or else it WOULD be
black! Solids and Gradients have completely white Alpha. KF Scenes have Alpha
according to transparency and anti-aliasing, with the non-edge faces of
non-transparent materials being white, and areas with no geometry at all (or
nothing but 100% transparent, i. e. invisible, objects) being black. Bitmap
layers may or may not have their own Alpha, but when they do, any portion of
the bitmap with no alpha doesn't show up, and for anything TO show up at those
pixels there must be pixels with positive alpha in preceeding layers — which
then get accumulated into the total Alpha layer of the composited image!
This sequence should make it plain:
Video Post Begins with all pixels set to R, G, B, and A of 0, 0, 0, and 0.
No color, no alpha of any kind. Thus:
PIXEL 1 PIXEL 2 PIXEL 3 PIXEL 4 PIXEL 5 PIXEL 6
RGB ALPHA RGB ALPHA RGB ALPHA RGB ALPHA RGB ALPHA RGB ALPHA
—————————————————————————–
Starting: 0 0 0 0 0 0 0 0 0 0 0 0
+ Bitmap: 0 0 >0 >0 >0 0 >0 >0 0 >0 0 0
—————————————————————————–
= Subcompst.: 0 0 >0 >0 0 0 >0 >0 0 >0 0 0
+ KF Scene: >0 >0 0 0 >0 >0 0 >0 0 0 0 0
—————————————————————————–
= Composite: >0 >0 >0 >0 >0 >0 >0 >0 0 >0 0 0
As you can see, any pixel in any layer with 0 Alpha will not be composited
into the image being built. If the corresponding pixel before was also 0
Alpha, then that pixel will still be black, since the only way it could be 0 is
if there were no Alpha anywhere in the chain since the Starting All-Black All-0
Alpha image. The RGB of those pixels in the layers has no bearing since
without Alpha they won't even be taken into account!
So you see, the "=0" and ">0" Alpha buttons in these .IXPs are all but
utterly useless. At least, I haven't been able to find a use for them.
To make matters worse, these routines not only have no usable Alpha to key
off of, but they also don't GENERATE Alpha. The points of hilights generated
by HILITE.IXP, for instance, are lightened by varying amounts as far as the RGB
goes, but the Alpha of those pixels aren't at all changed. This means there is
no way to have Hilite affect only the objects in a 32-bit Bitmap or KF Scene
and yet have the points of the Hilite be transparently visible whenever the
points go over the background (0 Alpha of the previous layer). Ditto for the
effects of FLARE.IXP, GLOW.IXP, etc.
I've verified all of this by using Alpha-Split and viewing the Alpha files
produced at each stage of Video Post directly. Both that there is no usable
Alpha for .IXPs to key from, and that the Yost Boutique #1 .IXPs don't generate
their own Alpha even if Alpha is On.
We REALLY NEED these things to be fixed. For now, I would settle for having
the Yost #1 .IXPs upgraded to generate Alpha, as the other problem can be
worked around (albeit tediously) by splitting Video Post jobs into multiple
jobs. Has this other problem been fixed in Release 4's Video Post? Or are
both of these problems being caused by something else, such as by some obscure
setting in 3DS.SET?
<<That's my question as well. Those Alpha Channel buttons in the Yost IPAS
Boutique #1 .IXPs (Flare, Hilite, Glow, Blur, etc.) appear to be utterly
useless. Here's why: the instructions SAY that they will look at the Alpha
Channel of the item above them in the Video Post queue, assuming that said item
is 32-bit (has an Alpha channel) and that Use Alpha is On. This is apparently
not the case. Apparently they instead look at the ACCUMULATED Alpha of ALL the
Video Post queue entries above the .IXP entry whose timelines overlap at that
frame. In other words, they look at the Alpha channel of the CURRENT
COMPOSITED IMAGE being built, as it has been composited through the various
layers!>>
That's my question as well. I am waiting for this problem to be corrected in
R.4 of 3D-STUDIO,
but for the time being, untill there will be any upgrade to Disk-1, we can't do
a thing with it!!!
Thank you very much for the long reply.
Sus.
Please see my msg #126216.
– G
There are a couple of separate issues going on here.
I. Accumulated alpha.
The alpha channel IS accumulated throughout the compositing chain. That's an
important feature that we spent quite a bit of time working on to get right.
Your comment about the alpha switches in the IXP's being useless is inaccurate,
though, because if you do a single-layer renderings with an additional
light-effect layer, the alpha switches work perfectly. If someone wanted to
write an IXP that saved the accumulated alpha channel from all previous layers,
wiped the alpha channel for the subsequent layer, and then another IXP that
restored the accumulated alpha after the light-effect layer was done, it would
allow n-layer compositing with light effects and alpha-switch control. But the
point is that it works perfectly in a 2-layer situation.
II. Alpha output from IXP's.
As for the alpha output from IXPs such as FLARE, HILITE, etc., Alpha is not
modified by these processes because IT SHOULD NOT BE. The reason for this is
that lighting effects which are additive in nature do NOT mask out what is
behind them — they add to it. If you take a multiple-exposure photograph of
red, green and blue light sources with different overlapping cross-star
filters, the overlapping star points from the different color layers ADD UP —
Exposing red, then green, then blue does not result in a blue image (as you
seem to expect) — it adds up to white. Tom has some slides that he took as
experiments while doing the IXP's that I could dig up if I need to to provide
someone actual documented photographic proof of this, but you can try it
yourself. In the computer, if we generated alpha, compositing the resulting
image over another would mask out the other image rather than adding the flare
color to it.
There ya go,
– G
It works perfectly in a two-layer situation? Sure! Problem is, in a
two-layer situation (where the second layer is one of the .IXPs in question),
Alpha ITSELF is useless, since there are no other imaging layers for the Alpha
to allow to show through and thus my objection still stands. Since we're
talking two layers here where only one is an image and the other is just an
effect, there is only ONE imaging layer, so anything where Alpha =0 is going to
be BLACK! Why, gee, these effects will almost always ignore black areas ANYWAY
(can you imagine trying to Hilight the BLACK pixels of an image, for
instance?)! So it's STILL useless. Remember, we don't get to set an Alpha
Threshhold for these effects, or a particular Key Alpha value. We ONLY get
Whole Image (ignore Alpha entirely), Alpha >0 (any positive Alpha, including an
Alpha of 1/256!), and Alpha =0 (****ALWAYS**** BLACK in your "two-layer
situation"!!).
On the second answer: so in other words, Alpha only does SUBtractive
transparency, and Hilite, Flare, and Glow would need ADDitive transparency. I
was afraid of that. Basically, if they DID generate Alpha, and you used that
Alpha to apply it over a background, the portions of the Flares, Hilites, and
Glows that extended over the background would look more like glass or celophane
rather than like light as they should.
It seems that the only way, then, to realistically composite Hilite, Flare,
and Glow over an externally generated background (say, live video) would be to
map the live video to a Keyframer geometry rectangle that exactly fills the
camera's view and is behind all other geometry, and is linked to a Dummy that
the camera and its target are also linked to so that the rectangle always fills
the camera's view. That's fine, I suppose, if you don't need to animate the
camera's FOV over the course of the animation — it'd be kinda hard to scale
the rectangle to exactly match the camera's FOV. (Yet another reason you
really should have implemented Object Cameras in R4.)
One possible solution would require a new version of 3DS, namely, allocating
one bit of Alpha in Video Post to determining ADDitive or SUBtractive
transparency. Let's face it: you don't NEED a full 16 bits of Alpha channel!
15 is MORE than enough even with a full NTSC 2.2 gamma correction! Take the
LSB of the Alpha as a switch — if 0, treat the remaining 15 bits of Alpha as
SUBtracive Transparency. If 1, treat them as ADDitive Transparency. This way,
Video Post's own Alpha can not only take Glow, Hilite, and Flare into account,
but also such things as cones set to ADDitive Transparency to be used as "beams
of light" in the actual geometry. Perhaps two bits could be so sacrificed, to
allow for New and Old Subtractive, plus Additive, plus a fourth all-new use for
Alpha. Of course, when writing files out to a 32-bit format such as TarGA, the
Alpha channel would be reduced to 8 bits anyway and the extra flag bits would
be ignored. An option could be selected in these cases to cause file Alpha to
be set to 0 if the original Alpha is set to ADDitive, since external
compositing programs/hardware couldn't duplicate the effect correctly.
This still doesn't address the issue of documentation. All of the
applicable routines in Yost IPAS Boutique #1 state in their instructions:
Filter Whole Image, Alpha >0, Alpha =0. These radio buttons determine
whether ______
acts on the entire image or is constrained by the alpha channel.
______ uses the
alpha channel FROM THE QUEUE ITEM ABOVE IT if: Alpha >0 or Alpha =0 is
selected; THE
ITEM ABOVE IT IS A 32-BIT ENTRY; and the Use-Alpha button is set to
Yes in 3D Studio's
System Options dialog. Alpha >0 restricts _____ to THE PREVIOUS
LAYER'S live
image area (as defined in the alpha channel), whereas Alpha =0
restricts _____ to
everything that's not in THE PREVIOUS LAYER'S live area (as excluded
by the alpha
channel.) For general use, leave the Filter parameter set to Whole
Image.
Please tell me how I could have determined that this meant every layer above
the effect, not the immediately preceeding layer only, from what is written in
that paragraph (and repeated four times in the manual, once each for Blur,
Glow, Hilite, and Mono).
The alpha>0 option certainly has some use in a two-layer situation. It
limits the image-processing effect to look at pixels in just the live area,
effectively ignoring anything in the black portions of the image. The
alpha=0 option is simply the reverse, which rounds out the alpha controls
by limiting the effect on just the areas of the image with no alpha, so
the effect looks at pixels in the layer behind it. (This is effectively
the same as putting the image processing effect one-layer back.) You
certainly aren't forced to use either option, and as it says in the docs,
"For general use, leave the Filter Parameter set to Whole Image".
For multi-layer effects, your problem is basically that you can't use the
Alpha>0 option because the multiple layer's alpha channels are combining
on you. I've uploaded an IXP called NOALPH.IXP that can strip out the
alpha channel from a Video Post sequence, overcoming that limitation.
Here's an example of how it would be used.
PART1.TGA, PART2.TGA, PART3.TGA — all 32-bit images
The Video Post sequence:
PART1.TGA Alpha
GLOW_I.IXP Alpha>0
NOALPH_I.IXP
PART2.TGA Alpha
MONO_I.IXP Alpha>0
NOALPH_I.IXP
PART3.TGA Alpha
HILITE_I.IXP Alpha>0
NOALPH_I.IXP
[KF Scene]
BLUR_I.IXP Alpha>0
This sequence will operate as expected on each layer of the image —
glowing part1, monochroming part2, etc.
Regarding your comment about an "additive" alpha bit… it's not a bad
idea, and we'll keep it in mind for the future.
So… I've got to get back to work now. Enjoy noalph.ixp.
– G
I'm working on the rotoscoping prj and the no alpha.ixp is going to solve one
problem I'm having. Very timely. Thanks Gary.
You're welcome, Don!
– G