That's true, but this machine is a dual G5 and has over 2GB of RAM;
we're able to pre-load all of these stimuli under our old workflow on
a G4 with 1GB of RAM using PsychToolbox. I know it's not a RAM
issue; rather, I'm running into a limit on the number of open files,
which I can override in the shell or a sysctl value, but is a kludge.
While it's true that I could load the next stimulus during each
controller run, I'd rather not unnecessarily complicate things. As
well, I'd rather not deal with accessing the hard drive needlessly
during the experiment.
What I'm looking for is a way to force PIL to read the data from the
file and then close the file; I'm not conversant enough with PIL to
know how to force this and was hoping somebody on the list might know
(I haven't figured out in VisionEgg where in the process PIL is used
to actually load the Texture into open gl, thus closing the file
handle).
Thanks,
nick
On Aug 15, 2005, at 9:38 PM, Mark Halko wrote:
Nick -
Have you considered dynamically loading the images? It sounds like you're running out memory in some spectacular way.
An option would be to have your controller (if you end up using one) load the next image while an image is displayed.
At the very least, if this is a "standard" blocked design, you may be able to load images a block at a time.
fMRI should give you plenty of lead time, if you are briefly presenting pictures, you can load during rest conditions, or load during long duration presentations. A modern computer should be able to handle the loading faster than you might imagine.
Mark
On Aug 15, 2005, at 8:18 PM, Nick Knouf wrote:
Hi everybody,
(note: this will probably be the beginning of a large barrage of questions as I try and implement a standard blocked design fMRI experiment in VisionEgg)
I'm trying to pre-load a large number of stimuli for an experiment; say, on the order of up to 400 or so. My loop to load the stimuli is the following (taken out of context):
stimuli = []
for condition in filelist:
texture_list = [Texture(filename) for filename in condition]
stimuli.append([TextureStimulus(anchor = 'center', position = (round(position[0]), round(position[1])), texture = texture, size = texture.size, texture_min_filter = gl.GL_LINEAR) for texture in texture_list])
(filelist is a list of images to load, indexed first by condition, next by image; in this case, it's a list of dimensions 4 by 80)
It seems to bomb out at around 200 images, however, giving the following error:
2005-08-15 20:13:16,390 (7856) CRITICAL: Traceback (most recent call last):
File "test_rsvp.py", line 65, in ?
File "/Users/nknouf/Development/VisionEgg_work/nklab/experiments/ common.py", line 67, in createTexturesFromFilelist
File "/Users/Shared/Library/Python/2.3/lib/python2.3/site- packages/VisionEgg/Textures.py", line 171, in __init__
File "/Users/Shared/Library/Python/2.3/lib/python2.3/site- packages/PIL/Image.py", line 1717, in open
IOError: [Errno 24] Too many open files: '2 objects/gun 25.tif'
Looking at the source for PIL.Image, it appears to be running into the per-user open-file limit (since it runs the standard-library "open") command. I know that PILs open command only creates a file-handle, and actual reading of the data is deferred until later.
Is there a way to force PIL, through VisionEgg, to read the file when creating a Texture() object, such that I don't exceed the open file limit? I know I could simply increase the limit, but I'd rather not do that.
Thanks,
nick knouf lab manager, kanwisher lab
PS BTW, is there a reason why all of the demos use " texture_min_filter = gl.GL_LINEAR" as a keyword argument to TextureStimulus, especially since the help information says that texture_min_filter already defaults to gl.GL_LINEAR?
======================================
The Vision Egg mailing list
Archives: //www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html
====================================== The Vision Egg mailing list Archives: //www.freelists.org/archives/visionegg Website: http://www.visionegg.org/mailinglist.html
====================================== The Vision Egg mailing list Archives: //www.freelists.org/archives/visionegg Website: http://www.visionegg.org/mailinglist.html
