PixInsight Eccentricity

[TerryMcK]

This is not a reference to the users of PixInsight, although some may say I'm eccentric, but rather the output of star eccentricity measurements in the SubframeSelector process (not the script as that seems to have disappeared).

 

I have just run a bunch of Ha images through the tool and Eccentricity goes from 0.377 up to 0.791. I thought most of the frames showed quite tight stars when I Blinked them. From what I have been reading an Eccentricity value of 0.42 cannot be perceived by the eye of most people so the closer to that value you get the better.

 

My subframe scale on the ZS103 with x0.8 reducer and ASI183MM is 0.87 arcseconds/pixel 

 

In the subframeSelector Expressions table I entered FWHM < 6 && Eccentricity <= 0.6 (as Amy Astro suggests) with a weighting of SNRWeight

 

 

The results for 93 subframes is 51 ok for approval. It was a lot less for OIII and SII making me wonder if doing image analysis is actually detrimental. Approved frames start like this:

 

Unapproved frames end like this:

 

 

Raising eccentricity in the approval formula to 0.7 results in far more usable subs but of course more eccentric stars.

I then compared the stacked images in SHO after doing some very basic processing

• first with all subs stacked
• and then with only subs that SFS approved.

 

Zoomed in images showing all subs on the left and SFS approved subs on the right integrated as SHO - not a pretty picture but was not meant to be

The only difference I could see in the Hubble pallet was less red ringing around stars with the frames output by the SFS process. This is after magenta halo removal. Although the SNR of the all subs stacked integration was far better than the one which only had 50% of frames integrated.

 

I then changed the approval to the generally accepted formula through SFS which is 

20*(1-(FWHM-FWHMMinimum)/(FWHMMaximum-FWHMMinimum))+20*(1-(Eccentricity-EccentricityMinimum)/(EccentricityMaximum-EccentricityMinimum))+10*(SNRWeight-SNRWeightMinimum)/(SNRWeightMaximum-SNRWeightMinimum)+50

 

and guess what? Every frame passed muster. Surely that cannot be right as the FWHM and Eccentricity values were still the same as before. There might be issues with that formula.

I wonder if the residual red rings remaining after magenta deringing are caused by the Sulphur filter bloating the stars so might invest in 3nm filters soon. Mine are all 6nm currently.

 

I may be being a little picky on this but SHO red ringing around stars irritates me.

 

What Eccentricity values are you seeing?

 

 

[AstronomyUkraine]

1 hour ago, TerryMcK said:

This is not a reference to the users of PixInsight, although some may say I'm eccentric, but rather the output of star eccentricity measurements in the SubframeSelector process (not the script as that seems to have disappeared).

 

I have just run a bunch of Ha images through the tool and Eccentricity goes from 0.377 up to 0.791. I thought most of the frames showed quite tight stars when I Blinked them. From what I have been reading an Eccentricity value of 0.42 cannot be perceived by the eye of most people so the closer to that value you get the better.

 

My subframe scale on the ZS103 with x0.8 reducer and ASI183MM is 0.87 arcseconds/pixel 

 

In the subframeSelector Expressions table I entered FWHM < 6 && Eccentricity <= 0.6 (as Amy Astro suggests) with a weighting of SNRWeight

 

 

The results for 93 subframes is 51 ok for approval. It was a lot less for OIII and SII making me wonder if doing image analysis is actually detrimental. Approved frames start like this:

 

Unapproved frames end like this:

 

 

Raising eccentricity in the approval formula to 0.7 results in far more usable subs but of course more eccentric stars.

I then compared the stacked images in SHO after doing some very basic processing

• first with all subs stacked
• and then with only subs that SFS approved.

 

Zoomed in images showing all subs on the left and SFS approved subs on the right integrated as SHO - not a pretty picture but was not meant to be

The only difference I could see in the Hubble pallet was less red ringing around stars with the frames output by the SFS process. This is after magenta halo removal. Although the SNR of the all subs stacked integration was far better than the one which only had 50% of frames integrated.

 

I then changed the approval to the generally accepted formula through SFS which is 

20*(1-(FWHM-FWHMMinimum)/(FWHMMaximum-FWHMMinimum))+20*(1-(Eccentricity-EccentricityMinimum)/(EccentricityMaximum-EccentricityMinimum))+10*(SNRWeight-SNRWeightMinimum)/(SNRWeightMaximum-SNRWeightMinimum)+50

 

and guess what? Every frame passed muster. Surely that cannot be right as the FWHM and Eccentricity values were still the same as before. There might be issues with that formula.

I wonder if the residual red rings remaining after magenta deringing are caused by the Sulphur filter bloating the stars so might invest in 3nm filters soon. Mine are all 6nm currently.

 

I may be being a little picky on this but SHO red ringing around stars irritates me.

 

What Eccentricity values are you seeing?

 

 

You might want to check the title of your topic, Terry. 😁

 

I use the exact same formulas as you in subframeselector, but I never reject any frames on eccentricity, I'll remove frames with obvious star trails etc. I had 14 images rejected out of 120 on the Propeller nebula because of eccentricity, and mine is set to <0.7. I stacked all of them, and the stars looked perfect. What is even more strange, some of the ones rejected for eccentricity had the best FWHM figures.

 

I notice you don't put in the value for the camera egain in your setup. There is quite a difference in this value, depending if you are using NB or BB filters. My egain value is 1.0011 for NB, but BB filters it is 2.0916. Not sure how much difference it makes to the end result, but I was told to enter this value in the SubFrameSelector.

Edited July 23, 2021 by AstronomyUkraine

[TerryMcK]

LOL I missed that one Brian 😄

[TerryMcK]

11 minutes ago, AstronomyUkraine said:

My egain value is 1.0011 for NB, but BB filters it is 2.0916. Not sure how much difference it makes to the end result, but I was told to enter this value in the SubFrameSelector.

Interesting. I left that at default of 1 not really knowing what to put into it. How did you determine the egain value?

[AstronomyUkraine]

22 minutes ago, TerryMcK said:

Interesting. I left that at default of 1 not really knowing what to put into it. How did you determine the egain value?

Very simple Terry. Open a light frame, or double click on one in subframeselector if you have it loaded up. Just go to file/fits header in PI, scroll down to the relevent info. You will find the exact pixel scale and egain values just before the history.

 

Edited July 23, 2021 by AstronomyUkraine

[TerryMcK]

As I'm using INDI I haven't got it in the FITS header. Apparently it's only implemented in ASCOM.

I shall have to dig out a Windows PC with ASCOM on and take a snap or two to see what it is.

[AstronomyUkraine]

3 minutes ago, TerryMcK said:

As I'm using INDI I haven't got it in the FITS header. Apparently it's only implemented in ASCOM.

I shall have to dig out a Windows PC with ASCOM on and take a snap or two to see what it is.

Once you have the numbers, they will be the same for every NB or BB images you take with that particular camera. Another camera will have different figures.

[MarkAR]

I'd be interested to see the same subs run the the _nsg weighting to compare how many get rejected and if it's the same ones rejected.

[AstronomyUkraine]

8 hours ago, MarkAR said:

I'd be interested to see the same subs run the the _nsg weighting to compare how many get rejected and if it's the same ones rejected.

I run 120 5 min subs through SubFrameSelector, then NSG. I got 14 rejections in SubFrameSelector on eccentricity, and 50 rejections using NSG. I stacked the images with the rejections excluded from both SubFrameSelector and NSG. Then stacked all frames including rejections. I couldn't tell the difference in any of the stacks. I think this NSG is aimed more at RGB than NB.

 

Another interesting thing I noticed, in SubFrameSelector I have eccentricity set to reject any frames <0.7, and SubFrameSelector allowed 3 frames to go through that were 0.7+. One of them had an eccentricity of 0.78. Not exactly encouraging if you are looking for the best stack possible.