×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

New KStars/Ekos Module: Analyze

  • Posts: 969
  • Thank you received: 94
Hy, everyone
Work of art.
So good to have all this in just one window.
Cheers,
Steve
The following user(s) said Thank You: Jasem Mutlaq, Paul Muller
3 years 7 months ago #58959

Please Log in or Create an account to join the conversation.

  • Posts: 216
  • Thank you received: 120
This is awesome work. I've been using github.com/fenriques/AstroDom to analyze sessions after the fact, but having it live during a session is even better.

Feature request: Another checkbox to calculate and show star eccentricity in the images would be awesome. Guiding RMS approximates what I can expect from the image, but actually measuring eccentricity and seeing graphed next to the guiding info would be useful to me.
The following user(s) said Thank You: Jose Corazon
3 years 7 months ago #58976

Please Log in or Create an account to join the conversation.

  • Posts: 985
  • Thank you received: 161
Seeing will largely influence HFR so I deem HFR an excellent indication for seeing. Eccentricity will go into HFR, too albeit to a lesser extent (unless it is huge).
3 years 7 months ago #58982

Please Log in or Create an account to join the conversation.

  • Posts: 239
  • Thank you received: 38
Great work! I appreciate all your hard work!
3 years 7 months ago #58984

Please Log in or Create an account to join the conversation.

  • Posts: 2247
  • Thank you received: 223
Great evidence of a fantastic community we have here.
The following user(s) said Thank You: Jose Corazon, maxthebuilder, Giles
3 years 7 months ago #58985

Please Log in or Create an account to join the conversation.

  • Posts: 157
  • Thank you received: 19
During my session, I noticed an issue with calculating RMS. I used PHD2 for guiding, and I use the Z-filter algorithm for DEC control. According to the folks at PHD2, when Z-filter is used, PHD2 shifts the image - RA is centered, but DEC is shifted by 1 arc-second. I'm not sure why, but this will throw off the calculation of RMS due to the DEC shift. Take a look at the attached pictures so you can see what I mean.

But very nice tool!

Regards,

jmh
3 years 7 months ago #59051
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 269
  • Thank you received: 53
Who told you that? The Z-filter algorithm might result in an off center plot if guiding starts with the star off center and a large X-factor is used. This happens because it works in the frequency domain and a constant offset corrresponds to zero frequency so it does not get corrected. But it does not necessarily result in a 1 arc-second shift under all conditions. In fact, it is arguably preferable for the offset to be retained as it results in a better image.
On the other hand, RMS values should be calculated about the mean so a constant offset becomes the mean and therefore cancels out of the RMS value.. This is how PHD2 calculates the RMS as you can see.
3 years 7 months ago #59054

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559
This is what Analyze currently does re RMS guide error. Please let me know if you think I got something wrong.

Internal guider, see
invent.kde.org/education/kstars/-/blob/m...uide/gmath.cpp#L1242
SquareError(t) = ((RA(t) - RA_target(t))**2 + (DEC(t) - DEC_target(t))**2)

In the PHD2 case, the RA(t) - RA_target(t) or diff_ra_arcsecs is taken straight from PHD2 (PHD2 calculates that and sends it to Ekos).
See invent.kde.org/education/kstars/-/blob/m...lguide/phd2.cpp#L487 for PHD2 part.
So, in the PHD2 case, Ekos is taking as the RA or DEC error, what PHD2 says is the RA or DEC error.

Analyze implements an IIR filter with an approximate time constant of 40 samples (nothing magic about 40 samples == about 2 minutes with 3s samples)

// initialize
filteredRMS = 0;
constexpr double timeConstant = 40.0;
rmsFilterAlpha = 1.0 / pow(timeConstant, 0.865);

// at every time sample (x below is SquareError(t) above)
filteredRMS = rmsFilterAlpha * x + (1.0 - rmsFilterAlpha) * filteredRMS;
invent.kde.org/education/kstars/-/blob/m...yze/analyze.cpp#L485

and takes the sqrt of the (poorly named) filteredRMS to get the rms value you see. (I guess I should have named it filteredSquareError).
invent.kde.org/education/kstars/-/blob/m...yze/analyze.cpp#L542

It does not take the mean of the RA or DEC samples. I understand your logic, though, why that might be nice.

All that said, that's not quite true for the case of RMS error printed in the Details box, e.g. when you click on a guide timeline session or a capture timeline session.
There, it does not use an approximate IIR filter, but rather computes exactly the sqrt of the sum of the square error in the interval.

In any event, just to be clear, this is what is currently implemented.
Happy to entertain suggestions,

Hy
The following user(s) said Thank You: Ken Self, Paul Muller
3 years 7 months ago #59055

Please Log in or Create an account to join the conversation.

  • Posts: 249
  • Thank you received: 62
awesome work! thank you. All the insight needed to monitor and review the session in one window; to me it should replace the Setup tab.

@Rick, I'm thinking to use the .analyze file as the only source of information for Astrodom. What do you think?

ferrante
3 years 6 months ago #59059

Please Log in or Create an account to join the conversation.

  • Posts: 269
  • Thank you received: 53
This should be a really useful tool. Great work!
What would be really neat would be the RMS over the course of each capture to identify which ones might be sub-optimal due to poor guiding.
For info: The PHD2 remote interface returns the simple distance from the star centroid to the lock point. But in the Log Viewer (and I think also in the application but I havent checked) the RMS calculation subtracts the mean of the set from each sample before then calculating the RMS. So what is shown on the PHD2 screen is the RMS about the mean offset. What I think of as the "DC offset".
3 years 6 months ago #59064

Please Log in or Create an account to join the conversation.

  • Posts: 216
  • Thank you received: 120

@fenriques I think that would be fine. Might simplify things a lot for you, but it would tie your software really closely with Ekos, meaning anyone who uses other tools wouldn't be able to use it. But since I only use Ekos for imaging at the moment, it wouldn't affect me.
3 years 6 months ago #59080

Please Log in or Create an account to join the conversation.

  • Posts: 157
  • Thank you received: 19
Regarding the Z-filter comment, a core member from PHD2 told me that Z-filter used an offset. See the discussion here .
3 years 6 months ago #59083

Please Log in or Create an account to join the conversation.

Time to create page: 0.694 seconds