mckib2 / pygrappa

Python implementations of GRAPPA-like algorithms.

Home Page:https://pygrappa.readthedocs.io/en/latest/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Defination of kernel sizes not agree with most papers

mylyu opened this issue · comments

First, thanks for such a great project. I really love using this toolbox.

I noticed this problem when using kernel size (5,5) at high acceleration factor (R), because the results were too poor. After increasing the kernel size to about R times, the results became normal. Then I checked the code, and found the kernel size is used as a region? Then the actual number of data points used to interpolate may be far less than the "kernel size". I believe that in most published papers, the kernel size means exactly how many points are used to interpolate the missing point.

Am I right?

@mylyu I believe you are correct. The original thought process for specifying a region was to not have to assume specific, regular line geometries and allow for potentially arbitrary, non-repeating sampling patterns. If I understand correctly, this is what the GE ARC implementation does and what Mikki Lustig replicates in the GRAPPA implementation bundled with his SPIRiT code here.

But I agree, that the "total number of neighboring sources used for interpolation" is almost certainly what's expected here. I'll have to think of an implementation strategy. The first couple things that come to mind are:

  1. use a kd-tree and query for the $$\Pi_{k \in \text{kernel} } k $$ nearest neighbor samples, OR
  2. use a greedy strategy to push out in a hyper-rectangle with side ratios determined by the kernel size (?) all dimensions until the number of points are acquired

I'm leaning towards the kd-tree unless you have any ideas?

For reference, mdgrappa calculates all possible geometries here

@mylyu I believe you are correct. The original thought process for specifying a region was to not have to assume specific, regular line geometries and allow for potentially arbitrary, non-repeating sampling patterns. If I understand correctly, this is what the GE ARC implementation does and what Mikki Lustig replicates in the GRAPPA implementation bundled with his SPIRiT code here.

But I agree, that the "total number of neighboring sources used for interpolation" is almost certainly what's expected here. I'll have to think of an implementation strategy. The first couple things that come to mind are:

  1. use a kd-tree and query for the Πk∈kernelk nearest neighbor samples, OR
  2. use a greedy strategy to push out in a hyper-rectangle with side ratios determined by the kernel size (?) all dimensions until the number of points are acquired

I'm leaning towards the kd-tree unless you have any ideas?

For reference, mdgrappa calculates all possible geometries here

Thanks for the reply. I agree that Lustig also implemented it as such. It will be great if a reminder can be put in the docs so that users can know how to use a proper kernel size.