SharpCap Forums

Hi Robin,

Recently, one target gave me poor guiding, which made too many frames get rejected. Later I re-balanced the scope and all was well. But in the meantime, I simply disabled the checks to Pause stacking if guiding lost, but kept Dither going ...


The problem is that it included all the 2s dithering frames in the "saved stack" as well. I would think that with dithering enabled here, it should not stack the frames shortened during dithering, even if other guiding issues do not veto saving to the stack.

In this case, I probably should have selected "Save except when paused/dithering". But I still think that the 2s frames should never get saved, as they are not the selected exposure.

Cheers, Chris.

Hi Robin,

The plot thickens. I returned to my Tarantula nebula data, which was around the new moon, and everything appeared to work very well, acquired with these settings in Live Stack ...


It was then processed by using the Folder Camera to re-run Live Stack and tweaking the FWHM filter. All seemed good until I noticed the Brightness plot showed severe dips to very low Brightness (and a dubious period in the middle, which may have been thin clouds and were caught by increased FWHM) ...


Checking a few of the low Brightness frames, it is clear that a few of the 2s dither frames have slipped through into the "Saved Stack" frames. With 60s exposures and dithering every 3 frames, there would have been about 20 dither periods during the run, not just the 3 we see here. It seems that under certain circumstances that some, but not all, of the 2s dither frames sneak into the saved Stack set and add noise.

Have I missed something here, perhaps in the setup?
Cheers, Chris.

Hi Chris,

I think the answer is that there is a bug in there somewhere that causes the short frames to get into the stack under certain conditions that I don't yet understand. It is probably that it only happens with particular settings *and* that a frame has to arrive at just the right (or wrong) time compared to the dithering process to bypass the normal checks.

I will have a dig through the code to see if I can spot any way that this could happen - the last time I looked at this sort of report I tried to reproduce the issue by stacking and couldn't make it break. Can you just confirm what build of SharpCap 4 you are running - just so I can be sure to be looking at the right code.

cheers,

Robin

BTW... if you put SharpCap into Still mode then the problem should go away - in still mode when live stacking, no images are taken during dithering.

cheers,

Robin

Hi Robin,

The stacks were acquired using SC 8334 and the reprocessing using the latest 8395.

Good idea to try it in Single frame mode. I have been meaning to try that.

But why not just switch to Single frame mode when Live Stack is selected? Since Live Stack will ‘trigger’ frames anyway, it behaves to all intents and purposes like the free-running live mode anyway.

One of the things I like about SC is the live camera updates. But going into Live Stack should put acquisition completely under single frame control, I would think.

Cheers, Chris.

… the same could be said for any “programmed sequence” like acquiring Darks and Flats.

Why not switch to Single frame mode and avoid collecting 31 frames when you ask for 30, for example?

Cheers, Chris.

Hi Chris,

it's a good idea, and would definitely make sense except for the fact that not every brand of camera works 100% reliably in both modes Some cameras work much more reliably in one mode or the other, so automatically switching between them is something I worry about. It's certainly something that could be controlled of an option perhaps.

cheers,

Robin

Hi Robin,

Another good sky last night, so tried more Live Stack (now SC 4.0.8395). Again, it appears that some 2s frames get stacked, but not all. I belatedly enabled the Brightness filter to remove anymore of them (used coarse 80% threshold). I Dithered every 3 frames, so many dithers went OK (around 25-30 dithers), with no 2s frames stacked. But about 5 here slipped through and gave a long series of 2s frames each during dithering.


Reprocessing data today using Live Stack and Folder Camera again, so I can tweak FWHM and histogram, I found some other odd things. Firstly, the total exposure stays close to zero (should be 119 minutes). I had switched to saving FITS files, and each shows a valid exposure.


Comparing FWHM filter and Brightness plot: The odd frame that gets filtered (above 7.1 FWHM) consistently shows higher Brightness. It seems like the FWHM measure is affected by brightness and records larger FWHM with an increase in signal. May be a bias, e.g., caused by how background is subtracted?


Flats seems to be applied to each frame, prior to stacking (can’t just select that after stacking is done, as for histogram controls – needs to be rerun). But it’s really a post-processing correction in many ways, like histogram controls. And applying it to each frame may have strange effects on Poisson statistics. What's the thinking behind applying the Flat to each new frame increment? Could it be part of the final "viewing/ rendering" transformations?

Cheers, Chris.

P.S. I did try Live Stack in Still Mode, but some weird things happened. Trying to exit Live Stack for a new focus, most tool bar menus were ghosted, including "Live View". I was stuck. Only "Stop Capture" was available, which did not help. I had to close the camera and open it again.

Oops, sorry, disregard the Flats comment/ question.

Of course with movement and Dithering in particular, the pixel positions move around and so the ONLY time the Flat can be applied is for each frame.

Cheers, Chris.

Hi Chris,

so hopefully the update out later today will finally stop the 2s frame problem (knowing my luck it will stop all the other frames stacking too!!!).

The link between FWHM and brightness is not surprising in a way - both figures come from the stars being detected in the frame, and if something affects the star detection - maybe thin cloud or a guiding glitch or something - then it can change the set of stars being detected and therefore cause changes to both FWHM and brightness. I guess in theory you could track individual star brightness/FWHM values through all frames to compensate for this, but the code right now just keeps track of the aveage across whatever stars happen to be detected.

I also notices the missing value for accumulated time when using the folder monitor camera the other day - haven't had a chance to look into it yet.

cheers,

Robin