Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Burst capture #968

Open
davidedelvento opened this issue Mar 24, 2024 · 5 comments
Open

Burst capture #968

davidedelvento opened this issue Mar 24, 2024 · 5 comments
Assignees

Comments

@davidedelvento
Copy link

Prologue

I am not sure if this is operator error, PTP limitation, or using the wrong tool for the job.

I have a number of different DSLR and mirrorless Nikon cameras which all can take extremely fast bursts with several shoots per second in either identical exposure or bracketing conditions.

It looks like whatever I do, with either gphoto2 CLI (from the latest Ubuntu's snap, which brings v2.5.15) or libgphoto2 (gotten from Pip's python-gphoto2, which brings libgphoto.so.6.3.0) I can never achieve more than 1 shot per second which is absolutely insufficient for my needs.

There is a large number of people with similar complaints spread out in time since the project started, so maybe this is not supported? For just two examples jim-easterbrook/python-gphoto2#123 and #317 but there are many more maybe mentioning terms like slow or fast or bracketing etc.

Describe the bug

Is this something that is supposed to work or not? If yes, how? Just repeating the capture slows to a crawl and is totally inadequate. Maybe it works only with some protocols? Only with some cameras (obviously not expecting to go faster than the camera can go on its on)?
To keep it simple let's say without downloading the images, just saving them on the SD cards (yes, these are indeed top-notch speed and work perfectly at the speed the camera is capable on -- when using it standalone rather than connected to the computer).

To avoid frustrating people, it would be greatly appreciated if there could be an authoritative section in the docs or README.md saying:

  • this is not supported ever because no protocol supports it, it's 1 second max cadence
  • this works only with cameras X, Y, Z
  • this works only with gphoto2 versions newer than v
  • any other information that would help people understand if they are dumb, if their hardware is broken or not up to specs (e.g. USB2 vs USB3 -- don't think it's relevant to me since none of my cameras uses USB3), or whatever
  • and if it does work, this is how to do it

Thanks!!!

@msmeissn
Copy link
Contributor

This is hard to specify, and I would say it is camera and hardware dependent.

Also a bit API challenge:

The original capture_image API waits until the image is fully available, which usually takes longer.

There is the trigger capture API and gphoto2 --trigger-capture command, which does not wait until the camera has the image ready, so can queue off more shots while the camera is processing the previous ones still.

So if you specify multiple --trigger-capture (or trigger capture api calls), you should get speeds higher than 1/second.

You will however only get the filename additions later on when the cameras has processed the images (and you can get them via wait-event).

For testing, I just did with my Nikon Z6:

gphoto2 --trigger-capture --trigger-capture --trigger-capture --trigger-capture --trigger-capture --trigger-capture --trigger-capture --trigger-capture --wait-event-and-download=20s

first shot - a 0.x second delay somehow - further shots with definitely less than a second distnace.

only after around 10 seconds it starts downloading images.

@msmeissn msmeissn self-assigned this Mar 24, 2024
@davidedelvento
Copy link
Author

Thank you @msmeissn this helps. I will try it today and report back with exact setup.

Yesterday I tried examples/sample-trigger-capture.c, even removing the wait_event_and_download was a far cry from what the cameras can do on their own.

You will however only get the filename additions later on when the cameras has processed the images (and you can get them via wait-event).

I suspect this is part of the problem. For this use case, I think one has to forgo the filenames and downloads and that is exactly what I am trying to do.

@davidedelvento
Copy link
Author

With my Nikon D5500, D5300 and Z50, a single --trigger-capture gives an error but works. Using more than one trigger, only errors (of the PTP device is busy kind). So it seems that gphoto2 is able to put out the request, but it does so too fast for these cameras to parse, which is quite unfortunate (especially because they can parse equivalently fast or continuous pressure of their physical shutter button).

Thanks again

@msmeissn
Copy link
Contributor

msmeissn commented Apr 7, 2024

There is also on Nikon a "BurstNumber" setting, here for us "burstnumber" configuration.

if you set this, and either do capture_image or trigger_image it will ttake the burstnumber images as fast as the camera can.

seems aavailable on all Nikon D and Z

@davidedelvento
Copy link
Author

Oh, fantastic!! Thanks so much for mentioning it!
I confirm it works with my cameras. Perhaps it just needs some advertising... Speaking of which, is there a place where a list of all these settings are specified, hopefully with their syntax? Every time I try to change something differently from what I've done in the past it feels like I'm reverse engineering the camera....

As far as I am concerned, this issue can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants