Description
When I configre “before sequence start” Autoflats, SGP inserts strange rotator angles “from nowwhere”. In particular, for R, G, B: two times the angle 311° (correct, from the target) and one times a fantasy angle of 324°. This can be seen in the “preview” window.
I suspect that the rotator implementation in Autoflats does not work correctly.
Link to Logs
Rotator: ZWO CAA
OS: Windows 11 Pro 24H2
Ver: 4.5.0.1534
AutoFlats sources rotator angles from the image FITS headers. Specifically, it gets them from the Positional Angle header (mechanical position) of the rotator.
I do not understand, of which .fits image do you speak? When autoflats are to be made before the sequence starts, then there is not yet any (valid) image; autoflats should take the rotator angle from the angle I defined in the sequence for the (reference) target, or at least should not alter the current angle …
Than you again for your fast reply. Thinking twice, your reply, though, fits to the behaviour I encountered when making autoflats “after the sequence”: I captured B and G images, but not R images, and the autoflats rotator angle was correct for the B and G, but nor for R (where it took some random rotator angle "from nowwhere Nirvana)
so, while your statement that autoflats “takes the autoflats rotator angle from a (which?) .fits header” may indeed be correct, this is not a meaningful behaviour of the mechanism; neither is defined “which” .fits header, nor makes “taking from an image fits header” much sense, as autoflat should take the angle from the sequence definition (and not from any former past images)
So I still believe that the Autoflats mechanism is flawed in this respect, as, above all, it does not work correctly
PS: The above error occurs when I chose “capture flats for all active light events” under “matching type”; when I chose “capture costum autoflats run” I can override the error and insert correct angles manually
PPS: …an then occurs a SECOND error:
when beginning autoflats, although SGP instructs the rotator to go to the angle I defined, and the rotator starts to move, SGP does not seem to wait for the rotator to finish (or the ZWO CAA rotator does not carry out the angle command correctly), but starts to image capture while the rotator is still in some intermediate position so that the flats are captured at a wrong angle…
*** Just made another try: I initiated Autoflats manually (ctrl-A): SGP instructs the rotator to a completely different angle value than (a) in the autoflats sequence and (b) any picture taken that night.
Only when I tick “ignore rotator value” than I can at least have the present rotator angle undisturbed by Autoflats.
And, I have now noticed that SGP records the field ANGLE (sky angle) in the light images captured, whereas it records the field POSANGLE (mechanical rotator angle) in the flat images captured. This might be the source of the wrong angles when SGP would indeed take the rotator angles from some past images (which makes no sense, anyway, as it should take the angles from the sequence definitions)
So, bottom line: there is a serious flaw in the rotator angle implementation of Autoflats