Custom Blending Mode!

[Magic.X]

There should be a scriptable custom Blending mode where you could define the Blending yourselfes.

I would like to see this basically within the effect list (input & output) but everything else like buffers would be appreciated.

How should it work?

The layout & functions of the DM / SSC should do it, we only need 6 new vars:
-source#red
-source#blue
-source#green
-destination#red
-destination#blue
-destination#green

This way you can get the color values of the source frame as well as frame you want it to blend to, in coaxial or radial coordinates, as you like.

What can we do with it? Something like UnConeDs Channelshifter APE would be quite easy and as we can add loads of code hyperweird color effects would be possible, even better ones as within an dyn color movement.

*droooooooooool*

[shreyas_potnis]

forget it...winamp wont do it. i lost all hopes now. UnConeD has retired and no one else has such abilities.

[dirkdeftly]

and it's already been suggested several times.
and i'm not even sure if it's such a good idea in the first place. ask yourself, what would you actually make with this?

[UnConeD]

You do realize this would slow a preset to a crawl, right?

[Zevensoft]

I see what he means, and no it's not as slow or bad as people think. It works like this...

The old formula: dst = src*alpha + dst*(1-alpha) for each component.

What he's suggesting: dst = src*alpha1 + dst*alpha2 + alpha3 for each component.

Basically, instead of just specifying alpha in a DM, you can specify alpha1 = 1 and alpha2 = 1 for additive, alpha1 = .5 and alpha2 = 1-alpha3 for 50/50 blend (original style), or even alpha1 = -1 and alpha2 = 1 for subtractive. Just imagine the weird effects possibly by playing around with alpha1, alpha2, and alpha3 (the bias).

[Zevensoft]

And yes, having r_alphax, g_alphax, and b_alphax wouldn't slow it down, since it recalcs the blend code for each component anyway.

[Magic.X]

In fact i mean

