Local astrometry not solving in 2.4.0.2681 (Beta 9)


#1

Using solve and sync blind using Beta 9 isn’t working well with local astrometry setup for blind solve and sync
Reverting to 2_3_15_2568 succeeds.
The problem looks like the Upper and lower bounds aren’t being supplied to ansvr
With Beta9 this is displayed
request_json is: {“session”:“627”,“allow_commercial_use”:“d”,“allow_modifications”:“d”,“publicly_visible”:“y”}
[2015-02-02 00:36:39] UPLOAD: session is 627
[2015-02-02 00:36:40] POST /api/submissions/627 HTTP/1.1
scale_args:
UPLOAD: /opt/ansvr-0.14/run_solver 30 /usr/bin/solve-field -p -O -U none -B none -R none -M none -N none -C cancel --crpix-center -z 2 --sigma 5 stars.fit
Using timeout = 30
exec /usr/bin/solve-field -p -O -U none -B none -R none -M none -N none -C cancel --crpix-center -z 2 --sigma 5 stars.fit

With 2.3 I get
[2015-02-02 00:29:23] request_json is: {“session”:“625”,“allow_commercial_use”:“d”,“allow_modifications”:“d”,“publicly_visible”:“y”,“scale_units”:“arcsecperpix”,“scale_type”:“ev”,“scale_est”:3.4509229120542,“scale_err”:100.0}
[2015-02-02 00:29:23] UPLOAD: session is 625
[2015-02-02 00:29:24] POST /api/submissions/625 HTTP/1.1
[2015-02-02 00:29:23] forcing scale_err to 10 (was 100)
scale_args: -u arcsecperpix -L 3.10583062084878 -H 3.79601520325962
UPLOAD: /opt/ansvr-0.14/run_solver 30 /usr/bin/solve-field -p -O -U none -B none -R none -M none -N none -C cancel --crpix-center -z 2 --sigma 5 -u arcsecperpix -L 3.10583062084878 -H 3.79601520325962 stars.fit
Using timeout = 30
exec /usr/bin/solve-field -p -O -U none -B none -R none -M none -N none -C cancel --crpix-center -z 2 --sigma 5 -u arcsecperpix -L 3.10583062084878 -H 3.79601520325962 stars.fit

Laurie


#2

I also noticed this–here is confirmation that Laurie isn’t the only
one. I finally upgraded to v2.4.0.2681 last night and my blind solves
went from about 7 secs (for v2.3.15.2568) to multiple minutes. I was in
the middle of testing other stuff, so I did not pursue it like Laurie did.

I figured that maybe it was time to upgrade the ansvr–I’m on a fairly
old (pre-windows installer) version that has just worked for a couple of
years. I will hold off on that until Laurie’s message gets resolved.

  • Shane

#3

This is expected behavior. (Not the failing part…just the hint data.) In 2.3 we were incorrectly passing hint data for “Blind” solves. In 2.4 this has been corrected.

Essentially you want to use the non-blind option in 2.4 if you have a known scale. Otherwise use the blind solve. This also means you should disable the scale override in ANSVR as it will now be very problematic.

Thanks,
Jared


#4

This is news to me. So essentially we should set the ansvr setting "Scale error estimate, percent: " blank?


#5

When using 2.4, yes.

Jared


#6

I have always used Elbrus as the non-blind with astrometry local as the blind basically because Elbrus is faster than astrometry when you are already accurately pointed.
Looks like I’ll now stop using Elbrus and use astrometry for both.
I wasn’t aware that solve blind was supposed to be like this, makes sense now but I bet it catches a few out.

Thanks
Laurie


#7

Hm, that’s a valid use case. We may need to rethink this some.

Thanks,
Jared


#8

Actually I think we’ll end up leaving it as is for a bit. I would HIGHLY recommend removing the scale error setting from your ANSVR settings though. Having it in there will likely cause blind solves to completely fail (what you’re seeing now).

Thanks,
Jared


#9

I, too, used Elbrus with fail-over to local astrometry.net. When Elbrus
didn’t solve in 1 second, astrometry.net solved in 7 to 10. I sure hope
we can get this functionality back. How about a checkbox for “Provide
hints to blind solver”. If some folks really don’t want the hints, they
don’t have to check it.

  • Shane

#10

Please reconsider! This makes manual rotation go from under a minute to
over 15 …

  • Shane

#11

So we’ve discussed this some and here’s how 2.4 will behave. I think this gives everyone everything they want with respect to using ANSVR locally.

  1. For non-blind solves SGP will send in the scale with an error of 5%.
  2. For blind solves SGP will send in the scale with an error of 100% (this was what 2.3 did for both blind and non-blind)
  3. If you want a true blind solve in SGP then you’ll need to set your scale to 0 and do a Blind Solve and Sync. (These are rarely required)

This will also allow you to override the values in ANSVR if you so desire. Just remember that if you override and do option 3 then you’re likely going to be sitting there a while waiting for your solve to fail.

Thanks,
Jared


#12

Thank you. I really appreciate the quality of the software and the
responsiveness of its developers.

BTW, last night was also my first experience with the AWESOME new
auto-focus routine. Once I moved the slide from 100 to around 30 or so,
I have not had to repeat a focus once! Thank you for that also.

  • Shane

#13

That sounds good to me, another thanks for your responsiveness.

Laurie


#14

what affect does this have if Astronomy net is your only solver??
I’m very new to plate solving so apologies if these questions sound basic.

I normally would do a “solve and sync blind” to get the initial scope synced before slewing to target and then running centre now. I prefer not having to worry about hint data
Im still using 2.3 at present but if stick with this workflow when 2.4 goes live, should I set the scale error to 0% or leave it at 5% which is where I have it at present??


#15

If you’re already using the 5% override it makes no difference. The benefit would be to not set that in ANSVR and let SGP control it. That way you can get actual blind solving behavior out of it.

Thanks,
Jared


#16

Hi Jared

I’ve just been testing the local Astrometry.net scale error changes you’ve made with beta 10. My scale error setting in ANSVR is now blank and I see the following behaviour in SGPro:

  1. I load an image into Target Settings. If I click ‘Solve Blind’ I see in the ANSVR logs that the scale error is set to 100%. This is expected. If I click ‘Solve’ I see in the ANSVR logs that the scale error is set to 5%. Again, this is expected. Ok so far…

  2. I now open the same image with File->Open Image then right-click and select ‘Plate Solve’. In the popup I click ‘Solve’ and see in the ANSVR logs that the scale error is set to 5%, as expected. However, if I click the ‘Blind Solve’ button I see in the ANSVR logs that the scale error is again set to 5%. Shouldn’t this be set to 100%?

Regards
John

PS ANSVR and SGPro log files available here:



#17

Yes it should be sending 100%. . I’ll look into that.

Thanks
Jared


#18

This has been resolved and will be out in the next beta.

Thanks,
Jared


#19

Great! Keep up the excellent work!

Regards
John


#20

Hi Guys,

I have a sequence that I started a couple of months ago and will be
working on for a couple of months to come. Is it safe to update SGP to
the JNOW converting version? I use an Astro-Physics mount and I build
the sequence with the Framing and Mosaic Wizzard.

I guess I’m wondering if an in-progress sequence can survive the
transition to JNOW.

Does what I wrote even make sense?

Thanks - Shane

Shane Ramotowski kor@cotse.net


www.mainsequencesoftware.com