astrometry.net address hardcoded, impossible to use a local running nova server

[papaf76]

Hi, looking here: https://github.com/rlancaste/stellarsolver/blob/master/stellarsolver/onlinesolver.cpp#L325 It seems the software is using a hardcoded value of nova.astrometry.net in place of the specified server (eg. from ekos config). This makes it impossible to use a local copy of nova.

[rlancaste]

Hi there, we can definitely change that to support this. But I must ask, why do you need that? If it is on Mac, you can directly access astrometry.net's solve-field binary. If it is windows, you can directly access the Cygwin or ANSVR solve-field binary. Are you hosting another astrometry server on your local network on a different machine?

[rlancaste]

I think I found a post relating to that on the INDI forum just now. But I can't seem to log in. From that forum it looks like I found that you are hosting a local astrometry server for multiple imagers imaging nearby. That makes sense. Do you have any details about how you are hosting your astrometry server? Is this an ANSVR server or does it work exactly like nova.astrometry.net? If it is the second is that easy to set up? If I was going to make such a change I would need to be able to test it.

[papaf76]

Hi, thanks for taking the time to look into this. What I'm running on https://nova.papaf.org is essentially what you said, a server, based on ansvr, that mimics the API part only of nova. I used ANSVR cause I only needed the API part and also all the other pieces of software I found around have drifted back from an undocumented (!!!) set of changes into astrometry.net and it wasn't easy for me to implement that change in other softwares. Feel free to test it whenever you want, it's active. And thanks again for your time!

Il giorno mer 18 ago 2021 alle ore 06:03 rlancasteAstro < @.***> ha scritto:

I think I found a post relating to that on the INDI forum just now. But I can't seem to log in. From that forum it looks like I found that you are hosting a local astrometry server for multiple imagers imaging nearby. That makes sense. Do you have any details about how you are hosting your astrometry server? Is this an ANSVR server or does it work exactly like nova.astrometry.net? If it is the second is that easy to set up? If I was going to make such a change I would need to be able to test it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rlancaste/stellarsolver/issues/80#issuecomment-900794989, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMEK7CDXFRUVF4FLWZ6IUDLT5MWJLANCNFSM5CKVL4NA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[papaf76]

BTW, I had to make a change to my ANSVR server just now, as I discovered the configuration panel from Ekos has an enormous issue: clicking or not on use position and/or use scale does nothing if you're not using the internal solver. Actually, I'm not able to check if it does something with the internal solver, as that doesn't log anything despite me having the verbose option on on the alignment log. So I made it that my server always blind solves, no matter what the json object contains, it will always discard ra, dec and radius.

[laheller]

Hi there, we can definitely change that to support this. But I must ask, why do you need that? If it is on Mac, you can directly access astrometry.net's solve-field binary. If it is windows, you can directly access the Cygwin or ANSVR solve-field binary. Are you hosting another astrometry server on your local network on a different machine?

Hi @rlancaste

I have my own custom Cygwin build of astrometry.net on Windows. I also have KSTARS for Windows installed.

Can U please show me (when possible via a screenshot), how to access my solve-field binary from KSTARS? For example when binary is at C:\astrometry.net\bin\solve-field.exe how to specify that in KSTARS/EKOS Windows version?

Another question is, whether is it possible also specify custom cmdline arguments to the solve-field (again from KSTARS/EKOS on Windows)? Or it is calling it using hardcoded set of arguments?

Thanks and regards,

Ladislav

[rlancaste]

So one thing that I discovered when I was doing all this work on astrometry.net last year was that I could directly control ANSVR and Cygwin based astrometry.net on windows just like astrometry.net on Macs and Linux. This function is built into StellarSolver and also Ekos as a result. This method of access proved to be way way faster than using ANSVR the traditional way. This is why I made the change to just use online for the actual astrometry.net server and to use "local" for ANSVR, since it worked so much better.

[rlancaste]

I had not considered the use case of having ANSVR set up on one computer and a bunch of other machines accessing it in the field. I have always put either astrometry, ANSVR, or cygwin ANSVR on the same machine I was using to run Ekos since it is orders of magnitude faster than ANSVR. But I could see if you are using a bunch of older raspberry pi's or you were short on space, it might be good to have a local astrometry server. I will look into supporting this use case then later today.

[rlancaste]

