Archive: Blending Question
JFASI
15th November 2005 01:00 UTC
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.
eheiney
15th November 2005 01:14 UTC
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)
JFASI
15th November 2005 01:28 UTC
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?
eheiney
15th November 2005 01:50 UTC
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.
JFASI
15th November 2005 01:54 UTC
:weird: :weird: :weird: Huh??? :weird: :weird: :weird:
Can someone help me, scratch that, us???
StevenRoy
15th November 2005 02:14 UTC
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.
JFASI
15th November 2005 21:10 UTC
Ah. So its execute 3 times per pixel, for blue, green, and red?
jheriko
15th November 2005 23:24 UTC
Originally posted by JFASIEssentially correct, but under the hood all the blending uses MMX so that the red green and blue are operated on in parallel.
Ah. So its execute 3 times per pixel, for blue, green, and red?
JFASI
16th November 2005 02:03 UTC
Quote:
Originally posted by jheriko Essentially correct, but under the hood all the blending uses MMX so that the red green and blue are operated on in parallel. Also all the colors are always capped to 0..1 (0..255) after the blend is done. |
UIUC85
16th November 2005 02:09 UTC
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?
JFASI
16th November 2005 02:14 UTC
Aha, so 0..1 equals (1..255)/255. Cool. i'll let the MMX go.
UIUC85
16th November 2005 02:20 UTC
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.
Grandchild
16th November 2005 12:43 UTC
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].
JFASI
16th November 2005 22:44 UTC
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.
gordmoo
19th November 2005 20:09 UTC
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 ;)
JFASI
19th November 2005 20:34 UTC
Hmm... that's a lot of colors. Now how to program them all...
UIUC85
21st November 2005 18:44 UTC
Ok I'm gonna ask this again cause I think my question go overlooked, but what exactly does input blending and buffer blending do?
StevenRoy
21st November 2005 19:29 UTC
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.
UIUC85
23rd November 2005 17:55 UTC
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!
Fork me on GitHub