Render Picture II

As you might know, I'm working on a "Render > Picture" replacement that expands the flawed original.



This is what it looks like at the moment. Firstly, it's faster than the original for most pictures (except tiny ones), because it calculates the enlarged image only once rather than every frame. This also means it does bilinear filtering at no cost at all (only the pre-processing takes a bit longer, but that happens only once). I also implemented all the standard blend modes (replace, 50/50, additive, maximum, sub1, sub2, multiply, xor, adjustable).

Currently it only does .bmp, but I'm currently figuring out libpng (for .png support). Once that's done, I'll try JPEG, if I find a good library.

However I have a few questions about what else I should do. For instance, the original component has a "blend 50/50, onbeat additive" mode. This would logically expand to an extra output selection box for onbeat, so you can do any combination of regular and onbeat modes. However, I've almost never used this feature, so I'm not sure if I should implement it. Do you guys ever use it?
You could easily duplicate this effect by using two instances of the picture renderer in onbeat-switched effect lists, where one receives an inverted beat pattern.

Next is aspect ratio correctness. Implement it?

Finally any other suggestions? I don't want to turn it into one mega component though, because you can do quite a lot with AVS already. This APE is of course mainly aimed at experienced AVSers, so I'd like as little fluff as possible: only really useful stuff.

Next is aspect ratio correctness. Implement it?

definetly

(if that is what i think it is: a way to strech pictures so they fit better)


oh yeah, i hope you get .jpg support, you would be the coolest .ape (programmer) around 😛

Could it be possible to define the position of the picture? (like in text)

Yes you can do it with movements, but if it's faster to implent it directly to the ape it would be better.

I was also wondering about defining the picture size also. Possible? fast?

Or am i just talking crazy 🧟

Yeah, have an option for size based on both percent and absolute pixels.

hm, does this work with transparent PNGs aswell?

If I manage to read PNGs, making an additional blend mode "Alpha channel" shouldn't be a problem.

Alpha channel sounds infinitely useful. I don't suppose youd be able to make a 'draw alhpa channel only' option? Then you could make 'quake 3 shader' style effects for textures. 🙂

Either that or have multiple blend modes for the alpha channel... but I think that would be the more awkward way to do it.

If you could add possibilities for "On "N" beats change picture" will be cool. User may chouse folder with pictures and program will load pictures in name order or randomly from this folder on every "N" beats. Or may be instead of loading from one folder user may create playlist with pictures (from different folders) than program will load files from this playlist again in playlist order or randomly.

If you want to use multiple pictures, wouldn't the improved AVI player be better?

As I said, I don't want to make a mega APE, just fix the flawed Render / Picture.

"alpha channel sounds infinitely useful. I don't suppose youd be able to make a 'draw alhpa channel only' option? Then you could make 'quake 3 shader' style effects for textures."

I'm not sure what you mean. If you want to draw the alpha channel, why not just use that as the image?

I was just thinking about saving on pictures. Where as you would need two pictures for a texture and an alpha channel you could save on the number of pictures needed by using the same one for both. You might want to use the alpha channel from the picture on something else as well as the picture, say if you wanted to add blend some scopes over a picture (for whatever reason) and you wanted a circular black hole in the middle, you could recycle the alpha channel from the picture to multiply with the scopes to get the hole in the middle of them to match exactly with the hole in the middle of the texture so that when you add them together you don't end up with scopes in the hole.

Just do a subtractive blend of a picture of the alpha channel on the scopes? By the way, additive blending doesn't need an alpha channel 🙂.

I'm only going to do replace-alpha blending. Most other modes don't need it (you can modify the picture itself), and I fail to see the point of an alphablended XOR for example 🙂. Besides, you could use a regular AVS buffer blend for that anyway (see what I mean with keeping it simple? 🙂).

Like I said... I was just thinking about saving on the number of pictures used. You'd only need 1 picture rather than 2, it keeps the pack size down. Its not mega important, I just thought that it would be nice.

