FWHM is always 0 for first live-stacked frame

[lowenthalm]

As its full moon time, this means it's also time to update to the latest SharpCap and test it. The update to the 2024-07-15 release generally went smoothly, with some nice new features checked out (thanks for keeping them coming!), and only one glitch that I noticed in live stacking related to FWHM.

My live-stacking code checks FWHM after the first frame of a live stack is captured and uses this as a hint to setting the initial FWHM filter setting using Python code, then tunes the FWHM filter further several frames as live stacking continues. This broke spectacularly with the latest update, as now SC seems to always record the first frame as having a FWHM of 0! After starting a live stack, I came back to my computer after a few minutes and discovered it rejecting every frame that wasn't below the bar of a FWHM of 0. It also seems the first frame isn't included in the average FWHM, due to it being FWHM 0, and is recorded in the stacklog.csv file as having a FWHM = 0 as well. There just seems now to be no way of getting at the FWHM of frame 1 of a live stack.

I thought this was just a glitch in running live stacking from within a sequence with python code intermixed. However, I just ran live stack directly this morning using the deep sky test camera, and it also always got FWHM=0 for the first live-stacked frame. I see that the 2024-07-09 release had some sort of fix for crashes involving the FWHM of the first live stacked frame. Maybe this new behavior is somehow related?

[admin]

Hi,

that's a bit odd, since I don't think I have ever calculated the FWHM of the first frame (if you check in an earlier version then you should see that you get '???' in the graph for the first frame as no FWHM is available and it does the same now). What might have changed is details on how the FWHM is reported to the rest of the code in the absence of a result, which might just give you a zero rather than a 'missing data' or similar. I'd have to check. How are you getting the FWHM into your script so that I can follow the right code path?

I keep meaning to actually bother to calculate for the first frame - the reason it doesn't at the moment is that there is no need to do star detection on the first frame as it is stacked - it's when the second one comes in you need to detect stars on the second one to do alignment.

cheers,

Robin

[lowenthalm]

I am thought SC used to calculate this, since it uses it to filter frames with too high an FWHM. I definitely don't want the first frame to be accepted if it violates the FWHM filter limit I have set. The brightness filter of course has to wait a few frames before starting to pass judgement on when frame brightness is too low since this brightness is a relative measurement, whereas FWHM is an absolute measurement in each frame.

In the past, I am pretty sure I have had cases where I set the FWHM too low initially and SC live stacking rejected all frames until I adjusted the FWHM. That being said, the first frame FWHM being reported in live stacking has often looked a little out of context from the subsequent frames stacked. A little oddly high or oddly low. Maybe it was just picking up the FWHM from the previous stack that was closed?

Seems to me that FWHM for the first frame should definitely be calculated. My Python code was most definitely seeing a non-zero FWHM min, max and avg after stacking only one frame and then pausing.

Here is my Python code, including the patch I just put in to handle the new FWHM == 0 I started getting in the latest SharpCap. Note the comment I put in last year on 2023-09-21. I had forgotten that, but now its the opposite problem!

# LiveCapture Autoset FWHM.py
# Called from Live Capture sequence, with live stacking open, usually after histogram capture.
# This auto-sets the FWHM based the min and max FWHM in the current stack
# Might even be useful to call at the end of each stack to adjust the FWHM to varying seeing conditions…
#
# 2023-09-21 notes
# This needs work. If first frame is a dummy frame that wasn't stacked, its included
# in the min/avg/max stats. Need to analyze all three carefully
# Can't find raw frame FWHM data array, so just guessing using min, avg and maxFWHM
# to get an idea of the data spread.

slop_factor = 1.2 # upped from 1.16 to 1.2
maxFWHM = MDLSharpCapAPI.LiveStacking_MaxFWHM #SharpCap.LiveStacking.ViewModel.FilterViewModel.MaxFWHM
avgFWHM = MDLSharpCapAPI.LiveStacking_AverageFWHM #SharpCap.LiveStacking.ViewModel.FilterViewModel.AvgFWHM
minFWHM = MDLSharpCapAPI.LiveStacking_MinFWHM #SharpCap.LiveStacking.ViewModel.FilterViewModel.MinFWHM

if avgFWHM == 0:
# Bug in SharpCap showed up in 2024-07-15 release. The first live stack frame is stacked
# in some cases, but has not known FWHM, so its set to 0 after the first frame giving
# bad results here if we are called after the first frame. The first frame
# is not included in the average of the completed stack, so as long as avgFWHM isn't
# 0, it should be correct. This will force FWHM to 12.0 in this case.
maxFWHM = 12.0
avgFWHM = 12.0
minFWHM = 12.0

print ( "Predicting best max FWHM using current max, avg, min values: ", maxFWHM, avgFWHM, minFWHM )
print ( "Deltas for max:avg and avg:min are ", maxFWHM - avgFWHM, avgFWHM - minFWHM)
if maxFWHM - avgFWHM < avgFWHM - minFWHM:
# Weight toward range between max and avg
if maxFWHM < avgFWHM * slop_factor:
predictedMaxFWHM = slop_factor * avgFWHM
print( "Using max:avg weighting, base only on average average, new predicted value:", predictedMaxFWHM )
else:
predictedMaxFWHM = slop_factor * (maxFWHM + avgFWHM) / 2
print( "Using max:avg weighting, basing on average( max, avg ), new predicted value:", predictedMaxFWHM )
else:
# Weight toward range between avg and min
predictedMaxFWHM = slop_factor * avgFWHM
print( "Using avg:min weighting, just use average, new predicted value:", predictedMaxFWHM )

#SharpCap.LiveStacking.ViewModel.FilterViewModel.MaximumFWHM = predictedMaxFWHM
MDLSharpCapAPI.LiveStacking_FWHMFilterActive = True
MDLSharpCapAPI.LiveStacking_FWHMFilterThreshold = predictedMaxFWHM

[admin]

Hi,

just checked again and it looks like you are right - the previous versions did work out the FWHM for the first frame and somehow I have bypassed that with the new code changed I will have a dig into it and find the code that is missing and make sure it gets called again in the next version!

cheers,

Robin