han59

PlateSolve2 is fast and reliable but: Very critical in the arcseconds/pixel setting. So the telescope focal length, pixel size in microns and CCD width x height should be entered accurate. You could take these data from a blind-solve . Can scan only a small area. After a meridian flip, the offset could be as large as 1 degrees and this will take a long time to solve. ASTAP is less critical for these two points. An offset of 90 degrees is solved in a few minutes maximum. An offset caused by the meridian flip is solved almost instantly. Blind solving is the most reliable option but it takes more precious time.

You could try ASTAP as a replacement for PlateSolve2 as described http://www.hnsky.org/astap.htm#platesolve2 Probably a dedicated ASTAP menu option in APT will be available this year.

Not that I'm aware of. For your application I assume you require a simplified program to stack smart phone images only. For serious deep sky stacking work you will need powerful processing power and have to tune the settings and parameters, create and add dark, bias images. Remove outliers and so on. A smartphone is then a less suitable environment due to lack of processing power, small screen and more limited human interface.

You have the essential software for imaging and processing To assist with imaging, you could think of software for: Autofocus, to compensate for drift in focus due to temperature. Astrometric solving (plate solving), to find any faint blog and allow accurate pointing over several nights. Scheduling, to image when object is at the highest position in the sky. Automation of everything such as roof opening, cloud detector, so you can sleep while the automation is working Additional processing software. I think 1) and 2) are a great help for consistent and productive imaging. Most likely you need an image acquisition program with these functions integerated. Eg. with CCDCIEL, Kstars, APT, SGP, MaximDL, TheSkyX in order of cost. 3) can be done with a planetarium program bother others prefer an dedicated program. For 5) some can't work without APP or PI but others do everything with Photoshop or Gimp. Han

To the best of my knowledge below an overview of all solvers and front-ends available. Astrometry.net is dominant but you need a front-end to sync your mount. No information was added about the possibility to sync the mount directly:

The UCAC4 picked up fake star streaks, the UCAC3 didn't have. The USNO didn't show interest in cleaning the UCAC4. The UCAC5 was a release where they improved the star positions using Gaia DR1 but unfortunately they choose again a different format so I didn't bother using the UCAC5. All this is now superseded by Gaia dr2. All other star catalogues are now in principle obsolete. Stars don't have a designation anymore. You could identify stars using IAU style coordinate-based designation. If somebody is interested, I have also compiled a list of the missing brights stars in Gaia dr2. I checked up to magnitude 8 against Tycho2 but it was difficult. Han

It is an interesting experiment to try to use MS-Access for accessing millions of stars. I don't know what your trying to achieve, but by mapping, you should divide the celestial sky in area's and write a file for each section sorted in magnitude from bright to faint. Then you can fill a map in maybe a second or so even if you have 200 million stars on your hard disk. For all other queries you have to go through the whole database which will be time consuming. Dividing the celestial sphere can be also a challenge and worth a long study. To fill a star database, I found it is easier to extract them in CSV format from the Vizier server using a query rather then peeking in the original format. At least that is what I did for Gaia up to magnitude 18 and in steps of 0.1 magnitude. Han

I think to keep the size manageable, you can only use a lossy format like JPEG. But there is difference in quality of the compressors and most important a low compression setting to avoid too many artefacts. Compression factor 90 or 100%.

I have described the UCAC4 header record and decoding at: https://sourceforge.net/p/hnsky/code/ci/default/tree/hns_Usno.pas for program: https://sourceforge.net/projects/hnsky/ It is Object pascal, (lazarus/FPC), record length 78 bytes. Han

FYI, Both the HNSKY (planetarium program) and ASTAP (astrometric solver, FITS viewer, stacking) are now available for the Raspberry PI. I used an older version of the compiler for compiling HNSKY, so the menus don't look perfect but at least it works. See this as a ß version. The Tycho star catalog is included. You could add manually the star databases G16, G17 or G18 up to magnitude 18. See the HNSKY webpage. The CCDCIEL imaging program can use ASTAP for astrometric solving. The CDCCIEL program is also available for Raspberry PI (armhf). The ASTAP program with the included star databases will take about 500 mbytes disk space. So there is now more choice for the Raspberry PI: Planetarium programs: KSTARS, CDC, HNSKY Imaging software: KSTARS, CCDCIEL Astrometric solvers (Plate solvers): Astrometry.net, ASTAP See above software as ß versions. Feedback is welcome. Improvements will come. Han

FYI, the latest ASTAP versions (0.9.128) can do blind solving. Below a comparison of the solving time by Platesolve2 and ASTAP of a 10 seconds monochrome exposure (2328x1760) containing about 200 stars: Offset_____PlateSolve2____ASTAP 0.9.127 0°__________1.5 sec___________1.4 sec 2°________ 15 sec_____________1.5 sec 5°________122 sec_____________2 sec 10°_______535 sec_____________4 sec 30°__________________________18 sec 60°__________________________97 sec For this performance the search spiral was adapted to the sky sphere. Secondly the depth of the star database reading is adapted to match the number of stars in the image. ASTAP can be used as a Platesolve2 substitute. See instructions at: http://www.hnsky.org/astap.htm#platesolve2 Prior to this you can try the solving capabilities in the viewer Request are made for native support in SGP and APT but no firm confirmation up to now. Note that ASTAP is still a ß version and feedback is appreciated. It was developed as stacking program but the astrometric solving capabilities can be accessed using the command line. Note that the internal plate solver works best with raw unstretched and sharp images of sufficient resolution where stars can be very faint. Heavily stretched, very long exposures or photo shopped images are problematic. It requires minimum of about 30 stars. Images containing of a few hundred stars are ideal. For star rich images the detection limit is adapted to limit the number of stars detected. This will only work for unstretched images. In the latest version also binning prior to solving is available for large images above 3000 pixels wide. This will also improve signal to noise ratio. For very problematic saturated images Astrometry.net will do a better job. Han http://www.hnsky.org/

Does SGP keeps on trying or is SGP satisfied with the resulting position? When I remember well, you can set the target tolerance in SGP and number of retries. Reducing this tolerance will only help if SGP is happy with the achieved accurracy. Han

After analysing some images series you will know what HFR (or HFD:=HFR*2) you can achieve. In the zenith they will be better then at low altitudes. In general I like to keep all images and only throw away the real outliers caused by loss of tracking or clouds. So in some image series, all images good or maybe 5% is bad. If it is all running smooth the quality will be consistent. Sometimes the mount HEQ5 has a bad position or day and 50% is bad. Or I try to track on on a hot pixel. My telescope focal length is 580 mm. So seeing has not so much influence. For longer length the problems will increase. If you have a very good mount almost all images will be acceptable. The HFD achieved in my setup is 1.8 to 2.0, so lets say 1.9. This is reported by FITS grader as HFR at around 0.9 Outliers are images with a HFD of 2.3 or HFR of 1.1 So what I'm trying to say is that for deep sky imaging keep all images which have historical reasonable HFR or HFD value. Only skip the outliers in HFR/HFD or star count. You can sort on HFR/HFD by clicking on the top of the column. It is not like planetary imaging where you have abundant amount of images and are just looking for that short moment(s) of stable air and perfect seeing. The FITS grader is new for me, so I did some testing to compare it with my own program ASTAP with similar analyse/rename capabilities. This program work well and fast. The only major drawback is there is no viewer included and can’t be linked either. + Can include subfolders + Report and average, SD values + Fast - No viewer The HFR (Half flux radius) should 50% of the HFD (Half flux diameter) value. Compared with ASTAP, FITS Grader reports typical maybe 10% better HFR or HFD/2 values so better values then ASTAP. It can only read 16 bit files which is not a problem since these will produced by almost all image acquisition programs like SGP. The star detection routine behaves a little different for problematic images. Los of tracking, so streaks in the image are reported as an image with a high HFD but normal amount of stars. In ASTAP streak images can be detected by the low number of detected stars. Minor clouds in the image result in a low star count. In ASTAP the number of stars detected stay roughly the same but the background value as a third quality parameter is reported as abnormal high. The latest version of FITS grader is from 2012.

The development continuous. The latest ASTAP version 0.9.92 has a blink routine (for FITS files) to detect minor planets or nova or just make a video of a comet moving: Youtube demonstration: https://youtu.be/7cheLI-3ggQ At the moment the blink sequence can't be exported , but you could capture it by a screen capture program. So ASTAP has become more a software suite. The main functionalities are: - FITS viewer and manipulator including annotation of deep sky objects and stars. - Stacking program, blinker - Plate solver with two types of command line interfaces, remote accessible. Feedback is welcome Han The new blink tab:

Manual is fine. I did till 2 years ago. So your program automates camera control. Fully automated imaging has the advantage you can sleep while it is happening, focus is updated regularly and with plate solving in place, imaging series can continue the next clear night. For me the auto focus to compensate for temperature drift and plate solving are the big improvements. I still stay awake to review and change target. My typical exposure time and cooling temperature are pretty constant. As long it is not too bright like M31 center where it should be equal or less then 50 seconds, I stick to 200 seconds. It is just a number but I could also have taken 100 seconds. It is a compromise of lost time by downloading each image, percentage lost images due to guiding problems, data size and have enough images to recover from the 12 bit A/D resolution to something close to 16 bit by stacking. Gain is always at unity gain. so I don't have to update my darks and flat-darks/bias all the time and keep them for a few months. I see no real practical advantage of playing with the camera gain.