memory overflow for long videos and 4K cameras

[nivesh48]

During capture volume phase for high number of cameras and high resolution videos the memory is maxing up and crashing, is there a way to batch the incoming frames and later perform the bundle adjustment?

[mprib]

Thanks for raising this. I'll have a closer look at the relevant code hopefully later this week. Finding time to work out a solution may take longer, but I should be able to start reflecting on it in a few days.

And just out of curiosity....what is a "high number of cameras" here?

[nivesh48]

This is while running the capture volume step, i was monitoring through htop and crashed when RAM usage got to 100 percent

@mprib 8 of the 4k cameras. I have not gone through the repo in deep, like streamer, etc. seems like as the frames come in the images are being stores in a variable than only the 3d/2d points, camera id's. these cameras are all externally sync'd.

[mprib]

Thanks for the information. There is a related issue where I have a note that may be relevant:

https://github.com/mprib/caliscope/issues/624

I think that part of this may have to do with the visual feedback of the tracking. I have a comment in the above issue that suggests closing the visualization window may free up some resources. Looks like that issue came up right before some major work in my PhD and coding got sidelined. That major work will hit a deadline tomorrow, so hopefully I can take a closer look afterward.

edit: re-reading my comment I think it may have less to do with the visual feedback and more to do with the fact that caliscope is currently saving out versions of the videos that display the tracked points. It's easy to imagine that this may be crashing things and may provide a path to creating a toggle option to turn off saving new versions of the video and in doing so sidestep the issue.

[mprib]

@nivesh48,

I've made updates in version 0.4.2 that are merged into main and reflected in PyPI.

It is now possible to add two new parameters to the config.toml file that can help to throttle the processing demands (shown with their default values if they are not included in the file):

fps_sync_stream_processing = 100 save_tracked_points_video = true

By setting save_tracked_points_video to false you will avoid saving out a video and can substantially reduce the overhead. You can also dial down the fps processing rate to throttle demands. I've done some preliminary testing and this seems to work.

If you can confirm that this approach addresses your issue, I will look to include these in the GUI for ease of use. If it doesn't address the issue, then let me know and hopefully we can figure out a good next step.

Regards,

Mac

[mprib]

Have not heard back regarding the issue