Ladislav to answer your question, cygwin astrometry is supported just like ANSVR and local astrometry on Macs and Linux. As long as cygwin or ANSVR is running on the same windows machine you are using for Ekos, KStars will send it all appropriate command line arguments you would like to send it using the Ekos options. I believe it now supports every command line option that astrometry.net offers (at least the ones that matter).

[rlancaste]

I will see if I can get a screenshot for you

[rlancaste]

It might take a little bit because while I had a nice virtual machine all set up when I was doing this work last year, I don't think I have that machine anymore. It wouldn't help as much to show you a Mac or Linux screenshot.

[rlancaste]

Hmm, let's try this, here are some Mac screenshots where I filled in the settings that I think I was using for Cygwin on Windows. Your paths should be similar, but you should check

[rlancaste]

[rlancaste]

For the source extraction method, you have two options available to you, you can use internal SEP, or astrometry.net's built in Star extraction. For the command line options, that is what the "Options profile" is for. There are so so many options. I found it best to try to develop profiles of options for specific tasks. If you don't like them though, you can customize the options or you can make your own set.

[laheller]

@rlancaste Thanks for the screenshots and explanation, I'll try.

[rlancaste]

papaf76, as I said a couple of minutes ago, I will run some tests today/this weekend to verify how well StellarSolver is playing with ANSVR when used in place of astrometry. I can easily fix the problem you found, but my concern right now is whether some features I am relying on from astrometry.net (such as downloading logs) will be supported the same way on an ANSVR server.

[rlancaste]

Ladislav, so the "scale and position" options are separated from the rest. They are the settings that get changed all the time, they are in another tab. The rest of the settings can be accessed in the profile editor if you need to. But note that the profile that gets used is the one selected in the other screenshot at the far right. You shouldn't need to change these much, my goal is to figure out what the best settings should be for certain situations and make a profile that the user can select. You can make a profile of the "best" settings as well and save it or send it others as a file. It is exportable.

[rlancaste]

papaf76, I think I have fixed the problem you brought up. I believe the hard coded nova.astrometry.net was just an oversight on my part because just a few lines above where I hard coded nova.astrometry.net, it was using the custom astrometry server path. So probably just an accident. I also made a couple of edits to make the tester work with alternate astrometry servers and made the log output display what server is being accessed in its statements. I was able to solve an image with your remote ansvr server that you posted above after making these changes. Note that this change was made in master on GIT, so if you are using a stellarsolver that is packaged with windows KStars or if you are using a stellarsolver that is installed from a package manager, then there will be a delay before these changes show up there. Let me know if there are more issues.

[rlancaste]

papaf76, as for the other thing you brought up, that the online solver is not using the scale or position settings. It definitely should be using them since those options are passed by stellarsolver to the online server along with the image and other info. However, I could certainly check that they correctly get passed on, since there are several steps in the process and there could be a bug somewhere.

[papaf76]

Hi, I made a few tests, and I'm pretty sure if the image has the coordinates in its header the info gets passed to the solver, no matter what's been set with the Use Position and Use Scale toggles. Maybe do a test yourself, I'd hate to have been wrong on that and it's certainly a possibility..

Il ven 20 ago 2021, 17:19 rlancasteAstro @.***> ha scritto:

papaf76, as for the other thing you brought up, that the online solver is not using the scale or position settings. It definitely should be using them since those options are passed by stellarsolver to the online server along with the image and other info. However, I could certainly check that they correctly get passed on, since there are several steps in the process and there could be a bug somewhere.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rlancaste/stellarsolver/issues/80#issuecomment-902769345, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMEK7CEJ3HOW4J4AL4EJKK3T5ZXBRANCNFSM5CKVL4NA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[rlancaste]

Ok, did you try this with ekos's load and slew feature, or is this with plate solving? If you are plate solving in the align tab, you can select to have it upload the whole image, or do SEP on it and just upload the star list. You can set that with star extraction method.

Also are you saying that Ekos is passing the position and scale on to the solver separately or that the image is uploaded with position and scale in the headers and then astrometry on the server is using what is in the headers?

[papaf76]

I always tried with SEP, wasn't aware you can change that.. I can try tomorrow setting it differently. What I saw was the ra parameter and the scale one on the command line when I was using ASTAP, and in the json object that reached my server when I was testing it, both tests were without checking use scale and use position.

Il ven 20 ago 2021, 17:46 rlancasteAstro @.***> ha scritto:

Ok, did you try this with ekos's load and slew feature, or is this with plate solving? If you are plate solving in the align tab, you can select to have it upload the whole image, or do SEP on it and just upload the star list. You can set that with star extraction method.

Also are you saying that Ekos is passing the position and scale on to the solver separately or that the image is uploaded with position and scale in the headers and then astrometry on the server is using what is in the headers?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rlancaste/stellarsolver/issues/80#issuecomment-902786164, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMEK7CCLENW4QGR74PUDRZLT5Z2FVANCNFSM5CKVL4NA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[papaf76]

Oh they were all load and slew.

Il ven 20 ago 2021, 17:46 rlancasteAstro @.***> ha scritto:

Ok, did you try this with ekos's load and slew feature, or is this with plate solving? If you are plate solving in the align tab, you can select to have it upload the whole image, or do SEP on it and just upload the star list. You can set that with star extraction method.

Also are you saying that Ekos is passing the position and scale on to the solver separately or that the image is uploaded with position and scale in the headers and then astrometry on the server is using what is in the headers?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rlancaste/stellarsolver/issues/80#issuecomment-902786164, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMEK7CCLENW4QGR74PUDRZLT5Z2FVANCNFSM5CKVL4NA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[rlancaste]

Load and slew is different. When I first made my updates to integrate StellarSolver, I made Load and Slew use the "use position" and "use scale" checkboxes in Ekos (actually I think that I first made it blind solve every time, but that was short lived). I think someone might have changed it more recently so that load and slew ignores the boxes, but we can check that.

[laheller]

@rlancaste

I have KSTARS v3.5.4, this version: https://www.indilib.org/jdownloads/kstars/kstars-3.5.4.exe

Found the settings you had on your screenshots. Here are the settings I used:

As you can see in the first screenshot I am using custom profile called "Lacko". Also on the fourth screenshot there are settings for the "Lacko" profile. Unfortunately I can set only the solving parameters provided by this editor.

Here is the log output from the EKOS Alignment window:

2021-08-20T17:40:20 Solver Failed.
2021-08-20T17:40:20 Base: "C:/Users/Ladislav Heller/AppData/Local/Temp/externalSextractorSolver_13", basefile "externalSextractorSolver_13.fits", basedir "C:/Users/Ladislav Heller/AppData/Local/Temp", suffix "fits"
2021-08-20T17:40:20 Reading input file 1 of 1: "C:/Users/Ladislav Heller/AppData/Local/Temp/externalSextractorSolver_13.fits"...
2021-08-20T17:40:20 Command: C:/cygwin64/bin/solve-field.exe -O --no-plots --no-verify --crpix-center --match none --corr none --new-fits none --rdls none --downsample 3 --odds-to-solve 1e+09 --odds-to-tune-up 1e+06 -vv --backend-config C:/Users/Ladislav Heller/AppData/Local/Temp/externalSextractorSolver_13.cfg --cancel C:/Users/Ladislav Heller/AppData/Local/Temp/externalSextractorSolver_13.cancel -W C:/Users/Ladislav Heller/AppData/Local/Temp/externalSextractorSolver_13.wcs --keep-xylist C:/Users/Ladislav Heller/AppData/Local/Temp/externalSextractorSolver_13.xyls C:/Users/Ladislav Heller/AppData/Local/Temp/externalSextractorSolver_13.fits
2021-08-20T17:40:20 Starting external Astrometry.net solver with the Lacko profile...
2021-08-20T17:40:20 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2021-08-20T17:40:20 Configuring external Astrometry.net solver classically: using python and without Sextractor first
2021-08-20T17:40:20 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

From the log it is clear that it uses the "Lacko" profile during solving but it seems to ignore ScaleLow and ScaleHigh parameters. Also there are a lot of hardcoded parameters, some of them I would completely ignore. But the most important is that there are missing the parameters I really need during solving and I don't know how/where to enter them.

A typical WORKING solver command line in my custom astrometry.net build is following: solve-field --timestamp -O -l 30 -D /tmp -L 40.0 -H 90.0 -u dw -z 3 -y --no-plots --no-remove-lines --uniformize 0 --fits-image /cygdrive/d/Astro/Sas.fits

I guess it is not possible to call solve-field like the above example, from EKOS, right? What I really miss in the Alignment options window (in the profile editor) is a text field where we can enter our custom command line parameters for solve-field and when this text field is filled-in, EKOS shall pass them to solve-field and ignore everything else in the profile setting.

BR,

Ladislav

[papaf76]

