Tested under git development branch, using standalone app nufft_2d_radial, output matrix doesn't make sense.
My OS is debian jessie 64bit, cuda version 6.0.
Backward nufft is OK, also tested under the same setting. Still able to get a reconstructed image, as long as correct input data is provided.
command "nfft_2d_radial -d shepp_logan_256_256_no_noise.real -o 320 -p 402 -s 256" generated the attached file, which doesn't make sense.
In order to take a closet look at this we will need more information than "output matrix doesn't make sense".
You need to provide a test case with some data so that we can reproduce the problem. Our continuous integration test runs multiple tests on the nfft every time code is checked in. This includes end to end testing of iterative non-Cartesian SENSE, which uses both the forward and backward version and all those tests pass. That said you could have found a case that fails, which is why we need more information.
Thanks,
Michael
Sent from a mobile device - please excuse brevity and/or typos.
Since other recon that rely on the forward nfft is still working fine, I think the nfft function itself is intact, it must be some data handling part in the middle that's broken.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We recently changed the way the density compensation was handled for the NFFT. By accident, the standalone apps in the nfft folder were not updated.
I've just committed a fix for this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tested under git development branch, using standalone app nufft_2d_radial, output matrix doesn't make sense.
My OS is debian jessie 64bit, cuda version 6.0.
Backward nufft is OK, also tested under the same setting. Still able to get a reconstructed image, as long as correct input data is provided.
command "nfft_2d_radial -d shepp_logan_256_256_no_noise.real -o 320 -p 402 -s 256" generated the attached file, which doesn't make sense.
Last edit: Zhitao Li 2014-05-10
Thank you for the feedback.
In order to take a closet look at this we will need more information than "output matrix doesn't make sense".
You need to provide a test case with some data so that we can reproduce the problem. Our continuous integration test runs multiple tests on the nfft every time code is checked in. This includes end to end testing of iterative non-Cartesian SENSE, which uses both the forward and backward version and all those tests pass. That said you could have found a case that fails, which is why we need more information.
Thanks,
Michael
Sent from a mobile device - please excuse brevity and/or typos.
I did attach a output file from the command line described at the end of the post, please take a look.
Sorry, didn't see the file because it didn't get forwarded to my email. Thomas has reproduced the problem and is looking into it.
This particular file is not tested with the integration test.
I can reproduce the problem and we will look into it - and report back.
/ Thomas
Since other recon that rely on the forward nfft is still working fine, I think the nfft function itself is intact, it must be some data handling part in the middle that's broken.
We recently changed the way the density compensation was handled for the NFFT. By accident, the standalone apps in the nfft folder were not updated.
I've just committed a fix for this.