Non-Windows stacking software.

Home Forums Imaging Non-Windows stacking software.

Viewing 17 posts - 1 through 17 (of 17 total)
  • Author
    Posts
  • #574417
    Paul Leyland
    Participant

    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.

    #581439
    Nick James
    Participant

    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 target

    #581440
    Paul Leyland
    Participant

    Thanks 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.

    #581441
    Paul Leyland
    Participant

    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.triggers

    Likewise, 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.

    #581442
    Nick James
    Participant

    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.

    #581443
    Callum Potter
    Keymaster

    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

    #581444
    Nick James
    Participant

    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-dev

    Nick.

    #581445
    Paul Leyland
    Participant

    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.

    #581446
    Paul Leyland
    Participant

    How do I delete a duplicate post made in error?

    #581447
    Grant Privett
    Participant

    Yes, Python does make it very easy… Not as fast as C of course.

    #581448
    Paul Leyland
    Participant

    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.

    #581449
    Nick James
    Participant

    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.

    #581450
    Paul Leyland
    Participant

    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 24

    and 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.

    #581452
    Nick James
    Participant

    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.

    #581460
    Robin Leadbeater
    Participant

    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

    #581462
    Nick James
    Participant

    https://openphdguiding.org/man-dev/Tools.htm#Comet_Tracking

    Although I have never used this myself…

    #581463
    Robin Leadbeater
    Participant

    Ha!  I already use PHD2 and CdC but never realised that function was there 

    Thanks!

Viewing 17 posts - 1 through 17 (of 17 total)
  • You must be logged in to reply to this topic.