Average DynamicPSF theta parameter

[mschuster]

The average for theta in the DynamicPSF tool is not computed correctly. See the attached image. One possible fix: Compute the first eigenvector of the direction covariance matrix. Doing so avoids the biases of simple averaging on angular data.

[NKV]

Actually, (-88.09 + 87.69)/2 = -0.185 

[mschuster]

Of course, maybe I was not clear. Both stars are elongated upwards and downward. Reporting zero degrees is completely wrong. Either a value near 90 or -90 (don't care) is a much more useful average than zero. Imagine wind directions. If the wind blew north and south but never east you don't say the average wind was east.

[NKV]

UnCheck "Signed angles"

[mschuster]

Unchecking that option does help this case but is not a general solution. Suppose stars are elongated near 0 and near 180. You will get 90 as an average. You just cannot average angles using simple averaging and get unbiased results in all cases. Analyzing the covariance matrix is one way to avoid this problem.

[mschuster]

Here is the scheme. For each theta value find its direction vector (a pair with cosine and sine components). Build a N by 2 matrix M of these vectors. Compute the covariance matrix transpose(M) dot M. This is a 2 by 2 matrix. Find the eigenvectors and eigenvalues of this matrix (not hard for a 2 by 2 matrix). The eigenvector associated with the largest eigenvalue is the average angle. This is basically principle component analysis on the set of direction vectors.

If you wish you may weight the length of each vector first by the inverse of its associated MAD value. Now your average will incorporate the goodness of fit in a reasonable way.

[Juan Conejero]

If the wind blew north and south but never east you don't say the average wind was east.

Why not? IMO East is indeed the most informative answer in this case Jokes apart, what you are saying is that the mean of wind directions is not a robust estimator of wind direction. I completely agree, and your analogy is a clever one.

Definitely, I have to implement a more robust estimator of the average rotation angle in DynamicPSF. However, I personally tend to favor simple robust statistics methods instead of SVD methods and the like, especially in cases like this one, where the fitted data has a significant amount of uncertainty and outliers. Of course these robust estimates will only be available for sufficiently large sets, say for 10 or more fitted stars; otherwise nothing minimally reliable can be done.

On a side note, mean fitted PSF parameters should not be used to represent the true PSF of an image. The main reason is that the mean is not robust, so the computed mean parameters are sensitive to outliers, which are particularly problematic for rotation angles due to their inherent uncertainty. I have implemented a much more robust way of generating average PSFs, which is available in DynamicPSF as the Export synthetic PSF function. Synthetic PSFs provide excellent results for deconvolution.

Again, thanks for your insights.

[mschuster]

Thank you Juan,

I have a follow up question. This may be a bad idea: I am envisioning an Aberration Spotter script improvement that displays median PSF r and theta values for each of the corner, edge and center panels. This script would use StarAlignment to generate a star detection image and a convolution with a cross shape to detect star centers. These centers are then be passed to DynamicPSF for detection and fitting purposes. Star diameters will vary widely of course. If I export a synthetic PSF and run DynamicPSF once again on the synthetic PSF will the resulting r and theta parameters be in any sense robust?

[Juan Conejero]

Nice project; I look forward to it.

Instead of a convolution (followed by peak detection I guess) you could use a simple iterative routine to find the star barycenters. If you only need StarAlignment to generate a star detection map, then I can provide the complete source code of SA's star detection routines, which are very easy to implement in JavaScript. I have no problem to open this part of SA, so I'll post the code on the software development board later. Just let me put everything together in a presentable way. In fact, it would be nice if SA's star detection could be improved through brainstorming

If I export a synthetic PSF and run DynamicPSF once again on the synthetic PSF will the resulting r and theta parameters be in any sense robust?

The synthetic PSF has no noise and has been generated by stacking all fitted star functions, so fitting it should provide very reliable and robust results. The uncertainty in rotation angles differing by 180 degrees will still remain, though, but you can handle these particular cases in your script.

[mschuster]

Thank you Juan, yes I was thinking of using only SA's star detector. A js implementation would be helpful but not necessary of course. I do like your brainstorming idea however.

[mschuster]

Juan, maybe you have time to help:

I see no documented DynamicPSF PJSR API to force an instance to export a synthetic PSF.

Is there a way to do this?

Thanks,
Mike