×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed

  • Posts: 333
  • Thank you received: 92
That's strange. I just checked the Windows version here.

- With the default settings it will export around 500 of the brightest stars. I exported a star rich image to XYLS.
- Then import the XYLS in the fits viewer FV, I see the 500 stars again in the table.
- When I export from FV to text and sort, I see stars in all corners of the image.

So it looks all correct here. Can you check again? Note the values are stored as 4 byte floats.


For a second phase, can you export an XYLS list? It will be reasonable easy to import.

For the moment I don't want to add flux or SNR values to the export. That would slow down the bright star selection routine.

Han
Last edit: 3 years 10 months ago by han.
3 years 10 months ago #53623

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 92
For a check It is also possible to plot X,Y values in FV:

3 years 10 months ago #53624
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 92
I'm ready to import (experimental) some xyls data.

Han
3 years 10 months ago #53717

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809

So, I don't know what happened with the one image, the other one was perfectly fine. I will test it more soon.

For the Flux, HFR, Ellipse info, I think they are not as critical at this point. If it looks like it is is needed in the future, one way you could allow it to work without slowing down the routine is to do the same thing I did with the HFR in my program. I don't calculate the HFR unless it is specifically requested with an option. So they option could be -HFR or maybe something similar
3 years 10 months ago #53733

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809

Sounds great. So if I add an option to do INT SEP EXT ASTAP, and it just passes ASTAP an xylist, will that work right now? or would ASTAP need some other parameters like astrometry.net such as image width, height, etc?
3 years 10 months ago #53736

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
I'm currently working on Implementing the idea I shared with you before, to use multiple threads to solve the image. It works REALLY well with the internal sexysolver, but I'm having a couple of issues with the external solvers. I am working with two algorithms I developed, one that solves in parallel threads with different scales and the other solvers with multiple depths based on your suggestion of the depth command. Both algorithms work perfectly on the internal solver, but for the external ones, I've had problems with each. I should be able to fix the issues in the next day or two I think. The issues are related to a couple of things. First, the external solvers require many temporary files in order to function. In order to get it to work efficiently, some of them should be shared, but others definitely should not. I'm working out which are which by experimenting. The second issue I have had relates to the options, I had to add the depth keyword for the depths algorithm, and I had to play around with the scaling parameters for the scales algorithm. It seems like it should be solvable in the next day or two.

As to how effective the parallel solves are, for images where we know the scale and position fairly well, the parallel solves actually hurts the solving time just a little. For some images that were solving in 0.2 seconds, they take 0.4 in parallel. For images where the scale and position are not known, however, the parallel solves are GREAT. For some images, the time was halved from 15 seconds to 8 seconds. For others it was cut by a factor of 10, from 10-15 seconds down to 0.9 seconds. And for others, I was never able to get them to solve before, and with this algorithm, I got them to solve in less than 10 seconds. So my thought is to have it turned off by default for now and I will make a profile that takes advantage of it. In the future once it is tested more, it might be good to have an if statement, so that if the scale and position are both provided, don't do it in parallel, but if one or both are left out, to go ahead and do it in parallel.

I hope that soon, I can get it to work on the external ones just as well. I am attaching a screenshot of an image that I had trouble solving before, but that solved with the new algorithm in just 4.3 seconds.

3 years 10 months ago #53737
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
AH, I just realized something that makes it EVEN faster. For the scales algorithm, the parallel solvers that have smaller scales should have less scale range to solve. The bigger scaled parallel solvers can handle a bigger range. Nice!!
3 years 10 months ago #53739

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
For ASTAP, would it work in parallel like I have been trying with astrometry.net? I know you don't currently have a "depths" option, but you do have a fov option. Would that work well in parallel with different FOV's?
3 years 10 months ago #53741

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 92

I have the import routine mostly ready. At the moment I'm in little doubt which columns to read .

Option 1
a) X and Y in two columns in either single or double float format.
b) Condition : Most bright stars only
c) In first header Image scale CDELT2 or focal length & pixel size
d) Original image dimensions would help. Like keyword IMAGEW, IMAGEH as in axy files or just maintain NAXIS1, NAXIS2
e) Mount position


Option2
a) X and Y and flux in the firs tthree columns and optional background in column 4. ASTAP will sort the stars on brightness.
c) In first header Image scale CDELT2 or focal length & pixel size
d) Original image dimensions would help. Like keyword IMAGEW, IMAGEH as in axy files
e) Mount position


option 1a is available in both Astrometry.net AXY and XYLS files.
option 1b a not available by Astrometry.net
option 1c a not available by Astrometry.net
option 1d a is available in Astrometry.net AXY files. Not in XYLS files
option 1e is not available in both Astrometry.net AXY and XYLS files.

option 2a is available in Astrometry.net AXY . Not in XYLS files.
option 2c a not available by Astrometry.net
option 2d a is available in Astrometry.net AXY files . Not in XYLS files
option 2e is not available in both Astrometry.net AXY and XYLS files.


So ASTAP can't work with Astrometry.net files. This needs to be custom files files by Sextractor. So without some agreements this import will not be useful.

<strong>The most practical solution would be that SExtrator would append a table of brightest stars as second HDU behind a WCS style file containing all original header info. Probably it would be wise to give it the extension FITS since it will be a valid FITS file.</strong>


ASTAP is not designed for parallel operation.

Han
Last edit: 3 years 10 months ago by han.
3 years 10 months ago #53746

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 92
ASTAP in parallel would get in problems with star database file access. It would require a split of the search areas. It normally seached in a spiral around the original mount position

A appended WCS file with a table of the brightest stars is the same as ASTAP now exports as XYLS. The FITS extension would be more appropriate. Could you do such an export with your program?

Han
3 years 10 months ago #53748

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
So for consistency with astrometry.net, you don't think it would be appropriate to just do something like this with options?

/Applications/ASTAP.app/Contents/MacOS/astap -o externalSextractorSolver_359469005.ini -speed auto -f externalSextractorSolver_359469005.fits -ra 3.78231 -spd 114.116 -r 15 -width 1280 -height 1024 -xcol X_IMAGE -ycol Y_IMAGE -sortcol MAG_AUTO

If you did it like that, you could easily work with files from astrometry.net and from sextractor.

I think we could certainly do it one of the ways you described, but it could also be good to keep the formats consistent with astrometry.net and sextractor.
3 years 10 months ago #53751

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
I understand on the parallel solves. I will disable that option for ASTAP
3 years 10 months ago #53752

Please Log in or Create an account to join the conversation.

Time to create page: 1.219 seconds