HOWTO: Capture a planetary imaging timelapse with Planetary Live Stacking

[admin]

Hi,

OK, so it was almost certainly the 'planet/full disc' alignment that caused the drift and probably also the odd stacking artifacts. That mode looks for the center point of the bright pixels in the image and keeps that steady. For normal situations that is fine, but for an eclipse, the center of the bright part of the moon/sun is shifting as the area of shadow changes. If you can find an AVI or SER of a fairly long segment of eclipse then you could load that into 'Test Camera 2 (High Speed)' and let it play back in SharpCap while trying out various stacking options to check this and try alternate settings.

Your Omegon camera should have auto exposure - it's basically a ToupTek IMX571 with the Omegon branding, and the ToupTek SDK has autoexposure which you can enable via SharpCap - there is an 'auto' checkbox at the bottom right of the exposure control area and also a dropdown to allow you to optionally enable auto gain along with auto exposure. Worth checking out.

cheers,

Robin

[Mr. Phil]

Am I missing something as when you set the time lapse interval which in the example Robin gives at 5 seconds should it not be longer than the time taken to complete a stack as 70 fps for 5s is only 350 frames and stack length is 2100

[admin]

Hi,

no, there's no real need for it to be longer than the stacking time. Rather than performing a stack of (in your example) 2100 frames to make an image and then starting again from scratch, SharpCap has a continually evolving stack where new frames are added and old frames are removed as time passes(*). This means that the image produced by the stack is constantly evolving. It won't change much in 5s, so it may be worth increasing this time to 15s or so in this case, but it will change. The only downside to using a shorter interval is getting bigger output files.

cheers,

Robin

(*) Strictly speaking, the effect of old frames is always being gradually diminished, rather than strictly being removed. Fading out the effect of old frames can be done without needing to store all the frames currently in the stack and is faster to process too.

[AstroMathmo]

So I’ve been having great fun with this and used it with the double Jupiter moon transit a couple of nights ago. I have a question/request and a request.

Q1 when doing the moon transit it felt like the moons became ovoid in some frames and the motion speed a little uneven. I wondered how the window and weighting of older frames was being set. I think somewhere I saw that older frames impact gradually diminished rather than being cut altogether? Made me wonder if there is something like an exponential moving average being used rather than a binary window? I’d like to be able to to write a frame say every 30 or maybe 60s and be sure that each 30s frame did
Not include any data from prior to that 30s/60s window. My camera is at about 180fps so I reckon I’ll have enough data. Or maybe the
It’s my imagination and some gusts of wind stretched the moons!!

Q2. Any chance you could implement a 2X resampling with associated enhancements for the live stack at least as an option? I’ve put an gen 15 ultra 7 with 96G on initially so I can run post processing while Sharpcap does its capture stuff, but I reckon I’ve now got the power to do this live within the software. I know you’ve been reluctant to do this and have other tricks in there. The output from the live stacks is excellent but I think I can still get better quality from batch processing the .SER files though that is a time consuming pain. Being able to optimise the video->tiff frame output internally would be great as I can always throw an image container with the frames in it to a Pixinsight process for further tidying. A 2x super pixel stack with a von Crittert decon option on the fly would be the bees knees.

[admin]

Hi,

glad you are enjoying the planetary live stacking - I did see your timelapse recently on the Oxford Astrophotography group - very nice.

For Q1, are you using frame filtering as part of your PLS configuration? That could certainly cause some of the irregularities you are seeing with the movement if the seeing is also fluctuating. Picking which frames to include when quality filtering in real time is an interesting problem. The way SharpCap does it is to look at the quality history of the last N frames (N ideally about 2 * stack length / fraction of frames uses). Pick the appropriate centile in the quality distribution of those frames and include frames with quality above that centile.

But, if the seeing suddenly degrades, all the incoming frames are going to be well below the quality threshold - those will gradually replace older frames in the dataset you are measuring your filter against, but it could be a while before the threshold drops enough to start bringing in significant numbers of new frames. Possible result - a bit of a dead spot with movement happening due to rotation but no frames entering the stack. If the quality suddenly increases, the opposite happens - a flood of new frames enter the stack which might make the movement seem to advance faster than usual. The quality of your timelapse does seem to improve at various points, so I guess the seeing was variable.

Other things to check are to have 'single point' stacking on for a relatively small Jupiter (under 200 to 300 pixels on the sensor) - that, along with using planet rather than surface ROI seems to give the best results in this situation.

If you hover over the 'i' information icon to the right of the stack length then it gives you some info on how long the stack is in terms of the time it is averaging over, based on the current settings for length, frame filtering, frame rate, etc.

For the resampling, what I am unsure about is how the rest of the application would cope (I suspect badly) if the planetary stacking turned a 640x480 input image into a 1280x960 output image. The rest of the code doesn't expect that sort of thing to happen, and I expect it would end up being a bit of a bug fest dealing with all the fallout. It would be less troublesome to do the stacking/sharpening internally at double resolution then come back down to 640x480 for display - maybe that would work out... It might even be OK to save the snapshots/timelapse from planetary stacking as the higher resolution in that case. I will need to try that out and see if it works.

cheers,

Robin

[AstroMathmo]

Thanks Robin

I understand your point about frame displacement from seeing fluctuations if a filter is on. I’ll check to see what I am actually doing! I’ll also check the window size and stack size parameters. My Jupiter was quite big with a 4500mm CC10. Thanks for those insights.

Your point about the impact of extra processing elsewhere in the app is well taken. Last night I was able to do a more basic capture of many SER files while also doing some manual 2x up sampled stacking of a few of them in AstroSurface and post processing in Pixinsight. So I know have the processor clout! But I guess those are non interacting apps where it is easier to share resources. Of course you need to prioritise for your main market, and lunatics like me with a small workstation outside by the mount might be too much of a minority. But it would be good to have the option of being able to spin off an advanced live stacking thread with more options and pump out some very high quality tiffs. Last night I filled up my SSD with .SER files and the capture then failed. Doh! Maths fail. I was back thinking I should have live stacked.

[admin]

Hi,

definitely going to have a look at the 2x scaled processing when I get a chance as having thought about it, it should work as long as I reduce the size again before passing the image back to the main part of the software. Obviously it will consume 4x the CPU and memory, so only suitable for planetary rather than solar/lunar, but will be interesting to see if it works.

cheers,

Robin