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

PlanetarySystemStacker - Program features and user experience

astrophotography imaging solar planet moon
  • Please log in to reply
36 replies to this topic

#1 Rolf

Rolf

    Viking 1

  • -----
  • topic starter
  • Posts: 521
  • Joined: 25 Apr 2016
  • Loc: Cologne, Germany

Posted 29 January 2021 - 04:35 AM

Hi,

 

The "epic thread" New stacking software project "PlanetarySystemStacker" has been going on for about two years now. Many of you actively contributed to the discussion which was a big help in the process to make the software mature and useful for many application scenarios. I thank you all very much for your dedication and patience!

 

Now it is time to organize the discussion in a better way. I suggest that we split it in two threads. This one will be the place where we discuss program features, questions regarding the "best practice" in application scenarios, and wishes for new features to be added in future releases. Of course I would love also to hear from you if you have produced great pictures using PSS, and to see the results here.

 

I will start another thread where we discuss installation issues on the various hardware platforms and OS versions. Those discussions in the past used a lot of space, and I can imagine that this was painful for those of you who were only interested in the application aspects.

 

I hope that you will find this new organization useful, and that we don't loose contact in this transition. I'm very much looking forward to the continued exchange with you on PSS in this new setting.

 

All the best,

Rolf


Edited by Rolf, 29 January 2021 - 04:37 AM.

  • Ron359, Oleg Astro and daniele.bonfiglio like this

#2 daniele.bonfiglio

daniele.bonfiglio

    Explorer 1

  • -----
  • Posts: 61
  • Joined: 23 Jun 2017
  • Loc: Montagnana (PD), Italy

Posted 30 January 2021 - 05:38 AM

Dear Rolf,

When you manually select the area for image stabilization, is there any way to know that it is actually accepted? (ie it is within the minimum and maximum area limits?)

Best Daniele


Edited by daniele.bonfiglio, 30 January 2021 - 05:38 AM.


#3 Rolf

Rolf

    Viking 1

  • -----
  • topic starter
  • Posts: 521
  • Joined: 25 Apr 2016
  • Loc: Cologne, Germany

Posted 30 January 2021 - 09:21 AM

Dear Daniele,

 

Dear Rolf,

When you manually select the area for image stabilization, is there any way to know that it is actually accepted? (ie it is within the minimum and maximum area limits?)

Best Daniele

If you set the protocol level to "2", PSS reports if the stabilization patch is too big or too small. Here is a sreenshot:

 

screenshot.PNG

 

If that is the case, PSS switches to automatic mode.

 

All the best,

 Rolf


  • daniele.bonfiglio likes this

#4 daniele.bonfiglio

daniele.bonfiglio

    Explorer 1

  • -----
  • Posts: 61
  • Joined: 23 Jun 2017
  • Loc: Montagnana (PD), Italy

Posted 31 January 2021 - 03:47 AM

Dear Daniele,

 

If you set the protocol level to "2", PSS reports if the stabilization patch is too big or too small. Here is a sreenshot:

 

attachicon.gifscreenshot.PNG

 

If that is the case, PSS switches to automatic mode.

 

All the best,

 Rolf

Thank you for the explanation Rolf,

A new feature that you could possibly implement is that the automatic stabilization patch is shown already on the screen and so the user can decide whether to leave it like it is or select it manually.

Best, Daniele



#5 Rolf

Rolf

    Viking 1

  • -----
  • topic starter
  • Posts: 521
  • Joined: 25 Apr 2016
  • Loc: Cologne, Germany

Posted 31 January 2021 - 08:40 AM

Caro Daniele,

 

Thank you for the explanation Rolf,

A new feature that you could possibly implement is that the automatic stabilization patch is shown already on the screen and so the user can decide whether to leave it like it is or select it manually.

Best, Daniele

Thank you for your suggestion! To be honest, I myself use the manual selection of the stabilization patch only in very extreme situations. For example, if for a planet in daylight the "planet" stabilization does not work reliably. I have processed many hundreds of moon videos, but I never had to select the patch by hand. In my opinion one must have a very good reason to feel "smarter" than the automatic algorithm. And in that case I would not care to see what PSS would have selected.

 

