SharpCap Forums

I was puzzled by my stacking software warning me it was compensating for wildly different EGAIN values in a raw sub data set on the same target (PN K3-77) which I captured with Sharpcap over four nights between September 27, 2024 and October 7, 2024. Upon investigating, I discovered the first two nights of subs I captured at the end of September were using Sharpcap v4.1.12551, while the second two nights in October were captured using SharpCap v4.1.12606.

All subs were captured with my ASI294 Pro Color Cooled camera using 120sec exposures @ gain 60, with the camera cooler @ -5C. The raw subs were all captured while live stacking.

The two sub batches captured with 'SharpCap v4.1.12551.0, 64 bit' had the following in the fits headers:

EGAIN = 7.817 / Electrons per ADU at true bit depth

The subsequence two sub batches captured with 'SharpCap v4.1.12606.0, 64 bit' had:

EGAIN = 0.3054 / Electrons per ADU at true ADC bit depth

and the 'SharpCap v4.1.12606.0, 64 bit' subs also had the following new FITS fields which were not present in the fits headers:

ADCBITS = 12 / Bit depth of camera sensor ADC in current mode
EGAINSAV = 0.01909 / Electrons per ADU at saved bit depth
BIASADU = 523.2000122070312 / ADU for bias level (no photons) at current sett

I have no idea exactly what my stacking software was doing as a result the different EGAINS - I need to figure out how to investigate what effect this is having. Maybe stack the two pairs of data set separately and see how the results look different. The individual subs looked pretty much the same when I debayered a sampling from each sub batch. The stars reached somewhat peak brightness at the star mass center (20% more, maybe) which seemed to be due to FWHM differences due to seeing. Certainly not 7.817 / 0.3054 though! I have a couple of other image data sets that straddled this SharpCap version change, so I will check these out too.

I have attached a spread sheet that compares the fits fields in a sample file from each of the 4 batches. Matching fits fields are aligned in each row of the speadsheet. The order column can be used to recover the order the fits fields were written any of the four header files. I have also attached the camera settings files saved from live stacking.

Hi,

thanks for that report - I think I can see the problem ...

I wanted to add the extra headers to make the information more complete, which required a slightly different approach to the code that collects the information. What I forgot/did not notice is that the new approach doesn't ensure that the data being used is up to date for the most recent changes to the relevant camera controls (gain, black level, etc), so it would end up using values calculated at some point in the past, quite possibly for different gain settings Actually, I think that most likely the measurements being used would be those calculated the last time the camera changed bit depth from 8 to 16 bit (or vice versa).

Sorry about that - I wasn't expecting that regression. I will have a fix in the update that I hope to upload this afternoon.

cheers,

Robin

Is that fix included in 12660 released 10/14? Wasn't sure if that was the one released this afternoon!

Hi,

yes, that fix did go into 12660 - I did a quick test and was seeing the EGAIN value change correctly when I altered the gain control then captured images, so hopefully will be all OK again.

cheers,

Robin