35 replies to this topic

[MyBluOx]

I decided that I needed to image Mars. I'm not real happy with the session. Here is the best:

 

Any advise on how to improve the images will be appreciated.

]

 

Here are the Firecapture log.

 

FireCapture v2.6  Settings

------------------------------------
Camera=ZWO ASI462MC
Filter=IR
Profile=Mars
Diameter=22.16"
Magnitude=-2.59
CM=230.7°  (during mid of capture)
FocalLength=6750mm
Resolution=0.09"
Filename=Mars_221240.avi
Date=151020
Start=221110.617
Mid=221240.621
End=221410.625
Start(UT)=051110.617
Mid(UT)=051240.621
End(UT)=051410.625
Duration=180.008s
Date_format=ddMMyy
Time_format=HHmmss
LT=UT -7h
Frames captured=25368
File type=AVI
Extended AVI mode=true
Compressed AVI=false
Binning=no
ROI=640x480
ROI(Offset)=648x312
FPS (avg.)=140
Shutter=2.000ms
Gain=263 (43%)
AutoGain=off
WRed=52 (off)
FPS=100 (off)
Brightness=1 (off)
USBTraffic=100 (off)
AutoExposure=off
HighSpeed=on
SoftwareGain=10 (off)
AutoHisto=75 (off)
Gamma=14 (off)
WBlue=95 (off)
Histogramm(min)=0
Histogramm(max)=94
Histogramm=36%
Noise(avg.deviation)=n/a
Limit=180 Seconds
Sensor temperature=30.4°C

 

Thank you,

 

Jeff

Edited by MyBluOx, 16 October 2020 - 01:19 PM.

[rkinnett]

Hi Jeff,

 

I like the color, and it looks like you captured some morning clouds/fog.  Color registration is pretty good.  Detail is subdued and slightly over-processed for my taste.

 

Your acquisition settings are helpful, but there are many other things that could be causing surface details to be washed out. 

 

Did you shoot this with your 12" LX200 and 2x Barlow?  How do you collimate and focus?

 

I see you captured 180 sec at 3ms exposures.. that should be a good combination.  You could get more bit depth if you capture to ser files instead of avi, but some folks here say that shouldn't make much of a difference, and that certainly would not make your detail more sharp.  The only other thing I see in your capture settings is your ROI.  Use a square ROI to reduce data volume to disk unless you specifically need extra margin for Mars to wiggle horizontally across this view.  More importantly, if you could afford to tighten up that ROI (without Mars getting too close to the edge as it dances around), you could potentially capture more frames.  A 360x360 ROI uses 42% as much data volume per frame as the ROI you're using.  Using that smaller ROI should more than double your frame rate and ultimately yield twice as many keeper frames as you're currently collecting.  That may allow you to be more selective (use smaller percentage) in your stacking.

 

What does your histogram look like in Autostakkert?  At what frame count percentage does the quality graph cross the 50% mark?  What frame stack percentage did you stack?  Using too high a percentage will blur your image, and the quality histogram is key to picking stack percentage.  You could also try making multiple stacks with varying percentages.  Try as low as 5%.  Are you using drizzle?  If so, you probably want to scale your image back down 50% or less unless you have crisp 1-2px scale detail.  In my limited experience, I very rarely capture fine enough detail to support the 3x drizzled scale, so it's almost always necessary to scale back down.  It's still useful to drizzle and do your processing at 3x, but scale it back down afterward.  This is counterintuitive, given the lengths we go to for magnification and detail, but this will make your image look sharper and more interesting.

 

What wavelet settings are you using in Registax?  It looks like a bit much of the levels 4+, and maybe even too much 3.  It's very tempting to crank those sliders up to boost contrast, but the higher levels make the image look over-processed, and in this case, it makes Mars look flat (in my opinion).

 

The main thing limiting detail here was almost certainly seeing, especially if you're confident in your collimation and focusing.  Some of the suggestions I'm describing here may help a little but it may be that surface detail information was just too scattered.

 

Hope some part of this helps..

[Kokatha man]

Seeing, collimation & focus are the number ones!

 