This Render/Picture II sounds really good anyway, and really fast.(framerate = god)

🙂

For the blending, I think this would be the fucking shit:

Normal blend: blend options (adjustable slidebar and %)
X On-beat blend: blend options (adjustable slidebar and %)
. X On-beat frames: n
.(X After beat decay: x)

(blend options: ignore, replace, max, min, sub1, sub2, buffer, multiply, pixel w/alternate, line w/alternate, xor, adjustable)

X is a checkbox, and (...) is an option that's only useable when using adjustable blend. On-beat frames keeps the blending option for n frames, and after beat decay (only with adjustable blend on both normal and on-beat) starts decaying the on-beat setting back to the normal setting at rate X. Adjustable % is a textbox to specifically set what percent of the picture is used (instead of just a slidebar). Lastly, the pixel/line w/alternate means that it uses the alternate set of pixels and lines.

The aspect ratio correction NEEDS to be there. Have it just be correct, instead of making it correct on either the x- or y-axis. Also have it correct ******ds OR inwards. (in other words, if the picture is taller but thinner than the window, have it either expand to the width, or shrink to the height.)

Was that too many suggestions? 😛

Buffer blend is not possible because APEs can't access the internal AVS buffers. You'll have to use an effect list.

I just implemented minimum blend, because it's just switching around two lines from the maximum code 🙂.

Why would you need a percentage box? I doubt you'll notice the difference between 38 and 39%.

Does anyone *every* use those alternating pixel/line patterns? 🙂 Think of stuff you're going to use, not stuff that just sounds cool :P.

Have it just be correct, instead of making it correct on either the x- or y-axis. Also have it correct ******ds OR inwards.

By the way, that first sentence doesn't make sense. You can't 'just correct it'. Unless that 'also' in the second sentence wasn't supposed to be there.

Cool we are going to have a new Unconed ape. 🙂
What is minimum blend and how does it work?

Minimum blend blends the two pixels as little as possible.


I meant that instead of correcting on the x-axis OR the y-axis, which can result in either shrinking or zooming the picture, do one or the other in all cases. So if correct inwards is turned on, you would shrink either the x-axis or the y-axis to fit the window, and vice versa for correct ******ds. Do I make sense now?

BTW, I have uses for both a manual percentage text-box and an alternate every other pixel. They're hard to explain, though. And come to think of it...they don't really apply to render / picture. Never mind 😉

Minimum blend simply compares the channels of the two pixels and always takes the lowest value, just like maximum blend takes the highest value from the two.

E.g. blend (128, 0, 200) with (0, 50, 100):

minimum: (0, 0, 100)
maximum: (128, 50, 200)

Does anyone *every* use those alternating pixel/line patterns? Think of stuff you're going to use, not stuff that just sounds cool :P.

If someone want's to use that they can just DRAW it in the picture 😛

steven, what does the xor blend actually do

It performs a bit-per-bit binary XOR... just like the regular AVS XOR mode.

umhh, the thing is that i meant was that i did't understand what the xor blend avs does actually (how does it work)?

The binary XOR does an exclusive or on the bits by returning 1 if the bits are different and 0 if they are the same.

eg.


00101101
xor
11011101
---------
11110000

In AVS it just uses the colour for the foreground and background to XOR, the colours are in hex in the form 00RRGGBB where RR,GG,BB are the red, green, blue out of 255 in hex. Since hex digits are equal to 4 bits each you can easily convert this into binary and do the XOR blend. For instance, xor blending a = red=255,green=64 and blue=8 with b = red=64,green=128 and blue=0 you convert this to hex, then binary:

a=00FF4008
b=00408000

(ignoring the front zeroes)

   F    F    4    0    0    8

a=1111 1111 0100 0000 0000 1000



   4    0    8    0    0    0

b=0100 0000 1000 0000 0000 0000



          11=B 15=F 12=C 0=0  0=0  8=8

a xor b = 1011 1111 1100 0000 0000 1000 

