Question about Subframe selector script...

[UlteriorModem]

Greetings,

First post here nice to meet everyone

I found a spreadsheet to produce expressions to be used in the Subframe Selector Script.

The spreadsheet appears to work fine but when I copy and paste the expression into the Script it does not work.

Here is an example expression produced by the spreadsheet.

35*(1-(FWHM-2.092)/1.518) + 5*(1-(Eccentricity-0.3016)/0.181) + 10*(SNRWeight-0.9769)/7.7051 + 50

and here is an example of the rejection by the parse



Please be gentile boolian logic is not my strong point, hopefully I have overlooked something simple.

Thanks

[Niall Saunders]

35*(1-(FWHM-2.092)/1.518) + 5*(1-(Eccentricity-0.3016)/0.181) + 10*(SNRWeight-0.9769)/7.7051 + 50

I have never used this script, but a first glance at your expression makes me immediately want to re-write it as follows (spaces and line-breaks added for the purpose of clarity only) :

35 * (1 - (FWHM        - 2.092)   / 1.518) +
5 *   (1 - (Eccentricity - 0.3016) / 0.181) +
10 *        (SNRWeight - 0.9769) / 7.7051 +
50

And, from this I can see that the '35, 5, 10 and 50' would appear to add up to 100 !

Now I can see that the first two parts of the expression are very similar - and would seem to make very good sense if the FWHM and Eccentricity values are such that the calculations on the right-hand-side of each of those two sub-expressions resulted in a number between 0.0 and 1.0.

Further, I can see that FWHM and Eccentricity are 'better' when they are 'low' - hence the reason that you subtract the intermediate values from '1' in each case. SNRWeight, on the other hand, is 'better' when it is 'higher, so you do not perform the '1 - x' calculation.

That said, I never take any chances when creating expressions for any piece of computer software to interpret - I always force the order of calculations by using enough brackets to guarantee that there can be no ambiguity.

This would then take your expresion to this stage  (again, I have added the '0 +' for clarity):

(35 * ((1 - (FWHM        - 2.092))   / 1.518 )) +
(5 *   ((1 - (Eccentricity - 0.3016)) / 0.181 )) +
(10 * ((0 + (SNRWeight - 0.9769)) / 7.7051)) +
50

Now the whole expression can be taken back to its original format (without the extra spaces, line-breaks and the '0 + ' expression) :

(35*((1-(FWHM-2.092))/1.518 ))+(5*((1-(Eccentricity-0.3016))/0.181))+(10*(((SNRWeight-0.9769))/7.7051))+50


Of course - this may not yet be the full solution to your problem (however, I couldn't read the text on your screen-shot - perhaps you could capture a smaller area of the screen, allowing you to post it here at a better resolution, with less compression artefacts?).

Let us know how you get on.

[UlteriorModem]

Thank you for the input. What you are saying makes some sense to me but as I said this is not my strong suit.
Maybe I am better off just going through the plots and selecting them manually
I don't know how to get any better resolution of the screen grabs because they are just that.. screen caps but here is one more cropped.
I put in the expression you had developed ran the parse and got basically the same error message of "Relational operator expected".

[Niall Saunders]

Bearing in mind that I have never used this script (yet, but it looks more interesting than I had expected it to be !!!), the first thing that now pops into my mind is that the expression you are using is not appropriate to be used as an Approval Expression.

The Approval Expression would appear to require that it should resolve to a TRUE or FALSE condition (thus determining whether a given subframe should, or should not, be selected for output).

The expression that you have created would appear to be better suited for the Weighting Expression field - where the result is expected to be in a numeric form, indicating how much effect a particular sub-frame would have in further processing stages.

Try that, and get back to us.

[peteS]

Bearing in mind that I have never used this script (yet, but it looks more interesting than I had expected it to be !!!), the first thing that now pops into my mind is that the expression you are using is not appropriate to be used as an Approval Expression.

The Approval Expression would appear to require that it should resolve to a TRUE or FALSE condition (thus determining whether a given subframe should, or should not, be selected for output).

The expression that you have created would appear to be better suited for the Weighting Expression field - where the result is expected to be in a numeric form, indicating how much effect a particular sub-frame would have in further processing stages.

That is correct.

http://www.lightvortexastronomy.com/tutorial-pre-processing-calibrating-and-stacking-images-in-pixinsight.html#Section5

[drmikevt]

Yes, it is a weighting expression.  However, perhaps we should note that the author of Image Integration (perhaps he's biased) feels strongly that the default parameters are well designed to create the highest SNR image possible from the data, and that individual weighting of subframes does not yield much to any benefit.  Here is a copy/paste from the 'tips' section of the documentation of ImageIntegration:

Unless you have a strong reason to do otherwise, use the noise evaluation weighting method. In all of our tests this method consistently leads to the highest SNR improvement in the integrated images.


I use SFS to remove the outliers in FWHM, Eccentricity and SNR.  I used to weight all the images, but abandoned that approach after experimentation showed me it made no difference.  You will get a bigger and better impact on SNR by carefully tweaking the high and low pixel rejection parameters, to only allow rejection of the truly problematic pixels and nothing else.  Certainly there is a lot on the web about weighting images, and some people have proposed some pretty complicated expressions, but - has anyone shown it actually makes a difference if the subs themselves are well culled through? 

Mike

[UlteriorModem]

Thanks for the input everyone.

Sorry I did not get back to you sooner.

Indeed I was putting the weighting expression in the wrong field 

Anyhow I still run the SFS but just look at the plots. Mostly for FHWM and eccentricity for any frames that may be way out due to a tripod bump or clouds or some such. Not as much for SNR comparison. Even after using blink I often find at least one or two frames that should probably not be used.

Also I can use the weighting to determine which frames would be best to use as reference frames.

Thanks again for the help on this matter

[Niall Saunders]

Hi again.

I am assimung that the figures that you were using throughout the weighting expression were derived from your spreadsheet that, in turn, was calculating these from each individual sub-frame?

[goofisd]

The spreadsheet is from David Ault, you can see his explanation for it at his website: trappedphotons.com

As for the original issue - I get that sometimes when I don't copy correctly.  You want to copy the cell with the formula, and often I copy the wrong item and PI doesn't like it.