To be honest, it's not the first time I'm told it's different. In my opinion, the behavior should be as consistent as possible.. What do you think? Or at least make it really obvious the options don't work with load and slew..

Il ven 20 ago 2021, 17:55 rlancasteAstro @.***> ha scritto:

Load and slew is different. When I first made my updates to integrate StellarSolver, I made Load and Slew use the "use position" and "use scale" checkboxes in Ekos (actually I think that I first made it blind solve every time, but that was short lived). I think someone might have changed it more recently so that load and slew ignores the boxes, but we can check that.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rlancaste/stellarsolver/issues/80#issuecomment-902791580, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMEK7CGN3FCN25JT4EJU5TDT5Z3HRANCNFSM5CKVL4NA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[rlancaste]

I agree, I made it that way, it wasn't my decision to change it. I think it was changed though because the load and slew is using totally a different position and scale than the current ekos position and scale which is shown next to the "Use Position" and "use scale" checkboxes. I think it was causing some confusion on the part of users, which is why it was changed.

[papaf76]

That does make sense. Still, I think making it abundantly clear would be better. I saw your question on the indi forum, I'll reply there tomorrow as it's not very phone friendly.

Il ven 20 ago 2021, 18:25 rlancasteAstro @.***> ha scritto:

I agree, I made it that way, it wasn't my decision to change it. I think it was changed though because the load and slew is using totally a different position and scale than the current ekos position and scale which is shown next to the "Use Position" and "use scale" checkboxes. I think it was causing some confusion on the part of users, which is why it was changed.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rlancaste/stellarsolver/issues/80#issuecomment-902810221, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMEK7CF76RNG6UQ36O6WZ73T5Z6V7ANCNFSM5CKVL4NA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[rlancaste]

Yeah, there is always room for improvement. I will see what Jasem thinks about it.

[laheller]

@rlancaste @papaf76 Sorry for jumping in to your conversation. @rlancaste can you please check my last comment above?

[rlancaste]

Ladislav,

Sorry I missed that comment. I spent hundreds of hours going through all the details of parameters and code in astrometry.net last year, and working with people over the last 5 years who had no end of problems with plate solving. This project was intended to get on top of all the issues and get rid of most of them. I can help you with these details. The options in astrometry.net can get a little crazy. I studied all of them, exposed the ones you need in an interface, and hard coded the ones that shouldn't be turned off or it will fail. There are also some options that I added that make other features work. The custom box was nice, but it caused many many problems. When users entered one too many spaces for instance, or accidentally deleted something that needed to be there. It was bad.

If it failed immediately, please make sure first that all the paths you entered are correct for your application.

You told me that your solver was here: C:\astrometry.net\bin\solve-field.exe

But you entered this: C:\cygwin64\bin\solve-field.exe

Please check to make sure that all 3 paths exist and are entered correctly. You can probably not worry too much about the config file, since StellarSolver should make its own and you should use that, but still check all the paths.

To answer your questions about the parameters, I will try to explain here:

Here was the option set you listed: solve-field --timestamp -O -l 30 -D /tmp -L 40.0 -H 90.0 -u dw -z 3 -y --no-remove-lines --uniformize 0 --fits-image /cygdrive/d/Astro/Sas.fits

The -O and --no-plots options match what was passed exactly. The -z parameter was passed, it is the same as --downsample The -L/--scale-low and -H/--scale-high parameters were not passed because you turned off "use scale", however if you check the temporary config file, you will find that it used the minwidth of 40 and maxwidth of 90 parameters in that file since they are settings that are to be used when the scale is not provided. The -u parameter was not passed because you turned off "use scale". The parameters in the temporary config file are in degrees by default. The --timestamp parameter is not really needed, but might be nice to add. The --no-remove-lines and --uniformize 0 options are added to avoid python usage if you decide to use an external star extractor or SEP, you should leave those options out if you want it to use the built in star extraction process. The -D parameter is not needed here since StellarSolver copies the file into the temp directory first and then all the files end up in there. The --fits-image parameter is unnecessary since it automatically assumes it is a fits image. The -l parameter was not passed because it was generated in the temporary config file.

I think that addresses everything that was in your options list. Please let me know if you have more questions.

Thanks,

Rob

[rlancaste]

Also, you should not have to make a new options profile unless you want to optimize something. If you are using one of the default profiles, they should just work. None of them would cause it to say "solver failed" right away. I would recommend using a default profile until you get it working, and then make a custom one if you like. An immediate "solver failed" message is usually a configuration or paths problem.

