-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Defination of kernel sizes not agree with most papers #96
Comments
@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:
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. |
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?
The text was updated successfully, but these errors were encountered: