Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

sgl_imaging_challenge_banner_terminator_challenge_winners.thumb.jpg.6becf44442bc7105be59da91b2bee295.jpg

rwg

SharpCap - free Astro Webcam Capture Software

Recommended Posts

Hi,

I have a question about the new polar alignment tool (It works great by the way).  The first time I tried the polar alignment tool a mistake (?) I made was to start adjustments immediately after moving the RA axis by 90 degrees without first clicking next.  If one makes RA/ALT adjustment at that step, once the mounts mechanical axis has been determined, does sharpcap subsequently recompute the mounts axis of rotation (at which point it would be incorrect)? While I understand this was user error, I wouldn't have made adjustments at that point if it weren't for the PA tool showing recommendations on alt and az adjustments to make.  Each time I'd make an adjustment it seemed to suggest a new conflicting adjustment.  Running it a second time afterward showed an error of +30 arcmin.
 
If the PA alignment routine keeps:grabbing an image, plate solving and re-calculating the mechanical axis then might explain the odd behavior I witnessed.  Or... I was mis-interpreting what I thought seemed to be occurring.  I've used the PA alignment tool at least 4 (possibly more) times since then and make sure I click next and it has worked very well and been quite accurate.
 
In the event my observation/theory has some validity to it, I'd like to suggest that the tool not show the alt / az adjustments during the 'rotate RA axis' step.  Call it defensive coding :)

Hopefully this is helpful feedback and not wasting the author's time.

Kind Regards,

John

Share this post


Link to post
Share on other sites

@jogrady

I hope that I've understood you correctly and that the info below answers your question

There should be no problem if all you do is rotate the mount without clicking next - while you are on the page that is titled 'Step 1 - Capture First Image'. That's because all that SharpCap is doing at that point is solving each successive frame and throwing away any previous solutions - it doesn't remember the solution until you press Next. Basically all that would happen is that you'd need to rotate either further or in the other direction once you've pressed 'Next' to move to the second capture.

If you adjust the Alt or Az at any time before the adjustment page then I don't think that you'd get reliable results - the movement would throw off the calculation of the position that the scope axis is currently pointing too.

So, I think the conclusion is that if you do change the Alt or Az before getting to Step 3 then the guidance could be wrong - I take your point on hiding the adjustment instructions until 'Next' is pressed (alternatively you can check the 'autoadvance' option on the intro page).

@calan

Some of the things partial so far - for instance the separate heights for the bottom panel work but aren't saved yet if you close and re-open SharpCap.

cheers,

Robin

 

 

 

Share this post


Link to post
Share on other sites
19 hours ago, rwg said:

@jogrady

I hope that I've understood you correctly and that the info below answers your question

There should be no problem if all you do is rotate the mount without clicking next - while you are on the page that is titled 'Step 1 - Capture First Image'. That's because all that SharpCap is doing at that point is solving each successive frame and throwing away any previous solutions - it doesn't remember the solution until you press Next. Basically all that would happen is that you'd need to rotate either further or in the other direction once you've pressed 'Next' to move to the second capture.

If you adjust the Alt or Az at any time before the adjustment page then I don't think that you'd get reliable results - the movement would throw off the calculation of the position that the scope axis is currently pointing too.

So, I think the conclusion is that if you do change the Alt or Az before getting to Step 3 then the guidance could be wrong - I take your point on hiding the adjustment instructions until 'Next' is pressed (alternatively you can check the 'autoadvance' option on the intro page).

@calan

Some of the things partial so far - for instance the separate heights for the bottom panel work but aren't saved yet if you close and re-open SharpCap.

cheers,

Robin

 

 

 

Thanks Robin, that answered my question quite thoroughly.  My initial mistake was adjusting Alt & Az before the adjustment page because the adjustment instructions showed.  

Other than that initial mistake - I think the polar alignment tool is a smashing success.

The main reason I asked about the behavior is as another member on CN commented that he was getting conflicting direction after making Alt & Az adjustments.  I suggested it may been due to not moving to Step 3.  Of course, it's always best to confirm a 'hunch' with the author of the software.  I'll point that post on CN back to your response here.

Cheers,

John

 

Edited by jogrady

Share this post


Link to post
Share on other sites

Hi,

I was able to do some imaging under good dark skies. One night I tried my ASI 120MC with a 210mm Telelens and Sharpcap which worked before. On the field I had some technical problems like that SharpCap (most) always stoped working when I changed the exposure time (status bar was showing progress but no images came in). However I continued with restarting SharpCap often and unplug/plug the camera etc.

I then tried some live stacking and the preview of the stacked images was fine and nice so I was happy. However next day I see this.... The dark substract does not seem to worked on the saved images?! What did I wrong? I posted some weeks ago such a experiment with the Bodes and Cigar Glxs which worked just fine (minus the good sky). I saved as FITS.

Cheers,

Carsten

 

Herz_Stack_23.jpg

M31_Stack_35.jpg