What is your experience? Do you feel like getting better results in manual mode?

 

By the way: This feature (automatic selection of the stabilization patch) was the initial reason for me to develop PSS in the first place. AutoStakkert!3 does not have this option, and in my large moon panoramas, processed in batch mode, there were always cases where the fixed alignment patch covered black sky only. If Emil Kraaikamp had followed my suggestion to extend AS!3 with this feature, most likely today there would be no PSS.  smile.gif

 

Ciao,

 Rolf
 


Edited by Rolf, 31 January 2021 - 09:48 AM.


#6 daniele.bonfiglio

daniele.bonfiglio

    Explorer 1

  • -----
  • Posts: 61
  • Joined: 23 Jun 2017
  • Loc: Montagnana (PD), Italy

Posted 31 January 2021 - 10:27 AM

Caro Daniele,

 

Thank you for your suggestion! To be honest, I myself use the manual selection of the stabilization patch only in very extreme situations. For example, if for a planet in daylight the "planet" stabilization does not work reliably. I have processed many hundreds of moon videos, but I never had to select the patch by hand. In my opinion one must have a very good reason to feel "smarter" than the automatic algorithm. And in that case I would not care to see what PSS would have selected.

 

What is your experience? Do you feel like getting better results in manual mode?

 

By the way: This feature (automatic selection of the stabilization patch) was the initial reason for me to develop PSS in the first place. AutoStakkert!3 does not have this option, and in my large moon panoramas, processed in batch mode, there were always cases where the fixed alignment patch covered black sky only. If Emil Kraaikamp had followed my suggestion to extend AS!3 with this feature, most likely today there would be no PSS.  smile.gif

 

Ciao,

 Rolf
 

Dear Rolf,

This is the rationale for my question above.

I have moon images taken with an APS-C sensor with 6240x4160 pixels. Given my focal length, all the frame is filled by the moon. But sometimes I want to do close-ups of say 2000x1500 pixels. Of course I could stack the entire frame and then crop, but I guess that to have an as much as accurate as possible alignment and stacking (and also to save compute time) is it better to select a ROI. Therefore, I also want to select an alignment patch centered on what will be my ROI. This is why I prefer to select my alignment patch manually (or at least to be sure that the automatic one does enclose my ROI).

Best, Daniele



#7 Rolf

Rolf

    Viking 1

  • -----
  • topic starter
  • Posts: 521
  • Joined: 25 Apr 2016
  • Loc: Cologne, Germany

Posted 31 January 2021 - 02:31 PM

Hi Daniele,

 

Okay, I understand! I don't think that the manual placement of the stabilization patch really helps. At least, if you have an equatorial mount and field rotation is not an issue. The residual shifts due to image warping which stay after frame stabilization are random and should not be ROI-specific. And they should be corrected in the stacking process.

 

It would be an interesting experiment if one really gets better results if the frame stabilization and ROI patches are close to each other. I would bet it does not make any difference.

 

All the best,

 Rolf



#8 daniele.bonfiglio

daniele.bonfiglio

    Explorer 1

  • -----
  • Posts: 61
  • Joined: 23 Jun 2017
  • Loc: Montagnana (PD), Italy

Posted 02 February 2021 - 10:17 AM

Hi Daniele,

 

Okay, I understand! I don't think that the manual placement of the stabilization patch really helps. At least, if you have an equatorial mount and field rotation is not an issue. The residual shifts due to image warping which stay after frame stabilization are random and should not be ROI-specific. And they should be corrected in the stacking process.

 

It would be an interesting experiment if one really gets better results if the frame stabilization and ROI patches are close to each other. I would bet it does not make any difference.

 

All the best,

 Rolf

Dear Rolf,

I did some tests and, as you expected, it does not make any difference if the stabilization patch encloses the ROI or not.

For instance, the image below is based on a stack with PSS using a stabilization patch that just marginally interects the ROI (ie the frame of the image which is a crop of a much wider area).

The resulting alignemnt has a very similar accuracy as if the stabilization patch was chosen to enclose the ROI.

R_pss_f100_p50_b140_ap303_drizzle3x_astraimage_gimp_scale.jpg


  • Rolf likes this

