FWIW, you can experiment with either one on a RPi4 by using their stand-alone programs. That is, if you run the ASTAP binary directly, it comes up with a UI that allows you to load fits files and solve them (so you can remove any fits header lines you want). Ditto for the StellarSolver_tester program that's part of the StellarSolver package.
I'll make some more tests, it can maybe lead me to good things.
Thanks for the idea.
Running the ASTAP solver itself can mislead, as I tried this a few months back, but the behaviour is very different compared to the binary launched from ekos because of the parameters used.
PS: I've read the first link you posted and maybe found what drove me off ASTAP in the first place: it doesn't play nice with proper exposures. It works well with short exposures, not full exposure ones. But anyway, some times has passed so I can try and verify with current releases and see where I can get. Will report back.
Got it. I took a quick look, and I'm pretty sure this is related to StellarSolver (as opposed to Ekos).
Not sure if that currently allows changing urls for the solver.
@rlancaste: are you able to take a look? (I'll send you a side email too, in case you don't see this).
See github.com/rlancaste/stellarsolver/blob/...nlinesolver.cpp#L325 where nova.astrometry.net is hardcoded.
Update: yes, Ekos is fooling you. Even if I deselected both Use Scale and Use Position, the astap binary gets called with arguments passed of both scale and position, and search radius too.
I think this is ultimately why it's so quick, but those are definitely not blind solves.
And maybe this is another bug, it seems the ASTAP interface completely ignores some of the settings.
EDIT: I find ASTAP really frustrating. It's very good that it can do blind solves by mouth of its author, but it would be nice if they explained HOW. All the software does, and it tells you as much when you hover over the Solve button, is search in a radius from a starting point, which seems to be a requirement, and after it reaches 20deg off, it stops. I can't find a settings page despite the program offers me the option to save them (???). I seem to recall there was an option to start with some different parameters but I can't find them now.
EDIT2: ok, I managed it, by specifying -r 180 on the command line. It was relatively fast, 20 seconds but with a 12 core Xeon. I doubt this will be useful on a RPi4. As I expected, real blind solve is just slow and requires a good amount of power.
I finally had the time to test on the RPi. I found a way to make it work, using ASTAP, but it hasn't been easy for a couple of reasons.
First, let's address the Use Scale and Use Positions switches: they don't work. The scale and position gets passed on to the solver, no matter what these switches are set to. At least, using ASTAP. The only way to really get a blind solve is to strip those info from the fit file itself.
Now, having done exactly that, I tested and confirmed that ASTAP can blind solve, and it's quite fast too. The most problematic image took 40 seconds on the RPi, which I think is fantastic. But another problem bugged me for a while. It seemed like Ekos liked to pass the "-r 15" parameter to ASTAP no matter if I changed the max radius search option. This was because I was changing another profile, not the one I was actually using. I think that part of the Ekos config could use some work, it's easy to get lost.
But finally I have a solution that can work on the RPi for blind solving images.
I'm still going to try and put up a nova like server, with the help of rlancaste I hope to be able to succeed. I also hope this thread is going to help somebody with problematic images in the future.
BTW: is there any specific reason the default search radius is so small? Upping it to 180 doesn't slow down anything if coordinates are close enough, just a thought.
Sorry that I couldn't log in here before, something was wrong with my password, but I have now fixed it. Hopefully I have provided helpful feedback in the GitHub site. I think I have fixed the first problem, the hard coding of the nova site should now be fixed. If you are using a package manager to install stellarsolver or if you are using Windows with embedded stellarsolver, there will be a delay to update it.
I think there were a couple of questions here I didn't address on the other site, so I will try to answer them now.
I am not sure what you mean by the internal solver can't blind solve, because that is one of the main things I worked really hard on last year during the pandemic, and one of the best features of StellarSolver is now that it can blind solves an image in less than a minute, often just a few seconds (depending on the image and computer of course). It manages this by doing several things that really can speed up solving such as parallel threads on multiple cores. Yes it can use a decent amount of energy and processing power, which is why you should only do a blind solve if it doesn't solve any other way. Even the raspberry pi can do it, but it isn't as fast as other computers.
I agree that under 1 second true blind solve on a Pi as you stated is not likely at this time. I typically use my laptop for solving images and controlling the session, where the PI is used for acquisition. My main computer solves images with scale and position information in about 0.3 seconds or so, the pi might take a few seconds (unless it is a pi 4). For blind solves it really really depends on the image. Here is an example of StellarSolver solving an image in less than 2 seconds on my main laptop. This is mostly a blind solve since the file is a JPEG, it has no idea about anything about the image. The only information it has is that it should use the parameters in the "ParallelSolving Small Scale" options profile. This profile does limit the scale to telescope sizes which makes it a bit faster, but if you don't limit the scale, it doesn't increase the time that much. Other images will have different solving times since blind solving is blind, but typically it is less than a minute. For a PI, the time estimates would be larger of course.
To answer the question of why 15 degrees, most users are using the internal solver or astrometry.net in some form and limiting the search 15 degrees does make a difference in those methods. 15 is typically the recommended parameter value. If your telescope is off by more than 15 degrees, there is a problem and you should be doing a blind solve and maybe check your equipment.
thanks for the detailed answer. I'll try to reply to some of your remarks:
I wrote that incorrectly. The correct way of putting it is, there's no way for me to force Ekos to do a blind solve easily. All of this started because I had an unsolveable image on my hands, which later turned out to contain wrong coordinates. I wanted to blind solve it, so to discard the FITS info. It isn't currently possible to do so. Load and solve will use the info and there's no way to make it ignore them safe from deleting the info from the actual image. Not sure if the option to blind solve would be useful in many cases, though. But this is what I meant. And as you can see from this answer Jaseem gave me indilib.org/forum/ekos/10035-non-solveable-image.html#73667, the Use Scale and Use Position not being read while Load and Slew is used has fooled him too...
And this is why I want a server to run for these kind of requests.
I understand your remark, but the radius limitation, as far as I can see, goes into the profile which is used always, including load and slew. Now, if I tri to blind solve, wouldn't a limit on the radius limit the blind solve as well? Or is it ignored in case of an image without info, say a JPG?
Also, in what way is it better to limit the search radius? To get back to my problematic image, setting the search radius to 180 solved it, even if it had those wrong coordinates. Leaving it at 180, all my other images solved quickly anyway, so I'm failing to see the downside of upping it to 180 or so.
Thanks again, also for the github thread!
EDIT: the quoted parts are not being shown, not sure why. But I think this is comprehensible anyway...