-
Notifications
You must be signed in to change notification settings - Fork 212
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
indi-gphoto: Unreliable long exposures on Canon DSLR (EOS6D in particular, but also others) #956
Comments
Just to add some more data. The problem may be worked around for 6D with setting "Long time exposure noise reduction" to off in camera. However, I think this is still a bug. We should wait for a complete exposure, not a particular timeout. Actually, I think we should wait on complete exposure and complete file showing up in the camera. The automatic dark frame in 6D is actually a very neat feature. It makes the scope shutter unnecessary. It will be a shame not to use it. |
I actually figured out where is the problem. In gphoto_driver.cpp indi-3rdparty/indi-gphoto/gphoto_driver.cpp Line 1431 in de09e79
we are waiting for fixed timeout - no mater what. We should wait for the complete capture and only after reasonable timeout (let us say 2*exposure + 10s) give up and decide the data is not coming. Unfortunately, I do not know how to get current exposure time to fix this properly (@knro - this will be 5 seconds for you to figure out, help ;). I will just disable the timeout in my branch and report if it fixed the problem. For now, here is the relevant debug log:
|
And it fixed the problem. This problem. Unfortunately, there is also a problem with focusing - but that is for another day. That is - it is worked-around. It still needs proper fixing... |
Thank you for your investigation. I suppose we could wait full-exposure but perhaps not by default. Maybe can add a toggle for timeout: Default vs Max |
Great idea! My tests last night showed that it really works over a wide range of times - so it is definitely worth it. Maybe just a switch: wait for exposure+timeout/wait for complete in-camera processing + timeout with adjustable timeout. It seems this was a problem before - the timeout used to be 5s (from the comment) now it is 10s... Additionally, I spotted a problem with focusing in EKOS. Autofocusing leaves the camera in hang state, while executing the same steps manually with buttons in EKOS is fine - I guess something is not closed properly at the end. The focusing is problematic with canon, but eventually it works (see the attached frame). But it is a problem with DSLRs and I do not think much can be done about that. |
Describe the bug
Long exposures (above 10s) on Canon DSLR are very unreliable. It is very obvious on my 6D but also 40D suffers similar problems. The capture hangs, repeats multiple times etc.
To Reproduce
Exact steps to reproduce the behavior.
Expected behavior
Well, reliable captures ;)
Desktop (please complete the following information):
Analysis
It seems with long exposures the data may be available after some, sometimes long delay. In case of 6D the delay may be as long as the exposure (I suspect the camera is doing dark framing internally). I have figured out that simple constant wait suggested in gphoto docs is not correct. After long search and trial-and-error, I have figured out the correct sequence for EOS 6D in gphoto CLI (example script - captures a frame with given exposition):
In case of gphoto2 tool, the LANG=C is crucial, but the real solution is
--wait-event-and-download=CAPTURECOMPLETE
which waits for the actual end of capture. This script essentially "works". Unfortunately, I do not know how to port this solution to indi-gphoto. I guess it may be easy for the person familiar with the code (just wait for this event instead of fixed timeout, although some configurable timeout on top of this may be useful).The text was updated successfully, but these errors were encountered: