Certainly it could, if you would like to modify ASTAP to accept XYLS inputs from Sextractor or SexySolver as an option just like Astrometry.net does

Hmm, yes, I haven't tried playing with the depths setting. It's worth playing with.

Using XYLS would be almost impossible. As far I understand they are refering to index files of Astrometry.net. I'm using a custom made Gaia dr2 star database with no relation to the Astrometry.net index files and a totally different and incompatible quads concept/formulation.

AXY are containing X and Y positions, flux and something else. That would make sense to me. I could experiment to feed them to nova.astrometry.net to test the concept. How far this is something useful has to be proven. At the moment I have doubt.

Also the fits viewer FV can display the .AXY files allowing a second test option and debugging.

cheers, Han

Hi Han,

To clarify, I am not talking about a file with any relation to index files of Astrometry.net. I believe you are referring to a file that is output by Astrometry.net, the <base>-indx.xyls file. That is a file that is output by astrometry.net, is just an xylist (list of x and y pixel positions) of the stars that were found in the image that match stars in the index files in astrometry.net and is not what I mean. What I mean is just an xylist of all extracted sources in an image (or at least the ones you want to use for solving) that is an acceptable input for astrometry.net

An xylist or XYLS file is just a simple FITS Binary table with at least the X position and Y Position of the extracted sources in an image in Pixels. Optionally the binary table can contain a number of other columns such as Magnitude, flux, star ellipse info, etc. The file I am referring to is an acceptable input file for astrometry.net just like an image file. The file you were referring to is also an XYLS file, but one that has had most of the sources in the image removed and now just contains the stars that matched astrometry.net's database. The XYList that is output by astrometry.net is NOT what I want because I think that the other sources not in astrometry.net's database would be potentially more interesting. The columns I am interested in are the X and Y Positions of all the sources, and anything else you can give such as Flux, Magnitude, Star ellipse info, and maybe hfr. I don't need any relation to astrometry.net indexes.

The AXY file or Augmented XYLIST file, is exactly the same as an XYLS file, it just has additional information in FITS headers to aid in the solving of the image. Here are some screenshots of terminal using Tablist to show what is in two different xyls files and one axy file. The axy file and the xyls files look pretty much identical in tablist. The table information in those two file types should be the same, the difference should be in the FITS Headers. The other xyls file has other information that I got back from Sextractor.

Please let me know if you need any more details. I can show you my code for reading and writing these if you need me to.

Thanks,

Rob

I would recommend that the table file have the extension xyls not axy because that means it is just an xylist and not an augmented xylist. We don't need all of astrometry.net's solving hints in the fits headers.

I have an idea. Astrometry.net and all its variants are single threaded and thus run on a single core, meaning they can't take advantage of multi core processors. But the way I wrote SexySolver it is inherently a thread, no matter which type of solver it is. It always runs in a different thread with different processes, different filenames, and everything separate. So, I could VERY easily have the SexySolver spawn additional worker threads to investigate different possibilities simultaneously on different cores. I think this could really speed up blind solves. Now if I do it, should I focus on having different threads investigate different scales simultaneously, different RA/DEC search positions simultaneously, or different depths simultaneously?

Does different threads not slowdown disk access? If everything is in memory probably not.

I have an ASTAP version producing XYLS files. Astrometry.net is not always solving them?? Is the xyls file a selection of stars?

This is an original xyls file:
nova.astrometry.net/user_images/3645189#annotated

This is one uploaded from ASTAP:
nova.astrometry.net/user_images/3645242#annotated

And this is the two images combined. Red is ASTAP. Green is Astrometry.net (the image are a little shifted due to different size)



Han

I have uploaded a new ASTAP version which will produce a xyls file after solving if the command line has the parameter -xyls

www.hnsky.org/astap_setup.exe
www.hnsky.org/astap_amd64.deb

The file contains only x and y coordinates in 4 byte float format.

Han

Nova.Astrometry.net is struggling with solving xyls files both from from ASTAP and it's own. Most fail. I assume due to missing flux and background noise in column 3 and 4. AXY file are quickly solved. This must be something by design. ASTAP has no problem with only X&Y coordinates under de condition only the brightest stars are selected.

Example XYLS:
nova.astrometry.net/status/3503338

Same image the AXY:
nova.astrometry.net/user_images/3645351#annotated

So I think multi-threading should be pretty helpful since I think most disk reads/writes happen near the beginning of a run, assuming in parallel is checked. I don't know, it is worth a shot.

Yes the indx-xyls file produced by astrometry.net is NOT the full set of sources found by astrometry.net according to their website, but just the objects that matched their indexes. Astrometry.net does not save the original sources in an xyls file, but I think the augmented xylist file they save is the full list of sources.

Astrometry.net requires additional parameters to be set to solve an xyls file vs. a regular image file. It needs the image width (--width) and height (--height), as well as the x column (-x-column) and y column (-y-column) names. Also if If you give it the --resort option , it does need the magnitude or flux column (--sort-column) as well as how to sort (--sort-ascending) in order to sort the stars by magnitude. If it doesn't have a sort column, then it can't sort the stars by magnitude and will struggle with the list. However, you can avoid all that and just solve a list with just x and y positions if they are already sorted by magnitude and you leave out the resort option. In that case, it should solve pretty well.

I will check it out, thanks! Please see my notes above about the additional parameters astrometry.net needs in order to solve an image and the other columns that could help.

Ok I made a slight change to the code to support the new xyls option. And I ran a couple of tests. Here are the results. On one image, it makes perfect sense, but on the other, I think some sources are missing from the bottom of the file.