SharpCap Forums

I started experimenting with Live-Stacking, as an adjunct to my "real" raw-image capture. Why not see a preview of what I've got to look forward to? Just because, I wrote out a developing stack as both 16-bit and 32-bit raw FITS, using Live-Stacking's Save function. Opening the 16-bit versions (I did this several times throughout the stack, results were the same each time) in PixInsight (PI) gave the result I expected - a debayered unstretched image, fully manipulable in PI.

But the 32-bit files had a weird result - all pixels had a fixed offset of 0.5 (PI scales values from 0.0 to 1.0 in floating-point) - with some variability out in the 4th decimal position. If I take one of these SC 32-bit files and open it in ASTAP, it presents normally, unlike in PI. If ASTAP writes the file back out as a FITS file, without having performed any explicit manipulations on it in ASTAP, this new version is readable by PI as it should be.

PI is V1.8.9-1 (latest patch level), SC is 4.0.8973, OS's are Win10Pro. The camera is an ASI071MC-Pro. During stacking, SC was subtracting an SC-created Master-Dark; saving unprocessed raw subs; Sigma stacking using defaults; Alignment using defaults; no Enhancements; Guiding, everything checked (dithering every 4th frame); Histogram auto-stretched; everything else at their defaults. Debayering the "Previews". 90-second exposures, took snapshots of the developing Stack at 40/60/80 stacked frames.

The attached screen-capture taken from PI shows this with 6 images, all representing the same Stack: the first row of 3 are the unstretched images as seen upon first opening in PI; the second row are the same 3 images, with a basic STF stretch applied, and magnified for a closer view. The first column of 2 images is the Stack, saved as a 16-bit FITS; the middle column is the 32-bit version, loaded directly into PI; the right column the 32-bit SC file first read into ASTAP and re-written back to the filesystem, then finally loaded into PI. I've shown the pixel-values of the unstretched SC 32-bit file. The outer columns are what I would expect, the middle column - Oi! This makes ASTAP-as-intermediary a viable mitigation for me.

Of course, this may well be a bug in PI, or SC, or both - but SC & PI are such a common combo, I thought I'd pass this on and see if it raises an "Aha!" moment.

Hi Bob,

try changing the 'Save 32 bit FITS files as floating point...' option on the 'Saving' settings page. There are two types of 32 bit FITS - SharpCap writes them in integer format by default but can be switched to floating point using that option. I suspect PI only expects the floating point version (or maybe only the integer version). Anyway, hopefully toggling that option to the opposite value will fix things for you. You can test using the folder monitor or deep sky test camera just to get some sort of stacked image to save and then try to load.

cheers,

Robin

Thank you Sir! That resolved it - PI only wants the floating-point version for 32-bit FITS. I'll pass the message on!

There are some interesting notes on the use of unsigned 32-bit integers on the Astropy.io.fits web site. Seems that FITS dates from the Fortran days, and has no unsigned integers. They use some tricks to map the FITS signed integers onto the full 32-bit unsigned integer range. (Same goes for 16-bit.) It uses some FITS header keywords to telegraph these offsets (see "BZERO").

https://docs.astropy.org/en/stable/io/f ... d-integers

Perhaps some tweaks to SC could make the 32-bit integer FITS files work with PI.
Cheers, Chris.

Hi Bob,

glad it worked

Chris,

SharpCap already writes BZERO for 16 bit FITS for the same reason - I will have to check for 32 bit (but also avoid breaking other apps like PIPP which seem to work with the current setup). I think SharpCap currently writes signed 32 bit integers (since the live stack pixel values can in theory be slightly negative due to dark subtraction - you have to carry forward any negative values in the stack or else you end up clipping when a frame happens to be darker than the dark due to random variation at some pixels). Maybe PI is thinking it is unsigned?

cheers,

Robin