-
Notifications
You must be signed in to change notification settings - Fork 28
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
Toeplitz gram #57
Toeplitz gram #57
Conversation
… trj = rand(3, 72960) .- 0.5 and shape = (192,192,192)
…ultihreading; some minor tweaks to improve speed
Hmm, I incorporated Polyester.jl into the LUT generation. That does not seem to fly with Julia 1.3. If you want to keep the compat, we could switch to Threads.@threads, but it was slower in my brief tests. On the other hand, Julia 1.6 is now the LTS, so maybe we can drop the older version? |
yes we can bump to Julia 1.6! |
Codecov Report
@@ Coverage Diff @@
## master #57 +/- ##
==========================================
+ Coverage 67.34% 67.73% +0.39%
==========================================
Files 12 13 +1
Lines 692 750 +58
==========================================
+ Hits 466 508 +42
- Misses 226 242 +16
Continue to review full report at Codecov.
|
Unfortunately our two branches diverged because we touched both too many files. We should fix this quickly which unfortunately requires some work. I would say we should go this way
In the future we can then directly work against master and gradually improve that. I would like the Toepliz stuff isolated on an extra branch so that Jeff can first review that. |
Just saw that you merged it. Sure, I will merge master into my branch and make sure everything is works again. And I agree, Jeff's feedback would be great and he offered to do so via email. |
Done, sorry for the merge conflicts! I duplicated some of your work since I needed to introduce a new precompute flag FULL_LUT, which reduces the precomputation time for the FULL flag substantially. |
I merge this as is since it touches too many files and we can gradually improve it on master. @JeffFessler can do a post merge review. Regarding the apodization: Yes, right now it is doing an fftshift and it is not possible to disable this. But we can simply implement an additional version without that. This should also allow us to have an NFFT for odd N (see #36). |
Hi @tknopp , @JeffFessler ,
re #55 : I gave it a first shot. Right now, the constructor is doing
fft(fftshift(apodization_adjoint_with_fftshfit(ifft(x)))
From my understanding, the apodization function is doing an ifftshift. I am not sure if it is possible to perform the apodization without this, I am having a hard time reading the metaprogramming.
Apart from that, I tested it with different data types and N dimensions.
Let me know what you think, I am sure both of you have a much better suggestion on how to implement this, I am somewhat an NFFT rookie.
Best,
Jakob