Hi,
I’ve referenced the docs as well as a few other threads with the goal of understanding exactly how the IDE gets the image to display. My understanding is that the current primary frame buffer (object defined by snapshot) is packaged as a jpg and sent to the IDE when calling the next snapshot. Therefore any modifications to that object between two snapshots are displayed in the IDE.
This is working most of the time for me, however I have a few paths in my logic that apply a skip_frames function of n=1. In those cases it appears that the IDE displays an unaltered frame with none of the modifications. Is my understanding correct, and why would I see this quick flash of a raw frame?
Also in my case I am using the skip frames to account for auto gain and auto exposure updates on the global shutter lens. A few other threads suggest I might not need to skip any frames for these settings to take effect.
Skip frames calls snapshot internally. So, that’s why you see the unaltered frame.
If you just need a delay you can just use the time module and sleep for some number of milliseconds. This is the same as far as the camera is concerned, but, it will mean that the video freezes for a bit. Skip frames was a way to not have the video freeze.
You can also trivially make a version of it yourself by just putting your logic in a loop that’s gated by elapsed time.
Finally, you can disable the frame buffer update in the OMV module and then re-enable after skip frames if you like.
1 Like
Using time.sleep_ms(500) still seems to be displaying blank frames. Every loop I always add text to the bottom of my frame with a version number. This does not display during this process. I can post some truncated code if that would help.
Does sensor.set_auto_gain or set_auto_exposure call snapshot internally at the time the function is called? That might explain my observation.
Yeah, we do that for various functions to make the system frame updates happen.
Note, you can use the flush() method to force the current frame buffer into the jpeg buffer. The IDE will then grab it asynchronously.
I suppose flushing is somewhat opposite and would result in more incomplete frames without processing. I did try the omv function to disable frame buffer but it seems to take a few moments to take effect.
For context, I am periodically updating exposure and gain manually as lighting changes in my environment. This can happen at various times and should process pretty fast.
In reality an LCD display shouldn’t be impacted by this, so it’s more of a flashy experience for development only.
So, you can force an update to the ide using:
.to_jpeg(encode_for_ide=True)
And then print that JPEG object. This will hard flush out an image to the IDE over USB serial. This works when connecting to a camera via REPL too.
That said, it blocks. So, your system FPS will degrade to whatever the speed you can send JPEGs is.