Issue with FITS file generated during Live Stacking

[RudyOtten]

Good day Robin,

I'm using version V4.0.7403 64bit version of SC-Pro.
I reverted back to version 3.2 as I have discovered that after spending 3 hours in the night that I could not use
any of the captured light frames. I do love the new features in the latest version but when I can not use the results
than I prefer the older version.

What is the problem: In the new version when I do a 5 minute live stacking with 60 second sub-exposures the resulting FITS file
when you want to use it say in PI you will notice that in the core of some stars, something funny has happened.
It looks that the saturation of the value is not handled correctly. I also used FITS liberator as a tool to examine the FITS file
and I see the same. I'm using a ZWO ASI299-MC camera, and in version 3.2 it is working OK. One thing I noticed is that the FITS
keywords "TRUDEPTH" and "BITSHIFT" are different between version 3.2 and 4.0?

With the link you can get to the 2 files, Stack_32bits_10frames_300s.fits is the one made with version 4.0
Stack_32bits_11frames_330s.fits is from 3.2.

The reason why one is 300s and the other is 330s is because that is another funny thing.
When you have the exposure set at say 30 seconds and say you want to save the results each 5 minutes
I sometime see that it works, after 10 frames (ie 300 seconds) the stack is saved, but sometimes it will take
another frame and will save it after 11 frames? Maybe another bug?

Hope you can find the reason as version 4.0 has many new features I want to use and bug fixes that I like.

If you need more information, just let me know.

Kind regards,


Rudy


https://drive.google.com/drive/folders/ ... sp=sharing

Screenshot 2021-03-02 142519.jpg (297.95 KiB) Viewed 1460 times

[admin]

Hi Rudy,

it looks like there is an issue with SharpCap over expanding the range of the image when saving it - can you tell me what colour space settings you had for your camera when this happened (RAW8? RAW16?) as I think that might affect what is going on.

I think you should be OK saving as a 16 bit stack for now- you don't really lose much that way and it shouldn't be affected by the problem.

cheers,

Robin

[RudyOtten]

Hi Robin,

I checked the camerasettings file and it shows: Colour Space=RAW16

I also checked the 16 bit version and yes, that one looks OK.

Lucky that I had not deleted all files from that night

Regards,

Rudy

Screenshot 2021-03-04 111430.jpg (882.89 KiB) Viewed 1429 times

[admin]

Ok, that's good - I think I have a potential fix for next week's update - would be grateful if you could test it if you get a chance to check it fixes the problem for you.

Robin

[RudyOtten]

Will do so Robin.

I now have set some options so I should receive an email when there is an update on the forum.

Rudy

[RudyOtten]

Ok, that's good - I think I have a potential fix for next week's update - would be grateful if you could test it if you get a chance to check it fixes the problem for you.

Robin

Was this already done? Just so I know I can test it...

Rudy

[admin]

Hi,

the change is made and in this week's version - for me it seemed fine, but as usual I'd suggest a quick test to validate that the problem is fixed properly before running a long imaging session.

cheers,

Robin

[RudyOtten]

Good to know Robin, will test it on Monday when the forecast is OK.

Brings me to a question.
When you use the 32 bits FITS format, does it mean that when you de the stacking and the integrated values saturate at 2^16 it will now
saturate at 2^32? Meaning for long integrated stacks the 32 bit should be used by default?

And is there a place where we can place our wish list? I have a few .

Regards,

Rudy

[admin]

Hi,

the standard live stacking algorithm will saturate at pixel value of 2^31, since it tracks negative pixel values too. For technical reasons that actually means that you need 65536 frames to saturate, which is probably unlikely!

If you save as 16 bit stack, the data is scaled, so no clipping, just a loss of resolution in terms of brightness level. In practice it's probably minimal due to the shot noise levels involved in the brightness of each pixel.

Feature suggestions welcome here : viewforum.php?f=17

cheers, Robin

[RudyOtten]

Hi,

the standard live stacking algorithm will saturate at pixel value of 2^31, since it tracks negative pixel values too. For technical reasons that actually means that you need 65536 frames to saturate, which is probably unlikely!

If you save as 16 bit stack, the data is scaled, so no clipping, just a loss of resolution in terms of brightness level. In practice it's probably minimal due to the shot noise levels involved in the brightness of each pixel.

Feature suggestions welcome here : viewforum.php?f=17

cheers, Robin

Thanks for the explanation.

I have done the testing and what I noticed os that the 16bit save file shows "normal" and the 32bit version looks like there is a DC offset on it.
I attached the files to explain.
Maybe this is normal, but it looks a bit weird.

You see that the L values is small for a part of black on the 16bit file version, but it is already 0.5 on the 32bits one.
The other 2 files are the FITS header parts of the saved files.

16Bits.jpg (211.41 KiB) Viewed 1274 times

32Bits.jpg (204.97 KiB) Viewed 1274 times