Open yannickbt64 opened 2 years ago
Your assumption about memory growing due to frames being allocated at stream start is correct. VimbaPython aims to be as simple to use as possible so it takes care of these tasks, that in lower-level APIs would be done by the user. This prevents you from easily reusing frames from one stream to another and is likely the cause of your growing memory use.
If you want to trigger the garbage collection manually to free the previously allocated frames, you can do so with the Python garbage collector interface. For some examples on how it could be used in situations similar to use you can take a look at #17.
The general idea is to import the garbage collector interface and use gc.collect()
in those places, where you want the garbage collector to run explicitly. That call will block until the collection is finished. You could probably replace your call to time.sleep
with this and achieve a similar result to what you currently have.
A similar issue was encountered in #60 and the solution suggested there might be of interest, as in that issue the user also tried to implement different "stages" of behaviour in their program. Maybe the approach suggested there is something you could also implement. This might even allow you to use a single start_streaming
call reducing the problem of increasing memory due to frame allocation altogether. In that case the recorded images are triggered with the help of software triggering. This is a convenient way to get the desired number of frames for each stage. From your code I can for example see, that you want to only record a single frame after recording a larger batch of frames. This seems like something a well thought out software triggering mechanism should be able to handle.
If you could provide some more insights in the desired sequence of images that you want to record I might be able to provide a more concrete code example for you to work with.
If you do not feel comfortable sharing your requirements publicly here, you can also contact our support via the form on our website and they will be able to help you with getting a good code structure for the task you want to achieve.
We're a medical company using Alvium 1800 C-2050c for inspection on production lines.
I'm developing a new software using VimbaPython.
We need to use continuous acquisition most of the time, and make captures (for stocking on network) in singleframe once in awhile. Which is what I'm doing. Except I'm running into an issue.
I joined an MWE showing the issue, stripped down to the basics of what I'm doing.
Running this, I obtain :
Clearly, changing the value of 'buffer_count' impacts how soon the crash happens, but shows there is some kind of memory leak. I suspect the frame buffer is not freed by the garbage collector fast enough, so each call to "start_streaming()" probably creates a new frame buffer, and the memory runs short.
Tested on Ubuntu 20.04 on VirtualBox, on Python 3.8.10. VM has 4GB memory. Syslog says it killed python3 because it ran out of memory. I wouldn't mind help on this issue from AlliedVision. If we can't correct this I'm afraid we'll discontinue the use of AV cameras (which we otherwise like).
I hope you don't tell me I should not to "start_streaming" and "stop_streaming" multiple times within the same with: block. Because if it's the case, this is an awful fix. Each time we re-open the camera, that causes a delay. A delay we want to avoid at all costs in a production setting.
Thanks