I'm solving lots of short subs to stack on 3I/ATLAS, the interstellar comet. I noticed that the first ephemeris stack i did produced very non-linear star trails, and a very diffuse comet. I then re-did the alignment (right-click and 'refresh...'???) possibly after tweaking something, but nothing of consequence i thought. I may have turned off 'SIP coefficients' and de-selected 'slow'. After this, the stack is much better with much sharper star trails and a sharper comet. But i noticed that the alignment still shows odd variations between subs. This can be seen with two examples, where the blue RA contour takes a different route between two faint stars. Im surprised, i assumed the alignment was quite a rock-solid thing. Any thoughts? Am i doing something wrong? Some subs arent solving at all - about 10%. I'll attach two screenshots showing this, and then the examples of the 'good' and 'bad' star trails and comet. Happy to provide more logs etc if useful.
Ephemeris stack will rely on the recorded data and time and astronomical solution. If it is not very accurate then likely the astronomical solution is to blame....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The background is pretty unequal. A flat correction would help. There are 8 quads found which should be fine for solving but I can image the for other images less are found and used. This could give a very small error/variation in the solve.
Either calibrate with flats and darks or you could try the new option to equalise background prior to solving. Using the last option a total 45 quads are used for the solution and will give a much better result. See attached.
I do use flats and darks - this is just the raw uncalibrated sub as fed into ASTAP. It also has the flats and darks. When the subs are solved in ASTAP does it automatically use these, or only when stacking?
Ive downloaded the latest ASTAP and have re-solved all subs using the equalise background method. Seems faster, and now all subs seem to have solved (EDIT not so)! Stack is also vastly better (attached).
Interesting though, i imagined that a solve was solve was a solve, but perhaps not and i need to pay more attention to this.
SOrry another related query. I wondered why all subs arent stacking. Oddly, ASTAP finds solutions for all subs but then doesnt list them in the file list (as shown) and then doesnt stack them. I tried again with SIP deselected and 'quick' deselected, with no difference. Any thoughts on this?
Even if i select just a single sub, such as 38, which doesnt have a solution listed, and ask ASTAP to re-solve, it does so successfully, but doesnt list this in the file list.
I checked the process here and solving is done prior to calibration. That is not ideal. After calibration would be better. Something for the future.
I suppose your gradient is rare. The solver expects a reasonable equal background. With a gradient like yours it could ignore the stars in the darker corners. If only a few stars are detected and different stars in each image there could be very very minor error which effects stacking. Keep the new option activated if all your images look similar. It will equalise the background in a fast way allowing usage of all detectable stars and does not take much processing time. Something like 0.1 or 0.2 seconds.
Cheers, Han
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm solving lots of short subs to stack on 3I/ATLAS, the interstellar comet. I noticed that the first ephemeris stack i did produced very non-linear star trails, and a very diffuse comet. I then re-did the alignment (right-click and 'refresh...'???) possibly after tweaking something, but nothing of consequence i thought. I may have turned off 'SIP coefficients' and de-selected 'slow'. After this, the stack is much better with much sharper star trails and a sharper comet. But i noticed that the alignment still shows odd variations between subs. This can be seen with two examples, where the blue RA contour takes a different route between two faint stars. Im surprised, i assumed the alignment was quite a rock-solid thing. Any thoughts? Am i doing something wrong? Some subs arent solving at all - about 10%. I'll attach two screenshots showing this, and then the examples of the 'good' and 'bad' star trails and comet. Happy to provide more logs etc if useful.
Last edit: Nicholas Haigh 2025-08-05
And crops of the good and bad stacks. 3I/ATLAS is the point source. Still room for improvement i think, and i dont know what the difference is.....
Alignment is normally very robust. Can you share some subs so I can have a look myself?
Han
Ephemeris stack will rely on the recorded data and time and astronomical solution. If it is not very accurate then likely the astronomical solution is to blame....
Here's one of the two subs shown above - not sure which one, and not sure which the other one is, but they were chosen at random.
The background is pretty unequal. A flat correction would help. There are 8 quads found which should be fine for solving but I can image the for other images less are found and used. This could give a very small error/variation in the solve.
Either calibrate with flats and darks or you could try the new option to equalise background prior to solving. Using the last option a total 45 quads are used for the solution and will give a much better result. See attached.
Cheers, Han
Hi Han.
I do use flats and darks - this is just the raw uncalibrated sub as fed into ASTAP. It also has the flats and darks. When the subs are solved in ASTAP does it automatically use these, or only when stacking?
Ive downloaded the latest ASTAP and have re-solved all subs using the equalise background method. Seems faster, and now all subs seem to have solved (EDIT not so)! Stack is also vastly better (attached).
Interesting though, i imagined that a solve was solve was a solve, but perhaps not and i need to pay more attention to this.
Many thanks!!!
Last edit: Nicholas Haigh 2025-08-06
SOrry another related query. I wondered why all subs arent stacking. Oddly, ASTAP finds solutions for all subs but then doesnt list them in the file list (as shown) and then doesnt stack them. I tried again with SIP deselected and 'quick' deselected, with no difference. Any thoughts on this?
Even if i select just a single sub, such as 38, which doesnt have a solution listed, and ask ASTAP to re-solve, it does so successfully, but doesnt list this in the file list.
Last edit: Nicholas Haigh 2025-08-06
Did you look to the correct column? See attached red marked.
The stack method has several options. Which option do you have selected? See green marked attachment.
The alignment method. Which alignment method do you have selected? See tab "alignment"
That last stack looks good.
I checked the process here and solving is done prior to calibration. That is not ideal. After calibration would be better. Something for the future.
I suppose your gradient is rare. The solver expects a reasonable equal background. With a gradient like yours it could ignore the stars in the darker corners. If only a few stars are detected and different stars in each image there could be very very minor error which effects stacking. Keep the new option activated if all your images look similar. It will equalise the background in a fast way allowing usage of all detectable stars and does not take much processing time. Something like 0.1 or 0.2 seconds.
Cheers, Han