Magic.X

20th May 2003 11:38 UTC

Custom Blending Mode!
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* :D

shreyas_potnis

20th May 2003 16:07 UTC

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

dirkdeftly

20th May 2003 16:54 UTC

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? :igor:

UnConeD

20th May 2003 17:55 UTC

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

Zevensoft

21st May 2003 07:24 UTC

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

21st May 2003 07:30 UTC

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

21st May 2003 11:35 UTC

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

21st May 2003 12:52 UTC

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

21st May 2003 14:56 UTC

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

22nd May 2003 11:48 UTC

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

22nd May 2003 12:12 UTC

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

22nd May 2003 13:38 UTC

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

22nd May 2003 21:28 UTC

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

23rd May 2003 02:56 UTC

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

dirkdeftly

23rd May 2003 03:01 UTC

...how come...?

Magic.X

23rd May 2003 11:34 UTC

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

23rd May 2003 15:17 UTC

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

sidd

24th May 2003 05:36 UTC

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

25th May 2003 23:11 UTC

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

26th May 2003 09:54 UTC

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

Magic.X

26th May 2003 11:32 UTC

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

sidd

26th May 2003 12:25 UTC

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

UnConeD

26th May 2003 13:50 UTC

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

27th May 2003 11:35 UTC

:hang: This is so depressing...!

jonasc1

20th June 2003 18:32 UTC

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

20th June 2003 18:49 UTC

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

21st June 2003 16:07 UTC

jonasc1, did you read the previous stuff?

Magic.X

23rd June 2003 15:55 UTC

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.