Fix bug re filter-change-autofocus

Authored by murveit on Nov 23 2019, 10:40 PM.



Added a test in Capture::captureImage() that checks to see if the filterManager is busy,
and if so, waits until it isn't. This resolves and issue where the focus and capture modules
could both be trying to take pictures, if auto-focus-on-filter-change is set, and if a filter
is changed mid-sequence, e.g. by a meridian flip causing align to run, which may run with a different filter.

Disabled auto-focus-on-filter-change for alignment. This wasn't 100% necessary to fix the above bug,
but I believe it is the right thing to do. Without this, align is likely to initiate an autofocus,
when the auto-focus-on-filter-change option is set, and then, after control passes back to capture,
another auto-focus would likely be run. Seems over the top.

Diff Detail

R321 KStars
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
murveit created this revision.Nov 23 2019, 10:40 PM
Restricted Application added a project: KDE Edu. · View Herald TranscriptNov 23 2019, 10:40 PM
Restricted Application added a subscriber: kde-edu. · View Herald Transcript
murveit requested review of this revision.Nov 23 2019, 10:40 PM

Thanks for the PR! How can this code be tested? what's the testing scenario? i.e. how the test behaved before the change and how it behaves after the change?

Sorry for not filling that out. Here's what to check.

Set auto-focus on filter change to all filters.
Start a capture sequence job with many captures for one particular filter (not the one that will be used for alignment).
Let a few of the captures occur (so it is not running the first capture any longer).
At that point a meridian flip should be triggered, (which should in turn start an alignment, and that alignment should use a different filter).
After the alignment is done, when capture restarts, the capture will switch filters back to the original capture filter, and, as part of that
filter switch, the FilterManager will trigger an auto-focus.
What to observe:
Before this PR, after all of the above, the auto-focus capture and the capture sequence job will both run concurrently, both attempting to access the same main camera (thus breaking the system).
With this PR, the capture sequence will pause, waiting until the auto-focus is done before resuming the capture sequence.

Thanks, got it :-)

Looks good to me. One issue is that if the filter manager state is not set to IDLE for whatever reason, then the capture is stuck forever in that loop.

That's true, though, as far as I know, that shouldn't happen.

To be more defensive against missed messages, I could add a method to FilterManager that directly access its state (e.g. FilterManager::getState() { return state; } and query that here instead of checking the Capture class variable filterState. However, I coded this to match the current style used in capture.cpp. That is, we already have and check focusState, guideState & alignState, and I believe your comment equally applies to those. Let me know your preference. Also, let me know if you'd like me to add a appendLogText() while it's waiting (though it would append that every second that it waits).

I tested this situation both with and without this diff. Without this diff, I could reproduce the problem that you described.

Your diff seems to fix this, everything works as expected. When the flip is completed, alignment finished, the state shown in the capture module remains "Aligning" instead of "Auto Focus" while focusing after the filter switch.

Wolfgang: Makes sense.
I assume what you mean is that I should do something like this:

secondsLabel->setText( i18n("Focusing..."));

just before the call to QTimer::singleShot(), where the text is dependent on filterManagerState.
E.g. if filterManagerState == FILTER_FOCUS then "Focusing...", if FILTER_CHANGE then "Changing Filters...", if FILTER_OFFSET then "Changing Focus Offset...".
I'll modify my change and do that.

murveit updated this revision to Diff 70273.Nov 24 2019, 10:06 PM

Added secondsLabel update to current change.
Capture should show that it's focusing while waiting for the filterManager.


Code duplications could be avoided by a fall-through

Perhaps I'm missing the obvious, but I don't see it. I don't want to overwrite secondsLabel. How would I use a fall through?

Ah, sorry, you're right. Forget my comment please.

mutlaqja accepted this revision.Nov 25 2019, 6:58 AM
This revision is now accepted and ready to land.Nov 25 2019, 6:58 AM
This revision was automatically updated to reflect the committed changes.