SharpCap - free Astro Webcam Capture Software

[alphatripleplus]

On Friday, July 29, 2016 at 02:50, rwg said:

Hi Don,

I have just tested with a 174MC and for that camera auto white balance also does not work in RAW16 mode, but it does in RGB and RAW8. This is going to be either a bug or a deliberate limitation in the ZWO camera driver or SDK - probably best to raise this issue on the ZWO forum and see what they say about it.

cheers,

Robin

Robin,

 

After reading yours and Don's comments on the two colour balance settings - White Bal (R) and White Bal (B) - in RAW16 mode, I went and checked the collection of CameraSettings.txt files that are captured when I use SharpCap with the ASI224MC. I found using RAW16 mode for my ASI224MC that all captures taken using up to SharpCap vs 2.8.2343 seem to be Auto balanced, with settings of R=52 and B=95. However, once I started using vs 2.9.2491 and later SharpCap versions in early May, I now notice that the Auto balance values stay at R=50 and B=50. I don't believe I changed anything in the Image Controls, as I usually just leave the White Bal controls alone. Not sure if this is a red herring, but  I thought I would pass it along. I haven't focused on colour balance previously, but I will take a closer look in the future.

 

Regards,

 

Errol

[alphatripleplus]

Robin and Don,

 

I see from the ZWO user group page that Sam has just indicated that this absence of Auto White Bal behaviour for RAW16 is intentional, so you can ignore my last post

[rwg]

Good to know that it's working as designed - looks like RAW16 means actual 'raw' - ie no tweaking of the pixel values in the camera SDK.

cheers,

Robin

[rwg]

On 30/07/2016 at 15:20, digitalcyanide said:

A Downloaded the latest version again last night to have another shot at the polar alignment feature.
Having followed the instructions and correcting it was giving me a error of a few seconds (<10) which I was happy with.

PHD is reporting a much larger error (a few minutes).
Is there anything I should be aware of or need to start looking to correct to get sharpcap to be more precise?
I am really hoping to be able to use this rather then spend far to much time drift aligning.

 

Any help or advise would be great and thanks again for the continued hard work

I've seen the same sort of symptoms that you are describing and I have a possible theory about this - it might be down to flex in the mount/tripod/pier system.

