- This topic has 16 replies, 5 voices, and was last updated 5 years, 1 month ago by
.
-
Posts
-
I’m aware that Astrometrica supports image stacking with a programmable offset in RA and Dec between frames, generally used to follow comets and asteroids as they move across the FOV. However, it is a Windows-only program which does not run under WINE in Linux.
Can anyone suggest a Linux program which provides this functionality? Stacking on stationary objects like stars is trivial with SWarp and I use it often.
The reason for this request is that back in June I took some images of Leda (Jupiter XIII) which was then at Vmag 19.9. Stars fainter than mag 20 are visible on the stacked images but the satellite trail, predicted to be 21 arcsec long, is way down in the noise. Properly stacked and there’s a fair chance of seeing Leda hiding among the trailed stars.
In principle I could muck around with the WCS on each sub to fool SWarp into doing the right thing. I don’t see that being an easy task.
Paul,
If you don’t mind command line software I have written a set of tools which I use as part of my image calibration and processing pipeline. They are based on the cfitsio library so should read any format supported by that library. You can download them from here:
http://www.nickdjames.com/astrolinux/utils.tgz
The stacking tool is called fcombine. The normal syntax to use it is:
fcombine -N -a 611,713 -A 0 -o 0.368,236.7,1.42 200p_ofs FLI*200P*FITThis says:Normalise the median level of each image before stacking, track on a guide star at position 611,713 in the first image, PA of the image is 0 deg (i.e. north up), Offset at 0.368 arcsec/sec in PA 236.7 deg, Pixel scale is 1.42 arcsec/pix. Output file is 200p_ofs and the input files are all files which match FLI*200P*FIT. You can add -F to write as a float fits and -s to do a true average rather than a statistically clipped average. You can also use -v to get a lot of stuff about what it is doing during teh stack (otherwise it is silent). Note that the position for the guide star assumes (1,1) is the top left corner of the image (the convention most amateur software uses) rather than the bottom left (which is what pros tend to use). The FITS standard doesn’t say which is right.
Typing the command with no arguments gives a list of what it can do. For fcombine you get:
fcombine [opts] outfile infiles
By default combines images using mean with outlier rejection
-a x,y[,d] Align on guidestar
-A n[,M] Position angle of image with optional mirroring
-C Cometstack
-c n Crop to image of size nxn
-d n Resample and drizzle by a factor of n
-F Write float format rather than int16
-f file Take alignment offsets from file
-g n Apply gain of n to output
-h Do not use FITS header
-m Minimum pixels
-M Maximum pixels
-n Normalize mean levels by scaling
-N Normalize mean levels by offset
-v Verbose
-V Version
-r n Tracking and PSF radius to use (default = 5.0)
-I Scale to a FITS that IRIS can handle
-R Write output mirror reversed
-o rate,pa,pix Offset (arcsec/min)
-O rate,pa,pix Offset (arcsec/frame)
-p n Add pedestal of n
-P n Reject for PSF > n
-D n Shift step size (default is 1)
-s No outlier rejection
-S n Stacksize (all images by default
-t Align on targetThanks Nick, this sounds very much like what I’m looking for. As for using the CLI, that’s what I generally do anyway.
This morning I kludged up a Perl script to modify the CRVAL[12] cards in the FITS headers in attempt to persuade SWarp to stack the images with an offset. Not very successful though. Ether I screwed up the code or the total exposure just wasn’t long enough because I can’t see anything circular on the stacked image — just lots of trailed stars.
Minor problem. Your tarball contains dynamically linked binaries which link against versions of libraries not installed on this Ubuntu system. For instance:
pcl@thoth:~/Nick$ ./fcombine
./fcombine: error while loading shared libraries: libnetpbm.so.11: cannot open shared object file: No such file or directory
pcl@thoth:~/Nick$ locate libnetpbm
/usr/lib/libnetpbm.so.10
/usr/lib/libnetpbm.so.10.0
/usr/share/doc/libnetpbm10
/usr/share/doc/libnetpbm10/changelog.Debian.gz
/usr/share/doc/libnetpbm10/copyright
/var/lib/dpkg/info/libnetpbm10.list
/var/lib/dpkg/info/libnetpbm10.md5sums
/var/lib/dpkg/info/libnetpbm10.shlibs
/var/lib/dpkg/info/libnetpbm10.triggersLikewise, my libwcs is in /usr/lib/x86_64-linux-gnu/libwcs.so.6 whereas the binary calls for libwcs.so.5
Would it be possible to have either source code (preferable) or statically linked binaries please?
Thanks.
Paul,
I have a VM running Ubuntu 18.04 LTS. I’ll build you a version of the tools in that. Hopefully that will work on your system. If not I’ll have a look at linking the libs statically and, failing all that I’ll give you the source (with an NDA!).
Nick.
I have aligned fits images using Python, AstroPy and the astroalign package.
If interested email me, and i’ll send a fairly trivial example python script.
Callum
Try this:
http://www.nickdjames.com/astrolinux/utils_ubuntu18.tgz
The tools are all dynamically linked so you will need the libraries but they are all available for Ubuntu. I think the following should get them all:
apt install libcfitsio-dev
apt install libgd-dev
apt install libnetpbm10-dev
apt install wcslib-devNick.
I’ve long had them all installed. The problems lies in the version mis-matches. The latest tarball still tries to link against versions which are not on my system, they being either newer or older.
I’m quite willing to keep the sources secret if you wish, even though my own code is almost always released under a BSD-like license.
Here’s the stack I made. The red arrow might, just might, indicate Leda but I’m far from convinced. It’s in about the right place and it’s not trailed like the other stars. Unfortunately, it also looks like it may be noise.
Good try Paul but that’s the trouble with faint objects in busy starfields! When you say it is “in about the right place” could you quantify in terms of arcsec? Leda’s ephemeris will be very good. Normally, in cases like this, you would produce two stacks at different times and check that the object’s motion is consistent with the ephemeris. You may not have enough subs to do this in which case the identification will always be iffy.
First off, I’ve verified my stacking code does the Right Thing by digging out some old images of (532) Herculina where it is by far the brightest object in the field and so there’s no chance of missing it.
To answer your question, the (slightly abridged) MPC ephemeris for Leda gives
Date UT R.A. (J2000) Decl.
2019 06 26 000000 17 02 01.7 -22 07 28
2019 06 26 001500 17 02 01.4 -22 07 27
2019 06 26 003000 17 02 01.1 -22 07 26
2019 06 26 004500 17 02 00.9 -22 07 25
2019 06 26 010000 17 02 00.6 -22 07 25
2019 06 26 011500 17 02 00.3 -22 07 24and my subs were taken between 2019-06-26T00:20:10 and 2019-06-26T01:12:21 inclusive, with a mid-point of 00:46:15.
The brightest pixel in the indicated blob lies at 17:02:01.3 -22:07:26 according to the ds9 viewer.Good agreement, in other words, especially as the plate scale is 1.42 arcsec/pixel..
You are much more experienced at this sort of thing than I — it’s my first attempt — so how much credence would you place on the identification?
It’s pretty clear that when I next attempt to image Leda I should aim for a much longer total exposure time.
Well, given the position, it is possibly Leda but I don’t think you could be sure unless you had multiple stacks which showed the blob moving at the correct rate. If you try this in future you will want to get a long enough series of subs that you can make two separate stacks, each of which have enough SNR to get astrometry of the object. Once you have confirmed it by its motion you can always stack the whole set to get a higher SNR. That’s what I did with this faint comet which was about the same magnitude as Leda.
A related question – Are there any guider programs which will track moving objects relative to an offset guide star, allowing long exposures ? (I was issued with a challenge to take a spectrum of Borisov which I declined but it might be interesting to know how it might be done for future reference)
Robin
https://openphdguiding.org/man-dev/Tools.htm#Comet_Tracking
Although I have never used this myself…
- You must be logged in to reply to this topic.