Without any knowledge of these 2 or the scope, a couple of points.

 

Avi's are absolutely fine for planets.

 

3 minutes  is too short when trying to get as many frames in a capture as possible to maximise your results.

 

At an f/l of 6750mm (if FC has measured it correctly, which by the angle of the presented image is unlikely btw) then you can go right up to 6 minutes with no worries whatsoever. (we do 5 mins with a similar f/l)

 

If you can use a 2ms exposure don't throw away light by running at 140fps...conversely if you want to run at 140fps set your exposure at about 7ms. (2ms can give you 500fps if you want to try that speed! )

 

The height of the ROI determines how fast you can push the fps: 640x480 is pretty large for Mars at the image scale used & as said it is also chewing up disk space unnecessarily unless you have a lot of trouble keeping Mars on the sensor: try something like 400x400 if possible which will give you more flexibility with frame-rates also. (you don't have to run at the maximum fps any ROI can achieve, but you'll still save disk space)

 

A 36% histogram is a bit low tbh, aim for something around 50% although if you need to go down to 45% you can get away with it ok. (we set ours' at 50%-55%)

[MyBluOx]

Hi Jeff,

 

I like the color, and it looks like you captured some morning clouds/fog.  Color registration is pretty good.  Detail is subdued and slightly over-processed for my taste.

 

Your acquisition settings are helpful, but there are many other things that could be causing surface details to be washed out. 

 

Did you shoot this with your 12" LX200 and 2x Barlow?  How do you collimate and focus?

 

I see you captured 180 sec at 3ms exposures.. that should be a good combination.  You could get more bit depth if you capture to ser files instead of avi, but some folks here say that shouldn't make much of a difference, and that certainly would not make your detail more sharp.  The only other thing I see in your capture settings is your ROI.  Use a square ROI to reduce data volume to disk unless you specifically need extra margin for Mars to wiggle horizontally across this view.  More importantly, if you could afford to tighten up that ROI (without Mars getting too close to the edge as it dances around), you could potentially capture more frames.  A 360x360 ROI uses 42% as much data volume per frame as the ROI you're using.  Using that smaller ROI should more than double your frame rate and ultimately yield twice as many keeper frames as you're currently collecting.  That may allow you to be more selective (use smaller percentage) in your stacking.

 

What does your histogram look like in Autostakkert?  At what frame count percentage does the quality graph cross the 50% mark?  What frame stack percentage did you stack?  Using too high a percentage will blur your image, and the quality histogram is key to picking stack percentage.  You could also try making multiple stacks with varying percentages.  Try as low as 5%.  Are you using drizzle?  If so, you probably want to scale your image back down 50% or less unless you have crisp 1-2px scale detail.  In my limited experience, I very rarely capture fine enough detail to support the 3x drizzled scale, so it's almost always necessary to scale back down.  It's still useful to drizzle and do your processing at 3x, but scale it back down afterward.  This is counterintuitive, given the lengths we go to for magnification and detail, but this will make your image look sharper and more interesting.

 

What wavelet settings are you using in Registax?  It looks like a bit much of the levels 4+, and maybe even too much 3.  It's very tempting to crank those sliders up to boost contrast, but the higher levels make the image look over-processed, and in this case, it makes Mars look flat (in my opinion).

 

The main thing limiting detail here was almost certainly seeing, especially if you're confident in your collimation and focusing.  Some of the suggestions I'm describing here may help a little but it may be that surface detail information was just too scattered.

 

Hope some part of this helps..

Ryan,

Thank you for the advice. I'll try to answer all you questions. 

 

!) I did shoot with the 12" and a 1.5x barlow

2) I'll try a 360x360 ROI.

3) Here is the quality graph of Autostakkert:

I used 10% and no drizzle

4) Here are my Registax6 wavelet settings.

5) I'll check my collimation tonight. It doesn't change much if at all for quite a while. For focusing I try to eyeball it. I have tried a Bahtinov Mask; but I find I get a better focus by eyeball on planets.

Seeing is rather bad in the desert from the heat and I try to wait until it cools down a bit, before I image.

 

Jeff

[MyBluOx]

