themos

I will try to add code to recover from this, probably just keep trying to contact the server, for now, maybe implement a timeout later.

That's a shame, sometimes the nova.astrometry.net server goes down for a while. This looks like one of those times.

Yes, to the first. The red x is where you are pointing now. The instructions are to move it (4 right, 2 down) so that it ends up on the NCP. The alignment of the camera relative to the mount does not matter. What matters is that the image we call "horizontal" or "improvement" is exactly of the orientation you'd see with your naked eye, that is, horizon to the bottom, zenith to the top.

Gonzo, don't put -z 2 in the extra, that is the option you select via the downscale setting. Also, no need for the -O, I put that in anyway. I always use arcsecperpix as the scale units, there may be subtle bugs if you use anything else.

Hello Gonzo, I messed up the Mac case in 1.0.4 To treat it as a Linux machine with 1.0.4 perhaps it will work if you edit your .bashrc file to include setting the environment variable OSTYPE to linux. export OSTYPE=linux

Hello Andy, the settings should have been saved in the file PPA.ini, in the same directory as all the other installed files. You may have reinstalled in a different directory, perhaps?

Hello Andy, the place to ask detailed questions about astrometry.net solves is https://groups.google.com/forum/#!forum/astrometry Yes, there are ways of figuring out which index .fits files you would need at a minimum, given your image scale and size. I don't feel qualified enough to give advice, though. I think the reason you see different RA/DEC centers for the solves is that the astrometry.net does not always pick the same stars to match, when you change the downscale and sigma options. I think the way it works is it tries matching a certain "quad" (a set of 4 stars) with a quad in its database and then goes to find corroborating evidence by finding database stars in the image where they are expected to be. Sometmes it uses a particularly squashed quad and then I expect the accuracy to drop off. Ideally, we would select the quad ourselves, picking 4 stars that are in the image and are "well separated". Something to think about... Themos

Andy, downscale =2 should help with cutting down on the number of sources identified. After your initial solve with scale [1,120] you find a scale of 2.57. Subsequent solves should be using a scale interval of [2.57*0.95, 2.57*1.05] if you have the "Restrict scale" setting ticked. I would be surprised if those two factors do not significantly improve your solve times. Here is what I get with one of your 2.57-scale images as a subsequent solve (downscale is 2, sigma is 16) C:\cygwin64\bin\bash.exe --login -c "solve-field -b /usr/local/astrometry/etc/astrometry4200.cfg -u app -L 2.45 -H 2.70 -z 2 --sigma 16 -p -B none -M none -P none -R none -U none -N none -S none -O \"Q07A8473.JPG\""Reading input file 1 of 1: "Q07A8473.JPG"...jpegtopnm: WRITING PPM FILERead file stdin: 5760 x 3840 pixels x 1 color(s); maxval 255Using 8-bit outputExtracting sources...Downsampling by 2...simplexy: found 115 sources.Solving...Reading file "Q07A8473.axy"...Field 1 did not solve (index index-4214.fits, field objects 1-10).Field 1 did not solve (index index-4213.fits, field objects 1-10). log-odds ratio 163.818 (1.39692e+71), 19 match, 0 conflict, 88 distractors, 25 index. RA,Dec = (11.9382,89.7333), pixel scale 2.57482 arcsec/pix. Hit/miss: Hit/miss: -+-+-+--+--++--+-+-++--+----+--------+-+--+---------------------------++--+-------------------------Field 1: solved with index index-4212.fits.Field: Q07A8473.JPGField center: (RA,Dec) = (11.82, 89.73) deg.Field center: (RA H:M:S, Dec D:M:S) = (00:47:17.243, +89:44:03.824).Field size: 4.11842 x 2.74579 degreesField rotation angle: up is -90.4765 degrees E of Nlocal solve time 16.1820001602downscale=4 and sigma=4 also produce quick solves with 100+ sources.

1. No, the PPA_coarse.cfg and PPA_fine.cfg are not looked at unless you explicitly click the "Read from Astrotortilla configuration" button and point to one of them. You can make lots of different AT config files and read them in as needed (but make sure they don't have mistakes in them!). 2. Correct, it doesn't matter how the camera is set up relative to the mount. The only sensitive issue is that the image marked horizontal (or improvement) is the one where the horizon would be horizontal. 3. After a 2-image solve and determination of where the RA axis is on the image, the one thing you must not do is move the camera relative to the polar axis. You can rotate about the polar axis or move the polar axis plus camera as rigid body. Normally, a few minutes delay is not going to be important. If you had tracking on during all the time, and a few minutes have passed your improvement image will no longer be horizontal. But the difference will be small so the left/right/up/down instructions will still make sense but they will be refering to a slightly rotated set of axes. You can rotate back to a more horizontal position if the camera is noticably non-horizontal (say you had to go away for 20 minutes or so). As long as you only rotate around the polar axis, the magnitude of the error displayed will be correct but the breakdown in terms of left/up will change.

Andy, I always use arcsec per pixel myself as it's what the solve-field command displays. I am also pretty sure that downscale=0 causes problems (if the user selects value=1, I just don't pass anything). Also, you have scale explicitly set in the extra field and it is the wrong way round (-H2 -L4.5). I am also suspicious of the --sigma and --objs options so try without them. In summary I would put in the extra field "-p -B none -M none -N none -R none -U none -S none" and nothing else, set arcsec/pixel, L=1, H=120, downscale=2 and try it. Then you can start experimenting.

Hello Gonzo, the instructions left/right up/down are as if someone were to grab the celestial point at the end of the polar axis and move it. I'd really not want to start confusing people with inverting but I could put a little Notes window under the Move window that says whatever the user wants it to say , eg, "Left means tighten blue knob".

Wow, Andy! How much do you trust the stability of your pier/tripod/bearings? I guess you'd first have to work out what the variation in drift is from one night to the next when you don't touch the polar alignment. I suspect you'd hit mechanical limits before you hit the precision limits of the PhotoPolarAlign method.

Hello, please trey again with downscale set to 2, scale_units set to arcsec/pix and limits set to 1 - 120. The extra options I use are "-p -B none -M none -N none -R none -U none -S none". The provided images have a scale between 23 and 24 arcsec/pixel. The numbers in the Computed column do not correspond to the data in the Given column. The displayed scale is the last scale computed from a solve. The pixel coordinates in the next 2 rows are computed after a "Find Polar Axis" or "Show Improvement" oepration and always refer to the Horizontal image and the Improved image respectively. When you start using your own images, first solve your first image in a fresh session with scale limits [1,120]. Once you know the scale of your imaging system, you can then adjust the the limits in the setting to speed up the local solve. If you check the "Restrict scale" button, scale limits are used for both Nova and local solves, if there exists a known scale (that is, if Computed scale is displayed). The limits are set to +-5% of the known scale. If no scale is known or "Restrict scale" is unchecked, then Nova solves are done without scale limits and local solves are done with whatever limits are specified in the Settings.

Hello Andy, do you prefer decimal arcminutes? I could put an option in there... Regarding the discrepancy: I print round pixel numbers but the solver actually returns subpixel accuracy. I convert the decimal pixel distance into decimal degrees first and then split it up into degrees minutes and seconds (line 913 and 914). ddeg = abs(x2a - x1a)*the_scale/3600.0 inst = inst + ('%02d:%02d:%02d' % decdeg2dms(ddeg))At the scale you are working on, half a pixel is more than 1 arcsecond so allowing for the actual pixel positions gaining or losing the odd arcsecond, we can reconcile the numbers. I see (4,2) as the pixel difference. Taking the square root of the sum of the squares = sqrt(20) = 4.472. Multiply by scale = 11.493 arcsec = 0.192 arcmin. So the (4,2) was a rounding up of the true pixel error which is displayed (rounded ) as 0.18 arcmin.

Well, astropy has facilities for determining the sidereal time so I can work out and mark the true vertical at the time the image is taken if I know the location (longitude, really) and the time of exposure in UTC.

Hello again, Version 1.0.4 is ready, Windows setup or Python file Pathname blanks should be handled correctly, dd:mm:ss display, detects wrong parity (mirrors in optical train) and incompatible image dimensions, local solver settings dialog, local solver settings maintained in own settings file, can import local solver settings from any AstroTortilla configuration file Thanks for your support, everyone!

Ok, at least that's a mistake on my part, fixed in the development version. Please edit PPA.py and go to line 1495 and put a # at the beginning of the line so that the line becomes a comment.

Hello Bill, what happens if you open an Anaconda Command Prompt from the Start menu and cd to the installation directory and issue "PPA.py" or "python PPA.py"? I just now managed to screw up the association deliberately! I have another python installation which is not loaded with the modules we need. To get back to something that works, I had to use the right-click "Open with" dialog and then "Choose default program..." then "Browse..." and then select the python.exe program from Anaconda's installation directory.

Thanks!

Very nice, Gonzo, mind if I use them for the doc? Stuart, perhaps something like the reticle overlays Al's Reticle or AMBReticle can be easily adapted for LiveView sessions.

Using a live-view overlay would be kind of neat as long as I don't end up having to support all kinds of video formats and devices.

Andy, thinking about it a bit more, I could find out which direction is the local horizontal if I know the location and the time and then adjust the instructions. Something to think about...

Thanks Andy, Happy NEw Year to you too! regarding orientation, the instructions for moving the polar axis only make sense if the image declared Horizontal is actually horizontal! A DSLR lets you see if the sensor is in the landscape orientation (horizontal) but other CCDs don't and you need to mark them somehow so that you know what RA position corresponds to horizontal image. Also, if the parity is wrong (reversed image) bad things will happen (the development version alerts you that the parity is wrong).

Andy, do the circles around Polaris and Lambda look centred on the stars? The only thing I can think of is a bad solve due to some dodgy pixels or other factors. If you send me the original images I can try different solve parameters to see if there is a sensitivity there. The scale with the SBIG seems quite a bit different.

Or connecting somehow to a local Raspberry Pi...