Page 1 of 1
32 bits fits corrupted on last save
Posted: Mon May 25, 2026 6:41 pm
by Opmc73
Hi Robin,
It comes from time to time that the 32 bits version of the .fit created at the end of a livestacking session appears totally corrupted.
See below the same file 32 bit(left)/16 bit right from a Ha session. I was using the very last version of SC , but this occurs with every version , as it appears to be random. (the processing pc is a melee quieter 4c - N100 with 32 gb ram memory)
- Capture d’écran 2026-05-25 203816.jpg (629.02 KiB) Viewed 707 times
Camera settings info
16bit
32bit
kind regards
Olivier
Re: 32 bits fits corrupted on last save
Posted: Tue May 26, 2026 1:02 pm
by admin
Hi Olivier,
does it look like that in all FITS viewing applications? There are two types of 32 bit FITS files - floating point and integer versions. SharpCap can save either based on a settings choice and some applications have problems with one of the types (most often with the integer type). In most cases it's a complete failure to load, but it's possible that there could be other glitches in the handling of one or both. Best to check that possibility first - even if we discover that the problem is limited to certain applications, it provides useful info.
Overall however, it would probably be best for you to send me some files to test with - one 'bad' 32 bit FITS and the corresponding 16 bit version from the same stack, along with pair where both are good would be ideal.
On a similar note, I am on the lookout for an issue where FITS files are failing to open in FITSLiberator, but are OK in other software. I've seen this happen myself, but was busy debugging another issue at the time. When I had a chance to go back and look into it, I couldn't make the bug happen any more in spite of using the same steps...
cheers,
Robin
Re: 32 bits fits corrupted on last save
Posted: Tue May 26, 2026 3:45 pm
by Opmc73
Hi Robin,
this is something that occurs from time to time and is not link to the .fit viewer. Most of the time it is ok and the 32bits or 16 bits are render the same.
I will send you a link to download the files in my next message here, I am not on the computer that have the file for now.
kind regards
Olivier
Re: 32 bits fits corrupted on last save
Posted: Thu May 28, 2026 2:06 am
by Opmc73
Hi Robin,
You can download the HAlpha capture data in the .zip file there (expire in 3days) =>
https://we.tl/t-z9bH3DGFkp67QTgE
I have added my flat and dark inside the folder.
Kind regards
Olivier
Re: 32 bits fits corrupted on last save
Posted: Thu May 28, 2026 9:33 am
by admin
Hi Olivier,
thanks for sharing those files - just what was needed to work out the cause of the problem.
What's going on here is that the dark frame doesn't match the light frame - it's taken at a higher effective gain than the light frame. This leads to over-subtraction when the dark is applied in turn leading to negative pixel values in the stacked image. In the 32 bit stack, these get written out as negative values to the output file (the 16 bit stack just sets all negative pixels to zero in the FITS file). It looks like the handling of negative pixels in a floating point 32 bit fits file is a bit hit-and-miss between different FITS viewing applications, leading to black holes in some viewers.
Back to why the dark and light don't match - the dark was taken with the option to manually control the LCG/HCG setting of the camera turned on, and in manual HCG mode (there is a 'ReadMode=HCG' line in the capture settings file). This used gain 1848 on the camera analogue gain, but combining this with the manual HCG gives an effective gain of 3x1848 = 5544. The light frames were taken with the LCG/HCG in 'controlled by SharpCap' mode, meaning that the HCG switches on when the gain setting you see in SharpCap rises above 300. When you set gain=1848 in this mode, at the camera the settings are HCG, gain=616, which gives an effective gain value of 1848 when you combine the 3x multiplier of HCG with the underlying gain.
In SharpCap 4.2, I am *removing* the tracking of negative pixel values in the live stacked images, instead just treating anything that comes out as negative (over-subtracted) as having zero pixel value. This is after a considerable amount of thought about the topic - although in theory it is the correct thing to do to preserve the negative values, in practice they will almost always occur due to either mismatched darks or very underexposed images. Since in both of those cases, the final image quality will be being badly degraded by the cause of the negative pixel values (the incorrect darks or underexposed frames) - almost certainly those will have more effect than ignoring the odd negative pixel value...
cheers,
Robin
Re: 32 bits fits corrupted on last save
Posted: Thu May 28, 2026 12:21 pm
by Opmc73
admin wrote: Thu May 28, 2026 9:33 am
Hi Olivier,
thanks for sharing those files - just what was needed to work out the cause of the problem.
What's going on here is that the dark frame doesn't match the light frame - it's taken at a higher effective gain than the light frame. This leads to over-subtraction when the dark is applied in turn leading to negative pixel values in the stacked image. In the 32 bit stack, these get written out as negative values to the output file (the 16 bit stack just sets all negative pixels to zero in the FITS file). It looks like the handling of negative pixels in a floating point 32 bit fits file is a bit hit-and-miss between different FITS viewing applications, leading to black holes in some viewers.
Back to why the dark and light don't match - the dark was taken with the option to manually control the LCG/HCG setting of the camera turned on, and in manual HCG mode (there is a 'ReadMode=HCG' line in the capture settings file). This used gain 1848 on the camera analogue gain, but combining this with the manual HCG gives an effective gain of 3x1848 = 5544. The light frames were taken with the LCG/HCG in 'controlled by SharpCap' mode, meaning that the HCG switches on when the gain setting you see in SharpCap rises above 300. When you set gain=1848 in this mode, at the camera the settings are HCG, gain=616, which gives an effective gain value of 1848 when you combine the 3x multiplier of HCG with the underlying gain.
In SharpCap 4.2, I am *removing* the tracking of negative pixel values in the live stacked images, instead just treating anything that comes out as negative (over-subtracted) as having zero pixel value. This is after a considerable amount of thought about the topic - although in theory it is the correct thing to do to preserve the negative values, in practice they will almost always occur due to either mismatched darks or very underexposed images. Since in both of those cases, the final image quality will be being badly degraded by the cause of the negative pixel values (the incorrect darks or underexposed frames) - almost certainly those will have more effect than ignoring the odd negative pixel value...
cheers,
Robin
Hi Robin,
Ok, I undestand , I did capture the dark in another computer than the one the is used to capture the ligth. At a moment I tried the manual HCG on both but was not satisfied witht the result , so I return back on the automatic HCG but forgot to do that on the dark capture.
By the way I have decided not to use the the High Full well mode of Touptek anymore because it make some bizarre random banding I don't have in default utlra noise mode.
In SharpCap 4.2, I am *removing* the tracking of negative pixel values in the live stacked images, instead just treating anything that comes out as negative (over-subtracted) as having zero pixel value.
is this explaing why on Ha pictures I often have kind of black pixels I don't get with other filter where the image is faster to get with ok quality ?
Thank you for the investigations and explanation
Olivier
Re: 32 bits fits corrupted on last save
Posted: Fri May 29, 2026 10:52 am
by admin
Hi Olivier,
it's a possible cause for black pixels, but really only likely if the darks don't match.
A more common cause of that sort of problem is if you have a pixel where it is intermittently hot (say 1 in 25 exposures). You take a dark with 20 sub-frames, and by chance that pixel comes up hot 2 or 3 times when capturing the dark. That makes the dark brighter than average at that pixel, which then tends to punch dark holes in the dark corrected image every time the pixel doesn't come up hot in the light frames. This sort of thing is obviously unlikely on a single hot pixel (coming up 3 times in 20 attempts at a chance of 1 in 25), but if you have a few hundred pixels like that then it will happen to some of them.
There is an option in the SharpCap capture dark window to exclude outlier values when creating the master dark, which can help with this - basically it uses sigma clipped stacking when making the master dark...
cheers,
Robin