I have the Qt development experience, and I would be happy to develop the import/export feature. At this very moment, however, I am in the final stages of enabling my 50-year old mount to take unguided exposures in the ~5 minute range. It has been the result of weeks of dedicated hacking. Once I get over this hump then I can enjoy a new level of astrophotographic enjoyment. That will then free me up to do KStars development.
Interesting. I captured an image to FITS. I submitted it to All Sky Plate Solver. It replied that Camera Angle was 2 degrees. Then I captured an image to PNG. But to view the PNG correctly I needed to rotate the image 180 degrees for North to be up. Interesting. This requires more experimentation. It may require a letter to be sent to NASA.
This past week I got serious about orienting my camera so that the image results in NCP:Up and East:Left. I snapped an image of Albireo and asked astrometry.net and All Sky Plate Solver for its opinion. You can see my image
Both astrometry.net and ASPS agreed with the orientation: "Up is -178 degrees E of N". I thought: what? I worked hard to ensure that North was Up. Why are you telling me that South is Up? I uploaded a JPG file not a FITS file, so my theory is that the plate solvers assumed that my telescope optics inverted the image. OK I can understand that.
Information is not easy to come by on the Internet about this topic, so I thought long and hard about it. Perhaps when the plate solvers refer to "UP" they are not referring to the top of the image -- instead they are referring to the top of the sensor. Does that make sense?
Also, FITS files contain metadata whereas JPG and PNG files do not. I am wondering if I should expect different results from the plate solvers if I capture my images in FITS files instead. I can certainly understand that getting the orientation of the sensor is important when applying darks, flats, and bias frames.
Would you recommend that I always capture to FITS?
Thanks for your reply, riccio. Yes, these are ballpark estimates just intended to get a wisp of nebulousity to imprint on the subframe. I decided that I desperately needed a tool like this when I was flummoxed as to why I couldn't get a print of the Fireworks Galaxy (NGC 6946) with a 30 sec exposure after I just got a print of the Ring Nebula at 30 sec -- after all, the catalog says that they are both magnitude 8.8. After that is when I discovered Surface Brightness.
The weather here has been terrible. I am lucky to get one night per week. Since then I did verify that a 52 sec exposure of the Dumbbell Nebula is roughly equivalent to a 30 sec exposure of the Ring Nebula, that according to my program. I have more testing to do. Right now I am hacking my 50-year old telescope and mount to enable auto-guiding. I have been pretty much limited to 1 minute exposures due to periodic error. I have now replaced the original synchronous motor with a stepper motor of my design, and putting the final touches on periodic error correction. I would be happy if I can do 5 minutes unguided with only minimal star elongation. The next step will be to write an INDI driver and do auto-guiding. First, though, I will try to go unguided.
Thanks for your input!
One of the terrible things about having so many choices is that it paralyzes one from making decisions, at least for me. For example, if I go to the grocery store I don't mind risking a few dollars on something new, but when it comes to a new telescope I can easily drop thousands of dollars on a new setup, only to discover that it did not meet my expectations. Part of the problem is the horrible job that manufacturers and retailers do to market their products. It is hyperbole without much substance. So, my response is to stick with the same set up I have had for the past 45 years: a Unitron Model 142.
I only have a motor drive on the RA axis: a stepper motor driven by a Raspberry Pi and Adafruit MotorHAT with my own Python code. I just added a routine to do Periodic Error Correction. I am very pleased with the results. Without PEC I was limited to 30 second exposures max. With PEC I am limited now by my uncooled camera but still I can image galaxies. So with PEC I was able to reduce PE from 50 arc-sec p-p to 10 arc-sec. I know that sounds awful compared to the sub-arc-sec guiding that you achieve, but for me it is a quantum leap forward.
The next step is auto-guiding. My RA stepper motor has a resolution of 0.43 degrees per step. I am confident that it can do the job. One of the problems is that I do not have a DEC motor -- I don't even have the gearing for it. Actually I work very hard at getting an accurate polar alignment. Over a 5 minute exposure I get very little DEC drift.
My questions are:
1. Can I use Ekos Guiding with a driver that only gives it control in RA? (Someone told me that PHD2 will do that.)
2. Can I use Ekos with a driver that does not have slew-ability? In other words, can I continue to use my setting circles?
3. With my set up can I use Ekos Polar Align?
Thanks to all for your help!
Hi Jasem, I discovered your "Kuwait Astronomy" channel on YouTube and subscribed to it. It's perfect for learning the capabilities of Ekos. Keep up the great work.
My only recommendation would be this: reply to the few people that leave a comment. Invite them to join the INDI forum for the best support for questions they have.
Thanks to Klaus for leading me to this paper by
where I learned how to calculate Surface Brightness given the size of the DSO and its magnitude. Now, I am wondering if I can use Surface Brightness to estimate the exposure needed to capture it according to the following formula:
m1 - mref = -2.5 * LOG (I1 / Iref)
rearranging terms yields:
I1 / Iref = 10 ** ((mref - m1) / 2.5)
In order to put this into practice I need a reference object and exposure. Let's say that I recently captured M57 with a 30-second exposure and that I am happy with the density of nebulosity on each subframe. Now I want to capture M27.
The surface brightness of M57 is 19.6.
The surface brightness of M27 is 20.2.
According to the above formula:
I1 / Iref = 10 ** ((19.6 - 20.2) / 2.5) = 0.57544
In other words it says that M27 is 57.544% of the intensity of M57.
That makes sense when I compare a 30-second exposure of M27 to a 30-second exposure of M57. The Dumbbell Nebula appears to have half the density on the subframe.
Then, can I safely estimate that I would need an exposure of 52 seconds in order to achieve the same density?
(i.e. 30 sec / 0.57544 = 52.134 sec).
If yes, can I safely use my reference exposure of M57 (a planetary nebula) as a basis for estimating the exposure time for other types of DSO's? Or should I endeavor to establish a different reference for each DSO type and only make intra-object-type exposure estimates?
Thanks to everyone for their help.
Thank you again, Klaus! This is perfect, it explains a lot of what I experienced the other night. The next time I will be better at my craft thanks to you.
I recently imaged M57. A catalog that I use says that it is magnitude 9.0 and a size of 2.5 arcmin. I took a single 30-second exposure and compared it to a star chart. The nebula is visible but it is rather dim. Not too far away is a 9th magnitude star that is burnt in and bright. In my primitive mind I rationalize this by saying that if I were to add up the number of photons in the larger area of the nebula and compress it into the smaller area of the star then I might say they are equivalent magnitude.
Somewhere in my mind a formula exists that relates star magnitude to DSO magnitude given the size of the DSO. I applied what I learned from undergraduate courses in Astronomy and Physics from 40 years ago, and came up with an equation that produces unsatisfactory results.
You see, this is the question I would like answered: If a single, unstacked, 30-second image shows stars down to the 13th magnitude then what is the magnitude of the faintest DSO that I can see in that image given its size in arc minutes?
Has anyone heard of such a calculator, or is there a rule of thumb?
Thanks so much.
We have had weeks of crummy weather in the Northeast US. Finally, yesterday we got a break, although the night sky was highly variable: one minute it was clear, and the next minute thin, obstructing clouds.
I got a chance to test out my software. It is effective but its accuracy depends on the resolution of your setting circles. I decided to provide two methods of operation: the first is the traditional approach of using the setting circles on your polar axis to dial in the right ascension of a calibration star, and then slewing to the desired object by matching the readout to the object's right ascension; the only problem with that method is that you need to re-calibrate for each new target. The second method uses the setting circles on the polar axis to dial in the hour angle of the calibration star which needs to be performed just once for the entire night.
I learned a few important lessons along the way. I plan on making the repo public after I author an informative markdown file. I am attaching photos of M57 and M27 that I took last night with my ASI120MC through an $80 70mm Celestron achromat at f/5.7 pick-backed on my Unitron Model 142. These are 30-second exposures, stacked with Registax 6; I had to throw out a lot of images due to corruption by clouds passing by. M27 has a lot of noise because there were so few good images.
Hi Jasem, I have not lost interest in KStars development, or any other type of development for that matter. However I have taken this time to learn Qt. For my first project I wanted to develop an application to help with my old school telescope's setting circles. I've attached a screenshot of my desktop that shows my QtSettingCircles app plus an AngularJS app that I completed several months ago. At the moment. QtSettingCircles is a private GitHub repo but over the next couple of days I will make it public. I have tested it on Ubuntu 16.04 and Windows 7. Works great!
What the attached image isn't showing is that the Hour Angle is updating in real time. And the reason why I show it in a large point size is that my laptop will be a good 2 meters away from me when I adjust the setting circles. I need that magnification.