Better special pixel support in reduce

[rvwagner]

Description

Currently, when the Reduce program is running with ALGORITHM=AVERAGE, if an input region has >VALIDPER% special pixels, the output pixel will be NULL, regardless of what type of special pixel value caused the replacement. There is a "VPER-REPLACE=NEAR" option that indicates that it will use the center pixel of the region(?) instead of NULL, but it may not be functional: it definitely replaces blocks of pure HIS pixels with NULL, and seems to replace valid center-of-invalid-region pixels with NULL, too, when compared with an "ALGORITHM=NEAREST" run on the same input cube.

At any rate, it would be nice if, in the case where an output pixel is not valid because a majority of the input pixels are a single non-NULL special pixel (e.g. HIS), the output pixel could be set to that non-NULL special pixel value, rather than at best falling back on a nearest-neighbor algorithm that may or may not happen to select a pixel with that special value.

A possible way to implement this would be to add a third state for the VPER_REPLACE parameter, "MAJORITY" (or some similar word), which would propagate the most common special pixel in the input region when there aren't enough valid pixels.

Example

A specific use case of this is ShadowCam images, which will generally contain large regions of HIS pixels due to being saturated in sunlight. It would be good to be able to run reduce on them prior to cam2map (which produces better results for low-resolution map output than running cam2map directly), without turning the large HIS regions into undifferentiated NULLs.

[github-actions[bot]]

Thank you for your contribution!

Unfortunately, this issue hasn't received much attention lately, so it is labeled as 'stale.'

If no additional action is taken, this issue will be automatically closed in 180 days.

[rvwagner]

Poking this issue because I'd like it to at least get discussed before being marked as "completed".

[github-actions[bot]]

Thank you for your contribution!

Unfortunately, this issue hasn't received much attention lately, so it is labeled as 'stale.'

If no additional action is taken, this issue will be automatically closed in 180 days.

[rvwagner]

See previous poke. Still relevant for ShadowCam.

[jlaura]

Out of curiosity - is there a PR coming in adding ShadowCam support to ISIS?

[volare1996]

Out of curiosity - is there a PR coming in adding ShadowCam support to ISIS?

Where can I see the process of pre-processing ShadowCam using ISIS software?.