Bug 454278

When running a capture sequence events appear to happen in the following order:

1. Camera completes image capture.
2. Camera downloads image to computer.
3. Image is converted into fits format, WCS data added etc.
4. Preview of image displays in fitsviewer.
5. Dithering starts.
6. Dithering completes and settle time occurs.
7. Guiding resumes.
8. ekos commands next exposure to start.

The clock time between 1 and 7 can be rather significant: on a Raspberry Pi 4 with a Canon EOS 600D (connects via USB2) it takes around 25s. The process doesn't seem to be optimised properly because there shouldn't be any need for the image-related activity and the dithering-related activity to be serial activities, they should be carried out in parallel. It would save a significant amount of idle time (and therefore allow more time imaging) if the process began dithering as soon as possible after image completion, especially on slower hardware and / or with USB2-connected cameras. The sequence of events would then be:

1. Camera completes image capture.
2. Camera starts downloads image to computer.
3. Dithering starts.
4. Dithering completes and settle time occurs.
5. Guiding resumes.
6. ekos commands next exposure to start.
(at some point) Download completes.
(following) Image is processed into fits format.
(following) Preview of image displays in fitsviewer.

I suppose if considering a sequence of very short exposures like bias you might want to ensure the next capture didn't start before the previous image had been completely dealt with, but even so the sequence could be:

1. Camera completes image capture.
2. Camera starts downloads image to computer.
3a. Dithering starts.
4a. Dithering completes and settle time occurs.
5a. Guiding resumes.
3b. Download completes.
4b. Image is processed into fits format.
5b. Preview of image displays in fitsviewer.
6. (requires 5a and 5b to be complete) ekos commands next exposure to start.