When you polar align using drift alignment (or PHD) you have the telescope pointing to a point near the celestial equator. When you polar align using SharpCap you are pointing at the NCP. Even though your mount is balanced in respect to the RA and Dec axes, the weight distribution relative to the pier/tripod head shifts as the scope moves about. This could flex the pier/tripod/mount a small amount (doesn't have to be much) to cause a change in polar alignment?

I'm not really sure about this idea - haven't worked out a way yet to test whether it's true or not.

cheers,

Robin

 

[barrie greenwood]

Hi guys

I've an issue I can't solve sharp cap works no problem with my webcam

I've just got a Samsung scb2000 and easy cap to bridge it into the laptop if I connect the camera it just give a black screen however if I fire the camera via arcsoft them open up sharp cap the image is fine but once I start to rec all it records is one frame and that's it

I have all the drivers and even bought a new easy cap to use as I thought it could be the device at fault but the new one is the same  been trying for a number of days now and can't get it to work I'm using Windows 8.1 any help advice guys

Regards Baz

[themos]

13 hours ago, rwg said:

I've seen the same sort of symptoms that you are describing and I have a possible theory about this - it might be down to flex in the mount/tripod/pier system.

When you polar align using drift alignment (or PHD) you have the telescope pointing to a point near the celestial equator. When you polar align using SharpCap you are pointing at the NCP. Even though your mount is balanced in respect to the RA and Dec axes, the weight distribution relative to the pier/tripod head shifts as the scope moves about. This could flex the pier/tripod/mount a small amount (doesn't have to be much) to cause a change in polar alignment?

I'm not really sure about this idea - haven't worked out a way yet to test whether it's true or not.

cheers,

Robin

 

https://learn.sparkfun.com/tutorials/getting-started-with-load-cells

[larryh]

Hello.  Quick question about polar alignment.  I see on the website that the FOV requirement is 1 - 2.5 degrees however, with my setup, I can't quite get to 1 degree even with a 0.5x focal reducer (I have a small chip camera and 750mm FL).  Is it possible the polar alignment will work with a smaller FOV?  I think I'm around 0.5x0.75 degrees with the 0.5x FR.  Has anyone tried it with less than 1 degree FOV?  Thanks!

[rwg]

Hi Larry,

I think this has a good chance of working with the very latest version (I added a lot more stars to the alignment catalogue, so it can cope with smaller fields of view). Give it a try and report back any problems.

cheers,

Robin

[larryh]

Thanks Robin, I will report back with results when I get a clear night.

[dyfiastro]

6 hours ago, rwg said:

Hi Larry,

I think this has a good chance of working with the very latest version (I added a lot more stars to the alignment catalogue, so it can cope with smaller fields of view). Give it a try and report back any problems.

cheers,

Robin

Thanks for the info, I too will also be trying this. Will give me a chance to see if I can get more accurate results with my main scope instead of using my guide scope

[larryh]

On ‎8‎/‎4‎/‎2016 at 08:24, rwg said:

Hi Larry,

I think this has a good chance of working with the very latest version (I added a lot more stars to the alignment catalogue, so it can cope with smaller fields of view). Give it a try and report back any problems.

cheers,

Robin

Hi Robin.  I had a chance to try out the polar alignment with my setup last night.  It was not able to solve any frames (always said "not solved" and latest frame status was "not solved").  It's hard to tell what the problem might have been.  It was definitely finding stars, and usually over 10 but less than 20.  I have two theories.  First, the simple one is that my FOV is too narrow and the algorithm does not consider an image scale that small when trying to plate solve.  My other theory is that I noticed it would often pick a (to me) known hot pixel(s) as stars which may be causing it to have a problem.  I increased the minimum star width up to 3 pixels which seemed to mostly get rid of the hot pixel selection, but then the real star count often was below 10.  I restarted the routine several times and would give it a few minutes each time before giving up.  I'm wondering if you are stacking and trying to plate solve on the stack, or whether it is an entirely new attempt on each "frame".  The hot pixels would be more of a problem if you are using a stack.  I think I saw frames come up with no hot pixels selected and more than 10 stars.  Anyway, my thought is that if a dark frame could be subtracted just like in live stack, that would help with the hot pixels.  I suppose another method would be to allow the user to select areas to ignore due to hot pixels.  I figure your dark frame subtraction code already exists from live stack though.  Since we don't know if that's really the problem I'm not sure it's worth spending time on.  If you have any thoughts on other things I could try, I'll give it another shot next time I get clear skies.  Thanks!  Larry

[rwg]

Hi Larry,

either the hot pixels or the small field of view could be the cause of the problem. SharpCap is trying to solve each new frame as it arrives, so if it doesn't solve within 10 frames or so then there's not much chance that waiting longer will help, although tweaking some other parameters (exposure, gain, etc) might.

I'm guessing that you are using a webcam or an analogue camera with a frame grabber, since if you were using a USB astro camera (ie ZWO, QHY, etc) then you'd have the dark frame subtraction available in the camera controls on the right hand side. This option isn't available for webcams/grabbers (but as you pointed out you can dark subtract in the live stacking code). It would certainly be possible to add the dark subtraction to the alignment code if that turns out to be the problem - in fact designing the UI for it is more work than simply wiring in the existing subtraction code.

The best thing would be if you could capture a few frames that fail to solve and send them to me (ideally along with darks too). That would let me test them out and see if I can get any results out of them by tweaking the code and/or the images.

cheers,

Robin

 

[larryh]

3 hours ago, rwg said:

Hi Larry,

either the hot pixels or the small field of view could be the cause of the problem. SharpCap is trying to solve each new frame as it arrives, so if it doesn't solve within 10 frames or so then there's not much chance that waiting longer will help, although tweaking some other parameters (exposure, gain, etc) might.

I'm guessing that you are using a webcam or an analogue camera with a frame grabber, since if you were using a USB astro camera (ie ZWO, QHY, etc) then you'd have the dark frame subtraction available in the camera controls on the right hand side. This option isn't available for webcams/grabbers (but as you pointed out you can dark subtract in the live stacking code). It would certainly be possible to add the dark subtraction to the alignment code if that turns out to be the problem - in fact designing the UI for it is more work than simply wiring in the existing subtraction code.

The best thing would be if you could capture a few frames that fail to solve and send them to me (ideally along with darks too). That would let me test them out and see if I can get any results out of them by tweaking the code and/or the images.

cheers,

Robin

 

I was kicking myself today that I didn't save some images.  You are right that I have an analog camera and frame grabber.  I will capture some images next time I have a chance.  Thanks!  -Larry

[Terestron]

Hi,

I just D/L Sharpcap 2.9 and installed on Win10.  I hooked up my SXV-H9 CCD and it worked great.  Caught a great sequence of the moon.  However, now when start the program I get the following error "Cannot start camera- Object reference not set to an instance of an object.  I tried a restart and unplugging USB and reconnecting and still same error message.  Why would it work at first and now nothing?  I attached the debug file.

v2.9.2739.0-ApplicationException at SharpCap.UI.BugReportWindow.OKOnClick(Object sender, RoutedEventArgs e)_line 26_#50778_.error.zip

[rwg]

@Terestron

I think that there is a bug with ASCOM cameras when you set a default capture profile - the order of some things happening during the capture start up seems to be wrong - I'm looking into fixing it.

cheers,

Robin

 

[Terestron]

6 hours ago, rwg said:

@Terestron

I think that there is a bug with ASCOM cameras when you set a default capture profile - the order of some things happening during the capture start up seems to be wrong - I'm looking into fixing it.

cheers,

Robin

 

OK I look forward to the fix..the one time it worked it was great!

[larryh]

Hi Robin, I had a chance to try the polar alignment again and it was still not able to solve.  This time I captured a few frames before the clouds closed in.  I polar aligned using the ZEQ25 polar scope first, so these should be fairly close to the pole. Here are two representative ones, along with a dark so you can see which are the hot pixels.  For whatever reason it did not seem to be picking the hot pixels this time, so that may not be the problem.  The frames are short live stacks but the dark is a single frame from a dark video (was not created using "capture dark", which crashes for me).  By the way, it seems like sometimes Sharpcap might be vertically flipping the image when it saves the stack.  I had to flip the dark to get it to match the stack.  I estimate the FOV of these frames to be 44'x32'.  Thank you so much for your program.  With or without the polar alignment it's a great tool.  Remember, as a software person I can tell you, you'll find the last bug when you stop looking!

 

 

 

[larryh]

FYI, someone on Cloudy Nights is reporting success with polar alignment using an FOV of 35'x27'.  I must have other problems...

[rwg]

Hi Larry,

I can't persuade nova.astrometry.net (which is the sort of gold standard of plate solving) to solve either of those frames, so I think that SharpCap isn't going to succeed either. Ideally I think you need to get rid of as much of the orange background as you can and also bring out more stars if at all possible.

http://nova.astrometry.net/status/1196236

http://nova.astrometry.net/status/1196243 (I tried darkening the background by adjusting the levels on this one)

cheers.

Robin

[larryh]

Thanks for the attempt Robin.  I will try to improve the quality of the frames I'm feeding to the algorithm.  I think if I turn on the in camera stacking that will clean up the noise a good bit.  Since someone has gotten it to work with a smaller FOV than mine, I figure there is hope.  Thanks again.  - Larry

[larryh]

Robin, I found the astrometry site very interesting.  I didn't realize something like that was available.  I've played around with my images some and I've gotten a solution off of that site with a modified image.  Here are two examples of ones that it was able to solve.  The key, as you said, was mainly reducing noise.  It did not seem to be affected by the hot pixels.  For both solutions I restricted the parameters to 20-60' FOV, RA 24hr, Dec 90 radius 5 deg and 5 pixels star movement.

Solution page: http://nova.astrometry.net/status/1196556

 

I also tried reducing a frame to black and white.  It seemed easier to adjust levels and reduce noise.

Solution page: http://nova.astrometry.net/status/1196620

So, I've got a few ideas of what to try next time, including using in camera stacking to reduce noise and possibly setting the camera to black and white.  I'd be interested to know if these frames are solvable by your polar align routine, but I will be trying it again regardless.  Thanks again for the help and tips.

 

[rwg]

Hi Larry,

that second frame (monochrome) definitely looks like it should solve, but it doesn't - I will look into it

cheers,

Robin

[calan]

I haven't had a chance to read this whole thread, but I have a couple of minor issues with SC 2.9 (Win 7 x64, ASI224MC)

1).  Changing the exposure slider often causes a program hang/crash, but entering a new value doesn't. Also, the "LX Mode" checkbox isn't always being saved. It seems as though SC is getting confused about when that box should be checked. For example, I can have an exposure setting of 15s saved, but when I load that profile the box will still be unchecked. Adjusting the slider then hangs the software.

2). Disconnecting the camera, temporarily connecting to it with another program (APT), then reconnecting sometimes causes a crash.

