Ken and I discussed this. And while it would be beneficial it would likely result in some pretty bad regressions at the moment. So the risk/reward just isn’t worth it right now. We may look into this in the future or make smaller movements toward making it less of an undertaking.
Currently we dither before every image. This is so that we know we’re taking an light sub rather than a dark, meridian flip, auto focus, etc. We would need to move the dither back to the end of the frame and then make the decision to dither there. It gets more complicated as we’d now be doing this in parallel with the camera in a “not ready” state so events that could normally go (plate solving, AF, etc) would need to check this new state. Also for certain sbig cameras that are guiding through the internal guider we’d have to make special appropriations since the guide chip couldn’t be accessed to perform a dither.
Because we cannot guarantee the consistency of implementation across devices, we will probably not be looking into this in the near future. It would be a fairly significant change to the sequencing engine (effectively undoing all of our effort to move the dither to the beginning of a frame capture so it can be “smarter” in making decisions about whether or not to dither).
In addition to this, it would require (effectively) two different dithering systems to maintain (and risk of regression). One system for cameras that report state properly and the other for cameras that don’t.
If CameraState were part of ASCOM conformance (not even sure if this is possible… just making a point) and we had some ground to stand on when we talk to driver authors and say “Your driver should do this, but it does not, and, as a result, it behaves this way”, then we would consider making the effort, until then we will likely stay with the more universally safe method (at the cost of time). Whether or not ASCOM can enforce this effectively is not for us to say…