loading a lot of images.

Hi, i’m using ofImage for loading about 1000 images and store them in
map<string, ofImage*> but after loading about 200 images, loading speed drops down quickly, and when loading the 410th image, the program crack!

here’s some pcode:
for (int i = 0; i < 1000; i++) {
// get name.
// get imgPath.
imgLoader = new ofImage();
imgLoader->loadImage(imgPath);
resources.insert(map<string, ofImage*>::value_type(name, imgLoader));
}

the program works well when i < 400…

Is it crashing just with the allocation of the ofImage * or are you missing the img->loadImage() from you pseudo code?

If you are actually trying to load 1000 images - what size are those images?
It could be that you are:

a) allocating more memory than your program has available
b) going over the limits of your texture memory.

Do you need to display the images or just get the pixels?
Do you need to show all images at the same time?

Cheers,
Theo

Actually I was just about to post something similar.
I too have to load a lot of images (around 1000).
For me it works, but, of course memory usage is huge and performance is so so.
I was wondering how to optimise something like this.

I have to display (and animate) all the images at the same time.
I do not need the pixeldata once the image is loaded.

Would it be possible to load the image in to videomemory and discard the data from systemmemory. Maybe only reloading them if the opengl context is lost or something?

I do not use any special geometry. Just the images.
So they are only 4 vertices, with texturecoordinates and probably a normal for each image.
Would this benefit from using VBO’s or any other newer techniques?

gDEBugger is telling me there’s a lot of time spent in redundant (deprecated) GL calls.
It says something like glEnableClientState is called like 3000 times but 99% redundant.

Any thoughts on this?

Regards,
Patrick

hey.
you could do something like this:

  
ofImage loader;  
loader.setUseTexture(false);  
  
ofTexture tex[1000];  
  
for(int k = 0; k < 1000; k++){  
    loader.loadImage("imageToLoadHere.jpg");  
    tex[k].allocate(loader.getWidth(), loader.getHeight(), GL_RGB); //assuming rgb image  
    tex[k].loadData(loader.getPixels(), loader.getWidth(), loader.getHeight(), GL_RGB);  
}  

With this approach the ofImage is not loading any textures and you only have one buffer of pixels on the cpu instead of 1000.

[quote author=“theo”]
With this approach the ofImage is not loading any textures and you only have one buffer of pixels on the cpu instead of 1000.[/quote]

Thanks for your reply.

I was just thinking about something similar.
But here you say this leaves me with a buffer of pixels on the CPU.
Is this correct?

I would prefer to have the image data to be loaded on the GPU-memory and discarded from the CPU-memory.
Otherwise the images are uploaded to the graphicscard every frame, I guess…

Patrick

no that is what happens.
once in the tex array the pixels are never re-loaded onto the GPU.

the single ofImage just means that instead of having 1000 * image pixels sitting on the cpu you only have 1.

Hmm, quite amazing!

this saved me a lot of system-memory.
Going back from 800Mb to around 460Mb.
And the loading of the images is WAY faster for some reason.
Before loading all the images took about 20 seconds, and now is almost instantanious.
Is the constructor of ofImage so expensive?

Thanks,
Patrick

thanks for the code.

maybe it is because i’ve used map<string, ofImage*> instead of ofImage[], and map cracked after loading lots of images.

anyway, i’m going to pack images first, and then use zlib for unzip it
really hard mission