[WIP] Registration public API for multi-slice 2D data

[samcoveney]

The functions in dipy/align/_public, which conveniently allow to register entire dwi series, are only designed to work with 3D volumes, i.e. 4D data, in which the acquisitions are in the last dimension.

In cardiac MRI, data is often stored in a nifti file as if it were volumetric, but the third dimension corresponds to slice positions, i.e., [Nx, Ny, num_slices, num_acq]. These data for different slices were collected in separate acquisitions, so we cannot treat data[:, :, :, 1] as a volume. The registration needs to be performed on each slice separately, and this is a 2D registration problem.

I have adapted the code in dipy/align/_public to work in such a scenario by giving an optional argument "slice_index", which when provided causes the code to perform 2D registration on the given slice.

One tricky catch with 2D registration, is that the images need to be in the same plane. The 3D affine that can specify static_grid2world and moving_grid2world could be checked to ensure this. But then the resulting data would (in general) have 3D coordinates even if the data was effectively 2 dimensional. For this reason, it's easier just to work in pixel coordinates, and enforce that *_grid2world to np.eye(3) (note that this corresponds to 2D data, which is an additional reason for this change).

This pull request is work in progress, but it is pretty much complete. I would like some feedback please. There is an example provided.

[pep8speaks]

Hello @samcoveney, Thank you for updating !

Cheers ! There are no PEP8 issues in this Pull Request. 🍻

Comment last updated at 2022-03-29 08:25:43 UTC

[codecov]

Codecov Report

Merging #2538 (6d487e1) into master (e82295a) will increase coverage by 0.00%.
The diff coverage is 85.71%.

❗ Current head 6d487e1 differs from pull request most recent head 877240e. Consider uploading reports for the commit 877240e to get more accurate results

@@           Coverage Diff            @@
##           master    #2538    +/-   ##
========================================
  Coverage   85.08%   85.08%            
========================================
  Files         129      127     -2     
  Lines       17579    17439   -140     
  Branches     2994     2969    -25     
========================================
- Hits        14957    14838   -119     
- Misses       1926     1927     +1     
+ Partials      696      674    -22     

Impacted Files	Coverage Δ
dipy/align/_public.py	87.81% <85.71%> (+6.19%)	⬆️
dipy/nn/model.py	27.77% <0.00%> (-62.97%)	⬇️
dipy/io/streamline.py	81.48% <0.00%> (-0.98%)	⬇️
dipy/data/fetcher.py	42.62% <0.00%> (-0.59%)	⬇️
dipy/io/stateful_tractogram.py	73.90% <0.00%> (-0.08%)	⬇️
dipy/info.py	100.00% <0.00%> (ø)
dipy/data/__init__.py	80.41% <0.00%> (ø)
dipy/segment/metric.py	100.00% <0.00%> (ø)
dipy/nn/histo_resdnn.py
dipy/utils/parallel.py
... and 2 more

[skoudoro]

Hi @samcoveney

But I would like some feedback please. To use, simply provide "slice_index" argument and the return values should be registered 2D data.

We are currently in the release process, doing multiple checks, finalizing some important points, etc... I just want to let you know that we will start to look in detail at your PR next week, after the release.

[samcoveney]

Hi @samcoveney

But I would like some feedback please. To use, simply provide "slice_index" argument and the return values should be registered 2D data.

We are currently in the release process, doing multiple checks, finalizing some important points, etc... I just want to let you know that we will start to look in detail at your PR next week, after the release.

Any chance that this could get looked at soon? Let me know if there's anything I can do to help here.

[skoudoro]

Hi @samcoveney ,

Apologize for not giving news. The core maintainers (including me) are really focused on this workshop that we are organizing: https://dipy.org/workshops/dipy-workshop-2022

That's why we were not so active these past 2 weeks. The workshop finishes this Friday, so everything will get back to normal, next week (review, update, etc...).

[samcoveney]

Tests are passing on my system, are they failing here for reasons not related to my PR?

[skoudoro]

Tests are passing on my system, are they failing here for reasons not related to my PR?

yes, fixed in #2566

[skoudoro]

Hi @samcoveney,

Can you share some data?

I am sure I understand what you are trying to do. I got a general idea, but something is disturbing me. the slice_index looks problematic to me. But I need to go deeper into your PR.

Please, let me know where can I find cardiac MRI data. Thanks

[samcoveney]

Hi @skoudoro thanks for taking a look.

Open cardiac MRI datasets (for DWI) are hard to come by, which is why I showed the idea using slices of brain data. Can you take a look at the example file that I wrote?

What is the problem with slice_index do you think? It is used to select a slice of 2D data e.g. data[:, :, slice_index, :] in the case that the array does not really represent volumes.

This may not be the best implementation of course, it was just meant to allow a simple extension of the API. It could be better to tell the user to simply provide an array of shape [num_x, num_y, 1, num_acq] instead of requiring the slice_index at all?

I appreciate your thoughts on this.

[samcoveney]

I've not heard back on this, but I think I will modify the code to take out the slice_index argument - if the user provides data with a spatial dimension of size 1, then do 2D registration, otherwise to 3D registration. This seems much tidier. I will finish that off after the Easter weekend.