DSLR live view delay

[nicegamer7]

I'm hoping to get some clarification on how the DSLR live view is implemented.

I'm a little confused because I understand that the live view is implemented by taking exposures, then transferring them to the device running OLS. However, I don't understand what the FPS setting does. It seems to me that the FPS is determined by the shutter setting. For example, if the shutter is set to 1/60, this results in approximately 60 fps (not exactly due to some time in between shots, but maybe close enough).

Changing the FPS setting seems to do nothing at all. I thought it was the rate at which OLS polls for a new image, but that doesn't seem to be the case.

The reason I'm asking is because when taking 30 second exposures, the live view is delayed considerably (as noted in an issue somewhere, it's about 2 or 3 frames behind). I'm trying to use OLS simply as a means to run ASTAP from my phone so that I can avoid starhopping. OLS is still usable with this delay, but it'd definitely be more enjoyable without it. Any help/clarification would be appreciated.

[artyom-beilis]

Good question. FPS is a top limit.

Some cameras especially with small frame and short exposures can create very high frame rate that OLS just ins't capable of processing/stacking. So FPS limit allows to throw frames if they pass certain amount. It is critical for built in Android camera, and planetary imaging.

For DSLR it is rarely an issues.

[nicegamer7]

Okay, this makes sense. Thanks for the clarification.

[artyom-beilis]

The reason I'm asking is because when taking 30 second exposures, the live view is delayed considerably...

It should not once image is downloaded it would show up. Can you clarify about the delay?

[nicegamer7]

It seems to me that the live view is behind by 2 or 3 frames. I set my camera to take JPEG images instead of raw images, and I lowered the resolution
as well because I thought it might be a transfer speed issue, but those changes didn't seem to affect the delay I was seeing.

I'll try this again just to make sure, it's possible I'm mistaken.

[artyom-beilis]

I just want to point a small thing, the sequence works in parallel. So while next capture is started (and you hear shutter) but the previous image is still downloading...

[nicegamer7]

I just gave it another try. It seems the picture on the phone is only updated when the camera isn't taking a picture (i.e. in the very short window of time in between shots). Sometimes the picture doesn't update at all. Maybe my camera isn't capable of transferring images at the same time as taking them? I'm using a Nikon D7200 for reference.

I guess I'll try modifying OLS to allow a delay in between shots, maybe that'll work. If it does and you'd like a PR I can do that.

Does my diagnosis seem likely? I have used tethering software in the past, but not for continuous shooting so I'm not sure.

edit: I tried building OLS locally, but it just seems to crash. Not sure why but here's the traceback.

Traceback

2024-07-31 00:04:47; cppcms_http, info: GET / (http_api.cpp:294)
2024-07-31 00:04:47; cppcms, error: Catched exception in thread poolInvalid document root
0x7fce85bac863: booster::runtime_error::runtime_error(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) + 0x73 in /nix/store/7hj2mwivic9ni9bxr6b4lcm6q8fima91-open-live-stacker-30/lib/libols.so
0x7fce8594bdea: ??? + 0x8594bdea in /nix/store/0z3ia3rnw362ivqljk5igjgdzmgjrhz0-cppcms-2.0.0.beta2/lib/libcppcms.so.2
0x7fce85964253: cppcms::impl::file_server* cppcms::details::create_app<cppcms::impl::file_server>(cppcms::service&) + 0x23 in /nix/store/0z3ia3rnw362ivqljk5igjgdzmgjrhz0-cppcms-2.0.0.beta2/lib/libcppcms.so.2
0x7fce8598f911: cppcms::application_specific_pool::get_new(cppcms::service&) + 0x21 in /nix/store/0z3ia3rnw362ivqljk5igjgdzmgjrhz0-cppcms-2.0.0.beta2/lib/libcppcms.so.2
0x7fce85991b64: cppcms::application_specific_pool::_pool_policy::get(cppcms::service&) + 0x54 in /nix/store/0z3ia3rnw362ivqljk5igjgdzmgjrhz0-cppcms-2.0.0.beta2/lib/libcppcms.so.2
0x7fce8598f3a8: cppcms::application_specific_pool::get(cppcms::service&) + 0xb8 in /nix/store/0z3ia3rnw362ivqljk5igjgdzmgjrhz0-cppcms-2.0.0.beta2/lib/libcppcms.so.2
0x7fce8598c79e: cppcms::http::context::dispatch(std::shared_ptr<cppcms::application_specific_pool> const&, std::shared_ptr<cppcms::http::context> const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) + 0x3e in /nix/store/0z3ia3rnw362ivqljk5igjgdzmgjrhz0-cppcms-2.0.0.beta2/lib/libcppcms.so.2
0x7fce8598da83: cppcms::impl::thread_pool::worker() + 0x103 in /nix/store/0z3ia3rnw362ivqljk5igjgdzmgjrhz0-cppcms-2.0.0.beta2/lib/libcppcms.so.2
0x7fce846e86d3: ??? + 0x846e86d3 in /nix/store/c6r62m84hywf4i6qq1h28f13zv38yqyp-gcc-13.3.0-lib/lib/libstdc++.so.6
0x7fce84499a42: ??? + 0x84499a42 in /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-glibc-2.39-52/lib/libc.so.6
0x7fce8451905c: ??? + 0x8451905c in /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-glibc-2.39-52/lib/libc.so.6
 (thread_pool.cpp:117)

[nicegamer7]

I was able build and run OLS locally (the above issue wasn't an OLS issue, I was trying to run OLS from within a read-only directory).

Here's what I found: the live view gets progressively more delayed as more exposures are taken. OLS logs "stacker, info: Real time video frame X arrived" once for every two exposures taken (though the X increases by one each time). So every time an exposure is taken, it takes an additional exposure in order to reach the computer. I'm not sure if this is because my camera isn't capable of transferring photos while taking photos, or if it's an OLS limitation.

Interestingly, if I let the live view run for a little bit then kill OLS, then run gphoto2 --capture-image-and-download from my terminal, all the remaining exposures from the live view are transferred to my computer (quite quickly too...).

I'm going to experiment with increasing the delay between shots.

[artyom-beilis]

Is it jpeg or raw? What is the frame size?

You can try to reorder operations: https://github.com/artyom-beilis/OpenLiveStacker/blob/main/src/gphoto2_camera.cpp#L522

Currently the loop is

trigger
loop
   wait
   trigger
   get_file

I start trigger before getting file. I don't think it should create a delay but check - you can try reirder wait get file and trigger

So basically download and capture run in parallel and allows more efficient use of time - especially for long exposures:

Play with it and try adding some lines to the driver itself to see what is going on.

[nicegamer7]

It's JPEG, and the frame size is about 3000x2000. The file size is 1.2MB. I tried to make it as small as possible so that transfer speed wasn't an issue.

I took a look at the loop and adding a delay didn't seem to help. I opened a PR with what worked for me. Does my change prevent the download and capture from running in parallel? I'm not sure, but if it does, then I can try a different approach. Maybe we can continue the discussion there.

[nicegamer7]

Actually upon further inspection, my solution still allows for the download and capture to running in parallel.