M31_Stack_35.fits.CameraSettings.txt

Herz_Stack_23.fits.CameraSettings.txt

Share this post


Link to post
Share on other sites

Hi Carsten,

I haven't seen anything like that before - can you share the dark frame that you were using and a single frame capture too please (the dark frame alone would be a good start if you don't have a single frame capture).

thanks,

Robin

 

Share this post


Link to post
Share on other sites

Hmmm. I have (a bit in a anger) deleted all darks the next day :-/ Really deleted.

I will do some tests by the time soon.

Attached a result (only saved as jpg from Fitswork) from the former test. The only (for me) difference is that I (somehow accidentally) used 100% Gain for the bad images. But that should not matter I guess when the dark frame is ok?! For me it looks as if the preview was correctly dark frame substracted but not the saved/stacked result? But that makes no sense I guess.

The approx same amount of lights images shows also no bad artifacts, small stripes where the hot pixels are but nothing I could get rid of by stretching or taking more darks.

Best regards,

Carsten

Bodes_Zigge_Stack_135.jpg

Bodes_Zigge_Stack_135.fits.CameraSettings.txt

Share this post


Link to post
Share on other sites

@jogrady

thanks for passing the info on to CN - I rarely find the time to get over to those forums, so much appreciated.

@calli

The reason I was interested in the dark is that I was wondering if it was something to do with the colour in the dark - I tested with the built in 'Deep sky test camera' where you can add dark noise then take it out again in the dark subtraction and it all seemed fine in both the display and the saved files.

cheers,

Robin

Share this post


Link to post
Share on other sites

I have a ZWO ASI224MC...  can someone explain the difference between the different color space formats, as far as SharpCap is concerned?

I.E.   ... why or when would I want to use anything other than RGB24?

Share this post


Link to post
Share on other sites

RGB24 is standard colour, 3 colour channels per pixel, 8 bits per channel, 3 bytes per pixel.

RAW8 is the unprocessed values that come from the individual R,G and B pixels on the sensor - 8 bit depth still, but only one byte per pixel. A saved raw image will look monochrome with a funny fine grid pattern on it unless you view it with the right software that knows how to 'debayer' the raw image to get the colour image.

MONO8 is RGB24 turned to monochrome - 8 bits per channel, 1 colour channel, 1 byte per pixel.

RAW16 is like RAW8, but the full range of the A->D converter on the camera is used, depending on the camera this might be 10, 12 or 14 bits per pixel (all are stretched to 16 bits). This format is using 2 bytes per pixel.

 

In general, RAW8 is the best format for high speed imaging - you have to use the right post-processing software that understands the RAW format, but the advantages are worth it - including

* capture files 3 times smaller than RGB

* often faster frame rates

* conversion to colour (debayer) can be done in post-processing using slower but higher quality algorithms.

 

If you are doing long exposures (1s or more) then change to RAW16 - you will likely want the extra dynamic range that is given by the greater bit depth.

cheers,

Robin

 

  • Like 2

Share this post


Link to post
Share on other sites

@rwg is there any benefit using MONO8 (camera internally convert) over converting a RAW8 to grey while postprocessing?

Carsten

Edited by calli

Share this post


Link to post
Share on other sites

For the ZWO cameras at least I think that MONO is done like this

Camera => RAW => PC => Driver => convert to RGB => convert to Mono => SharpCap

so actually MONO is slower than both RAW and RGB in terms of maximum frame rate (tested on ASI174MC).

cheers,

Robin

  • Like 1

Share this post


Link to post
Share on other sites

Hi Robin,

When I was trying to sort out the correct settings a couple of weeks back for my ASI1600 in SharpCap, you suggested depayering in DSS with the BGGR format.

That does give me colour, but with a green tinge.  The best setting I think is GRBG, but that has a red tinge.  How do I determine the correct debayer settings? 

Thanks,

Ben

Share this post


Link to post
Share on other sites

Take a short sample image of some everyday colourful object.

