Transparency APE Technical Problem

I thought of a plugin that would look at a pixel, and if its color is juuuust the right shade of black, it acts like as if it were transparent, i.e. it is rendered in Max mode. Otherwise it renders Replace or whatever. I would like to know this: Does AVS actually allow for each pixel to be handled like this? Can I look at every one and choose its draw mode, or can I only do that with the whole image?

I dont know so, but I doubt it, because then it require rquire thoose calcs to be done just before rendering anything, which I doubt can be done with an ape.
In order to do what you suggest, you would have to make a new rendermode, which is only possible through the avs source code.

Usually you can however work around not having that kind of transparancy, by first using replace (or subtractive for images) to first make a black outline of what you want to draw, and then draw what you wanted to draw (on top of something) using addictive blend.

I messed around with that for a while, and I couldn't get it to work like I wanted it. So you say no?

"addictive" blend, lol!

that could be a name for the ape you're writing JFASI!

Assuming it could be written as an APE.

I gave it a bit of though, and I think I could do the same thing using Trans->Color Modifier to write whether the pixel is the color or not to a global megabuffer and then take it to the DM and alpha blend it using that.

na that's not possible! [if I understand you right]

color modifier can NOT change the color of each pixel respectively to its position
e.g.

red = if(above(x,0),1,red);

or sth like that.

Knowing that, you will see that likewise, color modifier can't get the position of a pixel. It knows only its color.

So unfortunately you'll not be able to get and save the positions of all the pixels that have e.g. #010101.

I would like it very much to have such a "pixel reading" ape. It would be very useful but slow as hell, I promise.

GC

So if I go :

Frame:

nt=0

Pixel

nt=nt+1;

pix=if(band(equal(red,.1),band(equal(blue,.1),green,.1)),0,1);
assign(gmegabuff(nt),pix)//Or however the syntax works

in the color modifier, and then

Frame

nt=0

Pixel

nt=nt+1
alpha=gmegabuff(nt)

It wouldn't work? I thought it could actually do that.

Color modifier is quite clever and can do a lot of stuff, but to do more complex per pixel effects depending on, say, the pixel position, is pretty damned slow. I wrote an APE for doing this, but abandoned it as I was going to have to make quality sacrifices and effort to make it practical... mostly effort :P

As a side note it can be used to capture the framebuffer into the megabuf. If anyone else seriously wants to make an APE I would be glad to help out. Sticking the framebuffer into megabuf, perhaps as a low quality copy, is certainly possible, although without quality limits using it would automatically limit the preset to a low, just watchable speed.

I would attach the per-pixel ape, but its evil and shouldnt spread. But using I made couple of presets which were doing a few assigns and adds and an abs to render stuff at about 20-30fps, so copying data from pixels to megabuf would probably be at most that slow if there is no quality loss.

Interesting stuff tho, 'transparency'... /me laughs

Ok, then. Any tricks to get around it? Whenever you're done laughing...

Use buffer blend noob

lol. PAK is like he was before 😛

Let's calculate! (im not very good at that, but what the hell.)

Say you check the color value for each pixel, then you re-valuate the value to something else, that's times 2, right?
Now let's calculate the pixels, say, we have a screen with the size of 400x300 (a typical fullscreen resolution?) that would mean 400*300*2 (240 000) calculations per frame. And what ever complicated formula you were intending for it, that would mean you would do that almost a quarter a million times per frame. Sound fast to you? Because it sure as hell doesn't sound too fast for me 🤪



If you really want to do this, could it be possible to do it like the dynamic movement does it? As in divide the screen into a grid of points and blablabla-technicals-blablbala, so the user can decide between quality and performance.

For sprite-like transparency, I prefer the following "trick":

Effect list (Output=Subtractive 1)
- (Draw stuff here)
- Buffer Save
- Color Clip (Make everything white except pure black)
- Convolution Kernel (If you want black borders around the sprites)
Buffer Restore (Additive)

This is somewhat similar to DummyDDD's suggestion, but more general-purpose. It's not quite the same as a true "transparency" render mode, but it might be close enough. (Assuming you do it right.)

That's what I was looking for. Buffer Blend? I don't have it.

Window Resize APE! Very nice. The buffer blend is sexy too.

Damn, son. You've really been missing out. The window resize APE is essential to AVS artists. 😁

Originally posted by denkensiefursich
The window resize APE is essential to AVS artists. 😁

It is?

Funny how i manage to make a pack that gets featured even without it.

Yes, weird i know, it can't possibly be true, but it is! Be amazed at my amazing avs skills 😳

Hack the dll resources noob

Pak-9:

Use buffer blend noob

You meant the FXlist output mode using a buffer, didn't you?


And while we are discussing abilities of the Color Modifier, I checked it and noticed the frame [not "pixel" JFASI] section is executed 256 times a frame. Color Modifier is obviously checking each level of rgb. Sounds weird to me when we are talking mainly about pixels that have certain colors, not colors that have certain positions. 😕
Anyone an explanation?

GC

It's simply point processing. i.e. The new value of each pixel is dependant upon only the current value of the pixel. Contrast this to, say, convolution where the new value of each pixel is dependant upon the current value of the pixels surrounding it (local processing)

and yes... i do mean an el set to buffer blend

And how exactly does buffer output in effect list work? It doesn't exactly save it to that buffer, does it?

You have to save a buffer somewhere [preferably only once, when the preset is started] , and use this as an output buffer simply by selecting it in input or output blend mode.


I attached an example file that will serve two purposes:

1. Explain the use of Buffer Blend to JFASI [look into the FX lists' code] and
2. Will show a problem I have recreating a Unique Tone [or sth that puts color to grey similarly] with a CM.
Setting variable "color" = (r+b+g)/3; and then assigning this to r,b and g all the same should result in a grey image in my brain, but obviously it doesn't. [look into the CM]

GC

oh and /edit: it shows my decent gradient skills of course! 😞

Now, a different formula. How about using a DM? Alpha?

actually as a not-so-skilled avs'er i did prefer alpha a bit more than other options.




but maybe that's why i'm not-so-skilled 🙄

color modifier can be used to convert a pixel to another color if it is a certain color. for instance, making all white pixels black and leaving the rest alone. the way it works though is a little bit of a mystery to me. my guesswork is that it creates a look up table for each red,green,blue. this could have 255 entries as such:

r/g/b newred newblue newgreen
0
1
2
.
.
.

the recompute every frame option will update this table per frame i think

this is just guesswork, but it seems like the fastest way to do it. the obvious way of solving the problem (to actually run the code per pixel) is not practial, it comes out really slow for anything more than 4 or 5 lines of tightly optimised code.

Yeah, color modifier is suspiciously fast... What is behind that?

see color modifier calculates red with respect to itself and variables that change per frame.(thats the same of course for blue and green)
this means it needs too calculate a list with 256(possible red values) * 3(red , green ,blue) values per frame which is really fast.
if you wanted to do modify red with respect to itself and blue and green it would have to calculate a list with 256(possible red values) *256(possible blue values) *256(possible green values) * 3(red,green,blue) = 50331648 values which cant be fast.
thats why we cant easily do a saturation change with colormod

Amen. I was about to say.

damn typo!!