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?.

[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.

If you want to participate in our support prioritization meetings or be notified when support sprints are happening, you can sign up the support sprint notification emails here.

Read more about our support processs here

[rvwagner]

Still relevant, and will come up for people working with the map-projected PDS products released by the ShadowCam team. Here's an example using an early image with both HIS and LIS pixels:

`wget https://pds.shadowcam.asu.edu/observation/2023/030/M015443438S/M015443438S_map_raw.tif

gdal_translate -of isis3 M015443438S_map_raw.tif M015443438S_map_raw.cub

reduce from= M015443438S_map_raw.cub to= M015443438S_map_raw.reduce_avg.cub reduce from= M015443438S_map_raw.cub to= M015443438S_map_raw.reduce_validper.cub vper_replace=near reduce from= M015443438S_map_raw.cub to= M015443438S_map_raw.reduce_near.cub alg=near

qview M015443438S_map_raw.cub M015443438S_map_raw.reduce_avg.cub M015443438S_map_raw.reduce_validper.cub M015443438S_map_raw.reduce_near.cub`

Only algorithm=nearest keeps any non--NUL special pixels, but that isn't an acceptable downsampling algorithm for many purposes.