Hilbert transform for envelope detection

[tvercaut]

Is your feature request related to a problem? Please describe.
Many ultrasound computing pipelines rely on a envelope detection detection algorithm. Having such a feature in MONAI would help ultrasound researchers adopt MONAI.

Describe the solution you'd like
A GPU enabled, ideally differentiable, PyTorch version of scipy.signal.hilbert

Describe alternatives you've considered
Implementing the Hibert transform if/when needed by using the PyTorch fft.

Additional context
Adding @crnbaker in the discussion

[Nic-Ma]

Hi @tvercaut ,

I marked for working group discussion, maybe you guys can discuss deeper in the meeting and make some proposals.
Thanks.

[tvercaut]

Hi @Nic-Ma,
This doesn't need to be prioritised in a working group. We are looking at it for one of our projects and would submit a PR when ready. This issue is meant to keep track of the planned PR and start the ball rolling with @crnbaker. (Similar scenario with #1155 )
Tom

[crnbaker]

Hi both, happy to take a look at this once I've got my head round the project!

[crnbaker]

I've implemented a Hilbert transform for 1D tensors using torch.fft.fft() and torch.heaviside() . @tvercaut are you interested in multidimensional Hilbert transforms too? If so, I could implement the method described here.

As I'm brand new to MONAI, I'm not sure exactly where this new transform should go. monai.transforms.intensity maybe, inheriting from Transform?

[wyli]

preferably it should go into monai/networks/layers and inheriting nn.Module, like the gaussian filter

MONAI/monai/networks/layers/simplelayers.py

Line 133 in 4e91640

class GaussianFilter(nn.Module):

and could add a transform class to use the layer, like the gaussian smoothing

MONAI/monai/transforms/intensity/array.py

Line 512 in 4e91640

class GaussianSmooth(Transform):

[crnbaker]

Thanks, makes sense.

[tvercaut]

@crnbaker: I think a 1D Hilbert transform is enough for the use cases I have in mind. However, we should be able to aply it to 2D or 3D images by specifying the dimension across which to apply the 1D transform.

Also, a small performance benchmark with respect to scipy (maybe alse a jax-based implementation?) would be great. It could be as simple a notebook with some timeit in the first instance as e.g. here: https://colab.research.google.com/drive/17pI6xPGLTGcpGBulBrWZeNnBfLAwzqZT?usp=sharing

[crnbaker]

Just finalising this now. I've noticed that the other transforms in MONAI/monai/transforms/intensity/array.py return Numpy arrays rather than Tensors. For example class GaussianSmooth(Transform) mentioned above:

return gaussian_filter(input_data).squeeze(0).detach().numpy()

Is this the behavior we want? Wouldn't it be better to return Tensors in case the transforms are being used as part of a CUDA pipeline?

EDIT: I've just realised that all the transforms in /intensity/array.py are intended to take numpy arrays and operate on the CPU only - presumably that's why it's called array! I will include the Hilbert transform there, accepting and returning Numpy arrays. Is there another location for transforms that operate on Tensors, or would you expect the user to use layers/simplelayers directly? There's not much of an advantage using PyTorch over Scipy for this transform on the CPU.

[wyli]

Hi @crnbaker, the user should use layers/simplelayers if they are dealing with torch tensors on gpu. currently the transforms are mainly with numpy arrays, there's an ongoing discussion about how we support numpy/torch on cpu/gpu for the preprocessing. for now the transforms should at least support numpy. we can refactor these later. btw the transforms assume shape [channel, spatial_dim0, spatial_dim1, ...], but the layers assume [batch, channel, spatial_dim0, spatial_dim1, ...]. These assumptions simplify the input format validation

[crnbaker]

Great, thanks @wyli. I'll submit my pull request soon.