[FEATURE REQUEST] Return RA/Dec of Off-Center (x,y) Pixel Coordinate?

[kuanjuliu]

Would it be possible to return the RA/Dec not of the center of the field, but of a specified (pixel) coordinate in the image?

This would allow a simple way to compensate for the offset between a "guide" camera that isn't perfectly aligned with the main scope.

For example, if the main scope is centered on a bright star and the (x,y) pixel coordinates of that bright star identified with get_centroids_from_image(), we could use the same (x,y) coordinates during solve_from_image() to recover where the scope is actually pointed.

[kuanjuliu]

This could be accommodated by redefining the coordinate system of the image to center the specified coordinates in an enlarged space, while also updating the FOV parameters to match.

In other words, Tetra3 would plate-solve a (virtually) expanded and re-centered image, while still using the same database:

This would be the pertinent addition to _solve_from_image()_:

[gustavmpettersson]

Hi KJ, this has now finally been implemented.

We've already talked about this, but for posterity, the issue with your proposed implementation is that camera projections are not linear. The angle away from the boresight is (in a perfect camera) related to the tangent of the distance from the centre of the sensor. So, doing an offset like this is only correct for small angles.

However, in tetra3 we find the rotation matrix between the celestial coordinate system and the camera pointing, as such it is easy to get the ra/dec coordinates of any point using a vector. The reason this was not implemented immediately when brought up is that we need the camera's FOV to calculate the vector. tetra3's FOV estimates are good but not great, and I think not good enough for use here. For now, the implementation requires that the fov_estimate is passed and that value is used to calculate the vector.

To note on the implementation: You can give the solver one or a list of pixel coordinates as target_pixel. They are in (y, x) order and start with (0,0) in the top-left corner as all centroids in tetra3 do. The returned dictionary will have two new keys RA_target and Dec_target, and the original RA/Dec/Roll of the centre of the image will still be there. If a single target was passed the returned values will be scalars, otherwise you get a list with the data of every target queried.

Let me know if you have questions, I'll close this now

[gustavmpettersson]

The estimation of FOV has been improved significantly, so fov_estimate is no longer required to use this feature.

[kuanjuliu]

@gustavmpettersson Wonderful, thank you so much for the explanation and resolution! My imagination doesn't extend very far, but even just for "realignment to main scope" purposes having it done correctly within Tetra3 itself will be a major boon to developers.

[alexw-im]

The estimation of FOV has been improved significantly, so fov_estimate is no longer required to use this feature.

1) Thank you, this is awesome. 2) Pure curiosity, but if you'd indulge me: what was the previous algorithmic cause of the "good but not great" FOV estimate, and how is it now "improved significantly" such that there's no concern using it for this calculation? I'd have previously assumed that calculating FOV from known stars would be one of the more precise ways you could possibly go about it.