![]() |
Blending Question
I have a question that's been bugging me for a while (not unlike most of my questions). When a render mode, say, XOR, does its math, like exclusive or in XOR's case, what is it comparing? Better put, does it compare the colors of two pixels, or the brightness, or some other more transient quality? i.e. Maximum blending, does it display the brighter image, more colorful, etc.
|
TomyLobo's Buffer blend APE explains it a bit, if this is what you're looking for. It shows:
a=b (Replace) a=a+b (Additive) a=max(a,b) (Maximum) a=(a+b)/2 (50/50) a=a-b (Subtractive 1) a=b-a (Subtractive 2) a=a*b/256 (Multiply) a=a*x+b*(1-x) (Adjustable) a=a xor b (XOR) a=min(a,b) (Minimum) a=|a-b| (Absolute difference) |
Ok, but I still don't get, for example, max what. If you put two frames together, what determines what aspects and colors stay and what don't. What about say, the first frame, makes it greater, in max for example, than the second one?
|
Well in the case of the max, it returns the greatest of a and b. I don't really understand it myself, I just know what will happen if I select a particular blending or rendering mode.
|
:weird: :weird: :weird: Huh??? :weird: :weird: :weird:
Can someone help me, scratch that, us??? |
In the case of an Effect List, the output mode affects how the EL's data is placed upon the pixels that are already there. The "Set Render Mode" works the same way: Superscopes or Texer IIs use the current render mode to determine how the line or image is added to the previous image.
Also, all of this math is done with the individual red, green, and blue components of each pixel. For example: Replace: The pixel of the previous image is simply overwritten by the new pixel. Additive: Each component (red, green, and blue) of the new pixel is added to the same component of the previous pixel. Maximum: Each component (r, g, and b) of the previous pixel is increased (if necessary) to match the same component of the new pixel. And so on. "New pixel" means whatever image is created by the Effect List, Superscope, Texer, et cetera. The "previous pixel" is simply what was there before. In the equations such as "a=a+b", the "a" represents the previous pixel and the "b" is the new pixel. The resulting image then becomes the new "previous pixel" of whatever operation comes next. |
Ah. So its execute 3 times per pixel, for blue, green, and red?
|
Quote:
Also all the colors are always capped to 0..1 (0..255) after the blend is done. |
Quote:
I'm confused. MMX??? and capped to 0..1??? I don't get it. |
I think MMX just has to do with the processor performing specific operations for sound and video. As far as capping between 0 and 1, that's just done to keep values correct. Having a value outside of that range means nothing to AVS in terms of colors so it's just more convenient to cap it inbetween. Both of these topics are behind the scenes stuff anyways so as long as you're aware that colors range from 0 to 1, you're set unless you really want to know the abstract details.
I'm curious as to exactly how/what buffer blend does. And I think I'm slightly confused as to the what two frames the input blending uses for effects lists. Anyone? |
Aha, so 0..1 equals (1..255)/255. Cool. i'll let the MMX go.
|
Uhh yeah or you could go with straight 0 to 1 and skip the conversion completely. That would be faster in code, but yes scaling 0 to 255 would work.
|
in the Color Modifier it's sometimes better to have a value ranging [0...255] divided by 255, especially when you have "equal()" expressions. for example an expression like "red = equal(red,0.5)" will always return zero, since no color value will ever be exactly 0.5 [rather 127/255 or 128/255].
|
Ok, so the strength of a color could be 0-255? (Realizes 256 color depth) Oooh... so doing like n=1000 on a massive colormorphing scope is completely pointless. Aha.
|
it depends on how many colours you have in the scope. you arn't limited to 255 colours, more like 2 to the power of 24... 16,777,216 colours then. unless of course your running in 16-bit colour mode in that case its 2 to the power of 16...
and just to make things a lil' clearer. mmx is just a fancy thing that works in the back of your processor to speed things up some, it can be ignored ;) |
Hmm... that's a lot of colors. Now how to program them all...
|
Ok I'm gonna ask this again cause I think my question go overlooked, but what exactly does input blending and buffer blending do?
|
In Effect Lists, you mean? Input blending is pretty much the same as the output blending, but it affects the image at the very beginning of the Effect List.
For example: Ignore: The Effect List starts with whatever data it had before. (Unless you have "Clear every frame" enabled.) Replace: The current image data (before the Effect List) is copied into the Effect List. Additive: The current data is added to the Effect List's data. ...And so on. The important thing to remember is that each Effect List maintains its own image data, much like a separate preset. Just as the output blend option controls how (and if) the Effect List's data modifies the data that comes after it, the input blend option controls how the Effect List is modified (at the beginning) by the data that comes before it. The "Buffer #" blending modes are rather unique, in that they use the data of one of the "Buffer Save" buffers as a kind of "Alpha map". It's similar to "Adjustable", except the amount of blending is controlled for each pixel by the brightness of the pixels in the selected buffer. Put another way: Foreach pixel { Outputdata = (Effectlistdata * Buffer) + (Previousdata * 1-Buffer) } Where "Buffer" is the red, green, or blue component of each pixel (whichever is greatest). It's really a pretty cool feature, although using it too much can slow a preset down quite a bit. It took me some experimenting to figure this out, by the way. If you're still confused, try some experiments of your own. After a while, it may start to make sense. |
Ahh thank you! I knew this stuff at one point, but couldn't figure it out after not doing anything with AVS for a while. Thanks again StevenRoy!
|
| All times are GMT. The time now is 22:16. |
Copyright © 1999 - 2010 Nullsoft. All Rights Reserved.