Using Request functions in signal_function

[marsfan]

Section 6.5 of the picamera2 manual talks about performing asynchronous captures, and the use of the signal_function parameter to add a callback function when the capture completes. Since this function takes a single job parameter, I was hoping to be able to define a callback function that then saves the image and metadata to the disk. when the capture is complete, allowing other tasks (namely a remote server) to continue its event loop during the capture.

But the section also states:

The signal_function should not initiate any Picamera2 activity (by calling Picamera2 methods, for example) itself, as
this is likely to result in a deadlock. Instead, it should be setting events or variables for threads to respond to.

I found this a little big vague. Does this mean all functions in the library, or just the camera control ones? Are the methods on the job argument (such as get_result()) and the completed request it encapsulates considered safe to use, or should they be avoided?

[davidplowman]

I'm sorry this is a bit vague. The functions that will definitely cause trouble in the signal_function callback will be ones that can block waiting for camera frames to arrive. So that would include all the capture_xxx methods, stop, switch_mode methods.

Where you have an array, or a request, I think fishing data out of it, saving it, that kind of thing is fine. I think you can probably even set controls and release a request too. Though bear in mind that you are inside the camera loop here, so you probably don't want to do anything super-expensive either - but I guess it's a case of trying it and seeing how it works.

[marsfan]

Great. That should make some of what I'm planning on doing much easier. Thanks

[marsfan]

@davidplowman So actually, I do have a follow up question then.
With the request returned by a capture operation, does not releasing that block the camera even loop, or is it ok to store that and then process it later. (I've noticed there's a release method on the requests, which is what leads me to asking this)

So for example, would having the signal function push the requests into an array, and then later (potentially up to a few minutes later) I call the save_dng method on each in a loop be a bad idea, or is it fine to do something like that?

[davidplowman]

I think that would be fine. You can hang on to requests as long as you like - with the proviso that the fewer requests you have in circulation, the more likely frame drops will be. Of course if you're hanging on to all the requests, you'll never get any more camera images until you start releasing them.

You can increase the number of requests/buffers substantially using the buffer_count parameter of the create_xxx_configuration methods. At typical video resolutions (e.g. 1920x1080) you could push this very high if needed. At full sensor resolution you could probably still have quite a large number on a Pi 5; older platforms may be a bit more limited.

[marsfan]

Awesome. That should help me keep things simple on my end. Thanks