Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

  • entries
    2
  • comments
    10
  • views
    1,674

Jocular -- a new tool for EAA

Martin Meredith

1,053 views

Since shortly before xmas I've been developing a piece of software to support electronically-assisted astronomy (EAA). Realistically it is still some months away from release, but the main design elements are getting close to being fixed so I think now is a good time to document what I'm doing in the hope that any comments or suggestions might be taken on board before the thing fossilises too much.

The tool -- codenamed Jocular -- aims at promoting observation, but getting the most out of the limited number of photons we EAA-ers typically collect for each object we observe. The interface will be kept as simple as possible, but in spite of this I'm planning to implement a fair bit of AP-like functionality, adapted to the EAA use case where nearly all processes have to be handled semi- or fully-automatically. In a sense the tool was motivated by a desire to experiment with just what is possible to accomplish in near real-time and minimal user intervention. So there will be support for a full calibration scheme but operating silently where possible, as well as various luminance-chrominance manipulations, gradient removal and advanced stacking and stretching options. I'm attempting to operate by the principle of least commitment, which is especially important for EAAers, whereby it shouldn't be necessary to take decisions in advance that limit later options and potentially waste photons. For example, it will be possible to reject subs from any earlier point in the stack, or change the stacking mode, or choose a different key frame for star registration, or re-assign incorrect subs to the appropriate type or to a different object -- at any point during the observation of that object.

Currently, live mode operates via a 'watched folder' approach in which an arbitrary capture program dumps .fits into that folder. These can be darks, bias frames, flats or lights, or short captures used for FAFing (focus-alignment-framing); a user-defined naming template enables the program to sort out the type of each sub. However, I am one small step away from complete integration with Nebulosity, which will enable capture control for any cameras/filterwheels supported by Nebulosity, but all done via a simple interface. The Nebulosity option will also allow scripted captures, again heavily simplified e.g. click RGB to have the program capture N subs of duration D from each of RGB, rinse-and-repeat (assuming the user has an electronic filter wheel). I hope to support INDI-based capture/control at some point and would like to track down some compatible open-source capture options as this is one area I really don't have the time or inclination to work on.

It is possible to use the tool both live and offline in much the same way. The tool will provide easy access to previous observing sessions, enabling a user to revisit and re-process the data in a 'what if' fashion. It will support observation planning and logging as well as image annotation. 

The program is being written in Python. In principle it can be ported to all OSs, including iOS and Android, but I'm developing first and foremost for the Mac where there is a shortage of EAA tools. The software will be open source.

Here's a shot of the current interface during a recent test session observing the polar ring galaxy NGC 660 in Pisces. 

5a6e10c2d1f79_ScreenShot2018-01-28at19_03_43.thumb.png.105c05bef15790741be078e957981215.png

  • Like 7
  • Thanks 1


9 Comments


Recommended Comments

Very nice Martin. I thought I would ask questions here vs. CN since this is a dedicated thread.

What GUI framework are you using in Python to develop the UI? Python is incredibly easy to write in and most of my photometry scripts are in Python but I have not found a good GUI framework yet for rapid development.

Share this comment


Link to comment

Thanks, and sure, this is the best place to ask.

I'm using Kivy from kivy.org

Whether you could call it suitable for rapid development is another matter. The learning curve is quite high I found and some layout aspects are not very logical, but it is very powerful in terms of designing one's own widgets etc and I think well worth the initial effort. The beauty is that it is cross-platform and based around touchscreen ideas, so quite easy to build more natural interfaces.

 

Share this comment


Link to comment

It's nice that this software is being developed for Mac first. I don't know of any other Mac EAA tools out there.

  • Like 1

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.