Jump to content

Banner.jpg.b83b14cd4142fe10848741bb2a14c66b.jpg

SharpCap - free Astro Webcam Capture Software

rwg

By rwg
in Imaging - Discussion

Recommended Posts

  • Replies 1.5k
  • Created
  • Last Reply
rwg

rwg

Posted
  • Author
Posted

@Geremia,

I don't think going between the Genicam driver for the basler cameras and the direct driver in the same run of the application is a good idea. The genicam directshow driver doesn't seem to release the camera properly straight away, so you can see odd issues when trying to re-open the camera. Do you get any problems if you just use the direct basler driver?

Re: Date format

SharpCap just uses the system date formatting for the file name. So, if you go to regional settings ('Change the date, time or number format') in the control panel and select 'yyyy-mm-dd' for the short date format you should get the file naming you want. Of course you'll have to remember to change it back afterwards :p

Robin

Link to comment
Share on other sites
peterthebike

peterthebike

Posted
Posted

Re: Date format

SharpCap just uses the system date formatting for the file name. So, if you go to regional settings ('Change the date, time or number format') in the control panel and select 'yyyy-mm-dd' for the short date format you should get the file naming you want. Of course you'll have to remember to change it back afterwards :p

Robin

Robin,

Thanks for the simple way of solving that.

Link to comment
Share on other sites
rwg

rwg

Posted
  • Author
Posted

Ah, OK, never heard of that program before. I can see roughly what is going on in your error trace - it's trying to set one of the parameters of the camera to a value that is out of range. Not sure *which* value it is though. PM me your email address and I will send you a test build with some more logging in it. Might take me a day or two to sort it out for you though.

Robin

Hi Robin,

I apologize if I caused confusion, I'm talking about "Genika as program" not Genicam driver

Geremia

Link to comment
Share on other sites
tonyowen

tonyowen

Posted
Posted

Robin,

I have a (Morgan) spc880nc webcam (not modified in any way) that is run on a vista laptop and identified as a Philips TouCam Pro Camera Video. Using SharpCap v1.2.0.304 I have the choice of I420 or IYUV color space (??) {I'm uncertain if the coding refers to color space or compression, so I'll use the phrase color space}]

The same webcam run on a desktop Win7 computer is identified as a spc900nc Camera. Using SharpCap v 1.5.0.311 I'm offered I420, IYNU or YUY2 color spaces.

[i forget why I have different versions of SharpCap]

The vista computer is connected to my telescope take the avi files

I process the avis on the win7 computer.

However, when I use pipp to process my avis get the message that RGB242 is the preferred color space.

How can I get more color space options?

What are the practical differences between RGB242, I420, IYUV, YUY2?

regards

Tony

Link to comment
Share on other sites
rwg

rwg

Posted
  • Author
Posted

Have a look here for some more info on the colour spaces :

http://stargazerslounge.com/discussions-scopes-whole-setups/115344-yuy2-1420-a.html

Basically the RGB24 colour space is uncompressed, the others you list are compressed by storing colour information less frequently than brightness.

What you are seeing in SharpCap is a list of the colour spaces that you can use for transferring data from the camera to the computer. As you'll notice there is no RGB24 in the list, so there is no way to get the data from the camera in uncompressed format for the SPC900. So, by the time that you get the data on the computer some of the colour information has already been lost due to the compression. There's no way to get this back, and there's no point in saving the output avi to RGB24 as it would just be bigger, but wouldn't contain any more information.

More generally, SharpCap deliberately doesn't offer a way to change the colour space/compression of the output AVI to be different from the capture format. There is no good reason to do this. There are good reasons not to do this - recompressing already compressed audio or video data with a different lossy codec is a *really* bad thing to do, because now your output file has artifacts from two different lossy compressions in it rather than just one.

tl;dr - don't worry, just use YUY2 which is the best of the bunch for the formats supported by the SPC900.

Robin

Link to comment
Share on other sites
rwg

rwg

Posted
  • Author
Posted
Or you can change your webcam to produce unbayered image fields, which contain one intensity value for each pixel and then do the debayering yourself once you're through the USB1.1 bottleneck.

WcRmac - Description

Themos,

my experience of this is that it works _really_ badly. The trouble is that the SPC900 uses some pretty hefty compression on the USB 1.1 link. 640*480*5fps*16bpp(YUY2) is 24 Mb/s, compared to the 12 Mb/s bandwidth available.

