"Save as 32 bit" (and Drift limit...)

[diant]

Two question, please. May be I've missed these points...

1). We have two button at the end - "Save as 16 bit" and "Save as 32 bit". I use to choose the second (32bit) and like to stack with Sigma clipping.
Now. Unfortunately even 32-bit saving do not escape data stretching during saving, as we read in guide:
"Save as Raw (32-bit) Stack... when using Sigma Clipped stacking, the 32 bit values will be stretched up to a maximum value of 2^31-1".
(BTW, my stacks often do not stretched to a full range 1..2^32. For example, max value may be 3.3E8. Why?)

So we can't sum rightly two or more stacking with essentially different time integration. For example. We stacked the day before yesterday a DSO object 10min totally. And yesterday we stacked it 60min totally. First stack obviously much more noisy, and direct adding one to other (when they were stretched to the same range) kill the good SNR of the second sum (60 min). But we could add one to other without any SNR degradation were they be not stretched.

My question (if I am right, of course): May be it will be a good idea to add the button "save as 32 bit unstretched" (or something of this kind)?

2). Other. We have Drift Graph - a great and useful feature. But we can't set a Drift limits (on X and Y) for an automatically stop stacking when real drift values goes above these limits. Example. We stacking a good hour or more, and suddenly our friend touch our mount in the darkness by his leg. Touch a little, but it could be sufficiently to shift our field of view as more as a half frame! But stacking algorithm do not lose the part of reference stars and continue to stack. But the result will be corrupt totally if only one or two shifted frame will be added...
Is such Drift limits a good idea to add it in SC?

Anton

[admin]

Hi Anton,

the 'stretch to full range' is necessary as the default save behaviour, since the alternative leads to the viewed image being almost completely black in many software applications. That sort of thing is a real issue for beginners, since they often don't know how to deal with it and think that they have lost their images, and the number of people who would get hit by that problem is far higher than the number of people who are encountering the sort of problem that you face.

Actually, the sigma clipping algorithm doesn't make the internal data values get bigger as more frames are added (what is stored is the mean of the frame values so far, not the sum), so an unscaled save wouldn't help much either (it would just have a range of 0 to 65535 regardless of stack length). I will have to think about how an option could work on this.

For the drift graph limit, that's kind of covered by the 'recenter' option which you will find to the right hand side of the guiding tab in the live stack area (at least if you are using a GOTO mount in SharpCap). The recenter option allows you to specify a limit to the amount of drift, and when that limit is reached, SharpCap will pause stacking, use plate solving to recenter the telescope then continue. It's not just stopping stacking as a result of the drift growing, it's fixing the issue and putting everything back in the right place.

cheers,

Robin

[diant]

Actually, the sigma clipping algorithm doesn't make the internal data values get bigger as more frames are added (what is stored is the mean of the frame values so far, not the sum), so an unscaled save wouldn't help much either...

I understand the problem, and if you'll find any solution, it will be fine. Because there are many objects that stacked more than once and it is not always stacks' length will be the same. So they combining may meet a real SNR difficulty.

For the drift graph limit, that's kind of covered by the 'recenter' option which you will find to the right hand side of the guiding tab in the live stack area (at least if you are using a GOTO mount in SharpCap). The recenter option allows you to specify a limit to the amount of drift, and when that limit is reached, SharpCap will pause stacking, use plate solving to recenter the telescope then continue. It's not just stopping stacking as a result of the drift growing, it's fixing the issue and putting everything back in the right place.

No, I use non-GoTo mount, so that option will not help me. In case of simple motor-driven mounts Drift limits could be a good solution.