Hi,
i would like to copy one ofImage to another, and then grabSceen new data in the first image:
img[0].grabScreen(5,5,725,581);
img[1] = img[0]; // this doesn’t work
and repeat this several times. somehow this is not the way to do it, but i cannot find a way to copy images in another way, except for allocating the memory ‘manually’ and copying the data myself.
theo, zach, is there another way to copy images?
also: if i succeed in copying images, how do i free the memory used by an image when i don’t need it anymore?
Welcome to the forums.
Right now ofImage is not setup to be able to copy to another ofImage object. Though this will be possible in the next version which will be released soon.
For now you always grab the pixels with getPixels(); and then load the pixels into an ofTexture object.
i already figured out it would be much better to just use ofTexture for anything to display on the screen, and just use ofImage when i have to do file io.
are these textures all loaded into the graphics card? what if i want to load hundreds of pictures to show, should i then have my own arrays and load the images in textures when needed or can i just create hundreds of large (full size PAL video) ofTexture objects?
but thanx for the code, that is the way i’ll do it for now…
what you suggested would make sense to have in the next release, so I just took a look and it’s pretty easy to implement.
I quickly coded the following, you can try, if you feel comfortable poking around ofImage to add it. If not, don’t worry, we will post it shortly on the svn and in the next release… I thought some people might find it interesting anyway.
put this in “ofImage.h” in the public section, under draw for example:
void clone(ofImage mom);
put this anywhere in “ofImage.cpp”, but after the last draw is good…
and it’ll copy the pixels (as well as the info: w,h,type)
hope that helps – I think theo is right and the texture options are likely better and easier to use.
about numbers / quantity I don’t know actually! It wouldn’t be too hard to test. My suspicion is that at some point you would run out. I know there is a “priority” system for dealing with textures, and there are some gl commads for know about texture limits. I will take a look !
(that bug is actually elsewhere in ofImage – I just copied and pasted – but freeImage seems to handle memory deallocation pretty well on it’s own, so that you don’t have memory leaks… It will get fixed in the next release)