This might possibly be an issue with the Ekos Polar Alignment routine, not with StellarSolver. but it is too soon to tell.
Read More...
That is an odd amount of error, can you post an example image that produces this much error?
Read More...
So, I just downloaded and tested The Rosette image you sent. There is incorrect scale information saved in the FITS Header. That is why it fails to solve. The FITS Header says that the scale is 4.9" per pixel, but when I solve the image it says 2.22" per pixel. That is too far off to solve with use scale checked. Unchecking use scale allows this one to solve. I expect this is the first image? The others seem to have correct scale info?
Then I tried the Light 3 image that you sent, The scale was correct in this image and caused no problems, but the position information is very wrong. The position saved in the FITS Header says it is pointing at the pole. If you notice, the DEC is just about 90 degrees. Unchecking use position allows this one to solve. Usually the reason this would occur is if the mount and KStars thinks it is still pointing at the pole when you are really pointing someplace else. If you restarted KStars or your mount, and had the option in KStars set to send the incorrect position information to the other one, or something like that, and then tried to plate solve while pointing at someplace other than the pole would cause this to happen. I hope this made sense?
I'm not sure I understand the "Light 1" Images. They have the wrong position information saved in the FITS Header, and unchecking the "use position" option allows them to solve, but I am not as certain about what happened to cause it as I am in the "light 3" image. Do you have more information about these 2 images? The first one the RA was off a bit. For the second, both the RA and DEC were off. But each image it is a different amount they are off. Did you move the telescope without using the hand paddle or KStars? Or maybe were these done after restarting everything and trying again?
The horsehead image has correct scale and correct position information. It solves right away.
Read More...
So The INDI_RPICam is a very new driver. I know the author had asked me to include it in some of the AstroPi3 Build scripts awhile back this summer. But now it is integrated into 3rd Party. I think he is still working on improving it. I made the INDI Webcam Driver a few summers ago, so I know a lot about that one. But the V4L2 driver has been around for a long time and it is Linux Only, so I don't have any experience with that one really.
Read More...
Hmm, looks like somebody must have made a change to INDI recently that OS X did not like. This must have been very very recent though, since I just built the 3.5.1 beta DMG the other day since a user found that Toupcam was left out of 3.5.0 accidentally. I can take a look at the recent changes.
Read More...
For example, if your webcam is taking 60 frames per second and you tell INDI Webcam to take a half second exposure, it will average about 30 frames together if you select that option. The resulting averaged image will have a significantly higher signal to noise ratio than a single frame. You can also integrate the 30 frames instead, but you could very quickly overexpose and saturate your pixels that way. Of course, as with a regular camera, if the subject moves during the "exposure time", then it will blur in the averaged image.
Read More...
Well I'm not sure there is a bug per se. The V4L2 and INDI Webcam driver are treating the camera as if it is a webcam. You can't set arbitrary exposures on a webcam. However, you can set frame rates and sometimes that will change the exposure time. When I wrote the INDI Webcam driver a couple of summers ago, I added a feature to it where you could set an exposure time and it won't change the cameras actual exposure time since for many webcams that is impossible, but it will stack multiple frames together either averaging or integrating them to get a better image over the longer time.
Read More...
So I don’t right now have answers to all your questions here, but true binning is a capability that most ccds have but cmos cameras technically do not. But a number of cmos cameras are capable of binning in the cameras electronics before sending the image back. A ccd usually has wiring for each column of pixels and so it reads a whole column of pixels at a time. It can bin by just adding pixels as it reads them out. A cmos camera usually has wiring for each individual pixel so if it has binning capability in its camera, then it combined the pixels after reading them out in the software of the camera. This slight difference means that when a ccd camera bins, it is as if the pixels really were bigger and helps with signal to noise ratio because the signal gets greater but the readout noise remains the same. For cmos cameras with binning capability, the new bigger “pixels” will have more readout noise along with the signal since they will have the noise from each pixel. However, with both types of cameras, if binning can be done in the camera before transmission through the wire back to the computer, the smaller image should take less time to transfer. If a camera is not capable of binning in the camera, binning can be done later in the driver or software on the computer that receives the image, this is known as software binning. But with software binning you have already lost the two advantages of binning I mentioned above. I don’t believe the raspberry pi camera is capable of binning in the camera, but I might be wrong.
Read More...