SharpCap - free Astro Webcam Capture Software

[calan]

6 hours ago, rwg said:

Can you grab a screenshot of the message? The wording seems to indicate that it's not coming from the SharpCap code. It may be that the Meade driver isn't supporting the way that SharpCap tries to move the mount (the MoveAxis command). Calling ASCOM a standard is a bit of a joke as there are usually 3 ways to do anything and some manufacturers support option A, some option B and some option C. Lots of them also get things subtly wrong, just for fun. Grrr

Robin

Robin, it's a hard crash (SharpCap exits after clicking a move button).

Here is the dialog:
 

[rwg]

On 20/08/2016 at 13:57, larryh said:

Robin, here's a couple more examples taken last night.  These are raw frames from video.  Sharpcap seemed to be finding a reasonable number of stars, usually more than 10, but could not solve.

[snip]

Hi Larry,

I think I understand a big part of the problem with these frames now - the pixels are not quite square, which is throwing the plate solving off. I have some new code I am working on that improves plate solving a lot, but even that was failing on these frames. Then I tried resizing the images (make them about 9% narrower) and suddenly it works nicely. Haven't had a chance to try with the old code yet, but it might well help there too. Have you got any way of adjusting the aspect ratio (changing the grabber resolution?) to give pixels that are square?

thanks,

Robin

 

[larryh]

4 hours ago, rwg said:

Hi Larry,

I think I understand a big part of the problem with these frames now - the pixels are not quite square, which is throwing the plate solving off. I have some new code I am working on that improves plate solving a lot, but even that was failing on these frames. Then I tried resizing the images (make them about 9% narrower) and suddenly it works nicely. Haven't had a chance to try with the old code yet, but it might well help there too. Have you got any way of adjusting the aspect ratio (changing the grabber resolution?) to give pixels that are square?

thanks,

Robin

 

Robin,

   Thanks for the research.  I did realize that my pixels were not square, but I thought that the image was still proportionally correct.  But now I'm scratching my head as to how that could be so.  Perhaps when the analog signal is created in the camera the non-square pixels are taken into account to produce a proportionally correct image.  I'll have to check next time I'm out, but I think my framegrabber makes a 720x480 image from the analog signal.  If the image is not proportionally correct, then why would the Astrometry site be able to solve?  There is a parameter on that site that allows for star misalignment that I've been setting at 5 pixels, but that's quite a bit less than the 9% adjustment you needed to make.  Does your solution match the Astrometry solution when you get it to work?  Anyway, I will look into what my options are in the frame grabber.

    thanks,

      Larry

[larryh]

7 hours ago, larryh said:

Robin,

   Thanks for the research.  I did realize that my pixels were not square, but I thought that the image was still proportionally correct.  But now I'm scratching my head as to how that could be so.  Perhaps when the analog signal is created in the camera the non-square pixels are taken into account to produce a proportionally correct image.  I'll have to check next time I'm out, but I think my framegrabber makes a 720x480 image from the analog signal.  If the image is not proportionally correct, then why would the Astrometry site be able to solve?  There is a parameter on that site that allows for star misalignment that I've been setting at 5 pixels, but that's quite a bit less than the 9% adjustment you needed to make.  Does your solution match the Astrometry solution when you get it to work?  Anyway, I will look into what my options are in the frame grabber.

    thanks,

      Larry

A little more info...the specs on my chip are that it has a pixel size of 5x7.4 um and a resolution of 976x494, therefore an aspect ratio of 4880x3655.6 which is very close to 4:3 (I guess standard NTSC format?).  If I am indeed using the framegrabber to convert that to 720x480 (will check tonight), that is a 3:2 aspect ratio and so would distort the frame as you said (not tall enough, or too wide depending on how you want to look at it).  It looks like it should be more like 720x540 or 800x600.  I do recall that there were other choices for the framegrabber resolution but I don't remember what they were (not sure how I ended up picking 720x480).  I will report back when I know more.

[rwg]

@larryh

Yes, I did some more digging too - actually the ones that had the wrong aspect ratio were the early frames that Astrometry.net couldn't solve either (and I guess that's why). I need to test some of your later frames now, but I expect they will work with my new solving code. Trouble is the new code doesn't seem to work for the Southern Hemisphere yet - probably lost a minus sign somewhere

cheers,

Robin

 

[rwg]

Ooops, no, your newer frames only solve on Astrometry because of your allowance for star position errors. Once again a 10% shrink in the X direction gets those newer frames to solve nicely as long as more enough stars are found.

Let me know if you can't fix this in the camera settings - I could always add a UI control to allow an adjustable stretch to be applied.

