Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

AutoStakkert 3: To double stack, or not to double stack?

  • Please log in to reply
48 replies to this topic

#1 DMach

DMach

    Viking 1

  • -----
  • topic starter
  • Posts: 659
  • Joined: 21 Nov 2017
  • Loc: The most light-polluted country in the world :(

Posted 13 April 2019 - 01:32 AM

Any opinions on the "Double Stack Reference" option in AutoStakkert 3?

 

I'm struggling to decide whether it's worth the extra (almost double) processing time ...



#2 Tom Glenn

Tom Glenn

    Surveyor 1

  • -----
  • Posts: 1649
  • Joined: 07 Feb 2018
  • Loc: San Diego, CA

Posted 13 April 2019 - 01:48 AM

Not only is it not worth it, it will make the result worse.  Whenever I tried it head to head with the normal single stack version, the double stack produced a noticeably inferior result.  This was very noticeable on the Moon, in which the single stack produced a sharp result and the double stack was always blurred.  I don't know what it's supposed to do, but it definitely doesn't work well and is to be avoided.  I should add that I only tried it for lunar imaging, and after seeing how horribly it performed, never considered trying for planets.  Maybe others have different experiences, but I seem to recall some posts in the past where others agreed that the double stack doesn't help, and seems to hurt.  


Edited by Tom Glenn, 13 April 2019 - 01:58 AM.

  • DMach likes this

#3 DMach

DMach

    Viking 1

  • -----
  • topic starter
  • Posts: 659
  • Joined: 21 Nov 2017
  • Loc: The most light-polluted country in the world :(

Posted 13 April 2019 - 07:39 AM

Not only is it not worth it, it will make the result worse.  Whenever I tried it head to head with the normal single stack version, the double stack produced a noticeably inferior result.  This was very noticeable on the Moon, in which the single stack produced a sharp result and the double stack was always blurred.  I don't know what it's supposed to do, but it definitely doesn't work well and is to be avoided.  I should add that I only tried it for lunar imaging, and after seeing how horribly it performed, never considered trying for planets.  Maybe others have different experiences, but I seem to recall some posts in the past where others agreed that the double stack doesn't help, and seems to hurt.  

Thanks Tom ... I didn't want to bias the conversation, but that does indeed match with my impression: seems to actually make it more blurry!

 

My follow-up question would be: how many have moved to AS! 3, and how many have stuck with v2?



#4 aeroman4907

aeroman4907

    Viking 1

  • -----
  • Posts: 876
  • Joined: 23 Nov 2017
  • Loc: Castle Rock, Colorado

Posted 13 April 2019 - 07:51 AM

I would completely agree with Tom, results are worse.

 

I work with AS!3.



#5 Kokatha man

Kokatha man

    Voyager 1

  • *****
  • Posts: 12499
  • Joined: 13 Sep 2009
  • Loc: "cooker-ta man" downunda...

Posted 13 April 2019 - 08:30 AM

Thanks Tom ... I didn't want to bias the conversation, but that does indeed match with my impression: seems to actually make it more blurry!

 

My follow-up question would be: how many have moved to AS! 3, and how many have stuck with v2?

...I'm hoping something new comes onto the scene in the near future - I cannot remember who it was who posted on a new stacking software that several people were collaborating on atm...this person posted on this in the last 3-6 months here. confused1.gif

 

Interesting point about AS!3 Vs AS!2...I'd have to do a comparison with some "dubious" captures I have gathered over time but I have this distinct recollection that #2 handled split frames where the planet moved off or half-off the screen better, I particularly recall some aweful situations where winds were abominable with Mars being blown off the screen regularly during captures a few years back, but the resultant stacks were fine: with AS!3 I've had to employ PIPP a few times to throw out the "splits" etc because there were too many too manually delete. frown.gif

 

In my current thread I've shown an example where I "think" AS!3 is at the very least "hindered" in making accurate sharpnes/contrast estimations - quite possibly allied to our capture parameters etc but still disconcerting when I know that selecting qualities right down to nearly "3%" cut-offs will result in acceptable stacks...I can appreciate that if AS!3 selects a "split" frame it is because it thinks the greatest contrast variations are present here & this "might" skew somewhat, but I thought #2 was better at rejecting these & was only talking about it to Pat recently.

 

I have a feeling that Emil has abandoned any further development on AS! perhaps - somewhat akin to Cor seeming to lose interest or decide not to update anymore around the time when AS! took precedence over R6 as a stacking software...a real pity tbh because AS! has been a mainstay of planetary process for a long time now & invaluable imho!


  • RedLionNJ likes this

#6 kbev

kbev

    Apollo

  • -----
  • Posts: 1006
  • Joined: 29 Dec 2010
  • Loc: Far, far east Mesa

Posted 13 April 2019 - 08:37 AM

I cannot remember who it was who posted on a new stacking software that several people were collaborating on atm...this person posted on this in the last 3-6 months here. confused1.gif

 

That would be Rolf, the one who also created the MoonPanoramaMaker plugin for Firecapture.



#7 RedLionNJ

RedLionNJ

    Gemini

  • *****
  • Posts: 3384
  • Joined: 29 Dec 2009
  • Loc: Red Lion, NJ, USA

Posted 13 April 2019 - 10:27 AM

That would be Rolf, the one who also created the MoonPanoramaMaker plugin for Firecapture.

Not to stray terribly far from the original thread, but yes - that was Rolf. I was never able to get his Python solution (admittedly not even quite at the beta stage) to work for me. Too many undocumented library dependencies, all of which you have to locate (the correct version of) and download yourself. But Rolf was totally in agreement with this - still far from a practical solution.  The other aspect was that Rolf's Python implementation was more at the 'proof of concept' phase - nobody would really use Python for a finished 'product' - just too inefficient. But then, vert few people thought you could ever make a great capture product in Java - Torsten proved 'em all wrong, there (I am glad to say).

 

Back to on-topic:  I get the principle behind double-stacking (or I think I do), but I've never seen it make a positive difference on my data. I've also rarely had really, really good data, though. So I was always giving it the benefit of the doubt. I'd try it from time to time and it wouldn't make things any better.

 

To be honest, I'm not convinced I'm using AS!3 optimally at all. I've seen too many different opinions on how it could/should be used - and more than one set of steps can lead to great results.

For example, on Jupiter, if I use 'local', do I need to place my APs first before analyzing? Should I analyze first, prior to anything else, in order to put the sharpest frame first, so I know where to put my APs? Is manual AP placement on Jupiter really any better than automatic placement? Laplace vs non-Laplace?  A noise robust level of 4 vs 5?

 

The only person who can likely definitively document these kind of answers is the overly-busy Emil. And I get that we all have pet projects which we're sometimes massively-invested in, yet at other times lose interest in for several months at a time.  But like others, it would make me really happy if Emil could make the time to maybe tweak AS!3 or at least document HIS ideal, total AS!3 workflow for some situations (we've all seen his end results).

 

Here's hoping something can happen....

 

Grant



#8 kevinbreen

kevinbreen

    Surveyor 1

  • -----
  • Posts: 1536
  • Joined: 01 Mar 2017
  • Loc: Wexford, Ireland

Posted 13 April 2019 - 12:26 PM

I’m with Grant here - I suspect I don’t use AS3 to its full potential. I’ve been using it for 2 years.

At first I loaded a video and just pressed analyse.

Then (I think I read this on Darryl’s tutorial) I changed to putting the APs onto what my eye judged to be the best frame, reasoning that the software would use that as the benchmark upon which to judge the other frames.

Then, quite recently, I began to doubt I could visually appraise the frames effectively (a lot of them are really crap as a result of bad seeing).

So now I analyse without any APs.
I go to the frame where the quality graph says it’s best.
I use that frame as my AP frame.
I analyse again.
I select a number of frames to stack and proceed to Reg6, or the pub if the results are lousy.

On the subject of AS still further, I set Normalize Stack to usually 40%, which allows me lots of sharpening headroom in Reg6 because the data is usually woeful.

I’d be interested to learn what the AS workflow of other imagers is.

#9 RedLionNJ

RedLionNJ

    Gemini

  • *****
  • Posts: 3384
  • Joined: 29 Dec 2009
  • Loc: Red Lion, NJ, USA

Posted 13 April 2019 - 01:10 PM

I’m with Grant here - I suspect I don’t use AS3 to its full potential. I’ve been using it for 2 years.


On the subject of AS still further, I set Normalize Stack to usually 40%, which allows me lots of sharpening headroom in Reg6 because the data is usually woeful.

I’d be interested to learn what the AS workflow of other imagers is.

Wouldn't normalizing to 40% be effectively cutting your dynamic range to 40% of maximum?

Although I'm not sure that really matters quite so much for planetary work.



#10 Achernar

Achernar

    Voyager 1

  • *****
  • Posts: 11152
  • Joined: 25 Feb 2006
  • Loc: Mobile, Alabama, USA

Posted 13 April 2019 - 01:44 PM

In a word, don't. Other posters are right, and I have also tried doing that and the results are always a lot worse. You'll just be wasting time and effort.

 

Taras



#11 kevinbreen

kevinbreen

    Surveyor 1

  • -----
  • Posts: 1536
  • Joined: 01 Mar 2017
  • Loc: Wexford, Ireland

Posted 13 April 2019 - 06:42 PM

Wouldn't normalizing to 40% be effectively cutting your dynamic range to 40% of maximum?
Although I'm not sure that really matters quite so much for planetary work.


Well, probably. But let me ask this question. What’s the purpose of normalise stack? It’s to set the histogram max of the sharpened tif, right? That’s my understanding.
Unless I do this then I’m soon over 100% when I do even modest sharpening in Reg6.
Unless there’s something fundamentally wrong with how I capture in the first place, which wouldn’t surprise me.

#12 Kokatha man

Kokatha man

    Voyager 1

  • *****
  • Posts: 12499
  • Joined: 13 Sep 2009
  • Loc: "cooker-ta man" downunda...

Posted 13 April 2019 - 06:51 PM

Kevin - it wasn't me that suggested those approaches! lol.gif

 

I've shown my MAPs setups numerous times & there is an example of Jupiter on my website tute pages...but just to be clear I find no difference whatsoever between running through the "quality estimation" before any MAPs are applied - or after.

 

I certainly wouldn't be setting "stack normalisation" to 40% anytime btw - I don't think your reasoning holds water & I always set it between about 65% & 80% depending upon capture data.

 

Seeing your very last post Kevin you're setting the brightness of each frame at a % relative to the brightest frame (this can vary during any capture duration for more than one reason) & if you set a reasonable histogram for the capture there should be no reason why you are going to be "cut short" there.

 

Grant, I think you're romanticising any "special" capability of Emil's in using the software he wrote tbh...just a personal opinion but he got me to send him some excellent Saturn data back in late May 2016 where I carefully followed his exact stipulations as to how to create the RAW stacks from the capture data via his MAPs layouts & other settings...plus the various stack-sizes he wanted me to provide - it was too difficult to send the avi's at that time.

 

After quite some time he (grudgingly lol.gif ) admitted he could not better my own processings so I think you are being a bit over-optimistic if you think there is some "magic" that you haven't been initiated into...excellent data is just that & although I don't fully agree with the mantra that "the best data processes itself" you are on a hiding to nothing trying to make average or even good data compete with that from a night of really excellent seeing.

 

Incidentally - as one of those "hoarders" who can look up every email I ever sent or received lol.gif I've checked through the correspondence I've just referred to & interestingly here's a quote of mine in one email to Emil that reinforces something else I've said here: <"I haven't bothered making one of my own stacks here because there is a heap of data without me adding more...tbh your MAPs layout is very similar to my own except I don't bother with all those ring boxes unless I get that type of seeing that induces splits in the C.D. at the ansae...placing boxes like you have can often fix that problem then.">

 

The <"I don't bother with all those ring boxes unless I get that type of seeing that induces splits in the C.D. at the ansae"> that I was referring to was where Emil requested I place MAPs of specific sizes & placings all along the ring system of Saturn...

 

I might well be wrong (hopefully! :) ) but I seem to think he has more than "lost interest for several months" but only time will tell on that I'm afraid! wink.gif

 

 

 

 

 

 


  • RedLionNJ likes this

#13 kevinbreen

kevinbreen

    Surveyor 1

  • -----
  • Posts: 1536
  • Joined: 01 Mar 2017
  • Loc: Wexford, Ireland

Posted 13 April 2019 - 07:03 PM

Kevin - it wasn't me that suggested those approaches! lol.gif

I've shown my MAPs setups numerous times & there is an example of Jupiter on my website tute pages...but just to be clear I find no difference whatsoever between running through the "quality estimation" before any MAPs are applied - or after.

I certainly wouldn't be setting "stack normalisation" to 40% anytime btw - I don't think your reasoning holds water & I always set it between about 65% & 80% depending upon capture data.

Seeing your very last post Kevin you're setting the brightness of each frame at a % relative to the brightest frame (this can vary during any capture duration for more than one reason) & if you set a reasonable histogram for the capture there should be no reason why you are going to be "cut short" there.

Grant, I think you're romanticising any "special" capability of Emil's in using the software he wrote tbh...just a personal opinion but he got me to send him some excellent Saturn data back in late May 2016 where I carefully followed his exact stipulations as to how to create the RAW stacks from the capture data via his MAPs layouts & other settings...plus the various stack-sizes he wanted me to provide - it was too difficult to send the avi's at that time.

After quite some time he (grudgingly lol.gif ) admitted he could not better my own processings so I think you are being a bit over-optimistic if you think there is some "magic" that you haven't been initiated into...excellent data is just that & although I don't fully agree with the mantra that "the best data processes itself" you are on a hiding to nothing trying to make average or even good data compete with that from a night of really excellent seeing.

