Lead_weight,

I did some experiments last night with the issue you reported in a virtual machine with python3 installed in different ways to see why python3 sometimes is not working properly with astrometry.net to plate solve. Another user, who also installed non-homebrew python3 has reported a similar issue in this bug report:

bugs.kde.org/show_bug.cgi?id=405437

, and we were trying to diagnose it there too. In both cases, we did a number of experiments but couldn't find the problem. I decided to try a different approach. It was much easier for me to diagnose the issue in a virtual machine. I will post what I found last night in both places.



The problem:
The issue happens when the user has installed non-homebrew python. Python3 is installed properly, the site packages include astropy and numpy, it can find the site packages, the correct python3 is first in the PATH variable, KStars is installed correctly, and NOTE this is not the "illegal argument exception" caused by running software compiled for a newer computer on an older computer. But when the plate solve is run, it gives an error message which means it can't find astropy. When run from the command line, it gives the same error!

My finding:
It seems to me that the issue is that the calls to python astrometry.net are making use the name python not python3 when the calls are made. OS X has a python2.7 installed by default that is used by the system and should not be changed. Python3 is installed in various ways and could be in different locations. All the different python versions that I tested last night put a simlink in /usr/local/bin for python3 to redirect calls for python3 to wherever python3 is installed. There is not a simlink to python put in that location because the assumption is that if you call python, you want python2.7 to run the code and if you call python3, you want your self installed python to run it. I ran into this issue before with the homebrew python, and it gave me big headaches before, but later I found that there was a folder homebrew made called /usr/local/opt/python/libexec/bin where there actually was a simlink placed from python to the homebrew python3 and if I put that in the path, it automatically fixed the problem! I had assumed that the other versions of python would have a similar folder and you could just put them in the PATH variable and it would work. I was surprised last night when I didn't find a python simlink in /Library/Frameworks/Python.framework/Versions/3.7/bin (or similar folder for other installation), nor did I find anything in /Library/Frameworks/Python.framework/Versions/3.7/opt. So thus even with that folder in the PATH, it still called the system python whenever python was called for.

Now that I think I know what the problem is, I should be able to come up with a way to fix it for non homebrew pythons. Just to verify, can you check for symlinks to python (not python3) in your /usr/local/bin folder, your /usr/local/opt/python/libexec/bin folder, and in whichever python3 bin and opt folder you would currently like to use (for example: /Library/Frameworks/Python.framework/Versions/3.7/bin and /Library/Frameworks/Python.framework/Versions/3.7/opt). If none of those folders contain a file or simlink called python, I think we have found the python3 issue.

The real challenge here is that there are many ways python could be installed on OS X and in fact there often is more than one python installation on a user's computer. Since astrometry.net relies heavily on python, it needs to be able to find it, and whichever python runs needs to have the right packages installed in it. The crazy part of that is that we are volunteering our time to work on KStars, but in order to get it to work properly we have to get all these other programs working and talking to one another properly no matter what the user's computer configuration might be. That is a bit of a challenge, so sorry about the delay on this, but I hope you can understand.

I used to think the solution was to just bundle in a stripped down version of python inside KStars so that we could be sure it was set up properly. I managed to do that for a couple of years, but then I had some problems when I tried to build it on a newer computer, so I had to go back to this method of trying to work with the user's python installation again.

Hi Andrew, Robert,

as I might be the reason for that not home-brew python3 install, just to try to help in this area. OS X might also go away from python 2.7 in future as they stated, that they don't like to support other frameworks than their own from a fresh install. Things might get more complicated, because if you have an "old" system running (with python2.7 installed) and update to a newer OS X release, the python might be still there, but for a brand new computer, it won't be installed from scratch on.
As I did some work with astrometry.net on three different platforms (mac, win, linux) things improved, when staying with the official python.org installer. For the software I'm developing (MountWizzard), the situation lead for astrometry.net to call the executables from the python program directly. You only need two binaries for doing plate solving. All other stuff could be omitted. In result you don't need any python, if you arrange the two tasks: star extraction (from fits to *.xy file) and solving (from *.xy file to coordinates). Yes you might loose some parameters to set, but I found this not really restrictive for users. If you would like to experience this way, please let me know. I try to explain how I did this. As result I don't care even on OS X about the python versions installed as I don't need them.

Another solution is ASTAP (OK, it's not astrometry.net, and it does right now not calculate distortion parameters), but installation on multiple platforms is easy.

Michel

I have another thought. I experimented last year with using sextactor to do something similar to what Michel just suggested. With all the problems we have had with python and netpbm, it might be much easier to use just sextractor, which we already use in KStars for other things. Maybe I can make a version that doesn't use python at all and just forces astrometry.net to solve based on a list of stars, instead of the images like we have been using. It isn't the traditional way to use astrometry.net, but it is supported by the folks at astrometry.net and I have successfully gotten it to work with KStars and astrometry.net before by doing an experiment, so I think I can try this again. Another side benefit would be that all the issues I had with building Netpbm could be eliminated as well.

Sounds great,
I still use the image2xy as provided in the astrometry.net package (as I don't want to take care of managing all the libraries attached to the binaries) and than solve-field. That's it. So far I did not had any issues. One hint: I looked around the last hour how things are made in different packages and the the Astrometry package including astrometry.net which is provided by cloudmakers (many thanks for that really nice package and all the support for Mac's !!!) also does not use python, but just calls image2xy and solve-field.
Michel

So I worked very hard over the last couple of days on the issue and I think I managed to create a version of KStars that is capable of using Sextractor to extract the sources for an image and then feed that into
astrometry.net, avoiding any use of python whatsoever. It doesn't use numpy, image2xy, or anything else. Just Sextractor and astrometry.net. Note that, this version of KStars is still fully functional and still
contains the ability to solve with python. It just also includes an option to avoid python.

Please test this on a system that has python issues like the ones I have been trying to help people with on the last week.

www.indilib.org/jdownloads/kstars/beta/kstars-3.4.0-beta3.dmg

In order to turn off the usage of python, you will need to configure astrometry.net like this:

Thanks for the hard work! I’ll give it a go tonight.

I tested this on Linux and it works GREAT, faster too than using Python. This is truly spectacular work Robert, it felt like I'm using ASTAP for a moment

Because of the bad weather, I can't test.
If that's okay, I can try Simulator mode,
I also wanted to ask you two questions:
1) Have you read my post where I speak of being able to do before the alignments with the computer of the mount? What do you think about it?
2) I did not understand the discourse of turning off rotation.
If you refer to the item rotate in the Astrometry.net options,
where by default there is the number 30, I have always kept it off. Am I wrong?
I'll also make you a third:
since this works for me, isn't it that trying the new settings of the new version I can have problems?
Thank you.

1. I don't think you need to do alignment stars before plate solving. I never do that now that I plate solve. I use the plate solves as the alignment points.
2. I don't know about turning off rotation? I think my last suggestion to you was to use "sync", not "slew to target." I might have forgotten?
3. I don't know about the rotator option. I also have kept it off, I don't have a rotator for my telescope so I haven't even thought about that option.
4. Nope, trying out the new setting of using sextractor will not hurt your setup, you can always change it back to whatever you were using before. My addition of the new setting doesn't break the old functionality.

Ok, I've tried it out, and I didn't have a very successful run.

After installing and setting the new sextractor preferences, it solved the simulation image immediately. Very fast. Then I tried loading an image from my EdgeHD 11 scope, and it failed. So I stopped the server, went into the preferences and set the scope to the Edge so that it would have any focal length info it needed, and tried solving again, and it failed. Then I tried the simulation image again, and that failed too with the Edge set as the scope.

Here's the logs and screen of my settings.