Stack on a planetary moon, rather than asteroid?
Stacking program, astrometric (plate) solver, fits file viewer
Brought to you by:
han59
Menu
▾
▴
Hi!
Ive got about 10 hours of images (3600 x 10secs) to detect Caliban, a faint moon of Uranus. Shorter stacks can just be aligned on Uranus (in DSS comet mode, sorry) and are sufficient to detect Sycorax at mag 21 but at 10 hours over 3 nights I need it to align on the moon itself at mag 22 or so.
Is it possible to align and stack on this, as one would a faint asteroid/comet? The subs solve perfectly, and detecting asteroids/comets doesnt flag any Uranian moons or Uranus itself, though it does mark some faint asteroids.
Cheers
Nick
Last edit: Nicholas Haigh 2024-11-26
Hi Nick,
At the moment aligning on a moon is not possible. On a planet would be possible either manually or by entering the correct orbital parameters in the asteroid or comet input file of ASTAP.
It is easy to extract the delta X or delta Y position of the moon realtive to Uranus from the JPL web site. Probably the same for the actual position, so in ra, dec
The orbital period of Caliban is 1.59 yr (579.26 d) so it will likely not move visibly in three days. So aligning just on Uranus could be an option.
1) Have you for Uranus tried manual alignment and then option "automatic selection of reference object...."?
See attached. So if you select in the first image Uranus then it will fill automatically the corrections for Uranus in the next images.
2) Easier would be to enter the orbital parameters of Uranus in the ASTAP input files like it is a comet or asteroid. If you provide some test images, I could have a look into it.
Cheers, Han
Hi Han. Thanks for replying so fast. For a few hours the drift is ~1arcsec relative to Uranus, so that works fine (I did the stack in DSS) and this picked up sycorax fine. The problem is that over a few days (~1% of orbital period) it does drift by quite a few arcsecs, so detecting an object at the scope limit fails.
What Im doing now is something brute force - solving the first and last image in ASTAP, and finding the pixel coords in those images of the NASA HORIZONS Caliban position for those times, and then entering those coords as a comet in DSS into the .info file.
I expect theres a more elegant solution in ASTAP if i can just supply the RA,Dec for the 1st and last image, and ASTAP interpolates?
Cheers
Nick
Well that could possible work.
From two positions at two dates you could calculate the drift in ra, dec. The drift will be constant for a few days. I assume JPL will give you the drift directly. I could add that to astrometric stacking alignment.
I could test that on an series of asteroid images.
What does JPL give you for drift values if any? Or is it just the position?
I will have a look into it the next days.
Last edit: han.k 2024-11-26
JPL Horizon gives the movement of Caliban in arcsec/hour. See attached
Implemented in ASTAP development version 2024-11-28:
http://www.hnsky.org/astap_setup.exe
If you using an other version then the Windows version, please tell me. I have tested it for one asteroid but it should also work for Caliban. Tell me if it works for you.
Documentation:
http://www.hnsky.org/astap.htm#astrometric_alignment
Han
I'm just testing it again. It is only implemented for average stacking. I will also add it to sigma clip stacking. This will filter out the star mostly.
There is an other problem. The reference image is selected and then while stacking it can go back in time for the next image. That doesn't work currently for alignment at this moment. I have to correct this.
Han
Should be fixed in development version
http://www.hnsky.org/astap_setup.exe
But requires more testing like for rotated images.
Finished in ASTAP version 2024.11.30. I discovered an old problem in astrometric aligned stacking which took me a long time to trace and fix.
See attached.
Han
Hi Han this sounds tremendous. I'll give it a go on some more recent data as soon as possible. Been kept occupied with DIY the last few days.....
Best regards
Nick
No problem. Just note that you have to select stack method "average" and "astrometric alignment".
Seems to work! Have stacked 3500 subs in 'average'. Now re-doing kappa-sig.
One observation - the options in ASTAP read (tiny font but 99% sure) as '/hr ie arcmins/hr...assume this should be "/hr, arcsecs/hr as per HORIZONS?
I calced a mean value over the total exposure time of 30 hours, seems to work! Havent located Caliban yet (awaiting kappa-sig to remove stars) but Sycorax shows well even though not optimally aligned on it (as tracked for Caliban).
EDIT: ignore this, i found the setting - unticked 'ignore existing....'
Question: i have just changed 'average' to 'sigma clip' and on selecting 'stack' it re-solves every sub taking a full hour. Surely no need for this when its just done it for the 'average' stack, and batch solving says that they already have astrometric solutions in the headers?
*
Do I need to change a setting?
Last edit: Nicholas Haigh 2024-12-03
The resolving is caused by the option "ignore existing solutions. ..." See attached
The "solar drift compensation" is currently not working for sigma clip. I had it briefly implemented but it looked not good. Selecting sigma clip will gray-out the option "Solar drift compensation".
I can have a second look
The solution in the result should allow to annotate asteroids but the Moon will not be in the database.
Yes I will correct it.
I tried again sigma clip. It doesn't work well, I assume the stars have a too large value in the mean. Probably it will work for more then my 10 ten images but I do not think there is much to gain. It could also influence the object your trying to image if the drift rate is not perfectly known.
I'd be interested to try kappa-sig - 3500 subs should provide good stats....but....here's Caliban, at mag 22.4 (in small yellow box)!
Huge thanks for implementing this!
Last edit: Nicholas Haigh 2024-12-03
Average will also show you the movement of any other solar object.
I found some time today and implemented the option "solar drift compensation"also for stacking method sigma-clip-average.
Most of the star light is removed. But since the star passes by and the pixel value rises and falls there is always a star value close to the average. So flux from the base/foot of the star remains. I used only 10 images but I assume it will work more effective for more images. Setting sigma clip maybe 1.2 or 1.4 to filter out a lot of star flux.
Windows development version only:
http://www.hnsky.org/astap_setup.exe
Tell me if this works for you.
Cs Han
Thanks Han will do. Am just doing an average stack with a different dataset of 3569 subs, will repeat with the sigma clip when done later today.