cheers,

Robin

[calan]

Just in case this helps...

I have a Mallincam Xtreme (NTSC video), and my VC500 frame grabber formats it's output at 720 x 480. I couldn't get any of those images to solve with Plate Solver, Astrotortilla, or astrometry.net no matter what I tried....  until I resized the photos to 640 x 480. Once I did that, everything solved with no issues at all.

[larryh]

3 hours ago, rwg said:

Ooops, no, your newer frames only solve on Astrometry because of your allowance for star position errors. Once again a 10% shrink in the X direction gets those newer frames to solve nicely as long as more enough stars are found.

Let me know if you can't fix this in the camera settings - I could always add a UI control to allow an adjustable stretch to be applied.

cheers,

Robin

Yes, I just checked (indoors, not through the scope yet) and I can select a 640x480 resolution instead of 720x480 in Sharpcap and the image changes shape as desired.  I will test polar alignment again next time I'm out.  I have very high hopes!  The embarrassing thing is that I've been recording images with a bad aspect ratio all this time.  I'm wondering if this might also improve the "roundness" of my stars.  I'll find out soon.  Thanks for all your help Robin!

[calan]

Can someone please explain the FWHM filtering in live stack?

I'm guessing that this would allow me to filter out frames when clouds roll over or it turns hazy. I'm imaging a a dark nebula right now, and the FWHM values are hovering right around 4.2 to 4.7. So, if I set the maximum to say...4.8, will that cause it to skip frames if it gets hazy?

In other words... what causes the FWHM to increase? Would clouds do it?

If I'm correct, that is an excellent tool.

EDIT:

After some experimenting, it appears that the FWHM filter works great to cull out bad frames due to wind gusts and anything that causes the stars to be distorted. But, it doesn't help if everything becomes dim due to a passing cloud.

So what would be cool is if there was a minimum value that could be set as well.

[rwg]

@calan

Yes, the bad seeing filter was the original intention. I'd have expected cloud to also increase the FWHM due to the blurring effect it has, but perhaps the dimming has the opposite effect? I'll have to have a think about the cloud problem to work out the best way - it might be better to have some sort of brightness drop threshold.

cheers,

Robin

[calan]

Thanks Robin.

Did you see my post up there ^ with the error messages on the Meade driver that you requested?

[rwg]

Hi @calan

I looked into the Meade ASCOM thing last night and it looks like there's not a great deal I can do. I found a few threads on other forums discussing the same issue - that MoveAxis isn't supported by any of the Meade ASCOM drivers. For instance

https://www.otelescope.com/index.php?/topic/51-backyardeos-and-meade-lx200gps-ascom-control/

MoveAxis is the way that SharpCap tells the mount to move in a particular direction (and with most mounts you can pick varying rates too). With the Meade drivers it looks like the only option is to tell it to Slew to another set of co-ordinates (RA/Dec or Alt/Az, depending on the mount), which isn't really the same.

All I've been able to do is to stop SharpCap from crashing when it encounters that situation - instead it should just show a message that says (effectively) 'sorry, I can't work with this mount'.

cheers,

Robin

 

[calan]

Robin,

Why does that ASCOM driver work with other software, including the POTH hub?

The smoothest operation is through APT,... but I hate having to have that whole program open just to move the scope (and sometimes plate-solve), when SharpCap does everything else so well.  

(Wonder if I can get the Meade Classic 200 and LXD75 users to help me fund a workaround?  lol)

[rwg]

I presume the other programs must be hacking around with starting a slew then aborting it when you let go of the button - for instance start a slew toward the NCP if you press 'N'. Quite how you could control the speed is a mystery to me though. The problem seems to be that there are about 4 different Meade ASCOM drivers, none of them official and all of them have flaws/drawbacks/are missing functionality/are no longer updated/etc.

If you can find an ASCOM driver that supports MoveAxis then SharpCap will happily use it.

cheers,

Robin

[bendavidson]

On ‎23‎/‎08‎/‎2016 at 23:06, rwg said:

@bendavidson

You need to tell your stacking software (DeepSkyStacker?) to debayer the frames to turn the mono image with the grid effect into a proper colour image. DeepSkyStacker can be told to do this with FITS input images (look in the Raw/FITS settings). With PNG frames you might need to pre-process them in PIPP into colour frames.

 

Thanks Robin.  I couldn't get PIPP to work so started again - saved subs as FITS files from SharpCap, then told DSS to debayer them -  No improvement though - still getting just greyscale final results.  Does this setting look right?

 

