Fixes for mosaic output pixels not covered by inputs #413
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I noticed that, when using
reproject_and_coadd
with background matching and withcombine_function='first'
, a bounding box around some of the input images can be filled, so that outputs look like this:instead of this:
This happens because output pixels not covered by a given input image are set to zero after that image is reprojected, and those zero values get adjusted by the background matching. For the other
combine_function
options, those out-of-bounds pixels never get used, so their final value doesn't matter, but that wasn't the case forcombine_function='first'
, which this PR rectifies.While adding a test that works through the options and ensures the final output mosaics are zero outside the returned footprint and filled-in inside the footprint, I noticed an inconsistency in that all the
combine_function
s produce zeros for pixels not spanned by any input image, except forcombine_function='mean'
, which outputsnan
s for those unsampled pixels (generated when dividing by sum-of-weight values of zero). This PR also changes thosenan
s to0
, to ensuremean
is consistent with the other modes.