OpenStarTrack science_cam_may8_0.05sec_gain40 input.csv source?

[Carson Schubert]

Hi!

I'm using openstartracker in combination with astrometry.net and curious about the source of the input.csv file in the tests/science_cam_may8_0.05sec_gain40 directory. Astromety.net's "image2xy" utility outputs only whole number magnitudes. However, the input.csv has high precision magnitudes. I'm curious where these inputs came from and wondering if anyone knows a way to make astrometry output higher precision magnitudes.

Thanks!

-Carson

[Andrew Tennenbaum]

Hi - input.csv is a test input so the exact magnitudes are given. In real world data the magnitudes are unreliable - hence you only get one significant digit. If you really want a high precision magnitude take a look at the equation on line 58 of test.c - that is how you convert from magnitude to pixel brightness. The inverse will convert from pixel brightness to magnitude, which may be what you are after

--
You received this message because you are subscribed to the Google Groups "OpenStartracker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openstartrack...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openstartracker/8a125c4f-6799-49ac-9a0a-1bc13e5ce608%40googlegroups.com.

[Carson Schubert]

Thanks for the quick response!

I've piped the Astrometry outputs to a csv in the same format as the input.csv used for testing, but when I run it through the program no matches are found (all -1s). The inputs are matches found by the Astrometry "image2xy" utility when run on the images in tests/samples. I am using the same calibration settings as the since the images I am evaluating are from the science cam. 

Is it possible I'm getting no matches because of an issue with the Astrometry magnitude outputs? If I inject lines from the original input.csv into my new csv, the program finds matches for those lines.

On Friday, October 18, 2019 at 11:52:12 AM UTC-7, Andrew Tennenbaum wrote:

Hi - input.csv is a test input so the exact magnitudes are given. In real world data the magnitudes are unreliable - hence you only get one significant digit. If you really want a high precision magnitude take a look at the equation on line 58 of test.c - that is how you convert from magnitude to pixel brightness. The inverse will convert from pixel brightness to magnitude, which may be what you are after

On Fri, Oct 18, 2019 at 12:51 PM Carson Schubert <carson.s...@gmail.com> wrote:

Hi!

I'm using openstartracker in combination with astrometry.net and curious about the source of the input.csv file in the tests/science_cam_may8_0.05sec_gain40 directory. Astromety.net's "image2xy" utility outputs only whole number magnitudes. However, the input.csv has high precision magnitudes. I'm curious where these inputs came from and wondering if anyone knows a way to make astrometry output higher precision magnitudes.

Thanks!

-Carson

--
You received this message because you are subscribed to the Google Groups "OpenStartracker" group.

To unsubscribe from this group and stop receiving emails from it, send an email to opensta...@googlegroups.com.

[Andrew Tennenbaum]

So the magnitude isn’t actually all that important - it’s mainly used to fine tune the acceptance region around the stars. 

If you follow along with the readme, the calibration script automatically checks the output of the startracker with the output of astrometry and correlates the two, no csv required. Does calibration.py work with your test images?

To unsubscribe from this group and stop receiving emails from it, send an email to openstartrack...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openstartracker/22a1ac3b-be9c-40a3-b39c-41ffc6d13018%40googlegroups.com.

[Carson Schubert]

I'm using the same sample images that are provided in the test directory, so I didn't re-run calibration on them. I'm just using the same calibration settings from calibration.txt.

To view this discussion on the web visit https://groups.google.com/d/msgid/openstartracker/22a1ac3b-be9c-40a3-b39c-41ffc6d13018%40googlegroups.com.

[Andrew Tennenbaum]

so if you take a look at in the calibration_data all of the ones ending in .solved correspond to images that have successfully matched. 

To unsubscribe from this group and stop receiving emails from it, send an email to openstartrack...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openstartracker/d7e3d24c-c319-49b8-a2ac-c21602967511%40googlegroups.com.

[Carson Schubert]

Andrew,

I'm using these images: https://github.com/UBNanosatLab/openstartracker/tree/master/tests/science_cam_may8_0.05sec_gain40/samples

According to the calibration data it does look like img0 solved. However, if I run it directly through the astrometry image2xy and feed the sources through the test program, I get all -1 for this image. 

My hunch is that this is related to the # of sources being fed in. The input.csv testing data is providing far fewer sources (even at its highest) than the 974 I'm feeding in from image2xy. Do you think this is causing the problem?

Thanks again for all your help.

To view this discussion on the web visit https://groups.google.com/d/msgid/openstartracker/d7e3d24c-c319-49b8-a2ac-c21602967511%40googlegroups.com.

[Andrew Tennenbaum]

so, my guess is that you'd have better luck using the centroid extraction from startracker.py, which automatically whittles the number of stars down to a much more manageable number. openstartracker could probably be made to work with the output from image2xy, but I think it would be non-trivial

To unsubscribe from this group and stop receiving emails from it, send an email to openstartrack...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openstartracker/6f96a11c-b721-4d2c-a29c-06b3db1bdbd3%40googlegroups.com.

[Carson Schubert]

That makes sense. I'll look into using startracker.py. Out of curiosity: are you running Python/OpenCV onboard the CubeSat this runs on? Or have you ported it to the C++ API?

To view this discussion on the web visit https://groups.google.com/d/msgid/openstartracker/6f96a11c-b721-4d2c-a29c-06b3db1bdbd3%40googlegroups.com.

[Andrew Tennenbaum]

We are using python/opencv on the satellite - startracker.py uses a swig wrapper to talk to the C++ interface, which lets us use it from python/opencv with no loss of performance

 If you wanted, you could write a c++ version of startracker.py - the logic is not particularly complicated. You’d still need opencv or some other image processing library 

To unsubscribe from this group and stop receiving emails from it, send an email to openstartrack...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openstartracker/10ec6767-9cbf-42e8-9aff-9ed56db9b9a8%40googlegroups.com.