Live Stacking and pixel values

[Tonisee]

Hello!

I have few questions about FITS files that contain the result of Live Stacking using SharpCap Pro v3.2.6346, 64bit version.
My procedure is following when doing photometry of bright stars:

- ZWO ASI183MM Pro gain is set to 0 and binning is 1x1, output file type is FITS
- In SharpCap settings, I have selected "Save 10/12/14 bit images in FITS files without scaling to 16 bit".
- Live Stack has short exposure times (below 1 s) and I pre-process all frames on fly by dark frame
- stacking algorithm is "Default", no alignment or any enhancements are used
- when enough frames are collected (I'm looking after specific total exposure time), I hit Pause
- then I select Save as Raw (32 Bit stack) and live stack gets stored on disk

Because exposures are so short, there is barely any dark signal or significant signal from sky and dark-subtracted frames should have background close to 0. Just for an example, let's assume that background level after dark subtraction is 10 ADU because of sky background. When I stack 100 frames, the expected background level would be 1000.

When I take single frame in FITS format, that is indeed the case (although I haven't confirmed if max pixel value is still 12 bit or not), I'm getting a very low background signal in saved frames.

However, in the case of Live Stacking instead of expected background ~1000, my stack shows values around tens (if occasionally not hundreds) of millions.

I have tried to find out what conversions take place but so far I haven't succeeded. Could anyone please explain those conversions that take place.. maybe in the form of a receipt how final values are created from raw ADUs?

With best wishes,
Tõnis

[admin]

Hi,

I had to go and look at the code to remind myself of what is going on here. SharpCap bit shifts the data to the maximum amount possible when writing to 32-bit fits files in this way. The reasoning behind this is to avoid people being convinced that SharpCap has lost their data – without bit shifting almost every 32-bit save would appear to be completely black.

The image should have a BITSHIFT header to tell you how many bits to the left the data has been shifted.

Hope this helps, Robin

[Tonisee]

Hello Robin,

yes, that explains it and in fact the solution makes completely sense from most users point of view. Indeed, in one of my flat field frames (collected with Live Stack) some random pixel has value 1600000000, in the header TRUEDEPTH = 16 and BITSHIFT=15 are present. So every original pixel value should be multiplied by 2^15 (32768)? When dividing that 1.6 billion by 2^15, the result is 48828. But as I live stacked 80 frames for that flat image, single image signal level would be ~610 that is probable (it was an ultraviolet filter flat taken after civil twilight). Could you please confirm if my logic was correct?

Just a possible tiny feature request - if it is not very difficult to do that, maybe there could be a checkbutton in Settings that tells software not to shift pixel values? Like you have currently implemented 10/12/14-bit non-scaling for photometry purposes. OR maybe even - if that current button is checked, it could be/may be evident, that user is interested in original pixel values (i.e. for photometry) AND then 32-bit live stack scaling could also be turned off. What do you think about such idea?

Best wishes,
Tõnis

[admin]

Hi,

Yes your calculations sound reasonable for the actual pixel value for your flat frame. I'll certainly look into making another option available to disabled the bit shifting.


Cheers, Robin