#9 Rolf

Rolf

    Viking 1

  • -----
  • topic starter
  • Posts: 521
  • Joined: 25 Apr 2016
  • Loc: Cologne, Germany

Posted 02 February 2021 - 10:58 AM

Hi Daniele,

 

Thank you very much for this experiment! I'm glad that, as I expected, the location of the stabilization patch is not critical. Therefore, I think it is reasonable that by default the patch is selected automatically, so the user is not bothered at all with this processing step. And if the user really opts for a manual selection, in my opinion the current user interface is good enough.

 

All the best,

 Rolf


  • daniele.bonfiglio likes this

#10 Der_Pit

Der_Pit

    Vanguard

  • *****
  • Posts: 2,261
  • Joined: 07 Jul 2018
  • Loc: La Palma

Posted 03 February 2021 - 07:08 PM

Hi Rolf,

 

as you had asked for images in this thread smile.gif I take the chance to share my first experiment with the Baader FFC.  I used it at the 'standard' backfocus of 55mm, giving me a 2.3 magnification and 0.37"/px image scale.  The moon is too large, so I took two runs and combined them in GIMP after stacking.

 

I did have issues with the tracking/stabilization: My mount didn't track the moon correctly, so I was correcting manually the pointing, creating large jumps that PSS wouldn't handle.  Did that separately in IDL, then PSS was happy.

 

I'm still not sure what the 'best' choice is for the number of images to stack.  I guess there must be some sweet spot between not reducing noise (low number) and smearing detail (high number).  Finding that is probably what you'd call 'experience' cool.gif

 

Anyhow, here's the largely scaled down full image, plus a small cutout at full resolution showing the 'Montes Causasus' between Aristillus and Eudoxus.

 

The full size image (4352x5200) is on Astrobin

 

Moon_mosaic_small.jpg

 

Moon_mosaic_part.jpg

 


  • roelb, Rolf and daniele.bonfiglio like this

#11 Rolf

Rolf

    Viking 1

  • -----
  • topic starter
  • Posts: 521
  • Joined: 25 Apr 2016
  • Loc: Cologne, Germany

Posted 04 February 2021 - 05:12 AM

Hi Pit,

 

Thank you for sharing this great picture with us! I downloaded the high-res image. The level of detail is very good for a 140mm telescope.

 

On Astrobin you mentioned that you used 5% of the frames. Did you shoot 200 frames per video in total, or are the 200 frames the best 5% already? In the first case you would end up with 10 frames per stack only, which is rather little. But I agree with you that finding the "sweet spot" is only possible by trying various percentages and selecting the best one. The interesting thing is that if you choose a larger stack percentage, you can set the sharpening filters at higher values before noise becomes apparent. To some extent this additional sharpening can counteract the additional blur caused by including inferior frames.

 

Baader specifies the minimum magnification for the FFC as 3x. Below that there is no guarantee that the image is sharp up to the corners of a full-frame camera. With my refractor (focal length 1200mm) I have the same problem as you have, so I also used the FFC with a smaller backfocus which resulted in a magnification of some 2.5 to 2.7. A factor of 2.3 seems a little dangerous to me, though.

 

 

All the best,

 Rolf



#12 Der_Pit

Der_Pit

    Vanguard

  • *****
  • Posts: 2,261
  • Joined: 07 Jul 2018
  • Loc: La Palma

Posted 04 February 2021 - 07:37 AM

Hi Rolf,

 

thanks for the kind words smile.gif

I indeed only stacked 10 frames blush.gif.  One reason was that the SER movies I had created somehow ended up binned 2x2, so I had to fall back to a series of images that I had taken in DSO mode, storing single 16bit FITS files.  Readout and transfer are a huge overhead there, so not too many files.....

But I think it was compensated by really exceptional seeing that night - even for our standards here.  Moon was still relatively low though - I should have waited longer, but really was too tired.

 

But your comments/recommendations on #frames/noise/sharpening are very welcome!  I'll start experimenting with that series a bit more. waytogo.gif

 

About the Baader FFC:  Yes, I had read that claim of 3x min at 55mm BF, too, on the TS website.  However, that one is wrong.  So either it is not usable at 55mm BF, or the min magnification is lower.  Likely, the claim of TS that you can use it directly on a T2 adapter (=55mm BF) is wrong? 

 

