Can't make Image Integration work with SFS assigned weights?

[Terry Danks]

I've never done this before.
I use the SFS Process to affix weights to the fits headers. Seems to work. But when I run the Image Integration tool, the Process Console always reports the error as in the attached jpg.
I must be doing something wrong. No idea what. 
Suggestions as to what I've done wrong?

[dld]

Maybe the image file for which you are getting this error has a negative weight value?

[Terry Danks]

Absolutely, that's it!
But the negative weights are assigned by the SFS.
I thought there will ALWAYS be some negative weights.
Not sure I understand the implications here?

[dld]

Well, if the integrated image is a weighted average, weights must be non-negative. I can't find this restriction at the Reference Documentation, but in theory a weighted average won't allow for negative weights. SFS computes weights according to a user-provided formula, which can be anything, and thus can fail to fulfill the non-negativity restriction. Try to rewrite your expression in such a way that it can't take negative values, and assign your "worst" images with the smallest (non-negative) weights.

SFS doesn't perform any check to see if a weight is negative, but the ImageIntegration does, and that's why it halts.

[Terry Danks]

Thanks very much for the replies.
I cribbed the weighting expression from the SFS documentation.
Clearly it can, and does every time, return some negative values.
It is 2*(FWHMSigma / -3)+(SNRWeightSigma / 3)

Not sure why most of the weighting examples in the documentation return negative values with no mention that these can not be used with Image Integration.
But now that I understand the effect of negative values, I can adapt the expressions to avoid this happening.

[dld]

You are welcome!

I am sure that you have already adapted your expressions, but maybe others may find the following beneficial (I hope!)

Both FWHMSigma and SNRWeightSigma can return negative values. But a low FWHMSigma is a good thing, so you have to modify your expression to accommodate that. For the first part of your expression, something like:

( Max(FWHMSigma) -  FWHMSigma ) / ( Max(FWHMSigma) - Min(FWHMSigma) )

I am not sure how to get the max/min values of FWHMSigma and SNRWeightSigma 

will give your frames with low FWHM (the good ones!) a weight value towards 1. The above expression takes values from 0 to 1.

You can do a similar scaling for the SNRWeight part,

(SNRWeightSigma - Min(SNRWeightSigma) )/( Max(SNRWeightSigma) - Min(SNRWeightSigma) )

Here high SNRWeightSigma is a good thing and frames with good SNRWeight will have weights towards one. Again, the above expression takes values from 0 to 1.

From your weighting expression I see that you want a mix of "2/3 good FWHM " and "1/3 good SNR". Since now each "quality measure" is properly scaled, you can choose your "mix weights" (2/3 for "good FWHM" and 1/3 for "good SNR") at your taste (but again your "mix weights" should sum to one.)

You can also modify the numerators to avoid obtaining weights close to zero in order to give a chance to all images to contribute something at the integration stack! 

I hope this makes sense, and has no obvious mistakes

[Terry Danks]

Again, dld, many thinks for getting me to better appreciate what these expressions are actually doing.
I am still being very unsophisticated in formulating my expressions but a weighting based on both FWHM and SNR values, without producing negative numbers, is being accomplished and the resulting integrations are successful. How much better these integrations are, if better at all, then just letting the Image Integration tool have at the subs, is a mystery. 
Eccentricities are a constant bugbear for me and seem strictly seeing-related. I have already used SFS to eliminate any subs with Ecc > 0.600 and have been doing so for a couple of years now. So, I have not attempted an expression to take ecc into account during the weighting calculations.