PSF deconvolution should zero out negative pixels

[nabobalis]

In GitLab by @wtbarnes on Dec 17, 2020, 15:47

In our PSF deconvolution, we are not zeroing out negative pixels. When the data are in 32-bit floating point, this causes the code to blow up. In the case of 64-bit data, the routine succeeds, but leaves artifacts in the image and can cause issues downstream in an image processing pipeline.

We need a step to zero out these negative values. Maybe this should be a switch so that people can optionally turn this off? The documentation should also make it clear that this is happening.

This notebook shows how negative pixel values can propagate through the image prep steps and affect the final product: https://gist.github.com/wtbarnes/7087db18498ffe856afdc56a4a58f6d2

[nabobalis]

In GitLab by @markcheung on Dec 17, 2020, 15:50

I'd advocate for clip_negative=True. An alternative: assert(img.min() >= 0) but this is strict. RL deconvolution is not meant for data with negative values, so maybe not too strict.

[nabobalis]

In GitLab by @wtbarnes on Dec 17, 2020, 15:58

I would say we just add the clip_negative flag and then add a warning that tells the user they have negative values.

[nabobalis]

In GitLab by @wtbarnes on Jan 28, 2021, 15:43

mentioned in commit bc9dc68e99c7df889f39716e3d3e9dfd31de7d0b