I just wanted to say that I have nothing against Dirk-Jan. I applaud him for his work and the contributions he has made to research, programming and the matlab communities, in large. He certainly has produced excellent work in the past and generously contributed to others. I only wanted to make note of a minor or major omission (depending on how you look at it) when this file was first posted, namely a disclaimer and references. If it makes any difference, I am glad to give it another 4 star rating, even though I still haven't even tried it because I know that Dirk-Jan has put a lot of work into it and is contributing to the community.
I recommend simply removing the suggestion all together. If someone would like to venture into that territory by their own free will, then they will be liable and subject to peer review.
Alternatively, I would suggest the following amendment,
Warning !!!
Image filtering attempts to remove noise but because will end up removing some real values and replacing them with inaccurate estimates.
If tried on medical images, these artifacts are even more likely due to the different physical principles underlying image intensity at any given pixel. Please BEWARE that important anatomic and pathologic details can be lost with potentially tragic consequences. (see discussion below).
Just to let you know, I gave another rating at 1 star because I realized you only had 2 references, neither of which say anything about application to medical imaging (MRI or CT). That is very poor form!
Again, I want to say that I haven't tried your code, but I am willing to re-star your post at higher level, if you amend your opening statement to something less falsely advertising. Indeed, if you have done a good job, then you shouldn't have to sell it as more than it is. I see that you have posted many files before and so I don't doubt that you are able to code well. It is just your reckless propagation of something unscientific in such an important arena as medicine that I have problems with.
If we want to make automatic computerized recognition systems we need to use real science and not just translate what has been done in some other field and claim that it works great for medical images. Medical images are not like natural light images, they use completely different physical mechanisms to capture information.
Reconstruction needs to be performed, filtering does not. Furthermore, reconstruction is based on science fundamentally geared toward medical images to reduce bias.
I can tell you for certain that applying NLM to an MR would introduce an unacceptable amount of bias, blur the image, and cover up lesions. So what is the point? There is none. One can't just start posting up files saying they are good for this and that, when in fact they are not. Science needs to be done properly if one wants to make gains for ACRS. And thus, any medical doctor or true scientist would say that your claims and program are pointless and false with respect to medical images, as they would find the raw image better.
If you have not done your research, don't make false claims!
Propagation of unreviewed applications on the FEX to different fields is a danger to science! All you have are 2 literature citations, neither of which have anything to do with MRI or CT or any other medical imaging modality, yet you claim that it works on them!
Thanks, nicely written code.
Although I am experiencing the same problems as dileep with roundoff errors in the Kummer function. Did you happen to make any progress in this Mike?
Cheers,
Steven
dileep, thanks for your comment. I assume you meant parameters [10 7 7] [6 6] -.9, for both? This turns out to be a good test case, so I am glad you caught it.
After looking into the error it turns out to be a precision problem with accumulated round off errors. For these parameters the individual terms grow in absolute value to ~3E10 before eventually decreasing and converging to zero. This is in addition to alternating signs term by term.
The program assumed terms were convergent, and gave a TT=1. I will expand the code to try and correct for those cases and to hopefully keep track of better precision for cases like these. A newer version will be uploaded once that is complete.
-MIke
I have checked only few cases.
Apparently it's very fast. It is fully vectorized. Seems faster than genHyper (File ID: #5616) and hypergeom even for scalars. For example:
N = 100;
c = -.9;
r = -.7;
tic, genHyper(complex([.5, .5], [0, 0]), (2 * N - 1) / 2, (c * r + 1) / 2, 0, 0, 15), toc
tic, hypergeom([.5, .5], (2 * N - 1) / 2, (c * r + 1) / 2), toc
tic, pfq([.5, .5], (2 * N - 1) / 2, (c * r + 1) / 2), toc
Chapeau!
Comment only