Importing 32-bit Stack into PI failing, 16-bits OK

A place to report problems and bugs in SharpCap
Forum rules


If you have a problem or question, please check the FAQ to see if it already has an answer : https://www.sharpcap.co.uk/sharpcap-faqs

Please also read about Troubleshooting USB Issues before posting.

*** Please do not post license keys - please report any problems with licensing to 'admin' by private message ***

Please include the following details in any bug report:

* Version of SharpCap
* Camera and other hardware being user
* Operating system version
* Contents of the SharpCap log after the problem has occurred.
[If SharpCap crashes, please send the bug report when prompted instead of including the log]
Post Reply
BobHehmann
Posts: 17
Joined: Thu Sep 16, 2021 11:17 pm
Location: Moorpark, California, USA

Importing 32-bit Stack into PI failing, 16-bits OK

#1

Post by BobHehmann »

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.
Attachments
SCPI.JPG
SCPI.JPG (49.9 KiB) Viewed 502 times
Cheers, Bob
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Importing 32-bit Stack into PI failing, 16-bits OK

#2

Post by admin »

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
BobHehmann
Posts: 17
Joined: Thu Sep 16, 2021 11:17 pm
Location: Moorpark, California, USA

Re: Importing 32-bit Stack into PI failing, 16-bits OK

#3

Post by BobHehmann »

Thank you Sir! That resolved it - PI only wants the floating-point version for 32-bit FITS. I'll pass the message on!
Cheers, Bob
ChrisR Oz
Posts: 158
Joined: Tue Sep 28, 2021 11:03 am
Location: Melbourne

Re: Importing 32-bit Stack into PI failing, 16-bits OK

#4

Post by ChrisR Oz »

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.
Celestron EdgeHD 8, reducer 0.7x, Star Sense, CGX-L mount, Focuser, CPWI; Starlight Xpress AO, OAG and Filter Wheel; ZWO 294MC/294MM Pro and 174MM mini; SharpCap Pro, PHD2, Powermate 2x, Baader Neodymium, Astronomik CLS-CCD, ZWO UV/IR, Duoband filters.
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Importing 32-bit Stack into PI failing, 16-bits OK

#5

Post by admin »

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
Post Reply