I am running a raspberry PI 3 and am having trouble where the camera feed goes white not long after starting the client, picture shown below. I am moving the sample glass around in front of the camera when this happens. Updates are being shown to the screen up to the point it goes white.
Any suggestions on what I should be looking at to solve this? Perhaps related to this, the ofm tool doesn’t seem to do anything when I run any of the sub commands. This is the recently downloaded raspberry pi image available here: https://build.openflexure.org/raspbian-openflexure/latest
I am viewing via a HDMI connections to the raspberry pi. Perhaps that is not how users normally connect and that is pushing it over the edge for resources.
I am watching atop and it looks like the moment the picture goes white is when the system starts paging out to disk. The only thing I am doing is moving the sample slide around on the microscope. I am guessing there is some image processing happening like autofocus that can’t keep up with the rate of change. I am hoping someone can confirm that this is consistent with that is expected. I have a Pi4 on order to arrive tomorrow and am hoping that will resolve this.
Hello!
I had a problem, somewhat different - the image rich in details disappeared when manually focusing (at that time I had no motors connected) Moving and stoping the slide did not cause problems until there was a sharpness, as soon as the focus (or close to it) was set, the image disappeared as soon as mevement stopped
Thanks for adding your experience. I have continued investigating this and suspect it is due to the higher resolution of the Pi camera v2. I see the resolution of the camera included in a openflexure_settings.json file, but not sure if I can update it to maybe 1/4 resolution.
I was also clued in to resolution being involved because when I connect from a remote computer, the network connection maxes out while previewing the images.
I would like to reduce the frequency of images being sampled to reduce the I/O rate being processed.
Hey, could you please try updating to the latest software version to check if it helps at all? We’ve changed how the camera stream thread works internally, so it might help a bit.
I am currently running into this issue. I’ve ran both commands mentioned, but the issue still persists.
It seems to indeed happen mostly when a crowded sample is brought into focus, at which point the camera feed cuts out. The actual capturing of an image is working fine, but it’s complicating the use of the microscope by a lot. Does anyone have any other ideas?
This will put you on an upcoming beta release. It may not be totally stable because of that, but this release focuses on memory improvements and include the improved autofocus from 2.7.
Please let me know if this improves the issue at all. Thanks!
I believe in my case I was running out of RAM. My config at the time was a Pi3 and the v2 pi camera (higher resolution). I would think you could reproduce if you have the same hardware setup or artificially reduce available RAM with a huge malloc or something.
From what I know the most common factor for the stream cutting out is the amount of objects/details in the image. images with few objects work fine, but as the sample gets crowded the camera starts cutting out when nearing an in-focus image. Moving the sample to a less crowded spot or moving out of focus again usually restores the stream.
it may indeed have something to do with RAM issues. I’ve tried allocating double the RAM to the GPU but that didn’t seem to help.
If this continues can we create an enhanced logging mode that logs memory usage? Something explicitly turned on for debugging? This way if someone regularly gets the issue we can ask them to try that and see if we can capture what happened in a log?
We just have to hope it isn’t a Schrodenbug where the problems goes away once we log the memory.
Yeah I’ll look into adding this. I’m not wholly convinced this is a result of a lack of memory though. It’s an interesting one, I have a sneaky feeling the issue is with the client application rather than the server so I’ll explore that route too.
I think the memory logging option is helpful either way. Are we sure this isn’t some sort of resurgence of the slightly dodgy ribbon cable? It doesn’t sound like it is, but that experience of the semi-broken cable in Panama is etch into my brain for eternity.
