Adjustment to focus strategy in sequences with filters

Issue #930 closed
Barry King created an issue

This suggestion is not about filter offsets, just wanted to offer some context.

For reasons not yet identified, I have not experienced reliable focus when using filter offsets across imaging sessions. I am not saying the method is flawed. More time is required by me to sort it out for my circumstance. I have however had pretty good success returning to an absolute focuser position from a recent successful AF run within somewhat static conditions, e.g. the context of a short time in an imaging session.

Assuming one does not use filter offsets, for reasons, I would like to suggest an alternate strategy. This is from the perspective of a user and is not intended to be a robust design, but rather to convey an idea.

The proposal assumes absolute focuser position is achievable consistently and correlates to a good focus, which I think is as reasonable as Filter Offset assumptions.

Finally the suggestion: Provide an option where on filter change (when AF on Filter Change is enabled) NINA uses the absolute focus position from the last known good AF for the particular filter. Presumably this mode is only valid when not using filter offsets.

Would need to:

  • record HFR per filter in list (time, sub number?)
  • record absolute focus position per filter (would be associated with last known good HFR from list)
    per target (could be per sequence? also saw a corollary to this proposed)

I believe this information is already gathered in the AF json files, not sure if it i carried in any NINA internal structures. I saw another proposal that HFR graph have a filter for…err…filter, so seems doable.

Back of napkin logic snippet that might be added to the AF on Filter Change trigger. Assume naivety and ignorance of the code and architecture. This is for illustrative purposes only. Developers with NINA architecture knowledge will certainly have best insight into where and how this is actually implemented.

AF on Filter Change Trigger:

if current filter has no focus position { // within some context such as sequence, target or whatever
  execute autofocus
  // autofocus already records absolute focus position and the filter
}
else {
  move focuser to last known good position for the filter
  // optional: take a sub to validate HFR, subsequent action perhaps would be handled by AF on HFR trigger 
}

The AF on HFR trigger would be aware of the current filter and behave accordingly. That is, it would not necessarily perform an AF because HFR changed, but only if the HFR changed for a particular filter.

I believe this would minimize time spent focusing and should/may be as good as filter offsets on a session basis for those that cannot or choose not to use filter offsets. Additional option, a quick (user configurable) sub-exposure after the filter change to validate HFR might be useful if it would avoid an AF run.

I am sure there are holes in this and perhaps subtleties that may make it more complicated, but I believe I would use this approach in many circumstances and somewhat follows what one might do if handling this manually.

Thanks for reading this far.

Comments (3)

  1. Stefan B repo owner

    Hi Barry,

    when filter offsets aren’t working reliably it is most often caused by either incorrect offsets or just backlash in the focuser that is not accounted for properly.

    For the idea of the logic, the problem here is that this will only work when your focus didn’t shift in the meantime due to temperature changes etc. It should also not be tied to the autofocus on filter change trigger, as this would be rather unexpected and not indicated by the name of the trigger.
    A plugin could be created to have a separate trigger doing this kind of logic, but I see it as a problematic approach due to the shifting conditions throughout the night. Furthermore if your root cause of filter offsets not working correctly is indeed focuser backlash, this method won’t work either.

  2. Stefan B repo owner

    Due to the problems described, I don't see this as something to be reliable to add to the core application.

    If a plugin author wants to take a stab at it, this can be added as a plugin without much trouble.

  3. Log in to comment