Artifacts on object edges

[jil24]

Hi,

I'm seeing some behavior that differs a bit from what I expect. I have attached images of the same dataset deconvolved with the different methods, same PSF (except EpiDEMIC, which is blind), and largely the same settings. The RedLionFish results tend to have some unusual intense "ringing" on the edges of objects that are absent in the other results. Any idea what is going on here?

The source files can be found here: https://www.dropbox.com/s/5wvba69vb7yf4e1/todeconv-psf1.tif?dl=0 https://www.dropbox.com/s/jkvkolj2lg051h1/todeconv.tif?dl=0

[perdigao1]

Hi. Sorry for delay, I will look at that soon, but my suspicion is that your result is the 'normalised to uint8' output. This is what the napari RedLionfish plugin does by default. If this is the case, perhaps I will make this an optional feature.

[perdigao1]

I just tried to deconvolute your data in RedLionfish. It does indeed show some 'ringing'. I don't know why this is much different than the other software you tried. But here are possible explanations.

The PSF data has the z dimension higher than the data itself. This may or many not be significant. The Redlionfish does the deconvolution without padding the data.

Other packages handle the whole algorithm in different ways. Internally, they may increase the input data in the internal convolution to a size that is data+psf and may also pad to a size that is faster for FFT. Redlionfish does not do that, but we have considered. We chose not to because of several potential problems. Sometimes users like to load PSF's that are quite big in size, and if we padded data to size data+psf, then convolution would be done in a very large data volume, which may fail due to lack of memory in GPU or RAM. Padding to a FFT size was also tested, but I noticed that the ringing artifacts are noticeable different compared to not using this. As such, and for reasons of consistency, this idea was put aside for now, pending further investigation.

One additional and significant problem with Richardson-Lucy deconvolution is that edge effects 'propagate' from edges to the centre of the data. This is also currently being investigated. But put it simply, the 'valid' RL deconvolution result would be a volume smaller than the data itself. The larger the psf, the smaller the valid region would be (linear decrease). The larger the number of iterations, the smaller the region would be (exponential decrease).

As you psf z-size is bigger than the data z-size, that would make the valid z-size to be zero. Clearly not practical for most microscopy data.

To summarize, I am not sure how to improve your data quality, but recommendation is to keep psf and number of iterations small, therefore maximizing the (imaginary) valid region.

A small warning to DeconLab2, I looked at the source code I I didn't understand one step in the algorithm, that should do the convolution with the flipped psf, but it is doing something different. I may be wrong but I think it may lead to weird results if the psf is not symmetrical.

I hope this helps.

[jil24]

Thanks for looking into it; I attempted data padding and similarly to what you describe I also got worsened artifacts. I also adjusted the code myself to get uint16 output. I wonder if what DeconvolutionLab is doing is "non-circulant" edge handling?

[perdigao1]

I think the default for convolutions is to use non-circulant (where data beyond edges is simply assumed to be zero for the purposes of convolution). If that is what you are asking, then I believe that DeconvolutionLab, Redlionfish and many others use non-circulant.

[perdigao1]

I also made the ouptut as uint8 an optional feature in the napari plagin. Should be available soon in version 0.7.