You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Bulb mode capture is a relatively common usecase for controlling the camera remotely.
Right now it's implemented as a convenient command-line option in gphoto2, but libgphoto2 users have to replicate all the logic with reaching out to the relevant checkbox widget, setting it to checked, waiting, setting the widget to unchecked, and then sifting through camera events to detect and download the image.
In many cases, developer will open an issue here instead of guessing to look at the gphoto2 CLI implementation, which also adds to the triaging churn.
Describe the solution you'd like
Given how common it is, I suggest it's worth adding a gp_camera_{start,end}_bulb_capture helper to libgphoto2 API itself, which would just take the same params as gp_camera_capture, and take care of all the internal implementation details, returning CameraFilePath from the "end" function like the other capture methods. This should be more or less straightforward migration of the mentioned logic from gphoto2 codebase to libgphoto2.
WDYT?
UPD: Initial description suggested a single function that sleeps internally, but splitting it into two start/end functions is more async-friendly as it won't block the thread for a potentially very long duration of capture.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Bulb mode capture is a relatively common usecase for controlling the camera remotely.
Right now it's implemented as a convenient command-line option in gphoto2, but libgphoto2 users have to replicate all the logic with reaching out to the relevant checkbox widget, setting it to checked, waiting, setting the widget to unchecked, and then sifting through camera events to detect and download the image.
In many cases, developer will open an issue here instead of guessing to look at the gphoto2 CLI implementation, which also adds to the triaging churn.
Describe the solution you'd like
Given how common it is, I suggest it's worth adding a
gp_camera_{start,end}_bulb_capture
helper to libgphoto2 API itself, which would just take the same params asgp_camera_capture
, and take care of all the internal implementation details, returningCameraFilePath
from the "end" function like the other capture methods. This should be more or less straightforward migration of the mentioned logic from gphoto2 codebase to libgphoto2.WDYT?
UPD: Initial description suggested a single function that sleeps internally, but splitting it into two start/end functions is more async-friendly as it won't block the thread for a potentially very long duration of capture.
The text was updated successfully, but these errors were encountered: