han59

Once your started programming in a language/integrated development environment (IDE) it is very difficult to switch and you could be locked to Windows or an other operating system or facing fading compiler support. I assume most start coding in an environment they like or are used to and don't consider multi platform support until much later. The development of NINA goes very fast and programmers seems to be permanent online for support so this promises a great future. (for Windows users only )

For the ESA a contractor is developing the following: An astrometric web service providing fast and precise astrometric solutions for SST and NEO http://astrometry24.net/ Could be interesting, but not live yet. Han

I'm also playing with the PI trial, but I don't see any structure in the menu's. I believe all the external instructions are helpful and nice (and great they are provided), but there is fundamental something wrong with the program interface if external instruction are required to do something basic. Furthermore, why do I have to press all the time ctrl-A to get brightness and contrast of an image correct?

For the ASI1600, in most cases you better stick to unity gain=139, offset 21. Especially if you imaging deepsky and want to use the full 12 bit range. All other settings give less range. Your light , flats and darks should be made with the same settings.

People will not stop buying. The lifespan of software is typical shorter then that of your other possessions. It will become incompatible or the latest software is just better. Renting guarantees a stable income for the vendor but in general will result in higher costs for the buyer.

For post processing you could also have a look to the free GIMP which can do similar things as Photoshop. For solar image processing ImPPG was just mentioned in an other post.

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