Incidentally - as one of those "hoarders" who can look up every email I ever sent or received lol.gif I've checked through the correspondence I've just referred to & interestingly here's a quote of mine in one email to Emil that reinforces something else I've said here: <"I haven't bothered making one of my own stacks here because there is a heap of data without me adding more...tbh your MAPs layout is very similar to my own except I don't bother with all those ring boxes unless I get that type of seeing that induces splits in the C.D. at the ansae...placing boxes like you have can often fix that problem then.">

The <"I don't bother with all those ring boxes unless I get that type of seeing that induces splits in the C.D. at the ansae"> that I was referring to was where Emil requested I place MAPs of specific sizes & placings all along the ring system of Saturn...

I might well be wrong (hopefully! :) ) but I seem to think he has more than "lost interest for several months" but only time will tell on that I'm afraid! wink.gif


Darryl
“I've shown my MAPs setups numerous times & there is an example of Jupiter on my website tute pages...but just to be clear I find no difference whatsoever between running through the "quality estimation" before any MAPs are applied - or after.”

So why do you set the MAPs before running the quality estimator?

I certainly wouldn't be setting "stack normalisation" to 40% anytime btw - I don't think your reasoning holds water & I always set it between about 65% & 80% depending upon capture data.

For me this results in a histogram that’s too close to 100% to allow much processing before I’m clipping. What the heck am I doing wrong?

Seeing your very last post Kevin you're setting the brightness of each frame at a % relative to the brightest frame (this can vary during any capture duration for more than one reason) & if you set a reasonable histogram for the capture there should be no reason why you are going to be "cut short" there.

Do you mean my last run of 6 Jupiters?

#14 DMach

DMach

    Viking 1

  • -----
  • topic starter
  • Posts: 659
  • Joined: 21 Nov 2017
  • Loc: The most light-polluted country in the world :(

Posted 13 April 2019 - 07:08 PM

For example, on Jupiter, if I use 'local', do I need to place my APs first before analyzing? Should I analyze first, prior to anything else, in order to put the sharpest frame first, so I know where to put my APs?

I have wondered this myself ...

 

I've shown my MAPs setups numerous times & there is an example of Jupiter on my website tute pages...but just to be clear I find no difference whatsoever between running through the "quality estimation" before any MAPs are applied - or after.

... and it would appear Darryl has done that experiment!

 

One additional wrinkle though: I'm in the midst of processing some (fingers crossed**) nice data from 13th June, testing a variety of variables in AS3 (and using AS2 for comparison). I need to check this a few more times, but I got *very* different quality estimates over multiple analyses in AS3 ... not sure why!

 

**The quality graph in AS2 looks like this:

Jupiter 2019-04-13 05-00 quality graph AS2.JPG

so I'm hopeful!

 

The dips in quality are where I nudged the mount ... to Darryl's earlier point, I have a feeling AS2 is better at detecting/rejecting these than AS3? Need to check that too.


Edited by DMach, 13 April 2019 - 08:03 PM.

  • RedLionNJ likes this

#15 Kokatha man

Kokatha man

    Voyager 1

  • *****
  • Posts: 12499
  • Joined: 13 Sep 2009
  • Loc: "cooker-ta man" downunda...

Posted 13 April 2019 - 10:02 PM

DISCLAIMER: what I post are my own opinions/thoughts based on experience (often) & conjecture. (almost as often!) rofl2.gif

 

Kevin - tbh I always thought it was important to set the MAPs first before "Analyse" but like a lot of things I subsequently found it was either wrong or unnecessary! wink.gif

 

Since then I came to appreciate that the "Quality estimation" isn't a terribly complex nor sophisticated process/algorithm/lines of code/instructions & imho it shouldn't make diddly-squat difference whatever you do first, although after the first capture is processed in AS! every subsequent one is going to have the MAPs overlay regardless...

 

So don't get hung up on that aspect of the tute please. smile.gif

 

There is no reference in my comments above to your last Joves btw...

 

I mentioned histogram values for capture because if they are set too high then you are obviously going to restrict the "head-room" & with a high "Normalisation" % you are going to be even further reduced there imo...so what is your usual histogram values during capture..? (check out the FC .txt files)

 

We all "live & learn" if we're honest...looking at the emails between myself & Emil when I sent the files he asked for (something that people rarely do I might add! lol.gif ) I note another false interpretation I had for quite a long while...possibly something to do with being left-handed or just plain mad wink.gif but I originally thought that if you set the stack-size % you wanted to "10%" you got the best 10% of the frames - never realising that you got everything above 10% quality...ie, 90% of the frames! rofl2.gif

 

Not too long ago we discovered that pointing the scope face down allowed for much, much quicker cooling and temperature equilisation after several years of pointing it straight up - saves on fogged correctors also & when we have a few hours before imaging negates the use of salted ice...still necessary when imaging earlier in the night however.

 

Darren ,just to be clear I have not checked AS!2's ability to reject split or half-absent frames from a recording in comparison to AS!3...my memory is that this inability is a more recent aspect after the introduction of AS!3 but I could be wrong...I will do a couple of test sometime soon with captures with a heap of these to see if there is any substance to this notion... wink.gif


  • kevinbreen likes this

#16 RedLionNJ

RedLionNJ

    Gemini

  • *****
  • Posts: 3384
  • Joined: 29 Dec 2009
  • Loc: Red Lion, NJ, USA

Posted 13 April 2019 - 10:48 PM

 

**The quality graph in AS2 looks like this:

attachicon.gif Jupiter 2019-04-13 05-00 quality graph AS2.JPG

so I'm hopeful!

 

Personally, I have only had a graph like this a couple times in ten years, and never on Jupiter!


  • dswtan likes this

#17 DMach

DMach

    Viking 1

  • -----
  • topic starter
  • Posts: 659
  • Joined: 21 Nov 2017
  • Loc: The most light-polluted country in the world :(

Posted 14 April 2019 - 12:27 AM

Darren ,just to be clear I have not checked AS!2's ability to reject split or half-absent frames from a recording in comparison to AS!3...my memory is that this inability is a more recent aspect after the introduction of AS!3 but I could be wrong...I will do a couple of test sometime soon with captures with a heap of these to see if there is any substance to this notion... wink.gif


Likewise, mine is an initial first impression right now ... more testing is needed. :)

#18 DMach

DMach

    Viking 1

  • -----
  • topic starter
  • Posts: 659
  • Joined: 21 Nov 2017
  • Loc: The most light-polluted country in the world :(

Posted 14 April 2019 - 12:35 AM

Personally, I have only had a graph like this a couple times in ten years, and never on Jupiter!


Yep, very steady. Transparency wasn't great, though, so there's a chance the details will be blurred slightly still ... as I say, fingers crossed! :)
  • RedLionNJ likes this

#19 Kokatha man

Kokatha man

    Voyager 1

  • *****
  • Posts: 12499
  • Joined: 13 Sep 2009
  • Loc: "cooker-ta man" downunda...

Posted 14 April 2019 - 03:04 AM

Those graphs can be utterly misleading - not for a minute suggesting Darren's one is...but an "average" best single frame that has a huge number of frames of similar or within (say) 10% in quality wrt this "best frame" may présage nothing to get excited about... :(



#20 kevinbreen

kevinbreen

    Surveyor 1

  • -----
  • Posts: 1536
  • Joined: 01 Mar 2017
  • Loc: Wexford, Ireland

Posted 14 April 2019 - 03:17 AM

Darryl

OK, so it’s just a relative assessment of the “quality, whatever that is” of the frames, and says nothing about the actual quality.

Thanks!

#21 Kokatha man

Kokatha man

    Voyager 1

  • *****
  • Posts: 12499
  • Joined: 13 Sep 2009
  • Loc: "cooker-ta man" downunda...

Posted 14 April 2019 - 03:24 AM

Darryl

OK, so it’s just a relative assessment of the “quality, whatever that is” of the frames, and says nothing about the actual quality.

Thanks!

Spot on Kev - but if that "best single frame" rocks, you know a graph like Darren's presages something likely to be "special"..!



#22 DMach

DMach

    Viking 1

  • -----
  • topic starter
  • Posts: 659
  • Joined: 21 Nov 2017
  • Loc: The most light-polluted country in the world :(

Posted 14 April 2019 - 07:19 AM

Those graphs can be utterly misleading - not for a minute suggesting Darren's one is...but an "average" best single frame that has a huge number of frames of similar or within (say) 10% in quality wrt this "best frame" may présage nothing to get excited about... frown.gif

 

Spot on Kev - but if that "best single frame" rocks, you know a graph like Darren's presages something likely to be "special"..!

 

Yes, very true that the quality is all relative ... so they could all turn out to be a relatively unremarkable lol. As I said above, I'm concerned the high level haze could make it look a bit like a portrait photo taken using the "beauty" filter (vaseline smeared on the camera lens).

 

But the shear consistency of the frames makes a nice change from sessions of late!

 

Hoping I can get the stacking finished and do some processing tonight (putting your excellent WinJUPOS tutorial to work!) as I'll be on a business trip all week.

 

I also plan to prepare a comparison of AS2 (single stack) vs AS3 (single stack) vs AS3 (double stack) from one of the data sets.



#23 DesertRat

DesertRat

    Fly Me to the Moon

  • *****
  • Posts: 6261
  • Joined: 18 Jun 2006
  • Loc: Valley of the Sun

Posted 14 April 2019 - 11:12 AM

Darryl wrote:

I note another false interpretation I had for quite a long while...possibly something to do with being left-handed or just plain mad but I originally thought that if you set the stack-size % you wanted to "10%" you got the best 10% of the frames - never realising that you got everything above 10% quality...ie, 90% of the frames!

I believe your original thought was the correct one.

 

Back in 2012 Rik asked Emil:
"But just to be sure - if I set 50% for the stack to make - it will stack 50% of the frames starting from the best ones?"

 

Emil's answer:
"Yes, of course."

 

This was in post #58 & 59 of:

https://www.cloudyni...akkert-2/page-3

 

in case anyone has more or less posts per page than I have set read the post numbers.  This was for AS!2 but I don't think that has changed in AS!3.

 

Agree that the gray graph of quality sometimes does not represent a useful plot, but Emil made that point as well some time ago.  Often however it is good, but I never found it particularly useful.

 

Glenn


  • RedLionNJ likes this

#24 DMach

DMach

    Viking 1

  • -----
  • topic starter
  • Posts: 659
  • Joined: 21 Nov 2017
  • Loc: The most light-polluted country in the world :(

Posted 14 April 2019 - 02:16 PM

Darryl wrote:

I believe your original thought was the correct one.

 

Back in 2012 Rik asked Emil:
"But just to be sure - if I set 50% for the stack to make - it will stack 50% of the frames starting from the best ones?"

 

Emil's answer:
"Yes, of course."

 

This was in post #58 & 59 of:

https://www.cloudyni...akkert-2/page-3

 

in case anyone has more or less posts per page than I have set read the post numbers.  This was for AS!2 but I don't think that has changed in AS!3.

 

Agree that the gray graph of quality sometimes does not represent a useful plot, but Emil made that point as well some time ago.  Often however it is good, but I never found it particularly useful.

 

Glenn

I'm not so sure a 50% example is going to clarify things though ... irrespective of which way the software interprets your input (i.e. as you asking for the top 50% or to stop at 50%) the result is the same: 50% of the frames are stacked.

 

What I was today in AS3 confirms Darryl's statement: I input 30%, and it stacked around 70% of the frames.

 

In any case, usually scroll through the images (once sorted by quality) and input an actual number of frames that I want stacked.



#25 DMach

DMach

    Viking 1

  • -----
  • topic starter
  • Posts: 659
  • Joined: 21 Nov 2017
  • Loc: The most light-polluted country in the world :(

Posted 14 April 2019 - 02:44 PM

So it's pushing 4am here, but the results of the processing are in.

 

I'm dangerously close to de-railing my own topic, so I have posted the images in a separate thread.

 

More relevant to this thread, I'll work on some the comparison images I mentioned above next ... after I've had some sleep.  ;)




CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics