First clear sky in 6 weeks! Leo Triplet

[Smiller]

It’s been an especially cloudy Winter in the already cloudy Pacific NW, only 5 clear nights in 4 months….  So after 6 weeks of twiddling my thumbs, I had one clear night between storms.

 

So I ”dolly’ed” my Orion Goto 12” Dobsonian (Orion XT12G) out onto the lawn and pointed it to the Leo Triplet.  Seeing was predicted to be horrible given the Jetstream screams overhead in the winter, but it was actually OK, so I got greedy and took shorter than normal exposures hoping for some details on those pesky little galaxies:  3300 (he’s, three thousand three hundred) 4 second exposures from my Bortle 7 skies…. took a full day to stack in APP.

Here’s the results of initial post processing:     I also like the little galaxy smudges that show up… like little easter eggs.

 

Edited March 14, 2023 by Smiller

[glafnazur]

That's a nice image of one of my favourites 👍I love all those faint little galaxies

[happy-kat]

That stack was mammoth, nice detail in the result.

[ONIKKINEN]

Really nice with only 4s subs and a relatively short integration of those. Surprised to see so many background galaxies for sure.

3 hours ago, Smiller said:

…. took a full day to stack in APP.

Try Siril? Siril, at least for my computer, appears to be about 5x faster (at least) compared to APP or PixInsight (or anything i have tried) with large stacks. Yesterday i stacked 80gb of files - around 3000 subs and it took maybe an hour including registration, normalization and weighted rejection stacking (files were already calibrated though).

Edited March 14, 2023 by ONIKKINEN

[Smiller]

5 hours ago, ONIKKINEN said:

Really nice with only 4s subs and a relatively short integration of those. Surprised to see so many background galaxies for sure.

Try Siril? Siril, at least for my computer, appears to be about 5x faster (at least) compared to APP or PixInsight (or anything i have tried) with large stacks. Yesterday i stacked 80gb of files - around 3000 subs and it took maybe an hour including registration, normalization and weighted rejection stacking (files were already calibrated though).

Yes, SIRIL is indeed much faster.  In fact, I recently did a “chili cook off” between Deep Sky Stacker, SIRIL, PixInsight, and Astro Pixel Processor, all of which I have and have used.  DSS and SIRIL were a full 10x faster than APP, and 15x faster than PI. 

Now SIRIL, APP, and PI all have huge intermediate disk requirements that are 5-15x larger than the original data size (For SIRIL this is especially true if you use the new “-framing=max” setting in 1.2beta that increase the frame size to accommodate my rotating subs).  So that is often the limit.  Only DSS doesn’t.   Did you notice that on your big 3000 sub job you put through SIRIL?   Is there a way to avoid that?

So why did I stick with APP?  Well, as it turns out for some types of jobs, APP has the highest quality results, especially for my system that has a lot of field rotation.  APP does a superb job blending the rotated frames.  SIRIL and PI do good, but a bit less so, and DSS not so good.

SIRIL and DSS do have the highest real time disk speed requirements though.  So you do need to have your data on a fast SSD to get that speed.

So in this case, in hindsight, I should have probably used SIRIL.   My field rotation on this task wasn’t too bad and so I didn’t really need APP’s features.

One last thing I need from SIRIL that I haven’t spent the time to figure out is how to align the color planes when I have atmospheric dispersion in my color captures.  The align plane feature doesn’t work for me and I’ve asked around for help, but to no avail… I’ve tried several suggestions to no affect.  Perhaps you know the solution.   I was using the 1.2beta version of SIRIL.

 

Edited March 15, 2023 by Smiller

[ONIKKINEN]

2 hours ago, Smiller said:

Yes, SIRIL is indeed much faster.  In fact, I recently did a “chili cook off” between Deep Sky Stacker, SIRIL, PixInsight, and Astro Pixel Processor, all of which I have and have used.  DSS and SIRIL were a full 10x faster than APP, and 15x faster than PI. 

Now SIRIL, APP, and PI all have huge intermediate disk requirements that are 5-15x larger than the original data size (For SIRIL this is especially true if you use the new “-framing=max” setting in 1.2beta that increase the frame size to accommodate my rotating subs).  So that is often the limit.  Only DSS doesn’t.   Did you notice that on your big 3000 sub job you put through SIRIL?   Is there a way to avoid that?

So why did I stick with APP?  Well, as it turns out for some types of jobs, APP has the highest quality results, especially for my system that has a lot of field rotation.  APP does a superb job blending the rotated frames.  SIRIL and PI do good, but a bit less so, and DSS not so good.

SIRIL and DSS do have the highest real time disk speed requirements though.  So you do need to have your data on a fast SSD to get that speed.

So in this case, in hindsight, I should have probably used SIRIL.   My field rotation on this task wasn’t too bad and so I didn’t really need APP’s features.

One last thing I need from SIRIL that I haven’t spent the time to figure out is how to align the color planes when I have atmospheric dispersion in my color captures.  The align plane feature doesn’t work for me and I’ve asked around for help, but to no avail… I’ve tried several suggestions to no affect.  Perhaps you know the solution.   I was using the 1.2beta version of SIRIL.

 

For sequences containing less than 2048 images the sequence can be created with just the use of symbolic links, so it takes no actual disk space when imported to Siril. After registration there will be actual written files on the disk though, and this is pretty much the minimum disk space requirement for Siril. So there is a little bit of a tip here to try and make the sequence be less than that if you want to save on disk space temporarily. For more than 2048 you will need to write all the files into a .FITS cube (single .FITS file with 3000 layers) for them to be stackable. APP and as far as i know every other software has to do something like this under the covers as Windows OS prevents you from having more than 2048 files open at the same time so they have to be written to a single temporary file one way or another.

There is a trick to remove atmospheric dispersion, but it takes some effort. I also image with a colour camera, but i dont treat the data as colour data really at any point. I calibrate the data and then use the "seqsplit_cfa" command to split the OSC data into its raw 4 monochrome channels without debayering. This results in 1 red, 1 blue, and 2 separate green images per input sub and also effectively bins them x2. Then i stack them using a single reference frame for all the RGB channels, this aligns everything to one sub in the stacking phase so no colour channel separation due to atmospheric dispersion is possible (never seen lopsided RGB in a star this way). The second option is to extract RGB layers as mono images from the stacked colour image, register them against each other (green channel probably best for reference) and recomposite back to an RGB image. That works almost all the time too.

The cfa split method does require some extra effort, but it gets the job done well in the end. Not sure how practical it would be for you since you have 3000 images to begin with, so you would have 12 000 after the split!

You could also batch bin the files with ASTAP and stacking should be much easier. Or use superpixel debayering with APP which also halves the image size and so should make the subsequent processes run much faster. No easy cheats available for dealing with large stacks im afraid, its all a compromise of some kind which is why i have a 1tb SSD that i really treat as a 500gb SSD with the other 500gb reserved for stacking purposes.

[Smiller]

Great tips, I’ll have to play with some of these techniques.