Hello,
After taking a number of science images, naturally now I want to plate solve them. Nova.astrometry.net does a beautiful job, but this requires uploading large .fits files and waiting several minutes for each one. I have tried to build the astrometry.net software locally on a Linux machine (Scientific Linux 7.9), using the instructions for the very similar CentOS 7.8 on plaidhat.com, following the link from astrometry.net, but this fails to compile catalogs/ucac5tofits.c out of the box. Adding the compiler flag -std=c99 gets me past that hurdle, but then the build fails at what appears to be linking build-hd-tree, with complaints about a large number of multiply defined functions. I have no idea how to proceed from here.
Has anyone successfully built the astrometry.net software on a RHEL 7 or similar system? If so, what did you have to do to make it compile and link?
Alternatively, does anyone know of an easier (especially, more efficient) way to plate solve star field images? I have tried to use the native solver in ASTAP, but it has failed on every image I have of Delta Cephei, taken with a 250 mm lens and a 30 second exposure at ISO 200 and having a roughly 5.5 x 3.5 degree FOV.
Thanks in advance.
I have had success using the prebuilt astrometry.net packages for both the executable and data files simply using the prebuilt ubuntu packages. I have not idea how big a deal the Linux distribution is to you. I have also had excellent results posting questions to the Astroment.net Google Group.
Good luck,
Cliff
Thanks, but I have no idea how I would install those Ubuntu packages on a RHEL system - they appear to use an entirely different (i.e., not rpm-based) package management system.
Thanks for the suggestion of the Astroment.net Google group - I will post my question there as well.
Liz
Dustin @ astrometry.net was able to nudge me in the right direction, and I've managed to build the package. It runs very slowly, though, and (at least with the index files I've grabbed) fails to solve some plates that the online solver has no trouble with. If anyone has any suggestions for other plate solving software that can be installed locally on either Linux or MacOS, I would much appreciate them.
For the time being, I will use the online solver from within AstroImageJ. I see no way to batch solve a large number of images, though, and that is primarily what I would be interested in.
Elizabeth,
Do you need to solve the entire image? Or do you just need input of the RA and DEC of the variable to get its airmass in each image?
Roy
Hi Roy,
Thanks for the quick reply. I'm not sure how to correct for airmass, so that's not really what I was thinking of. Mainly, I was under the impression the whole image, or a large part of it, needs to be solved in order for an app like ASTAP to be able to stack the images. But I'm open to correction on that.
Liz
It might be worth while to figure out why ASTAP is failing. I find it does a great job of fast plate solving. Did you install the V17 database in addition to the program itself. Is there anything relevant coming out in the log that might help debug it?
Whoa! I posted too soon... had not tried my images from last night, but just did... and ASTAP solved them very quickly with its internal solver. So I may not need a new solver, and it may just be the quality of the images I had been using earlier. So I'll proceed with what I have - for now, and see how it goes.
Thanks.
Do you use AIJ for photometry?
Roy
That is my plan, yes.
Elizabeth,
I use AIJ. Alignment is based on a reference image by manual selection of a few alignment stars. Aligned images can be stacked. Plate solving is not needed for these procedures.
Roy
Well, I can see I have a lot to learn about this. I was following a video explaining how to use AIJ for constructing light curves of exoplanet transits. The guy had 100 plates to stack and do aperture photometry on, and he used ASTAP to solve them before stacking so I assumed it was necessary. How do you do manual selection of alignment stars on 100 plates? Is there a way to automate the process?
For what I'm doing now, I expect to have upwards of 60 plates from a single session.
I don't think ASTAP requires solving before stacking. It just looks for star patterns and matches them up.
If you do what to plate solve 60 images, there is a batch mode where you select all the files and let it rip through them.
I generally only plate solve the single stacked image before submitting to VPhot.
Yes, in fact that is why I was planning to use it for that purpose, and especially now that it seems that it can actually solve my current set. Hopefully if I can take more images tonight, they will also be solvable by ASTAP... but if not, it would be good to know how to stack images without solving them.
My understanding was that AIJ takes a set of solved images and stacks them itself, but maybe that isn't accurate.
Liz,
Load all your images using File>Import>Image Sequence from the AIJ toolbar. Make sure you have enabled Virtual Stack in the dialog where you select the images.
In the row of icons just above the displayed image (the first of the stack), find the one that is labelled "align stack using apertures" when you hover the cursor. Click that icon. A dialog opens. Click "OK". Then place (by clicking) an aperture around each of a few stars. I choose four near the corners. Make sure those stars are present in all images in the stack. Hit "Enter". The images will be aligned in a new subdirectory named "aligned" in the folder containing the original files.
To stack the images, load them (File>Import>Image Sequence), then select Image>Stack>Z Project (yeah, I know that's not intuitive). Select the appropriate responses in the dialog and click "OK". A stacked image is created and displayed. Save it (File>Save Image/Slice as FITS...) into your preferred folder.
On my PC, the above processes occur quickly with the 8MB binned 2x2 images I usually deal with.
Roy
Hi Roy,
Unfortunately I have the same problem trying to load a whole slew of images into AIJ (via File->Import->Image Sequence) as I do when I try to batch solve them in ASTAP: all of the filenames are grayed out in the dialog and cannot be selected, even though they are all .fits files.
I can load individual .fits files. I cannot load a sequence.
Liz
Sorry, I don't know…
Hi Liz,
Sorry, I don't know why that should happen.
Roy
You can try just renaming the .fits to .fit. There is no difference in the format, either extension should work.
If that works, you can see if the software that generated the .fits has an option to export .fit instead.
It doesn't work, unfortunately. Still grayed out (both in AIJ and in ASTAP).
Yeah, it doesn't work for me either. I will post a question in the ASTAP forum. Generally Hans is pretty good about responding quickly. I'll let you know what he says.
I will be curious to know the reason for this. I suspect a bug, because once - ONCE ONLY, and for no apparent reason - I found that on opening the batch solve FITS and TIFF dialog, the files were NOT grayed out and I was able to batch solve them. ASTAP did a great job, solved all 64, and replaced them with the solved versions, complete with WCS info. When I tried to select those output files in the dialog, I found they were, once again, grayed out.
Then I tried loading the solved images into AIJ - and there it turns out that I was misunderstanding the semantics of the Import Image Sequence dialog. The files were grayed out because you can only select a *directory* - and then it loads all the files in the directory. Then I tried to align them, alternately using the WCS info only and then using apertures.
Neither way was entirely successful. Using the WCS info the alignment went through without a hitch, except that the result wasn't very good. Admittedly this may be due to a flaw in the images. There was a point in my data collection, before taking image 18, that I found the target stars were gone from the viewfinder. There had been high clouds passing over and I had to wait a while, and I assumed that the stars had drifted out of the FOV due to imperfect polar alignment of my SkyTracker (no way to double check it with the camera aimed at Cepheus because at that point, the camera blocked the SkyTracker polar scope).
So I removed the camera, only to find that all the stars were blurry when viewed through the viewfinder. Tried to refocus, without success, then realized that condensation was the problem and wiped it off. Success! But I had to re-aim the camera, and as a result, there is a noticeable jump in the FOV between images 17 and 18, and the images from 18 on are more sharply focused.
Alignment using WCS didn't completely eliminate that jump.
Alignment using apertures failed at various points with "No signal for centroid at target T1" or one of the C stars, depending on the stars that I selected. When I finally found a set of stars that got me through the entire sequence, I found several discontinuities in the aligned sequence where a jump between slices was noticeable.
Also, regardless of the method of alignment, it seems the output images are dimmer than the originals. I don't understand this.
Sorry for the length of this post... I just discovered a number of things and wanted to get them all down, in case someone reads it all and has some ideas.
I reported the issue and Han quickly acknowledged the bug. This was problem only on macOS which I assume that is what you are using. He has fixed it already and uploaded a new 2022-07-08 version. I downloaded it and verified that you can now select .fits files for batch processing.
Excellent, thank you! Will grab that right away.
I'll be the first to admit I know nothing of ASTAP. The doc lists the first main feature as "Native astrometric solver, command line compatible with PlateSolve2".
If you find you do want to get solve-field to run faster, let me know and I will toss out some suggestions.
clear skies,
Cliff
Thanks. It appears, though, that ASTAP's native solver will actually work for me, and it's pretty fast. Out of curiosity, though, and for the future (possibly), what would you suggest to speed up solve-field? I was thinking of rebuilding with full optimization, but I'm not sure how much of an improvement that would make.
The first approach is to minimize the amount of work to be done. Specify reasonable values for —scale-low, -high and -units. These you usually know based on your equipment and they are fixed. The low and high let you give a range. For a particular image you usually know the ra/dec unless your scope is “lost in space”. So specify —ra, dec and radius. Here again use radius for a small range.
If you already specify those, then you might have to think about constraints at the OS or hardware level - too little memory, indices on a low performance disk and such.
Let me know if you this becomes more than a curiosity.
Cliff
... doesn't work for me with the .fits files ASTAP itself created from the .cr2 raw files. It's not that it fails, it's that it doesn't recognize them as being .fits files. The only option for file type in the file selector dialog is "FITS and TIFF files (*.fit*)", a pattern all these files match (the filename format is IMG_nnnn.CR2.fits), but all the files are greyed out and cannot be selected. What's wrong?