3). The histogram and Live view windows don't resize properly (not synced with each other). Seems that if one is resized, the other should also be resized the same...since they both occupy the same space.

4).  There needs to be "Reset to default" buttons for the live stack histogram, image, and display controls. Numerical boxes on the live stack histogram would be nice also.

5). The  USB "Turbo" auto function seems to be calibrated a bit too aggressively. I still get frame stutters with it on auto, but if I turn off auto and lower it slightly, they clear up.

*****

I am really liking SharpCap, and can't wait to see what else pops up in it.  I also want to try it with my Mallincam xtreme and see if the live stacking features can breathe new life into it.

Awesome job and thanks!

[rwg]

Hi Calan,

thanks for taking the time to report the issues - in order...

1) Not setting LX when loading a profile is a bug - I never thought of that and will have to fix it. The crash when using the slider is more subtle - I think that under some circumstances the camera/driver doesn't like having the exposure length changed many times in rapid succession, which is what happens when you slide it. It's ok when you are doing 20+ fps and then you want the update to the exposure to be instant, but at 1s + I might have to do something to limit the frequency of the updates.

2) Never experienced this, but it doesn't feel like a SharpCap bug, more likely something in the underlying ZWO SDK not happy with this scenario.

3) Put the zoom on 'Auto' and the live view should resize to fill the available space.

4) I'll have to think about this - it's already a struggle fitting things in on smaller displays and it's not obvious that there are any defaults for camera settings, since some camera SDKs remember the values for controls from the last time you used the camera and some don't, so SharpCap can't even rely on the control settings the very first time you open the camera as being the 'default'.

5) Auto Turbo USB is implemented by the ZWO SDK - SharpCap just sends it a message to enter auto mode. Try raising this one on the zwoug forums.

cheers,

Robin

[calan]

Thanks much for responding so quickly Robin!

On #3...   it's not a matter of the camera display, it's that the histogram and Liveview each reset the screen size if you drag them. In other words, if I have my histogram set how I want it, and then go to the live Live stack view, the live stack dialog will assume the size of the histogram I had open... not the previously sized live view. In other words, they share the same sizing information, instead of being persistent individually. Not a big deal, but a bit annoying if you prefer each to have a different height.

On #4 ... understood. The liveview histogram is really all I was concerned with the default button, mainly because I can never find the gamma center point.

(Maybe a parameter in settings that would show or hide histo value boxes for people on small screens?)

BTW - Do you take paypal donations? If so, what is the addy?