[Stub Mandrel]

Don't Panic! All DSS stacks look like that until you play with the curves and possibly increase the saturation.

This is an image as stacked by DSS (in this case the histogram was further to the left, but you can see there is little detail or colour (the red cast is partly because the camera is 'astro modded':

Now here's the file stretched in DSS and ready for proper processing (this is a quick and dirty, I would normally take more care and perhaps not stretch as much as this, but I want to emphasise how much the image changes when stretched -yes this is the same picture as the one above!):

These are typical settings I use in DSS, the 1% slope give the maximum stretch and needs to be aligned with the 'interesting' part of your data - move the control at '19.9' left or right until the curve starts rising at the left of your histogram. Doing this in DSS uses the full 32-bit stack data so when you save it as a 16-bit tiff for further work you have as much data as possible preserved - if you did this to a 16-bit tiff in photo shop the result would be noisier. Don't make the final number too high or the stars will get black rings on them.

And finally after processing in photoshop to improve contrast and bring out the colour:

[rwg]

Those are the right settings for forcing Debayer in DSS, but I do wonder - it does say '16 bit FITS files' - are you capturing at 16 bit depth? If not it might be that DSS is ignoring the settings?

Anyway, the settings to adjust in PIPP are these ones if you have no joy with DSS

Cheers,

Robin

[bendavidson]

2 hours ago, rwg said:

Those are the right settings for forcing Debayer in DSS, but I do wonder - it does say '16 bit FITS files' - are you capturing at 16 bit depth? If not it might be that DSS is ignoring the settings?

Thanks Robin - 

I'm not sure - I've used the settings you suggested in this post:

On 8/21/2016 at 19:49, rwg said:

@bendavidson

Ok, let's check a few things .... Are you using RGB24 mode or RAW8 mode (RAW8 recommended).

cheers,

Robin

I think there was also a Raw16 mode - would that be better?

 

[bendavidson]

Thanks Neil.

I'm pretty sure I understand what you're saying - I have been stacking and using curves in CS2 for a couple of years so know that's what should happen - but the final image DSS saves from the SharpCap subs appears to have no colour.  The SharpCap subs themselves seem to have no colour.  Seems like for some reason the debayering is not working.  Here's an example of a single subframe and the image settings from SharpCap.  I expect there's something obvious and daft I'm doing wrong, but I can't spot it!

Capture_0004.fits

CameraSettings.txt

[rwg]

Your capture file is only 8 bit, so DSS isn't debayering it for you. You could go for RAW16 and re-capture, or you could work with the data you have by using PIPP.

I got your FITS file to debayer in PIPP with the following.

* Add it to the source files (you can add multiple files here)

* Go to the input options tab, Tick the Debayer Monochrome Frames option and choose BGGR.

* Go to output options tab, select fits output.

* Go to the do processing tab, click start processing

That creates a colour FITS file you can open in DSS.

cheers,

Robin

 

[bendavidson]

49 minutes ago, rwg said:

Your capture file is only 8 bit, so DSS isn't debayering it for you. You could go for RAW16 and re-capture, or you could work with the data you have by using PIPP.

I got your FITS file to debayer in PIPP with the following.

* Add it to the source files (you can add multiple files here)

* Go to the input options tab, Tick the Debayer Monochrome Frames option and choose BGGR.

* Go to output options tab, select fits output.

* Go to the do processing tab, click start processing

That creates a colour FITS file you can open in DSS.

cheers,

Robin

 

Thanks Robin.

I've got SharpCap saving in Raw16 and I think DSS can now use that data.  I'll check again once I've got clear skies, but I can see colouration on the hot pixels coming through.  I'll use PIPP with those settings above if something goes wrong though.

Really appreciate all your help.  

While I think of it, why BGGR  rather than the other options?

Thanks Robin.

[larryh]

Robin, you're a genius!  I finally had success with polar alignment last night.  With my images sized to 640x480 it worked quite nicely and had no problem with solving.  It is a terrific capability.  I apologize that you were actually troubleshooting my setup rather than any issue with your software.  Thanks again for all your help.  -Larry

[rwg]

@larryh

Great news - glad we worked through it otherwise I wouldn't know that the aspect ratio problem existed and would have spent ages trying to get solutions for frames that would never have worked!

cheers,

Robin

[DonBoy]

Robin,

New version 2.9.2869 hard crashes when I click on SharpCap Settings under File.  I'm running Win7.

 

Don

 

[rwg]

@DonBoy

oops!

If you check back now you'll find build 2877 which fixes the issue above - thanks for the quick report.

cheers,

Robin