Jump to content

SkySurveyBanner.jpg.21855908fce40597655603b6c9af720d.jpg

SharpCap - free Astro Webcam Capture Software


rwg

Recommended Posts

@ChrisLX200

Good point on the occasional bug with frames getting stuck when changing exposure - I've seen it once or twice myself but never quite got around to doing something about it for the QHY cameras. I must look into that - I have dealt with similar problems for other brands of camera by resetting the camera if the frame is too far overdue.

Next time you see the streaking issue with darks, grab a screenshot - I can't quite think what could be causing that at the moment (particularly what could cause it that would go away with a restart of SharpCap).

cheers,

Robin

Link to comment
Share on other sites

  • Replies 1.5k
  • Created
  • Last Reply

Hi Robin

Newbie in both the sense of being in this forum and astronomy in general. With intro over..

Using latest sharpcap and the latest QHYCCD patch and drivers. I am having issue with my ASUS T300chi which I was hoping to use with a QHY163C. The camera works fine attached to my desktop where I can get 3-4 fps constantly (This is already odd that the fps is so low my desktop is a i7-4790 with 32 gigs of RAM). On the T300chi which has a core-M 5Y10 and 6 gigs of ram the camera starts off around 3-4 fps then after about 10-30 frames it drops to 0.1 or 0.

I am not sure what the problem is. Is there anyway I can get you more info to determine what the problem could be? I don't know if the problem is that the core-m is too slow or something else, but having just 3-4 fps on my relatively powerful desktop does makes me wonder if there are just teething issues with the camera.

 

Thanks! For the SW and any help you can give me.

Link to comment
Share on other sites

8 hours ago, cotak said:

Hi Robin

Newbie in both the sense of being in this forum and astronomy in general. With intro over..

Using latest sharpcap and the latest QHYCCD patch and drivers. I am having issue with my ASUS T300chi which I was hoping to use with a QHY163C. The camera works fine attached to my desktop where I can get 3-4 fps constantly (This is already odd that the fps is so low my desktop is a i7-4790 with 32 gigs of RAM). On the T300chi which has a core-M 5Y10 and 6 gigs of ram the camera starts off around 3-4 fps then after about 10-30 frames it drops to 0.1 or 0.

I am not sure what the problem is. Is there anyway I can get you more info to determine what the problem could be? I don't know if the problem is that the core-m is too slow or something else, but having just 3-4 fps on my relatively powerful desktop does makes me wonder if there are just teething issues with the camera.

 

Thanks! For the SW and any help you can give me.

First thing to try is does it give the expected frame rate using QHY's EZCAP.

Link to comment
Share on other sites

@cotak

Quick rundown of some possible causes of slow frame rates

* CPU just can't keep up with data rate (unlikely in your case)

* USB 2 ports for USB 3 cameras

* Slow disk that can't keep up with the camera (if the frame rate only drops when capturing)

* Overly long USB cables or sharing hubs with other devices

* USB speed parameter set wrongly.

The last is often worth checking - most cameras have this sort of parameter and SharpCap sets it to a value which gives slower frame rates but higher reliability. In the case of QHY the parameter is called 'USB Traffic' and you turn it down to try to get higher frame rates. Push it too far down and they may stop entirely.

Another possibility from the symptoms you describe is that the camera is seizing up entirely after a small number of frames - when the frame rate drops to the low level is the frame count still going up at all or is it completely stuck?

cheers,

Robin

Link to comment
Share on other sites

4 hours ago, rwg said:

@cotak

Quick rundown of some possible causes of slow frame rates

* CPU just can't keep up with data rate (unlikely in your case)

* USB 2 ports for USB 3 cameras

* Slow disk that can't keep up with the camera (if the frame rate only drops when capturing)

* Overly long USB cables or sharing hubs with other devices

* USB speed parameter set wrongly.

The last is often worth checking - most cameras have this sort of parameter and SharpCap sets it to a value which gives slower frame rates but higher reliability. In the case of QHY the parameter is called 'USB Traffic' and you turn it down to try to get higher frame rates. Push it too far down and they may stop entirely.

Another possibility from the symptoms you describe is that the camera is seizing up entirely after a small number of frames - when the frame rate drops to the low level is the frame count still going up at all or is it completely stuck?

cheers,

Robin

So a bit more testing as it's forecast for snow tonight. 

 

Got 14.5 fps on the i7 desktop by dialing back the USB speed parameter to as low as it would go. Pretty good, not hitting the max 22 fps claimed by QHY but i never actually expected that to happen.

On the T300chi it stops completely there's no update to the preview image at all after a a number of frames. I ran the USBView tool from the windows debug kit and found that I wasn't able to get USB 3.0 speeds. I never registered as a USB 3.0 device. Not sure if that's a limitation of the port or if it is the cable.

If it's not an issue with not having the correct USB 3.0 OTG cable, I am not sure how I can fix the issue I can't lug my full tower out to the backyard. The wife may not take kindly to another laptop appearing in the house. :(

Link to comment
Share on other sites

@cotak

I have the ZWO version of this camera and like yours it is a little fussy about USB ports. On my indoor PC (Intel chipset USB 3 ports) it works great and I get the ~20fps over USB3. On my observatory computer (USB3 addin card) I did once have it working over USB3, but it is much more reliable over USB2 even if very slow. So I could suggest trying various USB related things on your laptop - ie different ports, using a USB2 cable, using a shorter cable, using a hub (either usb 2 or usb3). If all that fails then maybe see if QHY can help you over on their forums (I'm assuming that the same problem happens in their own software, so is more a driver issue than a SharpCap issue)

cheers,

Robin

Link to comment
Share on other sites

3 hours ago, rwg said:

@cotak

I have the ZWO version of this camera and like yours it is a little fussy about USB ports. On my indoor PC (Intel chipset USB 3 ports) it works great and I get the ~20fps over USB3. On my observatory computer (USB3 addin card) I did once have it working over USB3, but it is much more reliable over USB2 even if very slow. So I could suggest trying various USB related things on your laptop - ie different ports, using a USB2 cable, using a shorter cable, using a hub (either usb 2 or usb3). If all that fails then maybe see if QHY can help you over on their forums (I'm assuming that the same problem happens in their own software, so is more a driver issue than a SharpCap issue)

cheers,

Robin

It works fine as a capture only test using Nebulosity so the ASCOM driver seems to work with USB 2 mode. While it seems to completely freezes on Sharpcap.

It appears the USB port on the asus is hard to get working in USB 3.0 mode. It seems a common complain online. I'll see what laptop deals can be had over the holidays. If it's not too much money it's possible to get another one. 

In the mean time yes I will make a post to QHY to see what they might be able to do.

Link to comment
Share on other sites

@cotak

Have a look at your drivers for the USB 3 controller and see if there is a newer version or alternative version - see if you can work out the controller chipset manufacturer - the ones I know of are Intel, Via and Renesas. I've never had much problem with the Intel ones, but previously I've found a USB port from one of either Via or Renesas (can't remember which - sorry) misbehaved when it was using the Microsoft driver that comes with Windows 7/8/10 but worked fine when I found and installed the manufacturers driver.

cheers,

Robin

Link to comment
Share on other sites

20 hours ago, rwg said:

@cotak

Have a look at your drivers for the USB 3 controller and see if there is a newer version or alternative version - see if you can work out the controller chipset manufacturer - the ones I know of are Intel, Via and Renesas. I've never had much problem with the Intel ones, but previously I've found a USB port from one of either Via or Renesas (can't remember which - sorry) misbehaved when it was using the Microsoft driver that comes with Windows 7/8/10 but worked fine when I found and installed the manufacturers driver.

cheers,

Robin

The issue appears to be that the T300chi has a USB OTG port where the actual proper OTG adapter is hard to find. Some folks have purchased 20 cables to find one that sort of works.

So in the end I decided to pick up a cheap laptop with a proper USB 3 port. I don't want to spend money on 20 cables and pay for useless stuff that adds up to a significant part of a new laptop.

 

Thanks for all the help so far. I'll hopefully be able to use SC with the new computer without any issues.

Link to comment
Share on other sites

Hi Sara,

upgrade to SharpCap 2.9? I don't recall changing anything significant in the webcam or USB grabber handling code recently that should have caused that. Is your USB device still being recognized properly by windows (in device manager?)

cheers,

Robin

Link to comment
Share on other sites

Robin,

I'd like to revisit timestamping of video streams.  I'm pretty certain that you implemented a visual timestamp for formats that used uncompressed video by writing a timestamp into the video frame.  Though for the life of me I can't find the option to enable it in the GUI.

I believe it would be beneficial to use meta-data to record UTC (GMT) timestamps.

The SER file format stores the per frame timestamp in the frame trailer so that comes automatically:

Quote

Trailer starts at byte offset: 178 + 8_FrameCount x 5_ImageWidth x 6_ImageHeigth x BytePerPixel.
Trailer contains Date / Integer_64 (little-endian) time stamps in UTC for every image frame.
According to Microsoft documentation the used time stamp has the following format:
“Holds IEEE 64-bit (8-byte) values that represent dates ranging from January 1 of the year 0001 through December 31 of the year 9999, and times from 12:00:00 AM (midnight) through 11:59:59.9999999 PM. Each increment represents 100 nanoseconds of elapsed time since the beginning of January 1 of the year 1 in the Gregorian calendar. The maximum value represents 100 nanoseconds before the beginning of January 1 of the year 10000.”
According to the findings of Raoul Behrend, Université de Genève, the date record is not a 64 bits unsigned integer as stated, but a 62 bits unsigned integer. He got no information about the use of the two MSB.

The AVI file format is messier, but at least the file header allows a timestamp, however there doesn't appear to be any standard per frame timestamp metadata (though you can calculate a timestamp on replay for a frame based on the start timestamp, frame number and frame rate).  However I think there's a easy way to add timestamps in a fully supported way.  Pretty much all video formats allow you to interleave multiple streams, and the most common of these is the sub-title stream, so you could just encode the timestamp in text format (e.g. yyyy/mm/dd hh:mm:ss.uuuuuu) into the subtitle. This approach has the great advantage that almost all video players will support this.  Additionally you don't overwrite part of the image with the timestamp data which the great god Murphy guarantees will land right on top of the most crucial part of the image.

The advantage of using these approaches allows timestamps to be recorded for both compressed and uncompressed video streams.

Cheers
Dave

Link to comment
Share on other sites

Interesting points - made me go and look back at the code for timestamping frames.

The SER timestamps are added by SharpCap (and they have been for several versions now).

Looks like the timestamp applied to webcam frames is local time (I was expecting it to be UTC like all the other timestamps).

The other thing that I thought was done but couldn't find was to add a binary representation of the timestamp to the first 8 bytes of the frame when adding the readable timestamp - that would give a machine readable version of the timestamp even in AVI format. I obviously only planned to do that and never quite got around to it.

The subtitle thing is a neat idea, but I don't think I have enough fine grained control of the AVI file writing to merge that into the AVI as it is being created (or not without an enormous amount of work, anyway). I'd also be concerned about compatibility issues with perhaps some processing apps struggling to read more complex AVI files.

cheers,

Robin

Link to comment
Share on other sites

Quote

I don't think I have enough fine grained control of the AVI file writing to merge that into the AVI as it is being created

Depends - what library stack are you are using to write the AVI files?  I'm happy to do some research ...

Dave

Link to comment
Share on other sites

Now if you were writing MP4 files rather than AVI, you could write the PTS (presentation time stamp) for each frame at either of two accuracies.  The basic one has resolution of 1/90000 sec. and the high accuracy version 1/27000000 sec.

That "should" be good enough for anyone! 

Another good option (I think 1mS resolution by default) is to use MKV files and the H.264 codecs

Take a look at Haalis Media Splitter which supports both Matroshka and MP4 https://haali.su/mkv/  or the GDCL MP4 filters http://www.gdcl.co.uk/mpeg4/  I think both of these can be used with Directshow to render the stream to these container formats.

HtH
Dave

Link to comment
Share on other sites

Ah, compressed output formats and other container formats are out for several reasons - image quality and performance are paramount considerations and also the bulk of the processing tools that people use (Registax, Autostakkert, etc) won't be able to read them!

In v2.10 you will be able to save to SER format from webcams, which will mean that you can have your per-frame machine readable timestamps if you want.

cheers,

Robin

Link to comment
Share on other sites

  • 2 weeks later...

Hello Robin,

I have been attempting to write some scripts and have seen some success for controlling my ASI1600MM-C. I have written a simple one that takes a number of frames at an increasing number of exposure times to test linearity of the camera. Most of the captures work however, seemingly randomly, I get an error that indicates the capture file name extension doesn't match the output format. It is a very strange error.

Here is the script:

import time

SharpCap.SelectedCamera.RestartPreview()

numOfExposures = 2
exposureTimes = [1, 2, 3, 4, 5, 6, 7, 8]
gains = [200]

def linearityTest(numOfExposures, exposureTimes, gains):
	print "----------------------"
	print "Running linearity test"
	print "----------------------"	
	for gain in gains:
		print "Setting gain to %d" % gain
		SharpCap.SelectedCamera.Controls.Gain.Value = gain
		for exposure in exposures:
			print "Setting exposure to %d" % exposure
			SharpCap.SelectedCamera.Controls.OutputFormat.Value = 'FITS files (*.fits)'
			SharpCap.SelectedCamera.Controls.Exposure.Automatic = False
			SharpCap.SelectedCamera.Controls.Exposure.Value = exposure
			time.sleep(0.1)
			for i in range(numOfExposures):
				SharpCap.SelectedCamera.CaptureSingleFrameTo("d:\\linearityData\capture-%d-%d-%d.fits" % (gain, exposure, i))
				time.sleep(1)
			
linearityTest(numOfExposures, exposureTimes, gains)

Nothing seems particularly strange to me, my only thought is it has to do with waiting a proper amount of time before or after an exposure?

Also, is there a way to change the offset of a camera via scripting? I took a look at controls (print SharpCap.SelectedCamera.Controls) and didn't see anything for offset.

Chris

Link to comment
Share on other sites

Hmm,

the OutputFormat control has an Automatic option, which if turned on can change the output format when the exposure changes (ie it will go to a video output format for short exposures and a still format for long exposures), so try putting

SharpCap.SelectedCamera.Controls.OutputFormat.Automatic = False

somewhere at the start of the script.

If there is an offset control in the right hand panel then it will be in the controls collection, but it will not have a named property as it is camera specific rather than common across all cameras.

SharpCap.SelectedCamera.Controls.Find(lambda x:x.Name == "<Name Of Control>")

will find any control that is present by name

cheers,

Robin

Link to comment
Share on other sites

  • 2 weeks later...

I am using Version 2.9.3032.0 and ran into issues of freezing last night when trying to live stack using an ASI1600MC-C. Just running the program the image is fine at all resolutions but when trying to live stack the application would become unresponsive. I also tried lower resolutions and that did work once or twice but none of the higher resolutions worked. This is running with the camera connected to a 2nd generation compute stick running Windows 10 with a 3 foot USB 3 cable to a USB 3 hub to the compute stick. The Anker hub can run either powered or non-powered, currently non. I tried in both RAW8 and other modes but didn't seem to have any effect.

Using an 800x600 capture area did work but I would get error messages that the frame rate was too high. This happened even though the exposure was set to 8 seconds. I did note that the stacking indicated it was taking a bit over 6000ms to complete.

You can see the complete setup over on CN if that's of any help.

http://www.cloudynights.com/topic/561613-my-compute-stick-setup-for-eaa-bii/

I just did some daylight testing and it froze again at full resolution. The other thing of note is that the only way to end the program after it's frozen is via the task manager. Using RAW8 at these resolutions  (800x600, 1600x1200, 2328x1760, 2640x2640) it ran but, as expected, couldn't stack any frames due to no stars. At 3520x3520 it froze. Is this possibly a physical memory or architecture issue? It does work when running on my Windows 10 x64 laptop w/4GB RAM as opposed to the compute stick w/2GB RAM running Windows 10 x32.

Link to comment
Share on other sites

I was playing with Sharpcap to work out how best to capture some stills to feed into CCD Inspector.

CCD Inspector needs to know the X and Y pixel resolution information so it looks for the pixel size information in the FITS header:

XPIXSZ – physical X dimension of the sensor's pixels in microns (present only if the information is provided by the camera driver). Includes binning.
YPIXSZ – physical Y dimension of the sensor's pixels in microns (present only if the information is provided by the camera driver). Includes binning.

It also helps if it knows the FL so it can calculate arc-seconds.

It looks like Sharpcap doesn't include this in the FITS headers.   Is this something you can do (assuming the driver tells you, maybe a configurable value in some setting if the driver doesn't)?

Cheers, Dave

 

Link to comment
Share on other sites

@perdrix

What camera are you using? I recall writing code for the FITS pixel size headers to be set, but they only will be if the camera driver can tell SharpCap what the pixel size is.

@Tom M

Sounds like it may be hitting problems due to the amount of work in aligning such a big frame - how powerful is your CPU? (PS in 2.10 I have improved the performance of live stacking quite a bit, so the problem should be less pronounced).

@USSArleighBurke

The modes and resolutions you see come from the driver for your frame grabber. To get the 720x576 resolution you may have to go to the setup dialogs for your grabber (the Video Capture Pin from the Options menu). Usually there are some options in there that you can use to change the mode for the video grabber, but again it depends on the model. Try playing with the PAL/NTSC choices.

cheers,

Robin

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.