First tries at planetary using SC livestacking/ processing

[timh]

This is all fairly new to me so looking for advice on improvement rather than my usual just boasting about great pictures ! -- it's great to now have the wherewithall to do planetary/ lunar at all but now looking for tips.


Equipment was a VX12 300 mm Newtonian F 4 on a CEM70 mount with a ZWO ASI 715 MC camera (which has tiny 1.45 uM pixels) and Baader UV/IR cut off filter.

The image scale was therefore 0.25 arcsec/ pixel giving a sampling of ~ 1.6X versus a Dawes limit of ~ 0.4 arcsec.

The ROI was set to 640 x 480 pixels at gain 110 using fast mode at RAW 8 with the ADC set at 10 bit depth to maximise FPS

Mars was imaged for 2 min -- exposure time 2.34 ms -- and Jupiter for 1 minute --- exposure time 8.8 ms -- resulting in .SER files of about 6000 frames of Jupiter and 12-13000 frames of Mars.

In Sharpcap frame filtering was set at 15% of 5000 or 10000 frames and thus the target stack size versus Mars and Jupiter was set at about 1000 and 2000 respectively.

The planet was tracked with the Camera ROI.

Below are a couple of the images from recording yesterday (25-26/01/25). The sharpness and deringing etc settings were adjusted in Sharpcap by eye -- generally at levels just set back slightly from 'autosharp' to avoid too artificial an appearance and some edge artifacts on Mars. The results seemed very similar when I tried using Autostakkert and Registax6 rather than SC to process the .ser files. So SC seems fine as a processing as well as a capture tool?

I suppose that my main questions are about what likely most limits the quality? These last nights the skies have been busy with passing storms etc and the air surely turbulent. How much difference would an ADC likely make -- or is it enough to align the RGB channels during processing and rely on the plants all being above 50 degrees above the horizon? How much gain would there likely be in imaging for longer and using WINJUPOS ?

Does anyone have any good tips on focusing? I just tried to set best focus on stars before then going back to the planet and short subs -- but the air was unsteady and best focus correspondingly uncertain.

Lastly - I took the decision to go for RAW8 and a minimal ADC depth for the sake of speed -- but - maybe especially with an OSC camera - would it have been better perhaps to trade some speed for going RAW16 and more ADC depth -- I was counting on the stacking effectively adding the the bit depth anyway?

thanks
Tim

[ChrisR Oz]

Hi Tim,

They are already looking great! The rule of thumb is to aim for an F# of 7x the pixel size, or F10 in your case. A 2-2.5x Powermate/Barlow would work in your case, helped by those tiny pixels.

Cheers, Chris.

[admin]

Hi Tim,

very nice images for a first time around with planetary stacking in SharpCap.

I would agree with Chris that a bigger image scale from a barlow would help - you can see particularly with mars that the pixel size is looking like the limiting factor. I run f/24 (f/12 scope, 2x barlow) with a 3.75 micron camera, which is close to the f/26 calculated by Chris's 7x guideline. I still find myself thinking at times that I could do with a smaller pixel/more magnification.

Seeing and focus are going to be the other big things to help you. Seeing is obviously just a matter of waiting for good conditions, but you can get good patches in an otherwise dodgy session - in the latest SharpCap watch the 'Auto Capture' (was Stack Quality) graph which shows the contrast of the stack measured over time - if that peaks without you touching anything then the seeing has improved.

Also, check out this post which I wrote last week which detailed some improvements and potential 'best practice' for planetary focusing in SharpCap : viewtopic.php?p=46695

cheers,

Robin

[timh]

Chris and Robin, thanks so much for the steers. So next time out will be with the barlow (I was avoiding using it in order to retain a possibility of plate solving -- with a 2X barlow the max field of the 715 MC will be down to ~ 8x5 arc min - and I was also worried about adequate brightness for high fps). But thinking it through - the guide camera should work adequately for plate solving and the numbers thus far suggest that - even barlowed - enough gain/ exposure headroom remains to get above 60 fps. So looking forward to having another go once the weather gods relent.

Suspect that unsteady air, poor focus or both limited this first effort -- counting the pixels across features I don't think resolution bettered 1-1.25 arc sec even after sharpening. So - Robin - I appreciate the advice and software features to facilitate focusing and catching the seeing so will explore and try to get familiar with these.

Tim

[turfpit]

Tim

Those turned out well for a first attempt, I like the Mars detail. Introducing the Barlow is the next step but it will leave you at the mercy of the seeing conditions. You will have to juggle gain and exposure and trade-off against fps.

Some of my experiences with planetary imaging - where I live, at the top of the Pennines I am at the mercy of weather fronts. It is not unusual to see clouds moving in from the east and the west simultaneously, leaving me under a turbulent atmosphere. The seeing can vary wildly (this tends to even out over longer deep sky captures). There are nights when my 2.5X Barlow just does not give anything worthwhile. How I deal with this now is to take multiple captures for say 1 hour of a planet (or lunar). When processing these multiple captures, I usually can find some decent data in amongst the wobble.

If you have a go at WinJUPOS then viewtopic.php?t=7344 post #6 might save you some time.

If you try waveSharp 2 https://github.com/CorBer/waveSharp?tab=readme-ov-file then the Background Enhancement Tool can assist with displaying planetary moons via masking.

Your 300mm reflector should be very good for lunar work.

Good luck.

Dave

[timh]

Thanks Dave,

Fortunately I collected a few videos over a half hour or so and have thus been able to give winjupos a go (which worked once I had realised that my files were all E/W inverted and so it was trying to de-rotate in the wrong direction at first) and yes it provides a pretty big improvement -- with 5 files the SNR seemed much improved.

Pennines a lovely part of the country -- but I reckon best UK area for more frequent runs of still air combined with darkness is probably Norfolk ? Anyway I'll take what I can get here in the murky Thames Valley while the planets are still riding high -- pity that it's a bit of a mini Mars opposition ..only a 67 pixel image.

The wavesharp tool looks interesting -- I was wondering exactly that ...i.e. how to get the moons in

Tim

[admin]

Hi,

just a note on Winjupos (or not) - the movement rate of features on the equator of jupiter can be calculated as follows

Time taken for a feature to move 1 pixel = 11460s / D - where D is the diameter in pixels of your Jupiter image

So, for a 200 pixel diameter Jupiter, you get about 57s to move 1 pixel. In that situation if you are stacking from a recording that is 30s long, you won't see significant benefit from Winjupos as the movement is only 0.5 pixels. If your recording is 120s long then you will see much more benefit as the movement during the recording is going to be 2 pixels.

I do wonder though (haven't tested this) if in actual fact the threshold for benefit is higher - if you are using a stacking tool that does multiple alignment points then the alignment point procedure will tend to correct for the *local* movement due to rotation over the length of the input video. The problem then arises because the movement rate isn't constant across the planet - it's highest in the center and lower towards the poles and E/W limbs.

cheers,

Robin

[timh]

Interesting comments ! thanks Robin

Your estimate of 200 pixels across the diameter of Jupiter fits my situation -- 0.25 arcsec/pixel and an apparent size of 50 arcsec. I suppose that the figure of 11460 s EW transit time arises from an estimate that- with the limb details being narrowed out - we only really clearly see about 2/3 of the hemisphere detail transiting across.

The .ser files of Jupiter were each about 60s in duration so that fits with your estimate of a 1 pixel movement blur.

However - that being the case -- am I right in thinking that I won't get any resolution benefit from say a 2X Barlow unless I drop to 30s length videos?

There seem to be two options for running winjupos. The first option to which I presume that you are referring ? is the one where you run winjupos on each ser file and let the program adjust each frame to sync the rotation. I haven't tried this option -- it is apparently processing intensive and takes time to run --but it would seem to make a lot of sense as you suggest to run it to correct ser files that are two to three times as long as would otherwise theoretically be sensible.

The second winjupos option -- the one that I took - was simply to feed in the stacked sharpened frames resulting from each of a number of 1 min ser files - along with the timestamp data (5 over about a 30 min timespan) and let winjupos derotate and align them. The primary advantage I think was in removing noise and improving SNR but the
resulting 'superstacks' were not any sharper as far as I could judge.

Your last point is interesting if I understand it correctly -- does it mean for example that it is never a good idea to stack frames that are differentially rotated with respect to eachother using a multiple point local alignment? So either don't do it -- or alternatively ideally do the frame by frame winjupos derotation first on the entire ser file before stacking?

I don't know what winjupos does when it stacks the stacks from quite widely separated 1 min time points? I suppose that it derotates first and then stacks according to either a single or multipoint alignment?

Tim

[admin]

Hi Tim,

if you go with a barlow then you are correct that the threshold time for stacking without derotation does reduce by a factor of 2, but I think that is probably a problem for another day. My instinct is that rotation isn't the limiting factor on your images at the moment - probably seeing is the prime suspect for the limit at the moment.

The 11460 is the rotation period of Jupiter divided by Pi - Rotation period is ~10h or 36000s. The circumference of Jupiter (measured in pixels) is Pi*Diameter, so the speed of movement is Pi*Diameter/Period or the time to move 1 pixel is Period / (Pi * Diameter). The highest apparent speed is the equator in the center, which is moving straight across our line of sight - as you move to the left/right sides of the equator, the movement speed sideways is lower because a bigger component of the motion is forward/away from us.

My point about the multi-point stacking is that the software will be trying to align each little part of the image around an alignment point separately. If you consider an alignment point dead central on Jupiter so that it is in the point of fastest motion, everything nearby is moving across at roughly the same speed due to Jupiter's rotation, so everything in the image box controlled by that align point is moving the same way. That means that - in theory - the alignment of each image with the reference one should compensate for the rotation effect. However, other align points will be working in areas of the image where the rotation speeds differ across the alignment box - that can't be compensated for by the alignment - at least not perfectly. Following that logic through, you would have to work out the difference in rotation rates across the width/height of each alignment box to see if the effect would be noticeable, and I haven't done that yet, but it does suggest that using a finer alignment grid might help let you get away with longer videos without having to properly derotate.

cheers,

Robin

[timh]

Thanks so much for this clear explanation Robin - yet again! Makes sense

I gathered some data with the barlow as an experiment last night so we'll see how that looks but I think that sky conditions were particularly bad.

One thing that did seem to work nicely though was the auto capture feature that you recently added. It worked to pick out the best of a bad bunch.