The compression in use seems to be both temporal (between frames) and spatial (loss of fine features). Unfortunately the compression doesn't switch off in raw mode. However in raw mode instead of the image changing smoothly there are big differences from pixel to pixel as some are the red value, some the green and some the blue. These differences get smoothed out by the compression, so the final debayered image is pretty miserable quality. It also gets even worse as you up the frame rate from 5fps to 10 or above.

In my opinion (controversy coming up...) the SPC900 is so crippled by its USB 1.1 interface that it's only really worth using today for the ability to mod it for LX mode. There are plenty of better webcams available today which are more suited for high rate planetary/solar/lunar captures (MS Lifecam Cinema, etc).

Robin

Link to comment
Share on other sites
themos

themos

Posted
Posted

At 5 fps, you don't have to compress at all if you're only transmitting 8 bits per pixel. The webcam where I've tried this on is the older ToUCam Pro (PCVC740K) and I run it at 5fps. Perhaps the SPC900NC does things different. I will experiment to verify any untoward effects but I remember one of my best captures was with this debayering OFF mod. We need some way of benchmarking this without relying on atmospheric seeing. Can you think of anything?

Link to comment
Share on other sites
themos

themos

Posted
Posted

If you don't debayer, you are only getting the L value that the pixel produces: 8 bits.

Or you can debayer, produce three values (using neighbouring pixel L values anyway), and then try to compress them for the USB1.1 bottleneck. Which sounds really stupid, doesn't it?

Link to comment
Share on other sites
riklaunim

riklaunim

Posted
Posted

I checked QHY5 recently via the ASCOM driver and it still doesn't work (the image shows some crazy pixels). Aside of PHD I didn't seen any other ASCOM app correctly imaging with QHY5 (Nebulosity2 also broken).

I'll try to post an example image from SharpCap later.

Link to comment
Share on other sites
rwg

rwg

Posted
  • Author
Posted

Interesting to see what the image looks like - there are a few things that the ASCOM driver might be reporting incorrectly that could cause problems - thinking here of the width or height of the image or the 'MaxADU' which is the maximum pixel value.

Robin

Link to comment
Share on other sites
JamesF

JamesF

Posted
Posted

If I might revisit the date format for a moment, it might be hice if it were possible to specify the entire format of the filename, so you could perhaps do something like:

filename format = %n-%Y-%m-%d.%h:%m:%s

where %n is the filename entered in the box at the top, and hopefully the rest are obvious. This would then have ".avi" or ".camera_settings.txt" appended for the relevant files.

The other think I'd personally like to have is a 125% zoom option. 150% is too big to fit on my laptop screen without scrollbars and I'd really like to be able to have the image as large as possible without scrolling.

James

Link to comment
Share on other sites
riklaunim

riklaunim

Posted
Posted
Interesting to see what the image looks like - there are a few things that the ASCOM driver might be reporting incorrectly that could cause problems - thinking here of the width or height of the image or the 'MaxADU' which is the maximum pixel value.

When I get home from work I'll make the pics. From what I know QHY5* uses 10 bit A/D.

Link to comment
Share on other sites
riklaunim

riklaunim

Posted
Posted

Here are pics from QHY5 + Latests sharpcap. When overexposed or close to it the image goes black. When camera is covered there is a chance to see something (q1.jpg) - but it's not very responsive or correct.

I also checked what values it returns when saturated (Clipboard08) - 255

post-18118-133877740401_thumb.jpg

post-18118-133877740407_thumb.jpg

post-18118-133877740412_thumb.png

Link to comment
Share on other sites
rwg

rwg

Posted
  • Author
Posted

Hi Tony,

nothing much specific that I can work out from the logfile except that SharpCap was trying to start the camera and it didn't want to play. First thing I'd recommend is updating from 1.5.304 to the latest version to see if that helps - lots of bugs have been fixed recently and maybe one of the fixes cures this problem.

If that doesn't help then In best Windows tech support fashion I'd first recommend restarting the program (and make sure you've only got one running), then unplug and replug the camera and finally if that lot doesn't work then reboot.

If it happens repeatedly and/or you spot a pattern in when it happens let me know as more info might give me something to go on.

cheers,

Robin

Link to comment
Share on other sites

Archived

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

Go to topic listing

  • 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.