One of the settings will render the image more or less right, all others will be way out (none will be spot on as an astro camera doesn't have auto white balance). You might find using a red, green and blue target makes it easiest.

  • Like 1

Share this post


Link to post
Share on other sites

Yes, what Neil says is the best trick to finding the right bayer pattern. Two will still look blocky, two will have smooth colours, but only one of those will have the red and blue the right way round.

Another trick is to use a red laser pen - don't shine it straight at the sensor as I have no idea if it could cause damage, but at a sheet of paper over the sensor maybe. You'll know you've got the right pattern when it comes out red :)

Robin

  • Like 1

Share this post


Link to post
Share on other sites

But if I'm doing everything in SC (Live Stack), and then saving a processed image for final tweaking... does it matter which format I use? Does one give more bit depth than another?

The couple of times I tried a RAW format in SC while live stacking with the debayer option checked...I ended up with the screen door grid. And, I didn't see much difference in captured detail or color.

Share this post


Link to post
Share on other sites

@calan

If you are live stacking then RAW16 is the best bet as it gets more dynamic range in the individual frames so in theory there might be a bit more of the faint stuff.

In Live Stacking the choice between RAW8 and RGB doesn't really matter as SharpCap has to debayer the RAW image to stack it. Also the frame rate is likely to be low enough that the performance differences don't matter either.  If you are saving the individual frames too, then you might want to choose RAW8.

Robin

Share this post


Link to post
Share on other sites

Minor issue while running an ASI1600MC-Cool-  I wanted to flip both vertical and horizontal orientations and selected 'Both', what ends up happening is the debayer color pattern changes and one has to force select the correct one.  Ver. 2.9.2895 Win 7 64bit

Share this post


Link to post
Share on other sites

Another issue when running the ASI1600 in bin 2x2 there is horizontal banding (railroad track like) which doesn't appear to be evident in bin 1. Image attached.  This has been something that has existed for quite sometime in all the recent versions I've used.  Is this something Sam needs to address?

Don

 

NGC6992_Stack_30.png

Share this post


Link to post
Share on other sites

Hello,

 

I have been struggling with my ASI224MC for one whole evening and found the root cause of the issue : when I set exposure > 1 second and I leave "High Speed Mode" on, my camera will only return a dark image. Sharpcap is also a bit lost. If you have a look at the frame count at bottom right hand-side, the display is quite odd : 4.7 s spent / -3 s left (minus 3 sec) for an exposure of 1.7 seconds.

 

If I set the "High Speed Mode" Off, then everything runs fine.

 

I'm using the latest version of Sharcap (2.9)

 

Regards,

 

Pat

Capture d'écran 2016-09-08 17.53.00.png

Edited by psaj

Share this post


Link to post
Share on other sites

@DonBoy

The banding issue is supposed to have been fixed in the ZWO SDK dated 28th July (which first appeared in SharpCap 2.9.2739). I have a new version from them today which will be in a new build in a day or so, so maybe try that before going back to Sam. The Bayer pattern thing is one of those things that I keep thinking I've finally nailed and then it falls over again. I'll have another go :)

 

@psaj

Good spot to discover that it's down the to high speed mode being on - the -ve number in the time left for the frame just means that a frame is overdue - for some cameras the number goes negative during the readout period without any ill effects, for others it can mean that something bad has happened.

As I understand it the high speed mode is something you probably wouldn't want to use in combination with longer exposures as it reduces the accuracy of the A->D conversion (to 10 bits).

cheers,

Robin

Share this post


Link to post
Share on other sites

Robin,

I've come across some unusual behaviour in the latest verison (and maybe previous versions of 2.9 as well).

Just want to check with you ythat I'm doing things correctly.

i use an integrating video camera (an Astro Video Systems DSO-1) via a frame grabber that hust identifeds itself as 'OEMDevice'.
Obviously it supplies images to sharpcap at the usual 25or 30 fps.
It is set to integrate frames and provide an updated image every 6.4 seconds. (x64 integrations of 1/50th on chip and then a further x5 factor in the camera firmware).

I am trying to capture a sequence of images in .png format so that I can process them later in DSS and/or pixinsight (haven't tried you livestacking yet).


i) I leave 'frame divisor' set to 1
ii) filenames set to 'sortable date format'


and then, in the start capture menu I set:-
ii) single fram capture
iii) tick 'capture a sequence of images'
iv) set sequence length to 30
v) set iinterval between captures' to 7 (I notice that I can't set decimals of seconds)

 

when the capture sequenbce has finished - I end up with a single frame.

Looking at the progress bar at the top of the screen it appears that sharpcap is overwriting the first frame captured with the latest frame captured -
it doesn't seem to be updating the filename with the latest date/time.

I've also tried the following:-
i) using the snapshot button - works OK, if I press the snapshot button every 7 second - I get the sequence of files that I expect -a bit tedious though :-)
ii) If I try to capture 30 frames rather than a single frame, still in a sequence - I get a series of avi files - each of 30 frames, with correct filenames - as expected
iii) Tried it with a bog standard webcam - Logitech - same problem.

Any thoughts?

I guess as a work around I could use method ii) above and capture single frame avis? (or maybe revert to 2.8 - I'm going to that that one shortly)

As far as I remember this used to work in v2.8 - but you put all the .pngs in separate directories ( I remember asking you about thisone a while back) and you said that you were 'tidying up' this in 2.9?

 

thanks in advance for all your great work

Neil

Share this post


Link to post
Share on other sites

@ngwillym Sounds like a clear bug - I'll look into it. I tried to tidy up file naming in 2.9 to avoid having lots of single frame snapshots called '00001.png' - I expect this is an unintended side effect.

You can keep 2.9 installed alongside 2.8, so you can switch back and forwards easily depending on what features you need, but I am expecting to put out a new version early next week - hopefully can fix this by then.

thanks,

Robin

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.