themos

Hello, I was going to try Kevin Sipprell's http://www.scopefocus.info/polar-alignment to see if it works nicely with PPA.

For anyone who, like me, downloaded All Sky Plate Solver (http://www.astrogb.com/astrogb/All_Sky_Plate_Solver.html) and is struggling with a correct PPA.ini file, here's what is working for me [local] shell = C:/Users/themos/AppData/Local/Astrometry/bin/bash --login -c "%s" downscale = 2 configfile = /etc/astrometry/backend.cfg scale_units = arcsecperpix scale_low = 18.0 scale_hi = 27.0 xtra = -p -B none -M none -P none -R none -U none -N none This app, ASPS, creates its own cygwin directory and gets everything needed to run astrometry.net locally. Quite handy

Nova may be misbehaving, it is not currently solving the v.jpg example image.

Hello, I see in the solve-field command extra options "--sigma 70 --no-plots -N none -H 1.2 -L 0.7 -r --objs 100 --dec 85 --radius 5" Did you mean to put these in there? The scale hints should be set with the sliders in Settings and I've never found the other options much use. My Settings "extra" field has these -p -B none -M none -P none -R none -U none -N none

Yes, I am having some issues too, with a fresh laptop. Using miniconda (which is 64-bit) python for PPA. But PHDLab needs a pure 32-bit python in C:\Python27. At least that's my current understanding of the issue. Anyway, a lean and mean C:\python27 at just under 20MB is enough for PHDLab.

Hello! Your reported image scale makes me think you are using full resolution images. It would probably speed things up if you shot reduced resolution images (at a correspondingly coarser image scale) and the solves might be more reliable, too.

I will do something about that in the next release, as it's pretty frustrating!

been there, done that. I always stick to arcseconds per pixel!

Ok, just finished a PPA session, the extra settings are -p -B none -M none -P none -R none -U none -N none -O and I use the 4100 series, my image scale is 8 arcsecs per pixel. My reported error is under 10 arcSECONDS in both alt/az.

daz, I woud stick to the long focal length end of that range, 55mm should be fine. I've downloaded the 4100 series of indices, myself. Make sure the downscale option is set to 2. There's a bunch of extra flags for turning extra file generation (and annotations) off. There's screenshot in the thread somewhere...I am not on my own laptop at the moment so can't paste my settings.

Thanks for the user support! It's been a while since I installed it and I had forgotten all the hoops. I'll make a todo-list now. So, use the "pip install stuff" to bring in the needed python modules.

If you already have a 2.7 python installed, it might be easier for you to install the necessary python packages instead of getting the Anaconda bundle. The probably complete list is ujson, astropy, PIL, numpy, scipy

That's right, Daz!

The only other significant setting I use (apart from downscale=2) is the "configfile" in PPA's settings. I've made an astrometry.net config that searches only the 4100 series indices. For your high-res images, the limits can be -L 3.29 -H 3.63, and I then get a local solve, showing 10 arcminutes error again.

Hello Nathan (is that right?) I always find that an initial solve using Nova provides a reliable solve and gives me an image scale I can use to fine tune local solves. I sometimes use Ron Wodaski's CCD calculator to get an estimate of image scale but people sometimes use different resolutions on their DSLRs. In this case, the CCD calculator gives a very much different image scale than a Nova solve. Nova gives me 18.44 arcseconds per pixel but the CCD calculator says more like 4. The difference is that you have posted reduced resolution JPGs (1024x683). So, try a local solve (through AstroTortilla if you like) with image scale limits 17.5 to 19.5 arcseconds per pixel and then use PPA to do the same and you might get this. (added in edit: the Polar Alignment error is about 10 arcminutes)

Hello there, I think it's best to send me your image files and I'll have a look. Themos

The alternative is to recognize the star pattern around Polaris, compare it to a planetarium view and rotate the camera until it looks correct, that is, similar to the horizontal planetarium view. I've been thinking about adding an automatic horizon finder, marking it with a blue line on the image, but I need to know the correct geographical position and time of capture.

Hello Malcolm, Yes, it can be used with a reflector, with some extra care. The longer focal length of the typical scope will give you a small field of view and perhaps too fine an image scale. You can compensate for that, to an extent, by choosing a reduced resolution mode on your DSLR. The online plate solver (through nova.astrometry.net) should handle almost anything you can throw at it, the local solver might need some tweaking of parameters to work quickly. There's two other issues with the reflector: parity and angle. Parity, first: the image produced by the camera may have the wrong orientation. Take an image of a terrestial feature you recognise through the telesceope and work out if you need to flip it right-left or upside-down to produce a correct image. I just did that with my newtonian and the image seems to come out with the natural orientation. Angle, next: However you place the camera in the focuser tube, you will have to figure out which RA-axis position corresponds to the horizon going along the long side of the sensor. If I place my newtonian horizontal, and have the focuser tube also sticking out horizontally, and then place the camera so that the long side of the sensor is horizontal, then I get the needed angle: the horizon looks horizontal! I haven't come up with a foolproof procedure so some thinking on your part will be necessary to determine how to shoot a horizontal image. If you get it wrong, the feedback provided by the utility will not be much use as it will have a wrong sense of what "up" or "left" means. The numbers reported are arcminutes, 1/60th of a degree. I aim to go under 5. The repository is in https://github.com/ThemosTsikas/PhotoPolarAlign

I think I sent the AT people a message about this method, suggesting they might like to incorporate it into AT, with the automation opportunities that might arise. But I am keen to keep this incarnation of the method something that can be used even with a barn-door tracker. Also, AstroTortilla development seems to have stopped.

That's true, Robin, and I had some experimental code that drew a blue line on the image for the computed horizontal for confirmation. The reason I am reluctant to put that feature in is that people might have the wrong time set on their camera, or the wrong time zone or the wrong long/lat coordinates and then they would get bad advice. I also lost those 10 lines of code during a disk crash (but they would be pretty easy to rederive).

I am sure at some point we will migrate to Python 3 but not yet. If your skills are up to it, you're welcome to do it yourself, you can fork the code from https://github.com/ThemosTsikas/PhotoPolarAlign. AstroTortilla is nice to have as it can do some very useful stuff. As a side-effect, it takes care of installing a working astrometry.net on your machine and we can use that. Themos

1) I'm sorry, Dave. I'm afraid I can't do that. 2) I think so, have you tried running the installer? 3) astrometry.net and I've made some attempt to support AstroArt solves. 3)(again) Yes, it does. The orthogonality is not crucial, some large angle will do. What is crucial is for the one marked as horizontal to be horizontal. The reason for that is that we want to give improvement suggestions in terms of the horizon directions, that is, left-right and up-down. 4) I think it will work if you manage to pick up enough round stars for a solve.

Do not set -H and -L values without setting the -u value. Personally, I always use "-u app", as that is what the solver reports back. -L / --scale-low <scale>: lower bound of image scale estimate -H / --scale-high <scale>: upper bound of image scale estimate-u / --scale-units <units>: in what units are the lower and upper bounds? choices: "degwidth", "degw", "dw" : width of the image, in degrees (default) "arcminwidth", "amw", "aw" : width of the image, in arcminutes "arcsecperpix", "app": arcseconds per pixel "focalmm": 35-mm (width-based) equivalent focal length

Thanks for the report Bill! I will have occasion to try it out at 7 degrees North latitude next week . I can imagine that refraction will cause problems with PPA...