Is it possible to make an image array?

Hi again, I have a .gif of a cartoon dog running and I want to make some simple left and right key controls to make the animation of the dog running play backwards and forwards. I figured that I might be able to put each frame of the animation as a separate image in an array and then use a counter and the keyboard commands to go backwards and forwards through the array. Below is an example of what kind of nodes I’m going to use, except instead of the rainbow hue array I’d like it to be an image array. Are image arrays possible? I’m aware that I could input an image using a texture node but it’s not quite what I’m going for

You’re kind of hyperactive, I must say.
Type player in node browser, right click on Player (EX9.Texture), enjoy helppatch.

vvvv’s arrays are called spreads, you should have a look at tutorials in the documentation.
vvvv is great because it lets you doing things quickly, but a bit of theory ain’t that bad.
Anyway, have a look also at this: contributions/1353+1355/ all, in particular at
parasitic-design-a-vvvv-beginners-cookbook.

And not to forget the girlpower-folder in your vvvv’s directory. There’s also one in the addonpack directory with lots of very useful demos

so in short:
use the filetexture node, load the pictures, voila, a picture array on the output pin. now use a getslice and its index pin to put one of them at a time on the quad.
this is not memory friendly, but it will work for a start =)

@guest
Player node is the best choice for images sequences - since we’re talking of extrapolated frames from a gif -; as a plus this node supports TIFF format, which is not the case of FileTexture.
It substitutes the FileTexture + Prelaoder combo, improving performance.
What @RadokaMadoka may need to understand is that textures’ filenames have to be in a frameindex style (img_000.jpg, img_001.jpg, …) as far as I know.
Then again, as of vvvv45, it is called spread and not array.

hey h99, your tips were absolutely ok no problem.
that would be the pro way for a serious project maybe. of course, ideally you want to “stream” the files from the disk as they are needed. Loading everything into memory at start is not very elegant and will limit you at some point pretty quickly.
just presented a more simple approach for a quick and dirty way. it gets you super fast and easy where you want to be regarding the question.
yeah i know the player node. not sure i would throw it at a beginner :)
All those pins and spread logic to maintain for a nice back and forth preloading.
I don´t think he aims for a scalable high performance system right now but just wants to play and try? -correct me- :)
And yeah spreads, arrays, who cares, it is the same damn thing, agree? :) just adjusting a bit to the wording of TS to make a smoother dive into v4 - i thought it was funny. cheers

Ok, just talking.
Playing a sequence with FileTexture, is “fine” of course. And since the source images are from a gif, for sure they won’t be huge, so with a nice harddisk one would be probably able to run a smooth animation with no hiccups.
But anyway, a correct way to do this with FileTexture, is using also a Preloader node, which, if I’m not wrong, should load all images into memory, so that user will face memory stuff and so on as with Player - not so much actually, since Preloader loads all the textures, while with Player one can choose the amount of frames to preload.
That said, it’s just a matter of approach: I just thought that RadokaMadoka should have a look at documentation; and since s\he already posted some other stuff elsewhre in the forum, I thought that s\he can and should manage more “complex” nodes.

BTW, I take spread, over array.
You won’t array Nutella on a slice of bread.
You will spread it.
And since vvvv is the sweetest thing, it’s spread not arrayed.
A spread on bread, remember.

hehe i dont like nutella but anyway, as i understand the preloader module, it is meant as a convinience thing. so you can argue about it beeing the correct way. there is no performance wise difference to the default usage of filetexture beside you specify the file loading properties at a seperate location. the filtexture nodes across your patches must be then used in the “use preloaded item” mode and the input filepaths are then used as internal refferals to the already preloaded images. thats all to that.
so basically dir -> filetexture -> getslice -> quad is the very same thing.
and that is good for a simple patch i feel. but importanter: you get something up on the screen:)
and yeah @RadokaMadoka rtfm noob! no just kidding =) but of course reading documentation, watching westbam, girlpowering and F1 is key to get the concepts and get forward, what else.
then you should go with the player node and specify multiple directories across multiple SSD RAID drives where you can preload frames for backward and forward seeking and have almost instant (fps wise) access to your vast amount of high quality tiffs at insane resolutions and colour depths. cheers

“there is no performance wise difference to the default usage of filetexture beside you specify the file loading properties at a seperate location. the filtexture nodes across your patches must be then used in the “use preloaded item” mode.
so basically dir -> filetexture -> getslice -> quad is the very same thing.”

Uhm, yes, so if you don’t enable the use of preloaded items, preloaded item are not used.
Really, I don’t get why you specified this… It’s in the Preloader helppatch (Use Preloaded Item IOBox), so I don’t get what this should add to the conversation… unless I’m missing something.

Well. At this point I’ll share my experience with a folder of a 30fps animation made of 150 png 1024*1024, playing back at 30fps in patch via 1/30 in LFO Period.

With Preloader (and may I have to specify with Use Preloaded Item = 1?)
Until all images get loaded, I get white frames (no texture = white quad, I mean).
After all images loaded, I get a smooth animation.
Having a look at TaskManager, I see ram reasonably going up and then going down.

Without Preloader (only dir > filetexture > getslice > quad)
No white frames but
No matter what, animation is not smooth at all.

With Player
No white frames
Animation is smooth from the first frame.
Memory raises quickly, and stays there (so I was wrong here).

