There have been various requests to be able to control the order of events on a finer scale. The current Target/Event model is problematic because of the way events are grouped into targets. A target has a Ra/Dec position but Darks and Bias frames don’t use the position and Flats will likely use a different position. Also, the event start/stop times and the desired altitude constraints only apply to light events. Lastly, dark and bias frames are rarely done at the same time as the light or flat frames and are not associated with a particular target. If you think about it, the current Target/Event system is really a mount positioning operation followed by some exposures.
Consequentially, the proposal is to have three types of events and no targets. The events would be position events, exposure events and grouping events. All events would have a run flag.
Position events would have Ra/Dec, Rotate to, Slew to, Center, and a name. Position events could specify the Park position as an alternative to Ra/Dec. (Name could be optional?)
Exposure events would be the type (light, flat, dark, and bias), exposure time, binning, repetition count, file suffix and filter (for only light and flat).
Grouping events would have one or more sub-events (position, exposure or group). A group would specify sequential or rotating execution. Rotation groups would specify how many exposures to do on each round. A group may have optional constraints (start/stop times & altitude limits) and an optional name. (Name could be required?)
Like the current implementation, events would be executed in the order they appear with the exception that group rotation parameters would be applied and any time or altitude constraints would cause events to be delayed until the constraint was satisfied.
The difference between this proposal and the current method is that you have direct control over the sequence events, it factors parameters into related events, and you get the added benefits of group events.
Consider several scenarios:
- A simple target - One position event and one or more exposure events
- One target and rotate through the filters – One position event followed by a rotating group which would contain exposure events for each filter.
- A constrained target - A group event with a constraint which contains a position event followed by one or more exposure events.
- A constrained target with rotating filters - A group event with a constraint which contains a position event followed by a rotation group event which contains exposure events.
- Expose luminance followed by rotation of RGB filters - A position event followed by an exposure event for luminance followed by a rotation group which contains the RGB exposure events.
- Rotate though targets doing a few exposures for each - A group rotation event which contains a position event for the first target then exposure events for the first target and also contains another position event then exposure events for the second target.
- Expose a target then do flats – A position event for the target followed by target exposures. Then a position event for the flats followed by flat exposure events.
- Expose some dark and bias frames – Exposure events for darks followed by exposure events for bias. Notice there is no position event.
There is a question of how to name exposure files. The current system can include the Target Name which does not exist in this proposal. In its place, a name can be constructed by using the names of the enclosing groups followed by the last executed position event.
It would be handy to add some sanity warnings for sequences. For example, a light exposure event with no preceding position event is suspect. Note, however, that such a sequence is quite legal and can be run if that is what the user wants.
There is a backward compatibility issue with old sequences, however, the mapping from the current method to this proposed method is straight forward and could be done at the time an old sequence is loaded or as a stand-alone conversion tool. Lastly, the Framing and Mosaic Wizard would need to change.
In summary, what is being proposed is to eliminate the target/event model and substitute three types of events which are refactors of the current targets/events to collect together related parameters and allow flexible use of constraints and events sequences.