Seeing, collimation & focus are the number ones!

 

Without any knowledge of these 2 or the scope, a couple of points.

 

Avi's are absolutely fine for planets.

 

3 minutes  is too short when trying to get as many frames in a capture as possible to maximise your results.

 

At an f/l of 6750mm (if FC has measured it correctly, which by the angle of the presented image is unlikely btw) then you can go right up to 6 minutes with no worries whatsoever. (we do 5 mins with a similar f/l)

 

If you can use a 2ms exposure don't throw away light by running at 140fps...conversely if you want to run at 140fps set your exposure at about 7ms. (2ms can give you 500fps if you want to try that speed! )

 

The height of the ROI determines how fast you can push the fps: 640x480 is pretty large for Mars at the image scale used & as said it is also chewing up disk space unnecessarily unless you have a lot of trouble keeping Mars on the sensor: try something like 400x400 if possible which will give you more flexibility with frame-rates also. (you don't have to run at the maximum fps any ROI can achieve, but you'll still save disk space)

 

A 36% histogram is a bit low tbh, aim for something around 50% although if you need to go down to 45% you can get away with it ok. (we set ours' at 50%-55%)

Kokatha Man,

 

I put the histogram a 36% because Mars was so bright and was looking washed out. I'll try it at 45-50% tonight. I'll also try imaging at 5 min.

as for focusing and collimation check my post above this one.

 

Jeff

[rkinnett]

Your quality histogram looks exactly like mine most nights.  Seeing was pretty bad and it's unlikely you'll recover more detail than you already have.  With that histogram, I would suggest stacking 3% and 5% and see if either of those yields more detail than your 10% stack, and I'll bet 5% give the best balance between noise and detail.  In Registax, try turning off levels 3-6 and pull level 2 all the way up to 100.  You'll lose contrast between large-scale features but you can recover contrast with a curve stretch in Photoshop.  Those higher levels are over-emphasizing the edge of the disk and making it look 2-dimensional.

 

Any reason not to use your 2x barlow?  There are some good tips on f-ratio here:  http://www.ajax.ehu....istopher_Go.pdf

 

Kokatha Man, 5 minute captures?!  Are you sure?  That's guaranteed to add blur, but maybe the higher frame count makes that a good trade, especially in seeing conditions where you can only use 5% or so of the frames.

[Kokatha man]

Kokatha Man, 5 minute captures?!  Are you sure?  That's guaranteed to add blur, but maybe the higher frame count makes that a good trade, especially in seeing conditions where you can only use 5% or so of the frames.

Am I sure  we've been at this caper of hi-res imaging for quite some time now bro & I think our images are our proof, if I may be so bold - 5 minutes is easy-peasy...nothing against you personally Ryan, but there is so much bunkum posted about this "rotational blurring" business & I get so annoyed about it being perpetrated.

[Ittaku]

Want to put up the pre-processed image for us to play with? That'll give you an idea if the issue is pre or post processing since some people here are magic with extracting whatever information is buried within your image. Ideally put up the video itself but the bandwidth is usually prohibitive. I prefer to play with undrizzled stacked images, whilst others prefer using drizzled ones; neither would be very big files.

[rkinnett]

Am I sure  we've been at this caper of hi-res imaging for quite some time now bro & I think our images are our proof, if I may be so bold - 5 minutes is easy-peasy...nothing against you personally Ryan, but there is so much bunkum posted about this "rotational blurring" business & I get so annoyed about it being perpetrated.

Didn't mean to question your authorit-ah! 

 

But I mean, you're saying he might as well shoot ten minutes at a time?   (I'm being facetious)

 

I see your point though.  Bear with me as I try to reason through why you're right.  Over the span of 5 mins, the point at the center of the disk travels 0.24".  His imaging scale is 0.1"/px, so light from that point at the center spreads across 2.4 pixel widths.  That's compared to 1.4px smear over a 3 minute capture.  Is that extra 1px smear worth it?  Is it even detectable?  In this case, unfortunately, an extra 1px smear is simply not detectable given the scale of the rendered detail is larger than 2px (seemingly due to poor seeing).  The advantage of capturing 66% more frames outweighs the cost in motion blur.  It appears that, indeed, in poor seeing and/or with low frame rates, it's a worthwhile trade to extend beyond the more conventional 4 minute limit.