I’ll stick to Player, as first choice, to Preloader, as second, to lone FileTexture if it has not to be an animation - not RadokaMadoka’s scenario.

It’s not important if you like Nutella or not.
If a child asks you for a slice of bread with Nutella, you’re going to spread it anyway.

ok:

"Uhm, yes, so if you don’t enable the use of preloaded items, preloaded item are not used.
Really, I don’t get why you specified this… It’s in the Preloader helppatch (Use Preloaded Item IOBox), so I don’t get what this should add to the conversation… unless I’m missing something."

hey you brought up the preloader module as the correct way :) i am just saying, there is no difference whether you use that module or not. the time to load the files will be same anyway.
at the end of loading (in both cases) the textures are just sitting around at the output pin of filtexture and waiting to be called on the quad. and a getslice from there on will be always smooth!
And again prelaoding is just a convinience way for a centralized file loading.
You have to wait anyway. no matter whether you load the files with the preloader
or with the pure filetexture or even use the “load in background” pin. its the same thing: you wait for the loading :)

But at this point i see where you mistaken or might have something different in mind but writing this:

Without Preloader (only dir > filetexture > getslice > quad)
No white frames but
No matter what, animation is not smooth at all.

Please see that the node chain you describe IS a preloading scenario.
There is no preloader module involved, but what is really happening is: preloading.
You have loaded a dir of images, then you getslice them. They are preloaded, seems i am writing in circles, sorry :) there is no way this would stutter at 30fps.

Are you sure you did getslice the textures and not the filepaths in this example?
Because no smooth animation sounds like getslicing the paths. please try if you doubt.
A getslice behind the filtexture will always be smooth because loading
already happened and everything is in memory at this time.
i hope you see why we seem to to talk past each other =)

Maybe we should add that there is a exception to this (getslicing the paths)
when you use DDS files. Depending on the speed of your drive, resolution and DDS format
you can have pretty smooth playback with that method. without preloading anything =)
(if you want to try make sure you start vvvv with the good old /dx9 switch.
for whatever reasons the process is not smooth with the new default /ex9ex )

So, I have to retreat.
I swear that for me that GetSlice has always been between Dir and FileTexture.
Early morning fresh air is the best.
Yes, what you say somehow “replicate” Preloader functionality, thus we have the same thing.

  • I have to admit it. I need patches to understand what’s going on.

I just want to add that the approach you suggest, which produce a smooth animation both in /ex9dx and in /dx9 mode, freezes vvvv until all 150 images are loaded into memory. Only then the animation starts.
So in case one would like to switch from one animation to another, this would mean a stop in the show.

I guess that with Preloader one loads first animation, then, when needed, the second one, then unloads first and get ready for the third and so on, without freezing.
Loading everything in memory could not be the best thing to do every time.
But this is beyond this conversation.

Does this freezing happen with your machine too?
It is probably due to my system, which is closer to a wc rather than to a pc.

  • No Clorinda, I’m just joking… Come on, you can’t be s

uff, i am glad we figuered it out :)
so just to be clear. dir > filetexture > getslice > quad is not replicating preloading, it is exactly what the preloader module does. Really there is nothing else fancy involved. you could now for example go elsewhere in your patch and load the same files in an other filetexture node that is set to “use preloaded items” and have the same textures without no time of loading. That is useful when you want hard switch paths on that other filetexture node without stutter or blocking vvvv.
And regarding blocking vvvv, just enable the “load in background pin” then you can watch the textures been loaded one after the other (no freezing v4). Thats where you get white quads, because the spreadcount will be the first thing v4 sets up, so instantly you will have x textures but they are not filled yet.
There is nothing one can do about the waiting time, whether blocked or non blocked.
And yes, as i said, we are limited here 1. by the loading time for the sequence and 2. by the amount of memory to store all those textures. No way to have hundreds of sequences and switch them seamlessly. but its a pretty simple and peformant approach for trying out on a small scale.
Of course the player node is vastly superior to this and the way to go for some serious stuff.

What i said regarding /dx9ex is just for the case of loading DDS.
There you go dir > getslice > filetexture > quad. The DDS format is pretty much the internal GPU format for textures so neither the CPU nor the GPU have much to process on that when its laoded. It seems the data just slips right from the disk into memory without decoding/transcoding or what not. That saves a lot of time, and the crucial factor seems to be the read speed of the disk (SSD preferably). When the read process takes less time than a frame lasts (1s/60 or 30), everything goes smooth.

And maybe finally for RadokaMadoka:
Yes it is possible to make image arrays, uhmm i mean image spreads :)
Just keep the limitations in mind. For more advanced things go with player.

cheers

“uff, i am glad we figuered it out :)”
We? It was just me.

May I troll you a just a little bit?
This is no longer a simple approach for a beginner.
Better use Preloader, then.
Lol.
Sorry.
I’ll stop here.
Have a nice life.

haha, you have a weird sense of humor i would say.
is there STILL anything unclear to you by now? ;)
i will not be able to write the word preloader for much longer
again and again without going completely nuts…

Still unclear.
Animation crystal clear.

oh you´re not over it?
nah anyway, that was a hell of a joke,
i must say, respect sir!

best since poof

@hrovac
This is an offence.
No joke.
I mean, if you see me as an other @poof.
Unless you’re https://discourse.vvvv.org/, https://discourse.vvvv.org/.
In this case I’m flattered.