[laheller]

@rlancaste

Thanks for replying. Both the following paths are correct since I have two indepenent Cygwin/Astrometry.net instances:

C:/cygwin64/bin/solve-field.exe
C:/astrometry.net/bin/solve-field.exe

I also enabled the Use Scale settings and entered my estimated scale parameters 40deg and 90deg:

The first interesting and for me confusing behaviour is that when I start "Load & Slew..." the ScaleLow and ScaleHigh parameters are missing from the solver command line, no matter whether I enable or disable the "Use Scale" checkbox:

2021-08-21T15:25:37 Solver Failed.
2021-08-21T15:25:37 Checking if file "C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_32.fits" ext 0 is xylist or image: image
2021-08-21T15:25:37 Base: "C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_32", basefile "externalSextractorSolver_32.fits", basedir "C:/Users/cica/AppData/Local/Temp", suffix "fits"
2021-08-21T15:25:36 Reading input file 1 of 1: "C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_32.fits"...
2021-08-21T15:25:36 Command: C:/astrometry.net/bin/solve-field.exe -O --no-plots --no-verify --crpix-center --match none --corr none --new-fits none --rdls none --downsample 3 --odds-to-solve 1e+09 --odds-to-tune-up 1e+06 -vv --backend-config C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_32.cfg --cancel C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_32.cancel -W C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_32.wcs --keep-xylist C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_32.xyls C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_32.fits
2021-08-21T15:25:36 Starting external Astrometry.net solver with the Ladsi profile...
2021-08-21T15:25:36 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2021-08-21T15:25:36 Configuring external Astrometry.net solver classically: using python and without Sextractor first
2021-08-21T15:25:36 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I also wrote a small program which catches and displays the temporary externalSextractorSolver_XX.cfg file before it is deleted. The content is below and seems to be correct:

minwidth 40
maxwidth 90
cpulimit 600
autoindex
add_path D:/data

I think the above scenario does not really work in Windows version of KSTARS/EKOS. Was able to reproduce many times, always the same result: Scaling parameter are not included in the command line.

For "Load & Slew" I use an image which perfectly works from Cygwin via command line solve-field!

Second scenario when I try "Capture & Solve", it also does some weird things: It sometimes changes/overwrites my scale settings defined in the "Scale & Position" options even when the "Auto Update" option is disabled. The defined scaling options however are appearing in the logged command line but they are definitely not the ones I specified:

2021-08-21T16:03:04 Solver Failed.
2021-08-21T16:03:04 (not xyls because: FITS file does not have any extensions)
2021-08-21T16:03:03 Checking if file "C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_34.fits" ext 0 is xylist or image: image
2021-08-21T16:03:03 Base: "C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_34", basefile "externalSextractorSolver_34.fits", basedir "C:/Users/cica/AppData/Local/Temp", suffix "fits"
2021-08-21T16:03:03 Reading input file 1 of 1: "C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_34.fits"...
2021-08-21T16:03:02 Command: C:/astrometry.net/bin/solve-field.exe -O --no-plots --no-verify --crpix-center --match none --corr none --new-fits none --rdls none --downsample 3 --odds-to-solve 1e+09 --odds-to-tune-up 1e+06 -L 32 -H 108 -u degwidth -3 111.089 -4 90 -5 50 -vv --backend-config C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_34.cfg --cancel C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_34.cancel -W C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_34.wcs --keep-xylist C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_34.xyls C:/Users/cica/AppData/Local/Temp/externalSextractorSolver_34.fits
2021-08-21T16:03:02 Starting external Astrometry.net solver with the Ladsi profile...
2021-08-21T16:03:02 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2021-08-21T16:03:02 Configuring external Astrometry.net solver classically: using python and without Sextractor first
2021-08-21T16:03:02 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2021-08-21T16:03:01 Image received.
2021-08-21T16:02:49 Capturing image...

As you can see in the above log, it is passing ScaleLow(L)=32deg and ScaleHigh(H)=108deg. I have no idea where those values are coming from. I expected values L=40deg and H=90deg.

I tried a lot of different comibnation of settings for both "Capture&Solve" and "Load&Slew" but it never solved me successfully. I give up, have no idea what I am doing wrong....

BR,

Ladislav

[rlancaste]

Ladislav,

For this first issue: "The first interesting and for me confusing behaviour is that when I start "Load & Slew..." the ScaleLow and ScaleHigh parameters are missing from the solver command line, no matter whether I enable or disable the "Use Scale" checkbox"

Ok, I think the issue here is "load and slew". This is an Ekos issue not a StellarSolver issue. As I was recently discussing with papaf76 both in the discussion above and in the other forum. I personally think that Ekos should respect the Scale and position settings when doing a Load and Slew, but it currently ignores them. Jasem made a change just yesterday I think, that would fix that. But it will take time to get into a windows build release I think.

As for Capture and Solve. I investigated it this afternoon. I just opened a fresh windows machine about 10 minutes ago and I ran some tests. I downloaded and installed ANSVR, then I downloaded and installed KStars. I did not open or change any configurations in ANSVR at this time. Then I opened up KStars, started up an INDI Server on a Mac machine and connected to the INDI server from the Windows machine. I then went into the settings for the Align module, I clicked to use "Local Astrometry" instead of the internal solver. I went to the Index file downloader and downloaded a bunch of index files (which get placed into ANSVR's index file directory). I turned on "verbose logging" and "alignment logging" in the Ekos logs options. I increased the capture time for solving to 10 seconds to get a decent amount of stars for plate solving, and I changed it to 2x2 binning. I did not change any other settings. Then I slewed to a location in the sky and did a "Capture and Solve". It did the following and solved the image:

Then I changed the star extraction method to the "built in option" and I did another capture and solve, and it solved it again:

In the screenshots, you should see all the details about how it solved the image, what parameters were sent etc.

As for this item you said: "It sometimes changes/overwrites my scale settings defined in the "Scale & Position" options". I think we should definitely look at why Ekos is doing this. I don't think it should do that.

[rlancaste]

I think this statement "I think the above scenario does not really work in Windows version of KSTARS/EKOS. " is true because Ekos is currently not respecting your choice to use or not use scale. However to say that it currently doesn't work on Windows would not be true because I just tested it on a fresh windows machine and it did work.

[laheller]

@rlancaste Maybe the EKOS doesn't like my astrometry.net built from latest sources on Cygwin 64bit. Which is interesting because when I start Cygwin terminal and try there any astro image, it just works. Anyway, I'll try that ANSVR stuff.

[rlancaste]

The ScaleLow(L)=32deg and ScaleHigh(H)=108deg instead of L=40deg and H=90deg is something that Ekos does I believe to enlarge the scale slightly because often times people specify a scale and the image ends up just outside of their range (due to things like filters, paracorr's, and other things that change the focal length a little. We were getting a lot of people who got failures because their scale was too narrow. So I think it is 40 0.8 = 32 and 90 1.2 = 108

[rlancaste]

I am not sure that it would matter that you are using Cygwin vs. ANSVR, I did test both a lot when I was working on the project. But its possible that some configuration is different on your system for some reason. Maybe a path is to a different place for example. I could definitely run a Cygwin test again.

[rlancaste]

You know I think it would be good if Ekos informed you why the scale it is sending to StellarSolver is not the same as what you entered. . . we should add a message saying that.

[laheller]

@rlancaste

Just tried the combination of InternalSolver & BuiltInMethodForSolver and it WORKED for both Capture&Solve and Load&Slew !!! So I am 99% happy and thank you for this StellarSolver stuff, it's really a good tool!

However I stil can't believe that it fails for my local custom build of astrometry.net. One last idea, if you have time, I can upload somewhere my astrometry.net build and you can download and try with that...

BR,

Ladislav

[rlancaste]

Ok so then you didn’t decide to try ANSVR?

Yes, for the Cygwin build it should work as well unless there is a configuration issue or I guess if astrometry made some big changes and they changed some parameters on us since last year. Did you just install Cygwin and build astrometry with the latest sources following their instructions? I could try that again and see. Yesterday I only tested ansvr since that is much easier to set up.

[laheller]

@rlancaste

Did not tried yet with ANSVR, since the internal solver works.

Anyway, if you want to check it with my custom build of Cygwin/astrometry.net, you can download it from: https://drive.google.com/file/d/1oJ6JveXm0nVNiwse4CUmF7ozaVyGlSX8/view?usp=drivesdk

If you decide to try it, just simple extract the downloaded file (and also the TAR inside) using 7-zip utility to any folder at the root drive.

BR,

Ladislav

[rlancaste]

Ok, so I tried your custom astrometry.net build. I unzipped it as instructed, I changed the paths to match the correct programs: The solver binary was located at: C:/astrometry.net/bin/solve-field.exe The wcsinfo program was located at: C:/astrometry.net/bin/wcsinfo.exe

Then I tested it using my INDIServer simulator as I did yesterday on ANSVR. I set it to use the following options:

It captured and solved successfully. But then I tried these options:

and it failed. This can be seen in the following output:

To investigate why it failed, I went to the cygwin terminal and I tried to plate solve an image using a terminal command and it said the following:

/bin/sh: C:/astrometry.net/bin/image2pnm: /usr/bin/python3: bad interpreter: No such file or directory

Which leads me to think that the reason it failed for you might be because python3 is not properly installed in your cygwin build.

As an interesting aside, a very similar issue is the very reason that I started to embark to create StellarSolver in the first place. A bunch of people were having all kinds of python issues with astrometry.net (mainly on Macs) and it was driving me crazy. So I made StellarSolver to combine SEP source extraction with astrometry.net solving. Then it evolved from there to become the StellarSolver internal solver and the library.

[rlancaste]

Let me know if there is something I can do with the python3 issue in your cygwin build and I can try again

[rlancaste]

Wait, it just got weirder. I think python3 does exist, but maybe it's a broken link. If you say which python2 you get: "/usr/bin/python2" If you say which python3 you get: "which: no python3 in" (then a whole lot of paths it isn't in) But I see the symbolic link in /usr/bin and in /usr.

[rlancaste]

Just tested that theory, it is even weirder still. its a rabbit hole of links. The link "/usr/bin/python3" links to: /cygdrive/c/astrometry.net/etc/alternatives/python3 Which is another symbolic link, which leads to: /cygdrive/c/cygwin64/astrometry.net/usr/bin/python3.8 Which doesn't appear to exist in the files you sent.

[rlancaste]

Ok so I changed your python3 link by doing a rm /usr/bin/python3 and replaced it by doing a ln -s /usr/bin/python3.8.exe /usr/bin/python3

And then I opened KStars again and tried the built in star extraction again, and it solved:

So yes, I think the main problem with your custom astrometry setup was the broken link to python3.

[laheller]

@rlancaste

Nice!

I'll check that once I am back from work. Thanks for investigating!

BR,

Ladislav

[papaf76]

As an interesting aside, a very similar issue is the very reason that I started to embark to create StellarSolver in the first place. A bunch of people were having all kinds of python issues with astrometry.net (mainly on Macs) and it was driving me crazy. So I made StellarSolver to combine SEP source extraction with astrometry.net solving. Then it evolved from there to become the StellarSolver internal solver and the library.

Just out of curiosity, might SEP be the reason why the behaviour in communication with nova changed? I mean specifically the need to pass the image size to the solver. That could explain a thing or two... Another thing, if you know: with my modifications, ANSVR is now able to properly solve with a recent kstars version. Still, I'm not getting the same FOV dimensions compared to the proper nova server. Do you happen to know how to use stars.wcs to calculate this? Right now I'm multiplying the pixel scale to the image size but as I said, I don't seem to get the same result as nova.

Thanks again, for everything! You've been nothing short of awesome!

[rlancaste]

For the first item, you will find that if you use internal SEP or external Sextractor for star extraction then a number of parameters that StellarSolver sends will change. Yes image height and width are required by astrometry to solve an xy list of sources. If you switch to the built in method and just send an image, width and height will not be sent.

For the second item, do you mean the final scale result sent back by nova? Did you downsample or bin the image? That can affect the scale astrometry reports. Do you have an example image?

[laheller]

@rlancaste

Just askin', why the python(3) is needed for the solving of an image when there is no plotting and the input image is always converted to FITS before even the solver is started? I mean in StellarSolver.

Using the ProcMon tool for Windows and documentation for astrometry.net I figured out that python is completely skipped in case, when the input to solve-field is a FITS format image and the command line has following parameters:

-p (--no-plots)
-9 (--no-remove-lines)
--uniformize 0

So to summarize there are 4 conditions to skip python. If only one is not met, python is started. But we don't need python. We need only center coordinates of the image, FOV, pixel scale, etc but nothing else. I checked this behaviour many times using the ProcMon tool and it's valid. Got always the same result.

I would suggest to include these cmdline parameters hardcoded into the command line in case of Cygwin, because I think in the 100% of cases the python is not needed for plate solving.

BR,

Ladislav