[Tom Glenn]

Over the span of 5 mins, the point at the center of the disk travels 0.24".  His imaging scale is 0.1"/px, so light from that point at the center spreads across 2.4 pixel widths.  That's compared to 1.4px smear over a 3 minute capture.  Is that extra 1px smear worth it?  Is it even detectable?  

If the only way to stack images was using a "global alignment" method, in which each individual frame is moved as a whole, then you would be correct about the rotational shift.  But the current stacking methods, such as used in Autostakkert, uses a "local" alignment method, which breaks apart each frame into a number of alignment points.  These are your "APs" that you place.  The advantage is that frame is not kept as a completely unit, but rather the APs are individually ranked, aligned, stacked, and stitched together as if they were each individual small images.  This means that small amounts of rotation are actually compensated for during the alignment procedure, because Autostakkert locks onto contrast features located within each AP.  The only consequence is that as you get closer to the limb of the planet, there is no longer a perfect match between APs over the course of a longer duration video.  So, blurring is confined to the limb.  However, the limb of planets is already associated with many artifacts in amateur images (diffraction edge artifacts, Gibbs artifacts) as well as a general absence of detail because of foreshortening.  So essentially, the rotational blurring is invisible.  Some older articles you find on the internet give outdated limits for imaging, because they were using older versions of the software.  

[Rac19]

For comparison here's mine from the same at about 13:00 UT. I had the gamma cranked up to 95% and my exposure time was about 22 ms. I did pay attention to focus (using a Bahtinov mask) and collimation. The seeing indexes were good but the jet stream was about 25 m/s and the bad layers were, well, bad. I put the poor detail down to those factors, and of course an inferior resolution.

 

EDIT: Actually, I see that my exposure was 10x the OP which could affect lucky imaging. I will try a higher gain a lower exposure next time.

 

FireCapture v2.6  Settings
------------------------------------
Camera=ZWO ASI1600MC
Filter=N
Profile=Mars
Diameter=22.21"
Magnitude=-2.60
CM=350.6°  (during mid of capture)
FocalLength=4600mm
Resolution=0.17"
Filename=Mars_234827_N_151020_Gain=140(off)_Exposure=22.4ms_Gamma=95.avi
Date=151020
Start=234727.950
Mid=234827.955
End=234927.960
Start(UT)=124727.950
Mid(UT)=124827.955
End(UT)=124927.960
Duration=120.010s
Date_format=ddMMyy
Time_format=HHmmss
LT=UT +10h
Frames captured=5349
File type=AVI
Extended AVI mode=true
Compressed AVI=false
Binning=no
ROI=776x526
ROI(Offset)=2040x1432
FPS (avg.)=44
Shutter=22.42ms
Gain=140 (23%)
HighSpeed=off
SoftwareGain=10 (off)
Brightness=0 (off)
AutoHisto=75 (off)
FPS=100 (off)
HardwareBin=off
USBTraffic=70 (off)
WBlue=90 (off)
WRed=50 (off)
AutoExposure=off
AutoGain=off
Gamma=95
Histogramm(min)=0
Histogramm(max)=87
Histogramm=34%
Noise(avg.deviation)=n/a
Limit=120 Seconds
Sensor temperature=35.5°C
Focuser position=21344

Attached Thumbnails

• 

Edited by Rac19, 17 October 2020 - 02:45 AM.

[Kokatha man]

But I mean, you're saying he might as well shoot ten minutes at a time?   (I'm being facetious)

 

Yeah - sure, why not: Kevin (Astrovienna) has a good tute on video derotation...he could use that..!

 

Jeff tried 180" & now it seems Richard is even more timid with 120 seconds - glory be...I give up, this "rotational blurring" nonsense seems to have gripped planetary imagers the world over!   

[Rac19]

Yeah - sure, why not: Kevin (Astrovienna) has a good tute on video derotation...he could use that..!

 

Jeff tried 180" & now it seems Richard is even more timid with 120 seconds - glory be...I give up, this "rotational blurring" nonsense seems to have gripped planetary imagers the world over!   

Reducing the effects of rotation was the reason that I limited the run to 120". That did yield over 5,000 frames of which I stacked the best 5% (250 frames). Looking at the best of the frames, sorted by quality in AS!3, even the best of them didn't look very good. i am keen to try the shortest possible exposure time, noise permitting.

 

I am not sure that many times more frames. with de-rotation would help. By this I mean that I think that I need better "lucky images" at the moment, not more of them.

Edited by Rac19, 17 October 2020 - 04:51 AM.

[MyBluOx]

Want to put up the pre-processed image for us to play with? That'll give you an idea if the issue is pre or post processing since some people here are magic with extracting whatever information is buried within your image. Ideally put up the video itself but the bandwidth is usually prohibitive. I prefer to play with undrizzled stacked images, whilst others prefer using drizzled ones; neither would be very big files.

Ittaku,

 

You can get the pre-processed image here:

https://www.dropbox...._ap389.tif?dl=0

 

I look forward to seeing how other people process it.

 

Jeff

[Kokatha man]

Reducing the effects of rotation was the reason that I limited the run to 120". That did yield over 5,000 frames of which I stacked the best 5% (250 frames). Looking at the best of the frames, sorted by quality in AS!3, even the best of them didn't look very good. i am keen to try the shortest possible exposure time, noise permitting.

 

I am not sure that many times more frames. with de-rotation would help. By this I mean that I think that I need better "lucky images" at the moment, not more of them.

250 frames is not nearly enough no matter how good or bad they are in normal circumstances!

 

I don't know what you mean by being <"keen to try the shortest possible exposure time, noise permitting.">  except that you appear to wish to lower the exposure or shutter speed to get faster/fastest frame rate. (fps)

 

This would naturally mean more frames regardless of how long you let your capture duration run for..!

 

The only other interpretation is that you want to lower your capture duration but that of course is not "exposure."

 

Whatever you meant to say let me be absolutely clear on this: you want as many frames as possible which, regardless of the fps you utilise means you should be running the captures for as long as possible - 5 to 6 minutes for Mars!!!

 

You also state <"I am not sure that many times more frames. with de-rotation would help. By this I mean that I think that I need better "lucky images" at the moment, not more of them.">

 

I never mentioned derotation for starters except in an equally facetious response to Ryan facetious comments: "lucky imaging" is all about getting as many frames as possible to maximise the number & possible selection quality therein - so of course you should want as many as possible to choose from!!!

 

At the image scale/focal length you employed you could easily run your captures for 6 minutes to come up with better outcomes.

 

As said we regularly use 5 minute captures for our Mars images - if you need any confirmation of what this creates go & look at any of the images I post for heaven's sake!

 

Apologies for being so particular about this, it is not personal   but the number of people who come on this forum that have apparently been brain-washed into thinking "rotational blurring" rears its ugly head in more than 1, 2 or 3 minutes is absolutely ridiculous & something that should be counteracted at every opportunity..! 

[Rac19]

250 frames is not nearly enough no matter how good or bad they are in normal circumstances.

 

<Snip>

 

Apologies for being so particular about this, it is not personal   but the number of people who come on this forum that have apparently been brain-washed into thinking "rotational blurring" rears its ugly head in more than 1, 2 or 3 minutes is absolutely ridiculous & something that should be counteracted at every opportunity..! 

I definitely don't take it personally and appreciate the comments.

 

What I was trying to say was that even the best frames were not so good and improving them would seem to be a priority. That depends partly on better conditions.

 

With regard to shorter exposure times, I meant to say that the shorter the exposure, the better chance of exposures with minimal atmospheric distortion. Naturally this also means more frames for any given period of time.

 

I am not at all keen on using de-rotation software and the choice of 2 minutes was arbitrary. I will try 5 minutes next time. With a shorter exposure and longer recording time, there could be over 50,000 frames.

 

I checked on the Mars speed of rotation and see that it is the same as Earth. Jupiter, by way of comparison, is more than twice that speed.

 

Cloudy nights are the main problem at the moment.

[Ittaku]

Ittaku,

 

You can get the pre-processed image here:

https://www.dropbox...._ap389.tif?dl=0

 

I look forward to seeing how other people process it.

I'm just a newcomer so nowhere near as good as some of the wizards here with post-processing, but a quick attempt gives me something like this:

 

[Rac19]

I'm just a newcomer so nowhere near as good as some of the wizards here with post-processing, but a quick attempt gives me something like this:

 

That looks pretty good to me.

 

EDIT: I can only see one image in Dropbox, which looks really bad. 

Edited by Rac19, 17 October 2020 - 08:41 PM.

[Kokatha man]

Hi again Richard, my Post #3 here lays out the priorities...the thrust of my latter response to you was predicated upon the 2 minute capture timespan I saw in your FC .txt & I wanted to emphasise the short-comings of such a duration.

 

Probably my zealous response to what I see as one of the major furphies being constantly disseminated on these forums!

 

As well, I'm between a rock & a hard place when confronted with some of the perpetrators of the "rotational blurring" brigade: they are often non-imagers (true!) or relative newbies who seem to like to argue despite reality...as an inveterate user of 5 & 6 minute Mars captures I feel obliged to ask them to look at our website or forum images to display what these time-spans create.

 

Btw, like Jeff (the OP) you are also using incorrect gamma settings. (each of you are on either side of the spectrum!)

 

Gamma shoud be set at "50" for capturing...you can increase it for a focus aid but must capture at "50" - I overlooked this before because I confused the threads where I had made specific points about gamma to Abe in this thread:  https://www.cloudyni...my-mars-data/     

[Ittaku]

That looks pretty good to me.

 

EDIT: I can only see one image in Dropbox, which looks really bad. 

That's the one I worked off.

[CosmicDave]

 

Others here have more expertise, but I've been trying to make the most of poor seeing conditions for Mars lately, so here's my quick treatment;

 

Registax 6: wavelets linear/default (not gaus)- layer 2 only (slider at 59), flip&rotate.  AstraImage: light deconvolution ( Lucy Richardson), denoise, color balance adjust. 

 

Good luck,

Dave

 

[rkinnett]

If the only way to stack images was using a "global alignment" method, in which each individual frame is moved as a whole, then you would be correct about the rotational shift.  But the current stacking methods, such as used in Autostakkert, uses a "local" alignment method, which breaks apart each frame into a number of alignment points.  These are your "APs" that you place.  The advantage is that frame is not kept as a completely unit, but rather the APs are individually ranked, aligned, stacked, and stitched together as if they were each individual small images.  This means that small amounts of rotation are actually compensated for during the alignment procedure, because Autostakkert locks onto contrast features located within each AP.  The only consequence is that as you get closer to the limb of the planet, there is no longer a perfect match between APs over the course of a longer duration video.  So, blurring is confined to the limb.  However, the limb of planets is already associated with many artifacts in amateur images (diffraction edge artifacts, Gibbs artifacts) as well as a general absence of detail because of foreshortening.  So essentially, the rotational blurring is invisible.  Some older articles you find on the internet give outdated limits for imaging, because they were using older versions of the software.  

Hi Tom!  With all due respect, the premise that Autostakkert aligns sections of the image individually and stiches the pieces back together is not at all how it works.  During the alignment phase, AS evaluates alignment error at each AP across the frame and then calculates a single alignment transformation which minimizes error across all of the alignment points for that frame, subject to weighting as you described.  It then applies that transformation to the frame globally, not in pieces as you say.  This is an important distinction.  If it moved the pieces around individually and reassembled them, then you would be correct that it compensates for differential drift, to a degree, but it just doesn't work that way. 

 

Let's say AS is aligning one frame from the end of a recording and evaluating against a reference frame from the begging of the recording, and the recording is sufficiently long such that the detail at the center of the disk will in fact have shifted multiple pixels.  If you use evenly-distributed APs (i.e. using auto-place), then the transformation will be influenced both by the APs along the edge of the disk and those near the center, such that the least-error transformation is a combination of the two.. it doesn't perfectly align the equatorial limbs or the center.. it compromises between the two, yielding sub-optimal alignment at both the limbs and center.  I agree completely with your later points that misalignment at the limb does not matter so much, and per my earlier post, 1px or so of residual alignment error at the center or elsewhere is in the noise for most of us mortals.  Which is all to say that indeed most of us can afford to add a few minutes to our captures.