But TBH, I'm not really concerned about the optical quality.  I did have a look at star images with the R filter, also recording some SER video.  Here's one of the frames.  Left is linear, right is stretched.

 

startest.jpg

 

At F=2090mm and λ=650nm, the radius of the first minimum of the Airy pattern is 11.8μ or 3.15 pixels, nicely matching the image laugh.gif.  It doesn't look like the FFC is introducing any degradation at 2.3x.  But I'll try 3x next time - that would give me optimal sampling for the green filter.

 

 



#13 Rolf

Rolf

    Viking 1

  • -----
  • topic starter
  • Posts: 521
  • Joined: 25 Apr 2016
  • Loc: Cologne, Germany

Posted 05 February 2021 - 05:35 AM

Hi Pit,

 

I don't know what TS says about the correct back focus. I attach the official document of Baader Planetarium. For 3x magnification they give a back focus of 92.3mm, and that fits to my own experiments. I usually use a 25mm T2 extension in front of the T2 adapter with 55mm back focus, which adds up to 80mm. That is less than the 92.3mm above, but I found the results acceptable for a full-frame sensor.

 

All the best,

 Rolf

Attached Files


  • Der_Pit likes this

#14 daniele.bonfiglio

daniele.bonfiglio

    Explorer 1

  • -----
  • Posts: 61
  • Joined: 23 Jun 2017
  • Loc: Montagnana (PD), Italy

Posted 27 February 2021 - 03:34 AM

Dear Rolf,

I have just started having a look into your nice code, in the view of tweaking some hard coded parameters for testing on planetary stacking (a few months old Saturn in particular).

I want to reduce the minimum box size and to increase the overlapping of adjacent alignment patches.

I have already a question about the code lines of configuration.py pasted below.

In the remark you mention that the factor 4.5/3 is such that adjacent patches overlap by 1/6 of their width. Do you mean on each side or on both sides? If on each side, should not the factor be 4/3 instead? In this way the alignment point step size would be 4/6 of the alignment patch width and then the overlap would be 1/6 on each side.

Thank you and best regards, Daniele

 

EDIT

Sorry but I must correct myself, now I think the factor to get 1/6 of overlap on each side should be 5/3 so that the step size is 5/6 of the alignment patch width

 

# Set the AP distance per coordinate direction such that adjacent patches overlap by 1/6

        # of their width.

        self.alignment_points_step_size = int(

            round((self.alignment_points_half_patch_width * 4.5) / 3))


Edited by daniele.bonfiglio, 27 February 2021 - 03:47 AM.


#15 Rolf

Rolf

    Viking 1

  • -----
  • topic starter
  • Posts: 521
  • Joined: 25 Apr 2016
  • Loc: Cologne, Germany

Posted 27 February 2021 - 04:45 AM

Hi Daniele,

 

I'm glad you like the PSS source code! I tried hard to document the entire code sufficiently so that others can understand what happens. Additionally, I documented all non-trivial algorithms, so you don't have to construct them from the code.

 

I made many hundreds of tests with different overlap widths and AP patterns before I set the "hidden" parameters as they are now. Therefore, I would be surprised if you found any substantial improvement with other settings. You have to be careful not to tune the parameters to a single use case, of course. On the other hand, if your search is successful, I would be glad to hear about it. The success criterion is if the image quality gets better for the same execution time. Execution takes longer for more APs and larger overlaps. But it would also be interesting to hear if a different parameter set produces a better image even if execution takes longer. After all, the image quality is most important.

 

Thank you for pointing me at the wrong comment line in the configuration.py file. The current setting is such that AP patches overlap by 1/6 of the AP step size on both sides, as you can see in this example:

 

AP_grid.jpg

 

I corrected the comment line accordingly.

 

All the best,

 Rolf



#16 daniele.bonfiglio

daniele.bonfiglio

    Explorer 1

  • -----
  • Posts: 61
  • Joined: 23 Jun 2017
  • Loc: Montagnana (PD), Italy

Posted 27 February 2021 - 06:07 AM

