Plate solving and goto with AstroTortilla

[Gina]

Can you post the frames for us to try and solve, see if that sheds any light on things?

OK

20_6823.tif

[Gina]

Yippee!! I've got it working Taking a long time to solve but it got there Now I can see how I can speed it up.

[IanL]

In the early hours I found that both computers had updated and rebooted closing all applications including TeamViewer So I went out to the obsy and set everything up again (clear skies are currently too rare to be missed!).

You should be able to change your Windows update settings to download but ask you when to install rather than doing it automatically. Either that or avoid imaging on the 2nd Tuesday of every month Automatic updates are a problem that only astronomers, insomniacs and IT Pros operating 24/7 systems know or care about.

- Try using the --objs <n> parameter with the -r parameter to limit the solving attempt to only the <n> brightest objects. That won't actually speed up or fix the solve if you are already using -r, but it will speed up the failure; if you can't solve on the first 20 or 30 sources, it's either going to fail anyway or probably take so long that it isn't worth waiting.

- Maybe change the sigma value to see if you can reduce the number of sources detected as it may be picking up on noise or hot pixels as stars.

- Try the -c parameter again to relax the star shape detection a bit. It may be that it is preferring small stars over larger ones at the default setting. That might mean you don't have the right index files for really features or your image scale settings are excluding them.

- A lot of people have found that playing with downscaling helps, 0, 1, 2 or 4 are the settings to try. Again it may force it to prefer big stars over smaller ones or noise.

[AlistairHowie]

In simple language, what does downscaling actually mean/do?

[themos]

It gives an image file of lower resolution to the source detection subprogram, I think.

[Gina]

You should be able to change your Windows update settings to download but ask you when to install rather than doing it automatically. Either that or avoid imaging on the 2nd Tuesday of every month Automatic updates are a problem that only astronomers, insomniacs and IT Pros operating 24/7 systems know or care about.

Ah yes - good point - thank you I'll look at that.

- Try using the --objs <n> parameter with the -r parameter to limit the solving attempt to only the <n> brightest objects. That won't actually speed up or fix the solve if you are already using -r, but it will speed up the failure; if you can't solve on the first 20 or 30 sources, it's either going to fail anyway or probably take so long that it isn't worth waiting.

Thanks, I'll try that OTOH AT seems to solve on the 2nd or 3rd set of objects which doesn't seem right really.

- Maybe change the sigma value to see if you can reduce the number of sources detected as it may be picking up on noise or hot pixels as stars.

Yes, I've done that.

- Try the -c parameter again to relax the star shape detection a bit. It may be that it is preferring small stars over larger ones at the default setting. That might mean you don't have the right index files for really features or your image scale settings are excluding them.

Aha, I think that may be the trouble - with binning 4x4 the best stars may be too big and it's ignoring them. That would explain why it solves on objects 11-20 or 21-30 rather than on the first 10. With the -r parameter, 1-10 are the best but it doesn't like them.

- A lot of people have found that playing with downscaling helps, 0, 1, 2 or 4 are the settings to try. Again it may force it to prefer big stars over smaller ones or noise.

Thanks, I'll try that too

Thank you for all your help

[IanL]

It gives an image file of lower resolution to the source detection subprogram, I think.

Yes, it just downsamples the image by the factor specified. That can be helpful for two reasons:

- Firstly if you have big images (DSLR-sized), downsizing may speed up subsequent processing steps. Probably less important or desirable if you are using jpegs, more useful if using FITS.

- Secondly it may kill off small-scale noise and stars which will be lost during downscaling, allowing the engine to focus on just the larger scale stars. Shrinking the image may also help the engine identify larger more saturated stars. Equally it may make it harder to identify useful stars if they are shrunk too much.

The overall key is to use a handful of images that you know the online nova.astrometry.net system can definitely solve and then try different settings and index files until you can solve most of them yourself. Keep a note of the working configuration and then start amending the parameters one by one, making a note of whether the total solve-time gets better or worse.

I'd recommend any AT user should take a look at the astrometry.net 'solve-field' command, since that is what AT actually uses to do the plate solving.

It's one of a number of unix command-line utilities that form the astrometry.net engine, hence why the CygWin suite is installed by AT. You can open a CygWin terminal using the CygWin icon (will either be on your desktop or in Program files somewhere) and type: solve-field --help | more

That will list all the options. (You'll need to find out where the solve-field binary is installed if it isn't in your path, probably under /usr/bin or /usr/share/bin or somesuch, can't remember off top of head). Some of the options are hard coded in to AT (image scale, downscaling, etc.) You can add any of the others in the 'custom options' box in the AT interface.

Documentation appears to be a work in progress, the project started a new 'missing manual' project late last year, but it is still missing as far as I can see. Best I have been able to find is this:

http://astrometry.net/doc/readme.html

Whizz down to the 'tips and tricks' section which gives you a bit of a low-down on the important command line options.

[Sp@ce_d]

Interesting.. I upgraded just AT (not cgwin, index) from 3 to v5. I seem to be having the same issues as Gina although I have also moved the 314L+ from the zs66 to the ED80 so that may have a bearing. I use Nebulosity to solve before switching to Artemis.. anyway it wouldn't solve so I've had to change from degwith min 1 max 3 to arcsecperpix 5.1 - 5.3 (for bin 2 @ 5.21, you can set the bin in setup for camera so for bin 1 it would be 2.61 for the 314/ED80). However I seem to remember further back in the thread it wasn't centering the target? Well that's exactly the same for me now. Before in V3 the same settings allowed both the 314L on the ZS66 & the 1000D on the ED80 to solve & center fine. Anyway not messing anymore & wasting clear sky tonight!

[Gina]

It's raining here and blowing a gale! So I'm playing indoors Been using a typical target frame obtained from Artemis Capture using L filter 2s subs binned 4x4. I now seem to have got the best I can by varying Downscaling, c, and scale max/min. app is 10.2 with bin 4x4 314L+ and ED80 with FR. It found just 11 sources with these settings. I think solving in under 15s is satisfactory

Forgot the log - here it is (added extra time to the process)

AT_log_2013-03-15-2316.txt

[Sp@ce_d]

mIght give your settings a try as I'm now on the same setup as you. I didn't have a problem solving previous images so obviously the new configuration upset it. Not sure about not centering the target though?

[IanL]

I have used V0.5 in anger and had no problems with it centring on the required location when selecting in Stellarium, slewing and then switching to AT to do an iterative capture/sybc/solve. Got bang on target in two iterations with no pre-alignment. The only possible cause I can think of is inconsistent JNOW/J2000 settings between AT, planetarium and scope driver, but other than that can't see why that would happen?

I don't think an upgrade of AT should have much bearing on your solving results either. As previously noted (and as the authors say), AT is just a tasty wrapper around other bits of software. All the solving is done by the astrometry.net engine which AFAIK hasn't changed at all between recent AT releases. So if you have a working (or nearly working) AT configuration which you replicate between upgrades and keep/install the same index files, changes to AT shouldn't really affect solving.

The only exception might be regression bugs in passing the parameters to solve-field (check your logs to make sure your settings are being used), and some early flakiness in spawning solve-field which seems to have gone away in recent versions. At the risk of being boring, once I cracked the right settings for my kit, I have been getting consistent results from V0.3 to V0.5.

[Sp@ce_d]

Yes, I was a bit surprised as I didn't touch the backend, I did a test upgrade on a VM first & all seemed ok... but then it wasn't connected to a scope. I think the solve issue was because I moved the Atik onto the ED80 from the ZS66.. at the same time.. silly really I should have checked AT with the orig setup first. It's the centering I'm not sure about. It did try 3 times.. normally it only needs one slew. After all its in an Obsy so it should hardly change. Anyway, It'll have to wait as I'm making the most of an unforcasted clear sky

[Sp@ce_d]

Had another play today. Now got it solving again, I've set it to arcsecperpix & given it a value to cover between bin 1 & bin 2 scales. So, now I can solve my existing images again I tried it out hooked up to the scope, but using the file open dialog for camera ( its daylight ;-)... Am I right in thinking this should work the same way as if it were getting a feed from the camera?

First I told it to Goto Image.. it slews to what looks like the right place (yes it's still daylight ).. It then opens the file dialog and I give it the same file.. All it does is keep slewing a bit and prompting me for another file.. so I give it the same one again.. and so on... got bored with that after a few tries and it started raining again so shut the roof... seriously thinking of backing it out & going back to v.3.. which seems mad as it's only a front end. Maybe the installer has touched something else even though I unticked the rest...

[IanL]

Had another play today. Now got it solving again, I've set it to arcsecperpix & given it a value to cover between bin 1 & bin 2 scales. So, now I can solve my existing images again I tried it out hooked up to the scope, but using the file open dialog for camera ( its daylight ;-)... Am I right in thinking this should work the same way as if it were getting a feed from the camera?

First I told it to Goto Image.. it slews to what looks like the right place (yes it's still daylight ).. It then opens the file dialog and I give it the same file.. All it does is keep slewing a bit and prompting me for another file.. so I give it the same one again.. and so on... got bored with that after a few tries and it started raining again so shut the roof... seriously thinking of backing it out & going back to v.3.. which seems mad as it's only a front end. Maybe the installer has touched something else even though I unticked the rest...

It should work exactly the same with a live image as using the file open dialog, assuming the saved images have the same exposure, etc. Solve-Field can't tell the difference since it's just a saved image file by the time it gets to that part of the process. The only thing that should make a difference is whether the mount is connected when you are using the 'capture and solve' button. If the mount is connected then AT should pass the current RA/Dec reported by the mount to solve-field. If you have 'search radius' set to something less that 180 degrees, it will then limit the search area to (I think) 2 x the search radius around the current RA/Dec. This should speed things up.

If the mount is not connected, or you use the 'goto image' menu option, or if you have search-radius set to 180 degres, then a blind solve is done which covers the whole sky and takes longer. This is where not installing the smaller-scale index files for parts of the sky you can't see will help.

I did notice something similar to your problem when doing some testing yesterday. When doing a 'capture and solve' using the file dialog and connected to the EQMOD simulator, AT just kept looping through the capture/solve process and didn't stop until I cancelled out of the file dialog. I wonder if using the same image file repeatedly is causing it some confusion as it solves to the same RA/Dec each time; in real-world use this wouldn't happen and it may be a use-case the AT developers haven't catered for. In the field at the the start of March the same V0.5 setup seemed to work absolutely fine; left the repeat until parameter at 1 arcmin and it did an initial capture/solve/sync/goto from my starting position, then a second iteration and stopped the cycle on target.

[Sp@ce_d]

snip....

I did notice something similar to your problem when doing some testing yesterday. When doing a 'capture and solve' using the file dialog and connected to the EQMOD simulator, AT just kept looping through the capture/solve process and didn't stop until I cancelled out of the file dialog. I wonder if using the same image file repeatedly is causing it some confusion as it solves to the same RA/Dec each time; in real-world use this wouldn't happen and it may be a use-case the AT developers haven't catered for. In the field at the the start of March the same V0.5 setup seemed to work absolutely fine; left the repeat until parameter at 1 arcmin and it did an initial capture/solve/sync/goto from my starting position, then a second iteration and stopped the cycle on target.

Thats what I was seeing.. had the mount hooked up all as it would be apart from under a dark sky. The only way to test it now I guess is when/if I get a clear night.

[Demonperformer]

Have spent the last couple of days doing a 'dry run' on this program and am so far very impressed with the results. Based on my results, it would appear that the most useful 'limit' to add is the size of the field (either in terms of degrees or arcsecperpix). This has dramatically reduced the time needed to solve the image (about 270s -> about 60s). Although playing with other settings have reduced the time still further (-> about 30-40s) the useful values seem to differ between different images (presumably because of the number of sources found), and transferring settings from one image to another can produce the complete opposite to the desired effect, sometimes even to the point of being unable to solve the image at all. The image-size, however should be constant for a given scope/camera setup.

This leads me to suspect that these other settings will be of very limited use when the program is used in the field, as I will not know until I have solved a frame how to best adjust them, at which point I will already have got the required co-ordinates at which point re-solving the image with more efficient (for that image) settings will be a little superfluous [unless I am missing something].

Until I get my EQ mount (planned date is in August) live testing is going to be limited, but when I get the chance I aim to get out and try some simple 'take image and solve' shots to see how this works out in practice using my current kit.

On a slightly different note, I had been planning to get the EQ6 syntrek, with EQMOD to provide GOTO facility as I only envisage using the EQ mount for imaging. However, I am now wondering if I will always have a camera attached to the scope on the EQ mount, and this program will be able to PA, do a drift-align, and provide a GOTO facility, together with the fact that I don't have a serial port and so would require the USB2EQ6 adaptor (£43 incl p/p from http://www.opticstar...p=0_10_5_0_5_65), would there be any particular benefits to getting the EQMOD in these circumstances? [i realise I would still need to install ASCOM, but this is obtainable free from http://ascom-standards.org/Downloads/Index.htm ]. Any thoughts?

Thanks

[IanL]

Heads up everyone, fresh from the README at http://astrometry.net/doc/readme.html:

We used to have the “4000-series” files: (http://broiler.astrometry.net/~dstn/4000), but these suffer from a bug where parts of the sky do are not covered by the reference catalog.

They have released new 4001 and 4002 series index files:

http://broiler.astrometry.net/~dstn/4100 (For wide field images)

http://broiler.astrometry.net/~dstn/4200

The scheme is the same, i.e. you need to download the appropriate files for the image scales and areas of sky that you are trying to solve. (See the README linked above for instructions on choosing the right files).

I'd back up the 200 or 4000 series files if you have them. The 0.5 AstroTortilla installer will still try to install the 4000 series files. You need to find usr\share\astrometry\data\ in your CygWin installation and remove the 4000 series files from there and copy in the 4001 or 4002 series.

[Demonperformer]

OK, I know this is probably a silly question, but I have gone to the 4100 link, which lists the files, but how do I download the actual file?

If I left-click I get a lot of weird symbols on the screen, if I right-click I get options to open/bookmark/save/copy the LINK, but not download the file.

Thanks.

[IanL]

Depends on your browser, but in Chrome I just right-click and 'Save link as...' and it gives me the usual file dialog so I can choose where to save the file.

[Demonperformer]

Thanks, Ian.

I was misinterpreting the 'save link' option - thought it was going to save the location rather than the contents. DOH!

[IanL]

The AT team have now confirmed they will be releasing an update (maybe this week) with an installer that downloads the new index files for you.

[mickut]

The AT team have now confirmed they will be releasing an update (maybe this week) with an installer that downloads the new index files for you.

New package (0.5.1) is uploading to mirrors now.

-Antti

[Gina]

Cheers for the heads up

[Gonzo]

Decided to give this tool a go, installing the 0.5.1 now

[Gonzo]

Some feedback on this version 0.5.1

(OS: Windows XP)

The LogWindow cannot be closed, despite hitting the cross many times over and over....

I do also get an Ascom error: Getting RA/DEC failed

I'm using my modded EQ1 scope for tests as my EQ3-2 is resting until next year.