Turning off 'Use scale' seems for me to be the only way to prevent it from using the wrong '-L' and '-H' argument to 'solve_field'. Even when the two scales say '0', some other values are used when running 'solve_field'. So turning off 'Use scale' also seems to work here in a few test cases. Running from the command line with the correct scales seems to be faster, though. ~400s in ekos without "use scale" and ~100s from the command line with the correct scales.
Another odd thing.... If I run solve_field from the command line simultaneous with a solve in ekos and press 'Stop' in ekos, it will stop both the one in ekos AND the one in the command line. Does the stop button use some kind of killall or something? That may lead to odd things in some cases...
Aren't there advantages to having coordinates in J2000 for consistency across platforms that do the conversion internally? Can we get either both at once or a choice?
Here is what is happening in my case: kstars uses the scale information found in the fits file to generate the options, over writing anything I manually set in the options dialogue. It seems to be done in Align::startSolving in align.cpp where getSolverOptionsFromFITS is called. The scaled reported in the log matches exactly 0.9 and 1.1 time the pixel scale in the fits header and clearing FOCALLEN and SCALE in the fits header results in a correct solve (but without any scale information...). Maybe there should be an options to either use the fits header (if available) or always use the user set options? My fits header was containing (slightly) wrong information leading to the (slightly) wrong image scale being used and there seems to be no way to manually overwrite this from ekos....
The following user(s) said Thank You: Jasem Mutlaq
Everything is in JNow because that what most mounts report, so when you compare mount and solution coordinates, you need to be looking at the same epoch.