SharpCap Forums

Hi,

I'm afraid that I don't understand why you get the horizontal lines in the image, but they would certainly ruin chances of star detection working properly. Very odd that they are only appearing some of the time.

Does the camera offer a binning option? If you were to enable 2x2 binning maybe the horizontal lines would go away and that might help the star detection work more reliably.

cheers,

Robin

Hi,
using first nights free of clouds (for some hours) I followed Robin´s recommendations.
First remark: The interlaced images of my "older" masterdarks in 10 cases were not usable and only one seems to be o.k. (from 11.3.). That was the reason to tray "produce" and use special masterdark (applying the first useful dark from 11.3., taking one from PHD2 and resizing, using 2x2 bining etc.). Than I applied them in the SC dark subtraction box to a new live dark taken by the camera. In parallel I tried to use them in PHD2. In PHD2 I got a noisy image without visible hot spots. The results in SC2.9 were different. Disturbed resulting image (appended image 0, left part was stretched for better distinction), gray image (first I was happy, but it was one gray level only without any deviations) or not changed image with hot pix plus real stars. Last is visible in the appended image 1. For comparison their is left hand the dark image too. For Robin I will send the log-files seperately. Any suggestions or ideas? Thanks.
Cheers,
Hobbyist

I think we are only going to get to the bottom of this when I get my hands on a Starlight Express camera for testing - the ASCOM driver is obviously not behaving in the way that SharpCap expects and that's making it very hard to diagnose what is going on exactly. If it was crashing, the log would show me why, but with it working but producing invalid images the log is much less useful.

The problem with ASCOM is that the specifications are not strict enough which means that different manufacturers interpret them in different ways. For instance one manufacturer created an ASCOM driver where the order in which pixels were returned was starting at the top left, then going down the first column, then starting the second column at the top and going down that and so on... Every other ASCOM driver out there works across rows of pixels instead, but this one went down in columns!

Once I have SharpCap 2.10 finished I will have a chat with SX and see if I can move to having proper support for their cameras in the version after that.

cheers,

Robin

PS. It may be helpful if you can find a lens to allow you to test your camera indoors. Sometimes it can be easier to diagnose what is going wrong with an image with a more 'normal' image as star fields can be difficult to interpret due to their nature. Not sure about the SX cameras, but many other small guiding cameras can have a 'CS thread' (25.4mm thread, 12.5mm back focus) or 'C thread' (25.4mm thread, 17.5mm back focus) lens attached - these are relatively cheap to buy from ebay, etc. The other advantage of this approach is that you don't need to wait for a clear night to test cameras!

Hi Robin, hi all,
I agree with you. Once next days presaged clear nights I decided to use daytime for further investigations. Feeling certain that it is a problem of darks I will tray different data formats and subdark numbers. Checking PHD converted darks bit depth it changed from 48bit to 8bit. The SC uses 24bit (from 48bit).
Nevertheless I will tray to produce masterdark by SC and applying/subtracting it to live (dark) images. Before it will not result in a hot spot compensation/suppression I will not get propper results in SC. Additional I will apply the same stretching parameters for better comparison.

Now (2 hours later) the results: Left hand the dark frame subtraction in SC. Right hand: N=3 yielded best results in diffence live image. N=9 as expected produces much sharper (smaaler spots not matching the entire original spot for compensation) and less noisy dark image, but the hot spots are visible in the difference live image because of outshining. One of the fault pixels (marked) disappeared. May be it´s a cold pixel.
Let´s see what happens tonight.
PS: The PHD dark-file data structure is different. It´s not possible to use without proper file conversion. In the following I only used SC darks.

Another 10 hours later clear sky invited me to test. Test was provided without bining. With SC2.9 I could not solve dispite the fact that the hot pixels were suppressed (by n=3). With 2.10 I got after several trials a proper solving and was able to continue my first alignment up to "excellent" result (dropping down to "fair" after fixing the attachment screws properly). So far, so good. Thanks to Robin.

Nevertheless for me it leaves a nasty taste. Obviously some factors concurred (beginner, ASCOM Lodestar drivers, proramm? are all interacting). The main questions for me are:
1. The "interlaced" darks. I do not understand how and why they appeared and disappeared.
2. The dark frame accumulation and subtraction. It seems to exist an optimum (in my/Lodestar case) concerning the number of darks.
3. The difference between SC2.9 and 2.10 and that it´s hard even vor 2.10 to solve at all.

Thank you again. It would be nice to hear from you, if their are news about the real causes of my beginner´s misfortune.
cheers,
Hobbyist