Vuo version: 

OS version: 

  • Mac OS 10.11

How severely does this bug affect you?: 

●○○○ — Not much; I'm just letting you know about it.

Steps causing the bug to occur: 

  1. Connect a list files node to fetch list of images
  2. Connect a get item from list to fetch list of images
  3. Open up Activity monitor and watch how memory consumption rises far beyond the point of the total image size and any reasonable overhead.

Other notes: 

Tested first with 2000 images at about 1.3-1.4MB each, a total of 2.43GB. Memory usage stabilized somewhat at 7.5GB, until looping through the list which caused it to go over 10-12GB.

I then tested with the full content of the folder, 12636 images ≈16GB, where it crashed my computer after eating up all the available RAM (16GB) and free disk space, somewhere north of 40-50GB.

It seems like it uses about three times more memory than the actual file size when "inactive", plus more when it is moving through the list. The crash might be more related to my computers space than anything else, but maybe it should be checked?


The Fetch List of Images node

jstrecker's picture
Submitted by
Waiting for review by Vuo Support Team
Not a bug

The Fetch List of Images node loads all of the images into memory (CPU RAM). When stored on disk (as JPG, PNG, etc.), the images are compressed. When Vuo opens the images, the images get expanded out to their full decompressed size in memory, which may be many times larger than the file size. As you saw, the total memory consumption can get pretty huge when fetching thousands of images.

The proposed Fetch image sequence node could get around this by loading one or a few images at a time (as you realized with your workaround). Perhaps it should behave similarly to Play Movie, firing out one image at a time.

More generally, there may be ways to enable more images to be used in Vuo simultaneously without running out of memory. There would be a tradeoff between memory consumption and speed/efficiency. The reason that images are decompressed when in RAM is to be able to access their pixels efficiently. Reducing memory consumption would mean not having all those pixels sitting there in memory ready to be accessed, and instead having to decompress an image at the time when it needs to be accessed.

I think enabling large numbers of images to be loaded simultaneously would be more of a feature request than a bug report (it would help to have the community's votes to see how to prioritize it), so please create a feature request if you're interested.

Ah! Thanks for the

MartinusMagneson's picture
Submitted by

Ah! Thanks for the explanation. It doesn't affect me that much, and I can always work around it if needed, but if this is a general issue with file loading, maybe a buffer node of some sort could be a better option? I'd rather see more nodes like these created within Vuo, and a larger focus on getting the compiled/core nodes blazing fast. Maybe this is better suited as a discussion as well?