[Rac19]

lProbably my zealous response to what I see as one of the major furphies being constantly disseminated on these forums!    

Thanks for the additional info. I appreciate all the help and advice. I was pretty sure that you were Australian from your profile but the use of the word furphy confirms it, as does your web excellent site.

 

I have always wondered whether or not the gamma value should be changed during image capture and will try it next time. Clouds are the main problem at the moment.

[Tom Glenn]

Hi Tom!  With all due respect, the premise that Autostakkert aligns sections of the image individually and stiches the pieces back together is not at all how it works.  During the alignment phase, AS evaluates alignment error at each AP across the frame and then calculates a single alignment transformation which minimizes error across all of the alignment points for that frame, subject to weighting as you described.  It then applies that transformation to the frame globally, not in pieces as you say.  This is an important distinction.  If it moved the pieces around individually and reassembled them, then you would be correct that it compensates for differential drift, to a degree, but it just doesn't work that way. 

 

Let's say AS is aligning one frame from the end of a recording and evaluating against a reference frame from the begging of the recording, and the recording is sufficiently long such that the detail at the center of the disk will in fact have shifted multiple pixels.  If you use evenly-distributed APs (i.e. using auto-place), then the transformation will be influenced both by the APs along the edge of the disk and those near the center, such that the least-error transformation is a combination of the two.. it doesn't perfectly align the equatorial limbs or the center.. it compromises between the two, yielding sub-optimal alignment at both the limbs and center.  I agree completely with your later points that misalignment at the limb does not matter so much, and per my earlier post, 1px or so of residual alignment error at the center or elsewhere is in the noise for most of us mortals.  Which is all to say that indeed most of us can afford to add a few minutes to our captures.

I am not an expert in the software, but I would have to defer to Emil (the author of Autostakkert) to address these issues.  You may very well be correct on these details, but the important points to me are twofold: 1) the local AP alignment method is vastly superior to the global alignment method, and 2) empirical evidence clearly demonstrates that capture durations much longer than theoretical predictions are superior, and do not lead to rotational blurring at the image scales presented.  Why this is the case is open to speculation, but I have frequently captured 6 minutes for Mars and Saturn, and 3 minutes for Jupiter (with color cameras) and did not suffer any negative consequences.  On the contrary, I have captured for shorter durations and had inferior results, due to less frames collected.  In addition to the "lucky" imaging principle of obtaining individual good frames, there is an important component to building a deep stack that can better tolerate deconvolution (or wavelets), without becoming noisy.  

Edited by Tom Glenn, 18 October 2020 - 02:16 AM.

[Tom Glenn]

And Ryan, another interesting consideration is an observation I have noticed from lunar imaging.  Despite the fact that during a normal lunar capture, the Moon experiences no significant change in perspective, your choice of AP size will affect the final position of many surface features.  This is best tested in a wide field, high resolution image, containing thousands of APs.  If you alter the AP size and make different stacks with each setting, and then layer them in a blinking animation, features such as small craters and mountains will shift by several pixels between the images, despite the fact that the raw data is identical, and the only variable changed was the AP size.  This is caused by the fact that the raw video has distortion from atmospheric turbulence, and therefore when the APs are mapped to the reference frame, you do not get equivalent results between the different AP size selections.  There is some element of randomness to it.  If we didn't have an atmosphere to image through, and the raw data was perfect, then you would expect each stack to be identical, regardless of the AP selections.  I think this explains why capture durations longer than theoretical rotational limits work.  The amount of physical distortion that occurs from rotation remains less than the apparent distortion that occurs from turbulence, and so it remains undetectable in normal captures.  If you were imaging from low Earth orbit, next to Hubble, you would be subject to different limits, but you also wouldn't need deep stacks in that case.