The RGB source values (the frame you're blending form, the just calculated one):
alpha_r_s
alpha_b_s
alpha_g_s

And the RGB destination values (the frame you're blending to):

alpha_r_d
alpha_b_d
alpha_g_d

Only little changes with awesome possibillities.

[Edit] Atero, i WOULD make some great color movements. Doing something like a channelshifter including blending between modes would be some of the easiest thing s you coud do. It would be a new way to render objects, as you can define colors now. It would be f**king great!

[UnConeD]

Okay now I just don't get it. How would you do a channelshifter with this setup? You'd need a 3x3 matrix of coefficients for both source and destination... otherwise there is no way to swap information between channels.

Though you have to remember that the whole blending pixels thing is done through very fast MMX assembly code. AVS doesn't split the channels into separate components, it works with all 3 at once.

The alpha_r_s/d, alpha_g_s/d, alpha_b_s/d thing would only work with positive alpha's in the range 0..1 with the exception that one of the two sets can be completely negative.

This is how alpha blending is done:
* 32-bit pixel 00R1G1B1 is mmx-unpacked into 0000_00R1_00G1_00B1
* 32-bit pixel 00R2G2B2 is mmx-unpacked into 0000_00R2_00G2_00B2
* pixel 1 is multiplied by 0000_00S1_00S1_00S1, where S1 is its alpha value * 256 (_ = separator, the whole is a 64-bit number).
* pixel 2 is multiplied by 0000_00S2_00S2_00S2 where S2 = (256 - S1)

After multiplication, the two pixels are added together, so each channel will contain a value between 0 and 65536 (2^16). Then the lower bytes are discarded and the result is packed back into a 32-bit color.

This means that (alpha1+alpha2) always has to be 0..1 (and both alpha1 and alpha2 separately separately as well). Otherwise after multiplication and addition, the channels will not fit into 16-bits and overflow occurs.
This is also what happens with convolution.ape when the sum of all values in the matrix is > 256.

Negative alpha values could be allowed for one of the two, by simply subtracting the colors instead of adding them.

Instead of one alpha value, you could allow several alpha values so that instead of 0000_00S1_00S1_00S1 you multiply by 0000_00A1_00B1_00C1 (3 separate alpha values).

The only thing you could do is NOT use MMX, but then it would indeed be ultra-slow.

[Zevensoft]

Damnit, and I here I am thinkin MMX was high and mighty. At least you explained it in terms I could understand, no DUnCe.

[Magic.X]

UnConeD, this is fore sure nothing for an selfmade APE, this would be a supercomplex high end plugin - which in fact could only be made by the nullsoft guys.

To answer the MMX Question: do you think DM works without MMX? Nope. So this is possible too with seperated color channels.

How can i do Channelshifting? Simple we switch on beat between 6 modes

This is an example for mode 1 (RGB -> BRG):
col_r_d=col_b_s
col_g_d=col_r_s
col_b_d=col_g_s

This is an example for 50/50 blending:
col_r_d=(col_r_d)/2+(col_r_s)/2;
col_g_d=(col_g_d)/2+(col_g_s)/2;
col_b_d=(col_b_d)/2+(col_b_s)/2;

This shows how we do 50/50 on red channel, max blending on green channel and source red -> destination blue channelshifting at once:
col_r_d=(col_r_d)/2+(col_r_s)/2;
col_g_d=max(col_g_d,col_g_s);
col_b_d=col_r_s;

Understood now what i meant? (Sorry for the confusing expression "alpha" in my last post "COLOR" describes best what i mean)

[UnConeD]

Magic.X: what you're describing would be ULTRA slow. Trust me, even Nullsoft couldn't speed that up.

Compare it to a superscope with n=320*240=76800.

[shreyas_potnis]

Magix, UnconeD told me this before, you will have to split RGB values of the color, then do all the alpha-blending stuff, then convert this back to color. I have played around all this stuff when I was making Dynamic Clear Screen and now understand parts of it.

btw. This will have to be so many times!

[dirkdeftly]

unconed - i think magic is suggesting this would work the same way as dm, with a much smaller amounts of calculations per frame (say 28x24x3=2016). this would still be far too slow though...equivalent to three seperate complex dynamovs.

[UnConeD]

Err atero, the formulas HAVE to be evaluated per pixel. No way around that.

[dirkdeftly]

...how come...?

[Magic.X]

Anyway, i think debating about "possible", "impossible" or "possible but überslow" aint the right way.

Most of you will agree thast this effect would kick ass, so why don't put it into the whishlist???

Besides, by now there are more powerfull optimized programming methods out there than MMX. There gotta be a way to do this, or how do modern Animation or Photoediting progs handle their work?

[UnConeD]

Magic.X: easy, they don't work real-time :P.

[sidd]

so if that idea would be so slow, how come your channel shifter aint?
Im pressuming that you cant use mmx at all for that.

[UnConeD]

Because channel shifter just switches the channels around without doing any processing on them.

Here are the instructions I use to process one pixel in the eax register.

e.g.
RBG:
xchg ah, al;

BRG:
mov dl, al;
shr eax, 8;
bswap eax;
mov ah, dl;
bswap eax;

BGR:
bswap eax;
shr eax, 8;

GBR:
mov edx, eax;
bswap edx;
shl eax, 8;
mov al, dh;

GRB:
shl eax, 8;
bswap eax;
xchg ah, al;
bswap eax;
shr eax, 8;


As you can see, the amount of instructions depends on the mode, because of the way an x86 processor is layed out.
Doing a custom blend mode would require at least 40-50 lines of assembly code per pixel and that would be in the case of optimized compiled assembly. In reality, the code you type yourself would be executed slowly and inefficiently because writing a decent, optimizing compiler is waaay out of the scope of this project.

[shreyas_potnis]

Simple and fast rgb swaping example is given with Render / Picture II source

[Magic.X]

Originally posted by UnConeD
Magic.X: easy, they don't work real-time :P.

My Photoediting prog gives me a realtime preview (fullsized) so i can adjust the effect and add it if i'm done. Whats the Diffrence now?

This effect is just the same as a blend only DM - perpixel manipulation. If you like we could specify a rastersize (just as the DM has) to save some rendering power.

Anyway, we shouldnt drop the idea just because we think its impossible. This is a WHISHlist not a READYSOLUTIONSlist

[sidd]

MagicX, good point.. but if you use a grid, like the dm's, how do you calculate inbetween pixels? Bilinear wont work.

[UnConeD]

Eh?
MagicX... AVS has to render at 20-30 FPS. That means maximum 50 ms to do this effect, and that's for a preset including ONLY this effect.
A much more realistic target would be 5-10ms or less.

Your photoshop might look 'realtime', but it probably has a latency of about 300-400ms.

Anyway I'm tired of discussing this. If you're so convinced it IS possible, then by all means, pick up a C++/ASM book and start coding!

[Magic.X]

This is so depressing...!

[jonasc1]

Maybe if it was a plugin like an Ape with a extra blend mode. some APE's have blend modes. so since it works in an ape so why should it not work alone in a way the AVS understand it. So wath im sayin is not a scriptable blend mode system but as an plugin writen in some computer language like APE's.
Did anyone get it?

[mikm]

don't revive threads, god damn it!!!

Anyways, if we wanted to access buffers, an APE could not handle that. APEs are .dll's and are written in c++


and please read the rest of the thread. I think you do not understand what you or anybody else is saying.

[shreyas_potnis]

jonasc1, did you read the previous stuff?

[Magic.X]

Unlikely, or he did'nt understands it maybe this discussion got too technified.

I recently downloaded the new Athlon 64 tech docs to see wheter there is a solution to this problem.

With the lack of Buffer Access it could be done as an APE. The main question now is only the speed.