so the result is 00BFC008

so the resulting pixel will have color:
red = BF = 11*16+15 = 191
green = C0 = 12*16+0 = 192
blue = 08 = 0*16+8 = 8

😁

EDIT: Oh... and the reason for the two leading zeroes is to make it fit into 32 bits. I know that in a targa file you can use those extra bits to store the grayscale alpha channel information, its probably the same with other formats with alpha channels.

The reason AVS uses 32-bit as well is for processor reasons. The Pentium memory bus is 32-bits wide and has to fetch data from 32-bit aligned addresses.

Suppose AVS used 24-bit instead, it would sometimes have to fetch 64-bit to get one whole pixel:

R1 G1 B1 R2 | G2 B2 R3 G3 | B3 R4 G4 B4

In order to get the second pixel, the two first chunks have to be
fetched.

R1 G1 B1 00 | R2 G2 B2 00 | R3 G3 B3 00 | R4 G4 B4 00

So by padding with zeroes, you get an increase in memory size, but a large speed-up as well.

And yes, usually 32-bit color means RGBA (with an alpha/transparency channel) instead of RGB0.

[offtopic]

Meh.. the x86 architechture is crap. All of its problems spawn from intels foolish desire to make every single processor fully backwardly compatible, I mean who wants to run software written for the 4004 on a Pentium 4? Thats just insanity.

Personally I think that they should start a new architecture from scratch and make their processors be compatible with both for a few years, then phase x86 out. Or they could slowly introduce the new one... anyway, it shouldn't be too hard a thing to organise and maybe they would learn a lesson, like 'do things properly in the first place'.

[/offtopic]

Isn't that what IA-64 is supposed to be?

I'll have to ask about that, most of what I know about the architecture comes from the intel (propaganda filled) manual and pak-9 (who is doing a degree in software engineering). But as far as I am aware the IA-64 is going to retain all backward compatability, its one of the things that intel is most proud of (god knows why) so it will still have all of the flaws of x86.

Apparently one of the biggest flaws is the program counter which uses two registers because it needs 20-bits, so it uses 2 16-bit registers where a single 20-bit or 32-bit register would do fine, and also make everything run much faster.

Heres an email I got from P9 on how flawed x86 is.

yea I don't have time right now to list the shit things about x86 but I assure you there are many. Oh, okay you twisted my arm, here's a couple:

When intel made their processors (8086) they made 16 bit registers, and you could access the top and bottom part of the registers as 8 bit. So the register AX could also be accesed as AL and AH (A low/A high). But when they added all the crap on to pentium processors to make them 32 bit, they just slapped another 16 bits to make the registers bigger (so AX for exaple became EAX). BUT, they didn't make it so that you could access the registers top 16 bits independantly, only the lower. This meant it was backwardly compatible with older software that stil accessed ax,bx etc... But why the hell didn't they make it so that you could access the top 16 bits? it just ripps off a load of capability for no reason.

I think I already told you about the instruction pointer/code segment
register fuck up too.... Rather than make 1 24 bit (I think 24 bit is
enough) register that was the instruction pointer, they made a code
segment register that points to the beggining of the code in memory, then ANOTHER register (the instruction pointer) that points to the point above the code segment register where the next instruction is.WHY intel? WHY? what a big fat waste of a register.

P9

If you think regular x86 is incomplete, check out MMX. It's as if they took a list of all possible instructions, and then picked only a few implementations.

For example, you can't shift 8 packed bytes, only 4 packed words or 2 packed dwords. Or, comparisons only work on signed integers, not unsigned. So you have to flip the sign bit before and after doing a comparison of unsigned ints.
Division is also missing.

All in all, quite annoying :P.

I thought that they tidied that up with SSE and SSE2. I know that they included a lot of other packed types, like double and single precision floats.

Yeah but SSE is far less common than MMX. Plus, it seems MSVC++6.0 doesn't understand SSE instructions... so I can't use them at the moment anyway.