This post will be updated as new ideas come to mind.
This post is for new ideas that I come up with in the middle of the night or similar, which I feel will merit revisiting at a later date.
-------------------------------------
Focusing assist - programmatical analysis of images to help the user obtain the best focus
Autofocus - connectable either to 3rd party electric focusers or to any old stepper motor, this should allow automatic focussing
Auto alignment - use multi-star alignment and/or plate solving to align the 'scope for GoTo and object acquisition purposes
Auto-polar alignment and/or polar alignment assist - use an iterative process which takes images to determine the quality of the mount's polar alignment. Potentially, with a mod, mounts could be persuaded to be aligned solely by the software, so that the user just needs to push a button when everything's set up and the app will do the rest. Would probably need some pretty beefy motors, particularly where people are using big mounts like the EQ8. I think even for the EQ6 this will require something pretty solid, but for an EQ3 this could probably be achieved with a fairly standard set of stepper motors.
LiveView Stacking - in the image acquisition panel, a supplementary window (smaller than the main camera's liveview) could be used to stack a few short exposures (unaligned) very rapidly. This would assist the user in identifying their target through the screen, bringing fainter stars into view for the purposes of targeting.
Friday, 2 September 2016
What am I doing?
The GUI will be split into four quarters. If this is run on a large screen the four sectors can be displayed simultaneously, but there should also be an option for each segment to be set to full screen individually for those running with smaller displays, particularly laptop users.
SEGMENT 1
This will be the image capture area with LiveView when possible. It will allow full manual control of the camera as well as the option to run imaging batches as defined by the user.
The main difficulty here will be enabling cross-platform support - Linux and OS X will happily run gphoto2, but if a user wishes to use this on Windows, they'd require Cygwin, which is likely to throw up a whole host of issues on its own. I should investigate command line camera control which runs under Windows and consider writing separate camera control code for each relevant OS. This will be a bit time consuming and, frankly, a bit dull. Taking this in mind, I will first address the Linux / OS X side of things. An important point to not here is that a part of the motivation for creating this app is that a) I'm getting a Mac and b) I'm not sure the astro software for Mac is as well developed as it is for Windows, so I think the Mac user market deserves more attention. P.S. I use the term 'market' in the loosest possible manner. I don't think I intend to create a sellable product, nor do I particularly imagine I'm up to it.
SEGMENT 2
This area of the screen will handle autoguiding. The guiding (pun intended) principle here will be simplicity, and I have already begun coding my own autoguiding program, so I've got an idea of what to do here.
SEGMENT 3
This segment will be concerned with displaying a star atlas and enabling GoTo functionality. My initial thought here is to obtain some kind of star catalogue, along with DSO catalogues and ephemeris data for the planets and minor bodies, and then allow the user either to select their object of interest (OOI) from a list or to click on it from the star map. Communication with the equipment should then slew to the OOI with the minimum of fuss.
This, along with the guiding, will require the use of ASCOM telescope control, and, as such, is likely to be my biggest stumbling block. I only have a single mount (NEQ6 White) and so I'm unable to create the functionality to operate other equipment. However, I suspect some of this may be handled by ASCOM itself. This will require further investigation.
SEGMENT 4
This last quarter of the screen is for an as yet undetermined purpose. I thought I could either allow the user to perform real time stacking of the images as they come in (not as a finished product, but as a guide to whether or not they need further data), or, more likely, a control panel with manual scope and camera controls, application preferences etc. I'd really like to try the real-time stacking option, but I guess we'll see.
SEGMENT 1
This will be the image capture area with LiveView when possible. It will allow full manual control of the camera as well as the option to run imaging batches as defined by the user.
The main difficulty here will be enabling cross-platform support - Linux and OS X will happily run gphoto2, but if a user wishes to use this on Windows, they'd require Cygwin, which is likely to throw up a whole host of issues on its own. I should investigate command line camera control which runs under Windows and consider writing separate camera control code for each relevant OS. This will be a bit time consuming and, frankly, a bit dull. Taking this in mind, I will first address the Linux / OS X side of things. An important point to not here is that a part of the motivation for creating this app is that a) I'm getting a Mac and b) I'm not sure the astro software for Mac is as well developed as it is for Windows, so I think the Mac user market deserves more attention. P.S. I use the term 'market' in the loosest possible manner. I don't think I intend to create a sellable product, nor do I particularly imagine I'm up to it.
SEGMENT 2
This area of the screen will handle autoguiding. The guiding (pun intended) principle here will be simplicity, and I have already begun coding my own autoguiding program, so I've got an idea of what to do here.
SEGMENT 3
This segment will be concerned with displaying a star atlas and enabling GoTo functionality. My initial thought here is to obtain some kind of star catalogue, along with DSO catalogues and ephemeris data for the planets and minor bodies, and then allow the user either to select their object of interest (OOI) from a list or to click on it from the star map. Communication with the equipment should then slew to the OOI with the minimum of fuss.
This, along with the guiding, will require the use of ASCOM telescope control, and, as such, is likely to be my biggest stumbling block. I only have a single mount (NEQ6 White) and so I'm unable to create the functionality to operate other equipment. However, I suspect some of this may be handled by ASCOM itself. This will require further investigation.
SEGMENT 4
This last quarter of the screen is for an as yet undetermined purpose. I thought I could either allow the user to perform real time stacking of the images as they come in (not as a finished product, but as a guide to whether or not they need further data), or, more likely, a control panel with manual scope and camera controls, application preferences etc. I'd really like to try the real-time stacking option, but I guess we'll see.
Why am I here?
OK so this isn't some existential crisis blog...
Basically I'm thinking about the creation of a single application that can handle all the tasks an astrophotographer needs when taking exposures. It's mostly here for me to keep a record of what I'm doing, but if you stumble across this blog by mistake and you have any ideas or suggestions for improvements, please don't hesitate to put the boot in.
Now I haven't done any astrophotography (AP from here on in) for a few years now - I did a bachelor's degree in Astrophysics which, needless to say, started taking up too much of my time. Then I decided I'd carry on and am currently about to finish my Master's degree and begin a PhD. Oh yeah, and I had a baby too, so time has been kinda tight.
However, I have had a lot of time to think, and one of the things that used to stress me out about AP was that you had to have so many programs running at any one time, and that they didn't always necessarily talk to each other all that well.
SO...the plan is to bring them all together into a single app.
Last time I did AP then, I was using the following software:
PHD for Autoguiding
APT for image capture
Cartes du Ciel for GOTO control
DeepSkyStacker for DSO image stacking
Registax 6 for planetary (I was always rubbish at this).
Photoshop CS6 for further processing.
Now, I'm not intending to take on any of these established brands for supremacy - they undoubtedly have the upper hand when it comes to technical know-how, coding skill and applicability - but what I lack in those I make up for in bald-faced idiocy, so here we go!
The app will be programmed in Java for two simple reasons:
1. Java is excellent for cross-platform operation, so I won't have to dick about too much with OS-specific coding.
2. I can only code in Java. Well, that's not strictly true - I can only do GUI based coding in Java. I may fall back on Python or something for some scripts here and there, but if I can I'll keep it Java.
2b. I also know a little about multithreading in Java which may prove useful, especially when a fairly large number of operations are going to be proceeding concurrently.
Whilst of course I will offer my efforts up for the use of others, I shall, at least initially, be coding this for my own benefit. This means it will be designed to work with my own quirky setup. Why is it quirky? Well, I want to operate my 'observatory' remotely, despite being only in the living room whilst the rest of it's outside. The problem is a) that I rent, so I can't start drilling holes in walls and b) AP happens best in winter, so SWMBO won't be too chuffed if I have the door open for a bunch of cables.
The plan is then, from a hardware point of view, to use VirtualHere server on a Raspberry Pi 3 connected to my scope and cameras, whilst the Client is inside on the Mac/PC/Linux machine. I have the luxury of all three, which will be convenient for testing when I start thinking about releasing this for others to use.
Now I'm not sure whether or not VirtualHere will operate fast enough, particularly for autoguiding, as I've never used it before. However, if all goes well, the devices connected to it should just behave as if they're connected to the client machine, so I'll be doing the coding as if this remote setup didn't exist. At a (much) later date, it might be worth investigating the possibility of integrating VH into my own software, but that is some way down the road. Hell, I've not written a single line of code yet, so baby steps.
OK well there's the basic premise. I'll next post about my thoughts on the layout and initial functionality of 'AstroShop' as I've hastily decided it will be called.
Basically I'm thinking about the creation of a single application that can handle all the tasks an astrophotographer needs when taking exposures. It's mostly here for me to keep a record of what I'm doing, but if you stumble across this blog by mistake and you have any ideas or suggestions for improvements, please don't hesitate to put the boot in.
Now I haven't done any astrophotography (AP from here on in) for a few years now - I did a bachelor's degree in Astrophysics which, needless to say, started taking up too much of my time. Then I decided I'd carry on and am currently about to finish my Master's degree and begin a PhD. Oh yeah, and I had a baby too, so time has been kinda tight.
However, I have had a lot of time to think, and one of the things that used to stress me out about AP was that you had to have so many programs running at any one time, and that they didn't always necessarily talk to each other all that well.
SO...the plan is to bring them all together into a single app.
Last time I did AP then, I was using the following software:
PHD for Autoguiding
APT for image capture
Cartes du Ciel for GOTO control
DeepSkyStacker for DSO image stacking
Registax 6 for planetary (I was always rubbish at this).
Photoshop CS6 for further processing.
Now, I'm not intending to take on any of these established brands for supremacy - they undoubtedly have the upper hand when it comes to technical know-how, coding skill and applicability - but what I lack in those I make up for in bald-faced idiocy, so here we go!
The app will be programmed in Java for two simple reasons:
1. Java is excellent for cross-platform operation, so I won't have to dick about too much with OS-specific coding.
2. I can only code in Java. Well, that's not strictly true - I can only do GUI based coding in Java. I may fall back on Python or something for some scripts here and there, but if I can I'll keep it Java.
2b. I also know a little about multithreading in Java which may prove useful, especially when a fairly large number of operations are going to be proceeding concurrently.
Whilst of course I will offer my efforts up for the use of others, I shall, at least initially, be coding this for my own benefit. This means it will be designed to work with my own quirky setup. Why is it quirky? Well, I want to operate my 'observatory' remotely, despite being only in the living room whilst the rest of it's outside. The problem is a) that I rent, so I can't start drilling holes in walls and b) AP happens best in winter, so SWMBO won't be too chuffed if I have the door open for a bunch of cables.
The plan is then, from a hardware point of view, to use VirtualHere server on a Raspberry Pi 3 connected to my scope and cameras, whilst the Client is inside on the Mac/PC/Linux machine. I have the luxury of all three, which will be convenient for testing when I start thinking about releasing this for others to use.
Now I'm not sure whether or not VirtualHere will operate fast enough, particularly for autoguiding, as I've never used it before. However, if all goes well, the devices connected to it should just behave as if they're connected to the client machine, so I'll be doing the coding as if this remote setup didn't exist. At a (much) later date, it might be worth investigating the possibility of integrating VH into my own software, but that is some way down the road. Hell, I've not written a single line of code yet, so baby steps.
OK well there's the basic premise. I'll next post about my thoughts on the layout and initial functionality of 'AstroShop' as I've hastily decided it will be called.
Subscribe to:
Posts (Atom)