search

LowellObservatory / All-Sky

Repository for the All Sky Camera software used at the DCT (and perhaps Anderson mesa)
1 stars 0 forks source link

All Sky Camera Software Requirements #1

Open dyerlytle opened 5 years ago

dyerlytle commented 5 years ago

Please read and comment on the All Sky Camera Requirements Document.

TedDunham commented 5 years ago

I edited the requirements notes for formatting and a few minor changes.

loxlig commented 5 years ago

I propose to add a requirement. The end user involved would probably be in the category of an "admin" type end-user.

Whenever either allsky camera is fiddled with for taking biases, correcting focus, cleaning the plastic dome, etc., it is practically impossible to get the orientation (pointing) exactly as it was before physical changes have been made. This is problematic since the sky moves overlays, labels and even the distortion map will change. This is not a problem if you do not mind that stars no longer coincide with their labels or that the grid overlay, whether equatorial or altaz, no longer matches the sky.

It is possible to realign everything by eye but you would be surprised at how much time this takes depending on which alignment has been effected as a result of repositioning the camera. I have done this several times with both allsky cameras and usually end up spending a day getting the images to match the sky.

There should be a fast, reliable and documented method for realigning the real sky with the "plotted" sky. I have an idea for making this task easier which includes using 3 points on the sky that are measured and translated to the same coordinate system used for doing each of the overlays. My suggested method is not exclusively the only possible way of making this process of realignment easier but I thought this should be included and a final method can be agreed on based on the requirement.

Should I append the requirements doc to include this or would everything like to have more discussion about this?

dyerlytle commented 5 years ago

I think this would be a good addition to the technical requirements, that the software should be able to adapt to the camera orientation, if the camera is moved, so that the overlays line up correctly.

TedDunham commented 5 years ago

I agree.

On Jan 10, 2019, at 2:47 PM, Dyer M Lytle notifications@github.com wrote:

I think this would be a good addition to the technical requirements, that the software should be able to adapt to the camera orientation, if the camera is moved, so that the overlays line up correctly.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/LowellObservatory/All-Sky/issues/1#issuecomment-453266164, or mute the thread https://github.com/notifications/unsubscribe-auth/Ap_7_egmrTCbcagd9ha7MM2okabTy6A_ks5vB7TVgaJpZM4Z2Z5R.

Teznie commented 5 years ago

Me three.

astrobokonon commented 5 years ago

I'd still advocate for a difference image (latest image - previous image), so long as there are some sensible limits to make sure the images in question are no more than X minutes apart. I don't use the current difference images myself because they appear to be the differences of final frames (JPEGs with all the overlays) - that makes them lacking in dynamic range and hard to use during most Moon phases. Subtractions (and image operations in general) should all be in FITS-land up until the absolute last second.

Another requirement I'd like to see is for some mechanism for raw FITS file access as they come in. An open directory of stuff is fine, or on-the-fly archiving rather than once per day/night. That'd allow neat things like https://github.com/LowellObservatory/NightWatch/issues/10 to be played with without any impact to the actual data collection/presentation.

One final thing - looking at the requirement's document, I can't tell if it's just for a process that creates images/movies of various types, or if it's for a full-up thing that creates the images/movies, and then gives an interface for some user to do ... stuff. I can't tell from the current document where this ends and NightWatch begins, for example.

loxlig commented 5 years ago

Attached are 2 examples of the DCT Night Summary Image. The first shows a clear night while the second shows an unambiguously cloudy night.

Clear dctns_20190104

Cloudy dctns_20190114

dyerlytle commented 5 years ago

I think the Night Summary image may be useful to some but should not be part of the current project because it is really a post-processing feature rather than a real-time feature to be used during the night. The Night Summary image can be generated anytime after the night in question is done.