I am starting a discussion thread here regarding my work in progress on
the implementation of a CPU version of the NFFT gadget. I'll be updating
my progress here and probably ask for a bit of support from time to
time.
I am planning to use the existing NFFT library
( http://www-user.tu-chemnitz.de/~potts/nfft/ ), which I am fairly
comfortable with (shameless plug of the Python wrappers I made for it
here: https://github.com/ghisvail/pyNFFT ). The licensing is the same as
FFTW, and the data structure looks fairly similar. The library also has
multi-threading support via OpenMP.
From my initial assessment, I see 3 main tasks:
implement a cpuNFFTOperator, with a similar interface than
cuNFFTOperator,
implement an NFFTGadget, to use for reconstruction with Gadgetron,
implement a ismrmrd_generate_radial_shepp_logan script to produce
phantom data for testing the NFFT gadget.
I have yet to estimate how much time each of these tasks is going take
and how hard they will be. Task #3 seems the easiest to me, #1 could be
fast too, and #2 is probably going to be the most demanding.
If you guys have any suggestions to help me getting started, please feel
free to contribute.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For #1, it would be awesome if the interfaces were as similar as possible
to the cu operator. That would allow drop-in replacement to by simply
changing the templated data type from a cuNDArray to an hoNDArray. If at
all possible, that would be ideal.
For #2, I would rely on the trajectories on the ISMRMRD header in a first
instance. For trajectories where they are not available, they could be
calculated and added to the data structures by an upstream gadget, which
would make it possible to use your NFFTGadget for any arbitrary trajectory.
See the Generic non-Cartesian SENSE gadget that is in there already for a
place to start.
For #3, be aware of a circular dependency. If you would like to use a
Gadgetron toolbox in the ISMRMRD library, you have to think about how you
do it, since the Gadgetron (at least parts of it) depend on ISMRMRD. This
can be managed but you need to think about it.
I am starting a discussion thread here regarding my work in progress on
the implementation of a CPU version of the NFFT gadget. I'll be updating
my progress here and probably ask for a bit of support from time to
time.
I am planning to use the existing NFFT library
( http://www-user.tu-chemnitz.de/~potts/nfft/ ), which I am fairly
comfortable with (shameless plug of the Python wrappers I made for it
here: https://github.com/ghisvail/pyNFFT ). The licensing is the same as
FFTW, and the data structure looks fairly similar. The library also has
multi-threading support via OpenMP.
From my initial assessment, I see 3 main tasks:
1. implement a cpuNFFTOperator, with a similar interface than
cuNFFTOperator,
2. implement an NFFTGadget, to use for reconstruction with Gadgetron,
3. implement a ismrmrd_generate_radial_shepp_logan script to produce
phantom data for testing the NFFT gadget.
I have yet to estimate how much time each of these tasks is going take
and how hard they will be. Task #3 seems the easiest to me, #1 could be
fast too, and #2 is probably going to be the most demanding.
If you guys have any suggestions to help me getting started, please feel
free to contribute.
On Tue, 2014-05-27 at 15:37 +0000, Michael Hansen wrote:
Hi Ghislain,
This sounds good.
For #1, it would be awesome if the interfaces were as similar as possible
to the cu operator. That would allow drop-in replacement to by simply
changing the templated data type from a cuNDArray to an hoNDArray. If at
all possible, that would be ideal.
Very good point. Looks definitely do-able to me.
For #2, I would rely on the trajectories on the ISMRMRD header in a first
instance. For trajectories where they are not available, they could be
calculated and added to the data structures by an upstream gadget, which
would make it possible to use your NFFTGadget for any arbitrary trajectory.
See the Generic non-Cartesian SENSE gadget that is in there already for a
place to start.
I like this workflow. I can see that working. I'll stick to the case
where the trajectory is provided in the ISMRMRD header. Later, maybe
conventional trajectories like Cartesian, radial, etc... could be
generated by the Gadgetron pipeline, if the information is encoded
somewhere in the header.
For #3, be aware of a circular dependency. If you would like to use a
Gadgetron toolbox in the ISMRMRD library, you have to think about how you
do it, since the Gadgetron (at least parts of it) depend on ISMRMRD. This
can be managed but you need to think about it.
I'd probably do it the same way as you did with the Cartesian case
(using FFTW), i.e. calling the NFFT library directly rather than using
the operator defined in the Gadgetron toolbox. That way, both the
ismrmrd and gadgetron projects will be kept separate, as it probably
should be.
Good luck. Let us know how it goes.
Michael
Thanks for these encouraging comments.
Ghis
Last edit: Ghislain Vaillant 2014-05-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi guys,
I am starting a discussion thread here regarding my work in progress on
the implementation of a CPU version of the NFFT gadget. I'll be updating
my progress here and probably ask for a bit of support from time to
time.
I am planning to use the existing NFFT library
( http://www-user.tu-chemnitz.de/~potts/nfft/ ), which I am fairly
comfortable with (shameless plug of the Python wrappers I made for it
here: https://github.com/ghisvail/pyNFFT ). The licensing is the same as
FFTW, and the data structure looks fairly similar. The library also has
multi-threading support via OpenMP.
From my initial assessment, I see 3 main tasks:
cuNFFTOperator,
phantom data for testing the NFFT gadget.
I have yet to estimate how much time each of these tasks is going take
and how hard they will be. Task #3 seems the easiest to me, #1 could be
fast too, and #2 is probably going to be the most demanding.
If you guys have any suggestions to help me getting started, please feel
free to contribute.
Hi Ghislain,
This sounds good.
For #1, it would be awesome if the interfaces were as similar as possible
to the cu operator. That would allow drop-in replacement to by simply
changing the templated data type from a cuNDArray to an hoNDArray. If at
all possible, that would be ideal.
For #2, I would rely on the trajectories on the ISMRMRD header in a first
instance. For trajectories where they are not available, they could be
calculated and added to the data structures by an upstream gadget, which
would make it possible to use your NFFTGadget for any arbitrary trajectory.
See the Generic non-Cartesian SENSE gadget that is in there already for a
place to start.
For #3, be aware of a circular dependency. If you would like to use a
Gadgetron toolbox in the ISMRMRD library, you have to think about how you
do it, since the Gadgetron (at least parts of it) depend on ISMRMRD. This
can be managed but you need to think about it.
Good luck. Let us know how it goes.
Michael
On Tue, May 27, 2014 at 11:28 AM, Ghislain Vaillant
ghisvail@users.sf.netwrote:
Hi Michael,
On Tue, 2014-05-27 at 15:37 +0000, Michael Hansen wrote:
Very good point. Looks definitely do-able to me.
I like this workflow. I can see that working. I'll stick to the case
where the trajectory is provided in the ISMRMRD header. Later, maybe
conventional trajectories like Cartesian, radial, etc... could be
generated by the Gadgetron pipeline, if the information is encoded
somewhere in the header.
I'd probably do it the same way as you did with the Cartesian case
(using FFTW), i.e. calling the NFFT library directly rather than using
the operator defined in the Gadgetron toolbox. That way, both the
ismrmrd and gadgetron projects will be kept separate, as it probably
should be.
Thanks for these encouraging comments.
Ghis
Last edit: Ghislain Vaillant 2014-05-27