Many thanks for your reply, Rolf.

 

My point is that I see significant improvement by manually placing the points as reported here: https://www.cloudyni...post&p=10601244

 

and now I want to see if I can get a similar improvement by tweaking the automatic placement

 

Best, Daniele



#17 Rolf

Rolf

    Viking 1

  • -----
  • topic starter
  • Posts: 521
  • Joined: 25 Apr 2016
  • Loc: Cologne, Germany

Posted 27 February 2021 - 09:49 AM

Hi Daniele,

 

I remember your earlier report on the Saturn example. In that example, did you try with different AP box sizes to find the optimal value?

 

All the best,

 Rolf



#18 daniele.bonfiglio

daniele.bonfiglio

    Explorer 1

  • -----
  • Posts: 61
  • Joined: 23 Jun 2017
  • Loc: Montagnana (PD), Italy

Posted 27 February 2021 - 12:55 PM

Dear Rolf,

This was the problem indeed. Even with the smallest AP box size, the total number of AP boxes with purely automatic placement was not enough to get a good result. So I had to place at least as much AP boxes manually.

Best, Daniele


Edited by daniele.bonfiglio, 27 February 2021 - 12:55 PM.


#19 Rolf

Rolf

    Viking 1

  • -----
  • topic starter
  • Posts: 521
  • Joined: 25 Apr 2016
  • Loc: Cologne, Germany

Posted 27 February 2021 - 02:57 PM

Dear Daniele,

 

okay, I see! I'm looking forward to hearing from you what you will find.

 

On my agenda for PSS developments is to re-write the entire automatic AP grid generation. Instead of the regular staggered grid I could imagine to place APs adaptively, based on the local brightness / contrast / structure. Not only would the spacing between APs be variable, but also the AP sizes would vary. In the long run I think that this would be a good idea, but I have not found a good algorithm yet. Perhaps something you could think about as well.

 

All the best,

 Rolf



#20 daniele.bonfiglio

daniele.bonfiglio

    Explorer 1

  • -----
  • Posts: 61
  • Joined: 23 Jun 2017
  • Loc: Montagnana (PD), Italy

Posted 27 February 2021 - 03:05 PM

Dear Rolf,

Of course I will let you know about my tests.

And yes, I agree that having an adaptive AP grid generation algorithm would be great! Indeed, I would be willing to help on this.

By the way, could you explain what happens in the stacking process when two APs overlap? I mean, how is the stacking performed in the overlapping area?

Have a good night,

Daniele



#21 Rolf

Rolf

    Viking 1

  • -----
  • topic starter
  • Posts: 521
  • Joined: 25 Apr 2016
  • Loc: Cologne, Germany

Posted 28 February 2021 - 10:08 AM

Dear Daniele,

 

Did you read the "algorithm_summary.pdf" documentation (available on Github under "documentation"). There the patch merging is explained in detail.

 

All the best,

 Rolf


  • daniele.bonfiglio likes this

#22 daniele.bonfiglio

daniele.bonfiglio

    Explorer 1

  • -----
  • Posts: 61
  • Joined: 23 Jun 2017
  • Loc: Montagnana (PD), Italy

Posted 01 March 2021 - 04:01 AM

Hi Rolf,

 

so this is a first test.

 

I changed the AP box size from 20 to 8. As a result, the total number of APs increased from 31 to 153.

However, I must have done something wrong with your code, because in the second case the "shadow" of the AP boxes is clearly seen in the final sharpened image.

 

AP box size: 20

TIF_corrected_pss_f800_p45_b20_ap31_gpp.jpg

 

AP box size: 8

TIF_corrected_pss_f800_p45_b8_ap153_gpp.jpg

 

I changed your code in just three places:

1) in configuration.py, from self.alignment_points_min_half_box_width = 10 to self.alignment_points_min_half_box_width = 4

2) in parameter_configuration.py, from self.aphbw_slider_value = QtWidgets.QSlider(self.tab_alignment)

        self.aphbw_slider_value.setMinimum(20) to self.aphbw_slider_value = QtWidgets.QSlider(self.tab_alignment)

        self.aphbw_slider_value.setMinimum(8)

