Implement variance propagation in the drizzle code

[stscijgbot-jp]

Issue JP-3757 was created on JIRA by David Law:

As discussed in JP-3680 and JP-3569, one of the limitations in dealing with resampling and proper error propagation in the JWST pipeline at present is the inability of the core drizzle implementation to propagate variance information.  This has resulted in JP-3569 needing to explore various approximate hacks and workarounds, and JP-3680 finding the limits of those workarounds when attempting to handle error measurements on surface brightness that scale properly with different output pixel scales.

The core required change is conceptually simple.  As per discussion on JP-3569, consider the case of only two pixel inputs to a given output pixel.  With input fluxes f1 and f2, and variances V1 and V2, each with weights w1 and w2, the output flux f3 is

f3 = (w1 * f1 + w2 * x2)/(w1 + w2)

and the output variance V3 is

V3 = (w1w1V1 + w2w2V2)/((w1+w2)*(w1+w2))

I.e., fluxes (which drizzle can currently handle) weight by the weights w1 and w2 derived from the drizzle pixel area overlap calculation.  Variances in contrast need to be weighted by the square of this area overlap weight.

If f1=1, f2=7, v1=0.5, v2=50, w1=0.99, and w2=0.01 (i.e., pixel 2 is much more uncertain, but the output is almost entirely dominated by pixel 1 area of overlap), then

f3=1.06, v3=0.495

One possibility may be to allow passing an optional parameter into the drizzle code that determines whether or not to use weights as necessary to propagate fluxes (default) or variances.

Note that this refactor will affect JWST imaging and non-IFU spectroscopy.  The IFU 3D drizzle equivalent implemented in the cube_build software already distinguishes between flux and variance propagation with the appropriate weights (see Eqns 8 and 9 and associated discussion in https://ui.adsabs.harvard.edu/abs/2023AJ....166...45L/abstract)

[stscijgbot-jp]

Comment by Mihai Cara on JIRA:

This was implemented via #8997 and spacetelescope/drizzle#163