Include source second moments and their errors in extracted objects

[spacekitteh]

Specifically, the following variables from SEP extractions: x2, y2, xy, errx2, erry2, and errxy.

[rlancaste]

Hi there, I'm not sure what exactly these parameters would gain for us in KStars or in a program using StellarSolver for source extraction and solving? In the star object, I was very careful to not save everything, just the things that help us get the position in pixels and coordinates (x, y, RA, DEC), the shape of the object (a, b, theta), and some information about its light (HFR, mag, flux, peak, numpixels). I'm afraid if we keep too much data for each star, the extracted stars could take up quite a lot of memory.

[rlancaste]

Lots of people do plate solving and other star extractions on Raspberry Pi's and we don't want the resulting data structure plus the image to get too big. One star extraction can result in thousands of star objects.

[rlancaste]

What is your goal for these variables?

[rlancaste]

I'm not necessarily opposed to it, if including those variables would be very useful, but the SEP documentation:

https://sextractor.readthedocs.io/en/latest/Position.html

Is not very clear (at least to me) on what exactly those "second order" variables mean for the source. I understand they are related to the curve fitting that it does, but whereas the x and y position of the star have a clear usefulness to us, I'm not quite sure what x2 and y2 do for us? If you can fill me in on that, I would appreciate it.

I do see how uncertainty data would be useful for scientific purposes but these look like they are error associated with those second order variables based on the variable names if I am not mistaken?

[rlancaste]

Is this somehow related to the dark guiding that I heard being discussed?

[spacekitteh]

Is this somehow related to the dark guiding that I heard being discussed?

This, as well as significant improvements to focusing :)

So, by "second order moments", it's meant the estimated widths/spread. This is crucial for both robust estimation of position (for guiding), and robust estimation of HFR (for focusing).

• X2, Y2, XY are the raw widths; HFR is just derived from this. It's important to note that A/B/Theta/HFR (as well as CXX/CYY/CXY) are easily derived from these
• ERRX2, ERRY2, ERRXY are the variances of the position; important for robust estimation of average movement of stars for guiding. Additionally, from these, you can calculate the variances of A/B/Theta/CXX/CYY/CXY parameters, which mean the variances of the widths, which is needed for robust estimation of HFR when focusing.

[spacekitteh]

For what it's worth, I'd be perfectly happy with a (default false) parameter asking for inclusion of this data, along with a just a single pointer in the normal struct which points to this data when the parameter is true.

[rlancaste]

Ok, so if I am understanding this right, X is the X position, X2 is the width of the star, and ERRX2 is the error in the width of the star? Or is ERRX2 really like ERRX?

[rlancaste]

In terms of how we include it, I like your idea about only including it if it is requested with a parameter, that is basically what we did with HFR. We should probably look carefully at what is the most important stuff to include and what should be optional.

One issue is that if we change the struct, that will break some people's installations if they update just KStars or StellarSolver, so we try not to change things like that too often. But it has been awhile since we changed it last, so I think we can get away with doing it again. We can make the change and change the version number and make KStars depend on the latest version.

[spacekitteh]

I think it's a matter of parenthesisation. I think ERRX2 should be read as (ERRX)^2, where ERRX is the standard deviation of X.

[rlancaste]

Oh, I didn't think of that. Thank you, that makes more sense!

[spacekitteh]

Yeah, it took me a while to figure out too!

[rlancaste]

Ok I started playing around with support for your additional variables. I also took this opportunity to reorganize the star struct so we can more clearly see the categories of what is in there. And then I made some improvements in how it uses the external sextractor as well. We might want to think about what is really important and if more stuff is needed or some things need to be removed from the star struct. The good news however is that when I checked the size, it was 48 bytes per star before and now it is 72. Even at that size, we could have tens of thousands of stars before there is an issue. So we might not have an issue with keeping all the info in there. Still something to consider though since every star is that big. Anyway, you can see what I tried out here: 2c4111a

I put the changes in a separate branch so that we don't mess anybody up who is using master with Kstars.

See what you think

[spacekitteh]

Looks good! Note that you should use M_PI rather than using 3.14