3) in alignment_point_editor_gui.py from self.aphbw_slider_value = QtWidgets.QSlider(alignment_point_editor)

        self.aphbw_slider_value.setMinimum(20) to self.aphbw_slider_value = QtWidgets.QSlider(alignment_point_editor)

        self.aphbw_slider_value.setMinimum(8)

 

Did I miss something?

 

Sorry for messing up with your code, but this is for the good sake of possibly improving it!

 

Best, Daniele

 

 



#23 daniele.bonfiglio

daniele.bonfiglio

    Explorer 1

  • -----
  • Posts: 61
  • Joined: 23 Jun 2017
  • Loc: Montagnana (PD), Italy

Posted 01 March 2021 - 08:59 AM

Dear Rolf,

 

here is a second set of experiments, all with AP box 20 pixels wide but with varying APs overlap.

 

1) Unmodified code, purely automatic AP placement, resulting in 31 APs

TIF_corrected_pss_f800_p45_b20_ap31_gpp.jpg

 

2) Unmodified code, mixed automatic and manual AP placement, resulting in 54 APs

TIF_corrected_pss_f800_p45_b20_ap54_gpp.jpg

 

3) Unmodified code, mixed automatic and manual AP placement, resulting in 92 APs

TIF_corrected_pss_f800_p45_b20_ap92_gpp.jpg

 

4) Modified code with 1 instead of 4.5/3 factor, purely automatic AP placement, resulting in 68 APs

TIF_corrected_pss_f800_p45_b20_ap68_gpp.jpg

 

5) Modified code with 1.5/3 instead of 4.5/3 factor, purely automatic AP placement, resulting in 295 APs

TIF_corrected_pss_f800_p45_b20_ap295_gpp.jpg

 

In the last two cases, the factor I am referring to is that in this line of configuration.py:

self.alignment_points_step_size = int(
            round((self.alignment_points_half_patch_width * 4.5) / 3))

 

In my opinion the last case is the best. I don't understand why the last two cases (with automatic AP placement and modified APs overlap) looks brighter, crisper and with more local contrast than the ones with mixed AP placement, original APs overlap and similar total number of APs.

 

In all the cases the postprocessing is precisely the same, with PSS wavelets and final adjustments with GIMP.

 

Best, Daniele



#24 Rolf

Rolf

    Viking 1

  • -----
  • topic starter
  • Posts: 521
  • Joined: 25 Apr 2016
  • Loc: Cologne, Germany

Posted 01 March 2021 - 02:28 PM

Hi Daniele,

 

Did you try larger box sizes than 20 pixels? The reason why I set the lower limit at 20 is that I cannot imagine that the cross correlation algorithm will find a reasonably precise local shift with fewer pixels. Actually, I have never seen an example where the optimal value was as low as 20. Usually at least 40 to 50 pixels are necessary for a precise displacement measurement.

 

The last example in your experiment series looks better than the other tests because you have an extremely large number of overlapping APs, and the miscalculations in the local shifts average out randomly. I wouldn't be surprised if you got a similar result with no AP at all, so that the original, globaly aligned frames are stacked with no de-warping.

 

All the best,

 Rolf



#25 daniele.bonfiglio

daniele.bonfiglio

    Explorer 1

  • -----
  • Posts: 61
  • Joined: 23 Jun 2017
  • Loc: Montagnana (PD), Italy

Posted 02 March 2021 - 03:25 AM

Dear Rolf,

thank you for the suggestions.

 

I have just tried with no AP at all. The result is not bad indeed, but noisier than my best case (the one with large number of overlapping APs).Here is the comparison:

 

295 overlapping APs (already posted yesterday):

TIF_corrected_pss_f800_p45_b20_ap295_gpp.jpg

 

No AP at all:

TIF_corrected_pss_f800_p45_b20_ap0_gpp.jpg

 

I will experiment with AP box larger than 20 pixels (even if this would result in a very small number of APs, in particular with standard overlap factor).

 

By the way, do you have any idea about the cause of the AP box "shadows" appearing in the final image in the test with AP box 8 pixels wide, I have posted yesterday?

 

Best, Daniele




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





Also tagged with one or more of these keywords: astrophotography, imaging, solar, planet, moon



Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics