Jump to content


Photo

AstroTortilla 0.4 - easy to install!

  • Please log in to reply
40 replies to this topic

#26 Vostok

Vostok

    Lift Off

  • -----
  • Posts: 13
  • Joined: 23 Mar 2008
  • Loc: Finland

Posted 30 January 2013 - 02:22 AM

There is a descriptive list of FOVs related to different index levels in the AstroTortilla user guide at http://astrotortilla..._user_guide.pdf and the same list in the installer program Ralph is talking about, at the step asking you to choose which indices to dowload. By the way if you select an index range that intersects some index files you already have on your hard disk, it won't download those levels.

And mind that the FOVs listed in the table correspond to the width of quads, which may span about 10% to 100% of your field size according to the astrometry.net documentation. There's an example calculation on which index files are suitable for a given FOV in the user guide.

And as Mitch said, you can examine which index levels astrometry.net is getting its solves to determine which levels to favor for your specific setup.

#27 fmhill

fmhill

    Messenger

  • -----
  • Posts: 436
  • Joined: 17 Jul 2012
  • Loc: Cape Cod, Massachusetts, USA

Posted 30 January 2013 - 11:18 AM

Part of the problem with determining a correlation between indexes and FOV, I have been using AT from 0.2.10 version on, presently at 0.3.0, and the user guide documentation has recently been upgraded within the past two weeks it would seem... I laud the group for this effort as I consider AT to be the most significant astronomical software development I have used to date...

However, using the formula and chart as listed in the new user guide results in a higher index number than what I find is used by AT in practice. I believe the documentation for using the formula and chart is misleading due to an ambiguity in description of sensor size. The standard form When using sensoir size in optical system calculations is to use the diagonal dimension of the sensor in mm. I have not fully tested the formula as described ro see what effect of using Sensor width vs Sensor maximum dimension (diagonal) to see if this corrects the FOV vs Index result.

Bottom line, this documentation of the FOV calculation needs to be modified to remove the ambiguity of sensor size to be used in the calculation in order for this method of selecting index information to be accurate. From my experience, it is incorrect and misleading as it presently is...

#28 Vostok

Vostok

    Lift Off

  • -----
  • Posts: 13
  • Joined: 23 Mar 2008
  • Loc: Finland

Posted 30 January 2013 - 02:28 PM

I believe the documentation for using the formula and chart is misleading due to an ambiguity in description of sensor size. The standard form When using sensoir size in optical system calculations is to use the diagonal dimension of the sensor in mm.


The formula works equally well for any of the directions the sensor size is given in, width, height or diagonal. It just maps a distance on the imaging plane onto an angular value on the sky. That is, if you input the length of your sensor diagonal in mm, you get your diagonal FOV in degrees.

The reason for not specifying to use the diagonal exclusively is not to burden users with unnecessary calculations. For instance a google search for "40D sensor size" results in many hits only specifying the width and height. Obviously it's easy to work out the diagonal size from those if you know who Pythagoras was, but it's unnecessary and out of the scope for the AstroTortilla user guide. After all, with normal sensor shapes, the width, height and diagonal are all of same order of magnitude which is the important quantity to be considered here.

The ambiguity of the index levels to choose is because of the astrometry.net solver engine behavior which depends on loads of factors. The quads recognized from a plate range from 10% to 100% of the field size according to astrometry.net documentation and therefore span several levels of incides as they are.

The user guide calculation example is a guideline and not meant to be used for optimizing the solving performance, but for getting new users in the right ball park to be able to start using the software quickly.

We're looking forward to creating a detailed optimization guide regarding the different solver command line parameters as well as narrowing down the index ranges for the solver to choose from to speed things up.

If any of you got a good grasp of what indices (plural of index, btw :) ) the solver typically favors above others, we'd be happy to collect this information together with information about the FOV you use and perhaps a description of your imaging setup too (focal length and camera used, and typical appearance of the ~5s frames captured by AstroTortilla).

Lauri

#29 Vostok

Vostok

    Lift Off

  • -----
  • Posts: 13
  • Joined: 23 Mar 2008
  • Loc: Finland

Posted 30 January 2013 - 02:32 PM

Regarding which indices to choose, IanL put up a nice description at Astronomy Shed:

http://www.astronomy...=11579&start...

#30 Aimo

Aimo

    Lift Off

  • -----
  • Posts: 18
  • Joined: 28 Jan 2010
  • Loc: Finland

Posted 30 January 2013 - 02:47 PM

The more detailed indexes come into play when shooting at a sparse star fields, where there might not be enough stars meeting the criteria at the higher level indexes. You don't have to move the index files anywhere from the default location, you can either create a per-system (scope+camera) backend.cfg -file, or use the scale limits to make the solver skip files not related to the FOV range. This FOV range can be adjusted automatically on your first blind solve when theScale Refinement in the AT config grid is non-zero, e.g. 0.1 for 10% variance.

The relatively small images are likely a major problem, as the limits by default are fairly tight for fitting the star patterns. The solve-field command takes several command line arguments for setting the solving parameters, such as accuracy limits. Increasing the pattern match threshold can also cause false positives more easily. If your FOV is about 30x20 arcmin, the likely indexes for finding a solution are in the range of 4004-4006, with occasional hits in 4003. A good way to check you image quality is the number of stars detected, it should be in the range of 200-300. You can use the AT log window to see this figure among the first lines of the solver run. Below settings are likely to yield a better result:

downscale = 0
scale_max = 30
scale_xrefine = 0.1
scale_low = 20
searchradius = 180
year_epoch = JNOW
scale_units = arcminwidth


-Antti

#31 LoveChina61

LoveChina61

    Viking 1

  • *****
  • Posts: 904
  • Joined: 19 Jun 2009

Posted 31 January 2013 - 09:11 PM

Thanks, Aimo! Just like before, it still does not solve about 20-25% of the photos I feed into it, but if it is going to eventually plate-solve a specific photo it now does it in record time (15-20secs) thanks to the settings you suggested.

At least some of the photos that I feed into it are not in very star-rich areas. This is true even though I am using high-definition settings for the photos and am using 30sec FITS shots (3.83mgs files). I don't know what else to do about that except to roam around a bit in the immediate area with the scope until I find a more star-rich area. Sometimes I can do that rather quickly but other times I have to slew to several different areas before I find one that has enough stars. I guess that sounds about normal and is just the nature of the ballgame :)

Thanks again!

#32 Aimo

Aimo

    Lift Off

  • -----
  • Posts: 18
  • Joined: 28 Jan 2010
  • Loc: Finland

Posted 10 February 2013 - 08:12 AM

The 1 out of 5 not solving doesn't sound right. I use 2-10 second exposures with 2x2 binning on my C8 and SXVR-H18 (KAF-8300 sensor), and I have set the --sigma flag to get between 200 to 500 stars (as indicated by the line "simplexy: Found N sources." in the logs) with the exposure depending on the proximity to galactic plane.

This gives me a solution rate of 100%, solve times range between 30s to 50s on my old netbook. The --sigma is fully camera dependant, it sets the noise level of the shot to the given floating point value. You can also use the --objs N to cull the object count and reduce your --sigma, this should give a more consistent solve time without changing the exposures across the sky.

Sample run-times on my desktop for a picture of M42 (averages of three runs):
"--sigma 100" found 139 sources, solved in 4.5s
"--sigma 50" found 341 sources, solved in 4.6s
"--sigma 10" found 1342 sources, solved in 6.0s
"--sigma 10 --objs 150" solved in 5.6s
"--sigma 0 --objs 150" found 2622 sources and solves in 12 seconds, extracting the sources with sigma=0 took 8 seconds and without object count limit the actual solve took one second longer.

Granted, I use the 200-series indexes. With the 4000 series indexes you might want to add the extra flags "-c 0.02 -r" meaning it relaxes the star pattern accuracy a bit and re-sorts the found objects by brightess if possible. This gives me a solution in 8 seconds with the same image.

-Antti

#33 LoveChina61

LoveChina61

    Viking 1

  • *****
  • Posts: 904
  • Joined: 19 Jun 2009

Posted 13 February 2013 - 11:16 AM

Can anyone share with me where I can download and convert (if necessary) the 200-series data files? Any help you can provide would be greatly appreciated. Please be as detailed as possible and email me privately if you prefer. Thanks!

#34 LoveChina61

LoveChina61

    Viking 1

  • *****
  • Posts: 904
  • Joined: 19 Jun 2009

Posted 13 February 2013 - 12:38 PM

Antii, thanks for your comments. Unfortunately, I have never gotten anywhere near "simplexy: found 200 sources". Usually I get about 8-35 but the highest I have ever gotten was around 135. I figured it was just counting the number of stars visible in the picture frame I had submitted for solving, so never thought more about it. What could be going wrong here? I am using FITS file that 30sec exposures with darks automatically subtracted.

If possible, please tell me how I can include the USNO A 2.0 files in the search database as well. I already have the entire database downloaded onto my C:/ drive so if I can simply add another string to the Astrotortilla program that tells the program where to search for this other database then that would be great! However, the USNO A 2.0 database files are saved as .acc and .cat files as downloaded from the Naval site. I notice that the 4000 series files used by Astrotortilla program are all .FITS files, so can Astrotortilla even use the standard USNO .acc files, or will I have to somehow convert them to FITS files first? If I need to convert them, how do I do that?

I would really like to download and use the "old" but evidently better (for Astrotortilla) 200-series files.

Concerning the insertion of further flags that you mentioned, where do I insert that into the .cfg file? Should it be right after the sigma information so that the entire configuration line reads "--sigma 0 -c 0.02 -r --no-plots -N none" ?

Thanks for all of your help!

#35 Vostok

Vostok

    Lift Off

  • -----
  • Posts: 13
  • Joined: 23 Mar 2008
  • Loc: Finland

Posted 13 February 2013 - 04:45 PM

You can't use the USNO catalog directly, that's not how the astrometry.net solver engine works. The solver uses pre-built lists of four star patterns calculated based on the catalog.

It's a huge computational effort and that's precisely the reason blind plate solving is possible in the first place -- most of the computation needed is already done when building the indexes. That leaves your computer with just the task of searching them through.

The 200-series are not under a free GPL license, but they can be obtained with permission. You can read more about acquiring a download link (and other licensing stuff) here: http://trac.astromet...NDICES?rev=1... (i suppose that email would still work?). You can, for example, describe to them that you wish to compare the solving process with different index sets.

Lauri

#36 Vostok

Vostok

    Lift Off

  • -----
  • Posts: 13
  • Joined: 23 Mar 2008
  • Loc: Finland

Posted 13 February 2013 - 04:47 PM

And regarding the configuration options, you enter them at the "Custom options" line in the solver configuration table at the main AstroTortilla window.

#37 LoveChina61

LoveChina61

    Viking 1

  • *****
  • Posts: 904
  • Joined: 19 Jun 2009

Posted 14 February 2013 - 09:23 AM

There is no email address listed on the Astrotortilla website that enables me to request the series 200 index files. Can you please give me the appropriate email address or otherwise give me access to the 200-series data files?

I can post my picture on to the nova.astrotortilla.net website and get a solve after just 6.5 seconds. That online site uses the series 200 index files. When trying to get a solve with the downloadable version that uses the 4000 series index data files (star data bases), it will not solve regardless of how much time I allow it to try.

#38 LoveChina61

LoveChina61

    Viking 1

  • *****
  • Posts: 904
  • Joined: 19 Jun 2009

Posted 14 February 2013 - 09:03 PM

I was able to locate the Astrometry.net email address. Thanks!

Concerning the customized settings while using the 4000 series data files, below is a screenshot of what the program displays when I first open it up. Under "Custom options", I have tried adding the custom settings "-c 0.02 -r" to the end of the string that is already displayed. I have also tried deleting the settings that are already displaying and in their place just putting the new settings. Neither method seemed to work. Any other suggestions?

Thanks again for your patience!


Posted Image

#39 Aimo

Aimo

    Lift Off

  • -----
  • Posts: 18
  • Joined: 28 Jan 2010
  • Loc: Finland

Posted 16 February 2013 - 01:55 PM

If you end up with very few stars detected, you should definitely reduce the sigma-value, which sets the noise floor level. And if you are using stretched images, all bets are off, as the relative brighnesses of stars vs background are possibly way off. I don't know what the setup in nova.astrometry.net is for the star extraction and sorting and there are some areas of sky where the 4000 series definitely has a clear disadvantage.

If your FOV is not within the limits set by Scale minimum and Scame maximum, it will never find a solution even if an otherwise suitable match is found, as it doesn't fit the limits.

-Antti

#40 LoveChina61

LoveChina61

    Viking 1

  • *****
  • Posts: 904
  • Joined: 19 Jun 2009

Posted 29 March 2013 - 05:19 AM

Thought I would give a quick update since I have downloaded the 200-series star database files and have been using them to plate solve. In short, they seem to work better for me than the 4000 series files but still are not perfect. If I take at least a 30 second exposure and subtract a dark, then the odds of success are considerably higher.

I find that downloading the 200-series files and then performing plate solving from the Tortilla desktop application has about the same success rate as the online version found at nova.astrometry.net. However, the online version can plate solve quite a bit faster in many cases.

A few times I have had to slew to an area of the sky which had more stars in it in order to finally get a plate solve. For example, I never could seem to get a plate solve in the immediate area surrounding M5. But after slewing to a more star-populated area, I was able to do an accurate plate solve and then sync solidly to M5.

The downloadable Astrotorlilla program works! While Sky6 and most other programs only allow a plate solve somewhere in the immediate area of where it already knows the scope is pointing, Astrotortilla's ability to do a "blind solve" across the entire heavens is quite a valuable tool indeed. Thanks again to the authors who have contributed this program to us all for free! :)

#41 fmhill

fmhill

    Messenger

  • -----
  • Posts: 436
  • Joined: 17 Jul 2012
  • Loc: Cape Cod, Massachusetts, USA

Posted 29 March 2013 - 01:11 PM

Thought I would give a quick update since I have downloaded the 200-series star database files and have been using them to plate solve. In short, they seem to work better for me than the 4000 series files but still are not perfect. If I take at least a 30 second exposure and subtract a dark, then the odds of success are considerably higher.

I find that downloading the 200-series files and then performing plate solving from the Tortilla desktop application has about the same success rate as the online version found at nova.astrometry.net. However, the online version can plate solve quite a bit faster in many cases.

A few times I have had to slew to an area of the sky which had more stars in it in order to finally get a plate solve. For example, I never could seem to get a plate solve in the immediate area surrounding M5. But after slewing to a more star-populated area, I was able to do an accurate plate solve and then sync solidly to M5.

The downloadable Astrotorlilla program works! While Sky6 and most other programs only allow a plate solve somewhere in the immediate area of where it already knows the scope is pointing, Astrotortilla's ability to do a "blind solve" across the entire heavens is quite a valuable tool indeed. Thanks again to the authors who have contributed this program to us all for free! :)


On Astronomyforum(dot)net, in the Astro Imaging subforum, search for a thread "Need help with Astrotortilla"

This is the best source of information about setting up AT and how to set the parameters. It is 28 pages long and you get to see the history of many of us getting started in AT and what not to do as well as what to do...






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics