From simon.rit at creatis.insa-lyon.fr Wed Feb 5 10:30:13 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 16:30:13 +0100 Subject: [Rtk-users] Ending ITK 3.20 compatibility Message-ID: Dear all, The RTK consortium has decided today to give up the ITK3.20 compatibility. It has been hard to maintain it lately (you may have noticed it on the dashboard) and we do not see any advantage of keeping it. Would you have any concern with this decision, please contact us quickly because it will be effective soon. Regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Feb 5 11:42:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 17:42:38 +0100 Subject: [Rtk-users] Fix the issue when use RTK on Nvidia Kepler Architecture based GPU. In-Reply-To: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> References: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> Message-ID: Dear Peng Liu, Thanks a lot, I have pushed your change right now. Don't hesitate to suggest changes in those flags, I don't think that so many people are familiar with them... Simon On Mon, Jan 20, 2014 at 10:06 AM, ?? wrote: > Hello, > > > > I find an issue when I try to use RTK on a Nvidia Kepler based GPU. > > The CUDA initializing always fails. > > And I can see an exception about _cudaMutexOperation when any CUDA > function is called in debug mode. > > > > Exception at 0x7fefd5f940d, code: 0xe06d7363: C++ exception, flags=0x1 > (execution cannot be continued) (first chance) in > cudart64_50_35!_cudaMutexOperation > > > > > > Following the guide in > > http://docs.nvidia.com/cuda/kepler-compatibility-guide/index.html > > > > This issue can be fixed by applying the patch on RTK code: > > > > > > =========================================================================== > > > > diff --git a/cmake/FindCUDA_wrap.cmake b/cmake/FindCUDA_wrap.cmake > > index e13a7c3..b40c6da 100644 > > --- a/cmake/FindCUDA_wrap.cmake > > +++ b/cmake/FindCUDA_wrap.cmake > > @@ -59,9 +59,19 @@ set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > ) > > > > if(CUDA_VERSION_MAJOR GREATER "2") > > - set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > - -gencode arch=compute_20,code=sm_20 > > - ) > > + IF(${CUDA_VERSION} LESS 5.0) > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_20,code=compute_20 > > + ) > > + ELSE() > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_30,code=sm_30 > > + -gencode arch=compute_35,code=sm_35 > > + -gencode arch=compute_35,code=compute_35 > > + ) > > + ENDIF() > > endif() > > > > if(CUDA_FOUND) > > > > > ============================================================================ > > > > Regards, > > > > Peng Liu > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 08:26:18 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 14:26:18 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? Message-ID: Hi, First thanks for the hard work on this nice toolkit. I am working on FDK reconstruction. I noticed that the InPlaneRotation seems not to be handled in some situations, such as in the DisplacedDetectorImageFilter, which is explicitly stated in the document. Furthermore, when I went through the FDKConeBeamReconstructionFilter, there seems to be no correction for the in-plane rotation to the projection images before they are send to the FFTRampImageFilter. Thus the filtering seems to be performed along the rows of the projection image but not the true horizontal direction of the projection. Did I miss anything around here? In which steps and to which extent the in-plane rotation has been taken into account? Best regards, Chao TUDelft, NL -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 09:10:10 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 15:10:10 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi, Yes, this is correct. In plane rotations are accounted for during backprojection but not in the FFT ramp filter which is done along lines. It should be modifiable if you want to. The weighting in the projection image should not sensitive to in plane rotation since it uses the distance to the center. How large are your rotations? Simon On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > Hi, > > First thanks for the hard work on this nice toolkit. > > I am working on FDK reconstruction. > I noticed that the InPlaneRotation seems not to be handled in some > situations, such as in the DisplacedDetectorImageFilter, which is > explicitly stated in the document. > Furthermore, when I went through the FDKConeBeamReconstructionFilter, > there seems to be no correction for the in-plane rotation to the projection > images before they are send to the FFTRampImageFilter. Thus the filtering > seems to be performed along the rows of the projection image but not the > true horizontal direction of the projection. > Did I miss anything around here? In which steps and to which extent the > in-plane rotation has been taken into account? > > Best regards, > Chao > > TUDelft, NL > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 10:32:57 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 16:32:57 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi Simon, Thanks for the confirmation. The rotation in my projections are less than 0.2 degrees, so the ramp filter along image line or along true horizontal direction may leads to almost identical reconstructions. I got into this subject because I was working with a displaced detector and found dark and bright regions along the axis of rotation at two side of the mid plane when the IPR is set to non-zero. After reading the document I realized that this would be due to that the IPR is not accounted when the weighting [G Wang] is performed, then later it is accounted during the FDK, so that Wang's weight function applied to opposite projections does not sum to 1. Before I make any changes to the DisplacedDetectorImageFilter I would like to see how you dealt with IPR in FDK, and suddenly I found IPR is not accounted for either in the ramp filter which is not 'mathematically correct' (but may be sufficient and efficient in practice). So now I am thinking how to solve the problem. The most straightforward way could be that I perform a pre-correction for IPR in all my displaced-detector projections, and send them to rtkfdk with an IPR=0 geometry, since this can make the behaviour of both DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less workload in coding, of course). Or modify the DisplacedDetectorImageFilter to account for IPR while leave the FFTRampImageFilter as it is. Do you have any other comments and suggestions? Thank you. Best regards, Chao 2014-02-14 15:10 GMT+01:00 Simon Rit : > Hi, > Yes, this is correct. In plane rotations are accounted for during > backprojection but not in the FFT ramp filter which is done along lines. It > should be modifiable if you want to. The weighting in the projection image > should not sensitive to in plane rotation since it uses the distance to the > center. > How large are your rotations? > Simon > > > > On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > >> Hi, >> >> First thanks for the hard work on this nice toolkit. >> >> I am working on FDK reconstruction. >> I noticed that the InPlaneRotation seems not to be handled in some >> situations, such as in the DisplacedDetectorImageFilter, which is >> explicitly stated in the document. >> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >> there seems to be no correction for the in-plane rotation to the projection >> images before they are send to the FFTRampImageFilter. Thus the filtering >> seems to be performed along the rows of the projection image but not the >> true horizontal direction of the projection. >> Did I miss anything around here? In which steps and to which extent the >> in-plane rotation has been taken into account? >> >> Best regards, >> Chao >> >> TUDelft, NL >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 10:56:56 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 16:56:56 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: The simplest is indeed to resample to a non-rotated detector. One reason I did not go into the in plane rotation stuff is that I wanted to keep the ramp filter independent of the geometry. But this could be changed if you find it useful, e.g., by adding a filtering direction. The best would be to avoid a resampling and to account for the rotation in each step. If you want to go in this direction, since it is a rather unusual geometry, I would suggest to check that you obtain relevant results for each step. There are command line tools that split rtkfdk in the 3 steps: rtkfdktwodweights, rtkrampfilter and rtkbackprojections. Let me know if I can help. If you develop something, your contribution will be welcomed! Simon On Fri, Feb 14, 2014 at 4:32 PM, Chao Wu wrote: > Hi Simon, > > Thanks for the confirmation. > The rotation in my projections are less than 0.2 degrees, so the ramp > filter along image line or along true horizontal direction may leads to > almost identical reconstructions. > > I got into this subject because I was working with a displaced detector > and found dark and bright regions along the axis of rotation at two side of > the mid plane when the IPR is set to non-zero. > After reading the document I realized that this would be due to that the > IPR is not accounted when the weighting [G Wang] is performed, then later > it is accounted during the FDK, so that Wang's weight function applied to > opposite projections does not sum to 1. Before I make any changes to the > DisplacedDetectorImageFilter I would like to see how you dealt with IPR in > FDK, and suddenly I found IPR is not accounted for either in the ramp > filter which is not 'mathematically correct' (but may be sufficient and > efficient in practice). > > So now I am thinking how to solve the problem. > The most straightforward way could be that I perform a pre-correction for > IPR in all my displaced-detector projections, and send them to rtkfdk with > an IPR=0 geometry, since this can make the behaviour of both > DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less > workload in coding, of course). > Or modify the DisplacedDetectorImageFilter to account for IPR while leave > the FFTRampImageFilter as it is. > Do you have any other comments and suggestions? Thank you. > > Best regards, > Chao > > > > 2014-02-14 15:10 GMT+01:00 Simon Rit : > > Hi, >> Yes, this is correct. In plane rotations are accounted for during >> backprojection but not in the FFT ramp filter which is done along lines. It >> should be modifiable if you want to. The weighting in the projection image >> should not sensitive to in plane rotation since it uses the distance to the >> center. >> How large are your rotations? >> Simon >> >> >> >> On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: >> >>> Hi, >>> >>> First thanks for the hard work on this nice toolkit. >>> >>> I am working on FDK reconstruction. >>> I noticed that the InPlaneRotation seems not to be handled in some >>> situations, such as in the DisplacedDetectorImageFilter, which is >>> explicitly stated in the document. >>> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >>> there seems to be no correction for the in-plane rotation to the projection >>> images before they are send to the FFTRampImageFilter. Thus the filtering >>> seems to be performed along the rows of the projection image but not the >>> true horizontal direction of the projection. >>> Did I miss anything around here? In which steps and to which extent the >>> in-plane rotation has been taken into account? >>> >>> Best regards, >>> Chao >>> >>> TUDelft, NL >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.champion.13 at ucl.ac.uk Wed Feb 19 12:35:59 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Wed, 19 Feb 2014 17:35:59 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading Message-ID: <5304EB7F.4080601@ucl.ac.uk> Hello, First of all, many thanks to the RTK community for this useful toolkit! While experimenting with different versions of the code (I'm a relatively new user), I've encountered large differences in rtkfdk (CPU) reconstruction speed between code versions (a newer version being substantially slower than an older version). To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the required -g, -p, -r and -o flags, but no other flags). Using git-bisect, I narrowed it down to a particular commit. The parent commit runs quite quickly, but the child commit shows nearly 4x reconstruction time, and less-uniform CPU utilization (it looks like a series of spikes). (See below) Looking at the diffs, it seems that in addition to adding the HannY functionality (which should be disabled by default?), there were some changes in this commit related to threading (in code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is misleading and the substantial difference consists in changing the FFT Ramp Kernel. I'm currently reading the source to try to understand those changes, but I thought I would post in case someone is able to point me in the right direction. Although these differences are unexpected to me, I doubt that they are unexpected to more experienced users...! Apologies if I've left out any critical information (or if I've provided too much!). Many thanks in advance, Ben ****** Parent Commit ****** commit 9df6108ae0293f86b455a2dcd4b35801e4815718 Author: Julien Jomier Date: Fri Nov 30 09:30:59 2012 +0100 ENH: Minimum CMake version is 2.8.3 ***Partial output*** Reconstructing and writing... It took 44.3992 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.67915 s Ramp filter: 26.3847 s Backprojection: 13.0447 s ***Screenshot of CPU usage attached: 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** ****** Child Commit ****** commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 Author: Simon Rit Date: Wed Dec 5 16:22:47 2012 +0100 First version of Hann windowing in the second direction (perpendicular to the ramp) ***Partial output*** Reconstructing and writing... It took 126.911 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.47678 s Ramp filter: 108.254 s Backprojection: 13.2973 s ***Screenshot of CPU usage attached: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** -------------- next part -------------- A non-text attachment was scrubbed... Name: 9df6108ae0293f86b455a2dcd4b35801e4815718.png Type: image/png Size: 80382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png Type: image/png Size: 75196 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 20 01:57:02 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 20 Feb 2014 07:57:02 +0100 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: <5304EB7F.4080601@ucl.ac.uk> References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: Hi, Thank you Ben for the amazing report. I can spot a few things that could have gone wrong there but it seems to me that your reconstruction is slow both before and after the commit... Two potential reasons: - you have not activated FFTW in ITK. You should definitely do that, the FFT of ITK is (very) slow and probably not multithreaded. You must turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent version of ITK4, I had some issues with the first versions, see http://www.itk.org/pipermail/insight-users/2013-April/047562.html - you are using a huge dataset. If you did not use FFTW, could you try again with FFTW and tell us if you still observe a drop in performances? If you had FFTW, can you provide the sie of the dataset you used? Thanks, Simon On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion wrote: > Hello, > > First of all, many thanks to the RTK community for this useful toolkit! > > While experimenting with different versions of the code (I'm a relatively > new user), I've encountered large differences in rtkfdk (CPU) reconstruction > speed between code versions (a newer version being substantially slower than > an older version). > > To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the > required -g, -p, -r and -o flags, but no other flags). > > Using git-bisect, I narrowed it down to a particular commit. The parent > commit runs quite quickly, but the child commit shows nearly 4x > reconstruction time, and less-uniform CPU utilization (it looks like a > series of spikes). > > (See below) > > Looking at the diffs, it seems that in addition to adding the HannY > functionality (which should be disabled by default?), there were some > changes in this commit related to threading (in > code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is > misleading and the substantial difference consists in changing the FFT Ramp > Kernel. > > I'm currently reading the source to try to understand those changes, but I > thought I would post in case someone is able to point me in the right > direction. Although these differences are unexpected to me, I doubt that > they are unexpected to more experienced users...! > > Apologies if I've left out any critical information (or if I've provided too > much!). > > Many thanks in advance, > Ben > > ****** Parent Commit ****** > commit 9df6108ae0293f86b455a2dcd4b35801e4815718 > Author: Julien Jomier > Date: Fri Nov 30 09:30:59 2012 +0100 > > ENH: Minimum CMake version is 2.8.3 > > ***Partial output*** > > Reconstructing and writing... It took 44.3992 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.67915 s > Ramp filter: 26.3847 s > Backprojection: 13.0447 s > > ***Screenshot of CPU usage attached: > 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** > > ****** Child Commit ****** > commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 > Author: Simon Rit > Date: Wed Dec 5 16:22:47 2012 +0100 > > First version of Hann windowing in the second direction (perpendicular > to the ramp) > > ***Partial output*** > Reconstructing and writing... It took 126.911 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.47678 s > Ramp filter: 108.254 s > Backprojection: 13.2973 s > > ***Screenshot of CPU usage attached: > e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From benjamin.champion.13 at ucl.ac.uk Thu Feb 20 06:20:35 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Thu, 20 Feb 2014 11:20:35 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: <5305E503.3000506@ucl.ac.uk> Hi Simon, Really appreciate your prompt response! Indeed, I was not using FFTW. After rebuilding ITK with FFTW, I get faster reconstructions, and the time increase between the two commits reduces to a little over 2x (See below). My dataset consists of 344 projections (about 172.0 MB) Does this sound about right? The CPU utilization still looks a bit like a series of spikes for the latter commit (but different than before). Reconstructing and writing... It took 36.0746 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.59479 s Ramp filter: 19.3106 s Backprojection: 13.8042 s ***versus*** Reconstructing and writing... It took 83.4121 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.62535 s Ramp filter: 66.5537 s Backprojection: 13.8829 s Thanks again, Ben On 20/02/14 06:57, Simon Rit wrote: > Hi, > Thank you Ben for the amazing report. I can spot a few things that > could have gone wrong there but it seems to me that your > reconstruction is slow both before and after the commit... Two > potential reasons: > - you have not activated FFTW in ITK. You should definitely do that, > the FFT of ITK is (very) slow and probably not multithreaded. You must > turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent > version of ITK4, I had some issues with the first versions, see > http://www.itk.org/pipermail/insight-users/2013-April/047562.html > - you are using a huge dataset. > If you did not use FFTW, could you try again with FFTW and tell us if > you still observe a drop in performances? If you had FFTW, can you > provide the sie of the dataset you used? > Thanks, > Simon > > On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion > wrote: >> Hello, >> >> First of all, many thanks to the RTK community for this useful toolkit! >> >> While experimenting with different versions of the code (I'm a relatively >> new user), I've encountered large differences in rtkfdk (CPU) reconstruction >> speed between code versions (a newer version being substantially slower than >> an older version). >> >> To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the >> required -g, -p, -r and -o flags, but no other flags). >> >> Using git-bisect, I narrowed it down to a particular commit. The parent >> commit runs quite quickly, but the child commit shows nearly 4x >> reconstruction time, and less-uniform CPU utilization (it looks like a >> series of spikes). >> >> (See below) >> >> Looking at the diffs, it seems that in addition to adding the HannY >> functionality (which should be disabled by default?), there were some >> changes in this commit related to threading (in >> code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is >> misleading and the substantial difference consists in changing the FFT Ramp >> Kernel. >> >> I'm currently reading the source to try to understand those changes, but I >> thought I would post in case someone is able to point me in the right >> direction. Although these differences are unexpected to me, I doubt that >> they are unexpected to more experienced users...! >> >> Apologies if I've left out any critical information (or if I've provided too >> much!). >> >> Many thanks in advance, >> Ben >> >> ****** Parent Commit ****** >> commit 9df6108ae0293f86b455a2dcd4b35801e4815718 >> Author: Julien Jomier >> Date: Fri Nov 30 09:30:59 2012 +0100 >> >> ENH: Minimum CMake version is 2.8.3 >> >> ***Partial output*** >> >> Reconstructing and writing... It took 44.3992 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.67915 s >> Ramp filter: 26.3847 s >> Backprojection: 13.0447 s >> >> ***Screenshot of CPU usage attached: >> 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** >> >> ****** Child Commit ****** >> commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 >> Author: Simon Rit >> Date: Wed Dec 5 16:22:47 2012 +0100 >> >> First version of Hann windowing in the second direction (perpendicular >> to the ramp) >> >> ***Partial output*** >> Reconstructing and writing... It took 126.911 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.47678 s >> Ramp filter: 108.254 s >> Backprojection: 13.2973 s >> >> ***Screenshot of CPU usage attached: >> e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> From simon.rit at creatis.insa-lyon.fr Wed Feb 5 10:30:13 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 16:30:13 +0100 Subject: [Rtk-users] Ending ITK 3.20 compatibility Message-ID: Dear all, The RTK consortium has decided today to give up the ITK3.20 compatibility. It has been hard to maintain it lately (you may have noticed it on the dashboard) and we do not see any advantage of keeping it. Would you have any concern with this decision, please contact us quickly because it will be effective soon. Regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Feb 5 11:42:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 17:42:38 +0100 Subject: [Rtk-users] Fix the issue when use RTK on Nvidia Kepler Architecture based GPU. In-Reply-To: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> References: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> Message-ID: Dear Peng Liu, Thanks a lot, I have pushed your change right now. Don't hesitate to suggest changes in those flags, I don't think that so many people are familiar with them... Simon On Mon, Jan 20, 2014 at 10:06 AM, ?? wrote: > Hello, > > > > I find an issue when I try to use RTK on a Nvidia Kepler based GPU. > > The CUDA initializing always fails. > > And I can see an exception about _cudaMutexOperation when any CUDA > function is called in debug mode. > > > > Exception at 0x7fefd5f940d, code: 0xe06d7363: C++ exception, flags=0x1 > (execution cannot be continued) (first chance) in > cudart64_50_35!_cudaMutexOperation > > > > > > Following the guide in > > http://docs.nvidia.com/cuda/kepler-compatibility-guide/index.html > > > > This issue can be fixed by applying the patch on RTK code: > > > > > > =========================================================================== > > > > diff --git a/cmake/FindCUDA_wrap.cmake b/cmake/FindCUDA_wrap.cmake > > index e13a7c3..b40c6da 100644 > > --- a/cmake/FindCUDA_wrap.cmake > > +++ b/cmake/FindCUDA_wrap.cmake > > @@ -59,9 +59,19 @@ set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > ) > > > > if(CUDA_VERSION_MAJOR GREATER "2") > > - set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > - -gencode arch=compute_20,code=sm_20 > > - ) > > + IF(${CUDA_VERSION} LESS 5.0) > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_20,code=compute_20 > > + ) > > + ELSE() > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_30,code=sm_30 > > + -gencode arch=compute_35,code=sm_35 > > + -gencode arch=compute_35,code=compute_35 > > + ) > > + ENDIF() > > endif() > > > > if(CUDA_FOUND) > > > > > ============================================================================ > > > > Regards, > > > > Peng Liu > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 08:26:18 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 14:26:18 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? Message-ID: Hi, First thanks for the hard work on this nice toolkit. I am working on FDK reconstruction. I noticed that the InPlaneRotation seems not to be handled in some situations, such as in the DisplacedDetectorImageFilter, which is explicitly stated in the document. Furthermore, when I went through the FDKConeBeamReconstructionFilter, there seems to be no correction for the in-plane rotation to the projection images before they are send to the FFTRampImageFilter. Thus the filtering seems to be performed along the rows of the projection image but not the true horizontal direction of the projection. Did I miss anything around here? In which steps and to which extent the in-plane rotation has been taken into account? Best regards, Chao TUDelft, NL -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 09:10:10 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 15:10:10 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi, Yes, this is correct. In plane rotations are accounted for during backprojection but not in the FFT ramp filter which is done along lines. It should be modifiable if you want to. The weighting in the projection image should not sensitive to in plane rotation since it uses the distance to the center. How large are your rotations? Simon On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > Hi, > > First thanks for the hard work on this nice toolkit. > > I am working on FDK reconstruction. > I noticed that the InPlaneRotation seems not to be handled in some > situations, such as in the DisplacedDetectorImageFilter, which is > explicitly stated in the document. > Furthermore, when I went through the FDKConeBeamReconstructionFilter, > there seems to be no correction for the in-plane rotation to the projection > images before they are send to the FFTRampImageFilter. Thus the filtering > seems to be performed along the rows of the projection image but not the > true horizontal direction of the projection. > Did I miss anything around here? In which steps and to which extent the > in-plane rotation has been taken into account? > > Best regards, > Chao > > TUDelft, NL > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 10:32:57 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 16:32:57 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi Simon, Thanks for the confirmation. The rotation in my projections are less than 0.2 degrees, so the ramp filter along image line or along true horizontal direction may leads to almost identical reconstructions. I got into this subject because I was working with a displaced detector and found dark and bright regions along the axis of rotation at two side of the mid plane when the IPR is set to non-zero. After reading the document I realized that this would be due to that the IPR is not accounted when the weighting [G Wang] is performed, then later it is accounted during the FDK, so that Wang's weight function applied to opposite projections does not sum to 1. Before I make any changes to the DisplacedDetectorImageFilter I would like to see how you dealt with IPR in FDK, and suddenly I found IPR is not accounted for either in the ramp filter which is not 'mathematically correct' (but may be sufficient and efficient in practice). So now I am thinking how to solve the problem. The most straightforward way could be that I perform a pre-correction for IPR in all my displaced-detector projections, and send them to rtkfdk with an IPR=0 geometry, since this can make the behaviour of both DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less workload in coding, of course). Or modify the DisplacedDetectorImageFilter to account for IPR while leave the FFTRampImageFilter as it is. Do you have any other comments and suggestions? Thank you. Best regards, Chao 2014-02-14 15:10 GMT+01:00 Simon Rit : > Hi, > Yes, this is correct. In plane rotations are accounted for during > backprojection but not in the FFT ramp filter which is done along lines. It > should be modifiable if you want to. The weighting in the projection image > should not sensitive to in plane rotation since it uses the distance to the > center. > How large are your rotations? > Simon > > > > On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > >> Hi, >> >> First thanks for the hard work on this nice toolkit. >> >> I am working on FDK reconstruction. >> I noticed that the InPlaneRotation seems not to be handled in some >> situations, such as in the DisplacedDetectorImageFilter, which is >> explicitly stated in the document. >> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >> there seems to be no correction for the in-plane rotation to the projection >> images before they are send to the FFTRampImageFilter. Thus the filtering >> seems to be performed along the rows of the projection image but not the >> true horizontal direction of the projection. >> Did I miss anything around here? In which steps and to which extent the >> in-plane rotation has been taken into account? >> >> Best regards, >> Chao >> >> TUDelft, NL >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 10:56:56 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 16:56:56 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: The simplest is indeed to resample to a non-rotated detector. One reason I did not go into the in plane rotation stuff is that I wanted to keep the ramp filter independent of the geometry. But this could be changed if you find it useful, e.g., by adding a filtering direction. The best would be to avoid a resampling and to account for the rotation in each step. If you want to go in this direction, since it is a rather unusual geometry, I would suggest to check that you obtain relevant results for each step. There are command line tools that split rtkfdk in the 3 steps: rtkfdktwodweights, rtkrampfilter and rtkbackprojections. Let me know if I can help. If you develop something, your contribution will be welcomed! Simon On Fri, Feb 14, 2014 at 4:32 PM, Chao Wu wrote: > Hi Simon, > > Thanks for the confirmation. > The rotation in my projections are less than 0.2 degrees, so the ramp > filter along image line or along true horizontal direction may leads to > almost identical reconstructions. > > I got into this subject because I was working with a displaced detector > and found dark and bright regions along the axis of rotation at two side of > the mid plane when the IPR is set to non-zero. > After reading the document I realized that this would be due to that the > IPR is not accounted when the weighting [G Wang] is performed, then later > it is accounted during the FDK, so that Wang's weight function applied to > opposite projections does not sum to 1. Before I make any changes to the > DisplacedDetectorImageFilter I would like to see how you dealt with IPR in > FDK, and suddenly I found IPR is not accounted for either in the ramp > filter which is not 'mathematically correct' (but may be sufficient and > efficient in practice). > > So now I am thinking how to solve the problem. > The most straightforward way could be that I perform a pre-correction for > IPR in all my displaced-detector projections, and send them to rtkfdk with > an IPR=0 geometry, since this can make the behaviour of both > DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less > workload in coding, of course). > Or modify the DisplacedDetectorImageFilter to account for IPR while leave > the FFTRampImageFilter as it is. > Do you have any other comments and suggestions? Thank you. > > Best regards, > Chao > > > > 2014-02-14 15:10 GMT+01:00 Simon Rit : > > Hi, >> Yes, this is correct. In plane rotations are accounted for during >> backprojection but not in the FFT ramp filter which is done along lines. It >> should be modifiable if you want to. The weighting in the projection image >> should not sensitive to in plane rotation since it uses the distance to the >> center. >> How large are your rotations? >> Simon >> >> >> >> On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: >> >>> Hi, >>> >>> First thanks for the hard work on this nice toolkit. >>> >>> I am working on FDK reconstruction. >>> I noticed that the InPlaneRotation seems not to be handled in some >>> situations, such as in the DisplacedDetectorImageFilter, which is >>> explicitly stated in the document. >>> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >>> there seems to be no correction for the in-plane rotation to the projection >>> images before they are send to the FFTRampImageFilter. Thus the filtering >>> seems to be performed along the rows of the projection image but not the >>> true horizontal direction of the projection. >>> Did I miss anything around here? In which steps and to which extent the >>> in-plane rotation has been taken into account? >>> >>> Best regards, >>> Chao >>> >>> TUDelft, NL >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.champion.13 at ucl.ac.uk Wed Feb 19 12:35:59 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Wed, 19 Feb 2014 17:35:59 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading Message-ID: <5304EB7F.4080601@ucl.ac.uk> Hello, First of all, many thanks to the RTK community for this useful toolkit! While experimenting with different versions of the code (I'm a relatively new user), I've encountered large differences in rtkfdk (CPU) reconstruction speed between code versions (a newer version being substantially slower than an older version). To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the required -g, -p, -r and -o flags, but no other flags). Using git-bisect, I narrowed it down to a particular commit. The parent commit runs quite quickly, but the child commit shows nearly 4x reconstruction time, and less-uniform CPU utilization (it looks like a series of spikes). (See below) Looking at the diffs, it seems that in addition to adding the HannY functionality (which should be disabled by default?), there were some changes in this commit related to threading (in code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is misleading and the substantial difference consists in changing the FFT Ramp Kernel. I'm currently reading the source to try to understand those changes, but I thought I would post in case someone is able to point me in the right direction. Although these differences are unexpected to me, I doubt that they are unexpected to more experienced users...! Apologies if I've left out any critical information (or if I've provided too much!). Many thanks in advance, Ben ****** Parent Commit ****** commit 9df6108ae0293f86b455a2dcd4b35801e4815718 Author: Julien Jomier Date: Fri Nov 30 09:30:59 2012 +0100 ENH: Minimum CMake version is 2.8.3 ***Partial output*** Reconstructing and writing... It took 44.3992 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.67915 s Ramp filter: 26.3847 s Backprojection: 13.0447 s ***Screenshot of CPU usage attached: 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** ****** Child Commit ****** commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 Author: Simon Rit Date: Wed Dec 5 16:22:47 2012 +0100 First version of Hann windowing in the second direction (perpendicular to the ramp) ***Partial output*** Reconstructing and writing... It took 126.911 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.47678 s Ramp filter: 108.254 s Backprojection: 13.2973 s ***Screenshot of CPU usage attached: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** -------------- next part -------------- A non-text attachment was scrubbed... Name: 9df6108ae0293f86b455a2dcd4b35801e4815718.png Type: image/png Size: 80382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png Type: image/png Size: 75196 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 20 01:57:02 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 20 Feb 2014 07:57:02 +0100 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: <5304EB7F.4080601@ucl.ac.uk> References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: Hi, Thank you Ben for the amazing report. I can spot a few things that could have gone wrong there but it seems to me that your reconstruction is slow both before and after the commit... Two potential reasons: - you have not activated FFTW in ITK. You should definitely do that, the FFT of ITK is (very) slow and probably not multithreaded. You must turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent version of ITK4, I had some issues with the first versions, see http://www.itk.org/pipermail/insight-users/2013-April/047562.html - you are using a huge dataset. If you did not use FFTW, could you try again with FFTW and tell us if you still observe a drop in performances? If you had FFTW, can you provide the sie of the dataset you used? Thanks, Simon On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion wrote: > Hello, > > First of all, many thanks to the RTK community for this useful toolkit! > > While experimenting with different versions of the code (I'm a relatively > new user), I've encountered large differences in rtkfdk (CPU) reconstruction > speed between code versions (a newer version being substantially slower than > an older version). > > To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the > required -g, -p, -r and -o flags, but no other flags). > > Using git-bisect, I narrowed it down to a particular commit. The parent > commit runs quite quickly, but the child commit shows nearly 4x > reconstruction time, and less-uniform CPU utilization (it looks like a > series of spikes). > > (See below) > > Looking at the diffs, it seems that in addition to adding the HannY > functionality (which should be disabled by default?), there were some > changes in this commit related to threading (in > code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is > misleading and the substantial difference consists in changing the FFT Ramp > Kernel. > > I'm currently reading the source to try to understand those changes, but I > thought I would post in case someone is able to point me in the right > direction. Although these differences are unexpected to me, I doubt that > they are unexpected to more experienced users...! > > Apologies if I've left out any critical information (or if I've provided too > much!). > > Many thanks in advance, > Ben > > ****** Parent Commit ****** > commit 9df6108ae0293f86b455a2dcd4b35801e4815718 > Author: Julien Jomier > Date: Fri Nov 30 09:30:59 2012 +0100 > > ENH: Minimum CMake version is 2.8.3 > > ***Partial output*** > > Reconstructing and writing... It took 44.3992 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.67915 s > Ramp filter: 26.3847 s > Backprojection: 13.0447 s > > ***Screenshot of CPU usage attached: > 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** > > ****** Child Commit ****** > commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 > Author: Simon Rit > Date: Wed Dec 5 16:22:47 2012 +0100 > > First version of Hann windowing in the second direction (perpendicular > to the ramp) > > ***Partial output*** > Reconstructing and writing... It took 126.911 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.47678 s > Ramp filter: 108.254 s > Backprojection: 13.2973 s > > ***Screenshot of CPU usage attached: > e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From benjamin.champion.13 at ucl.ac.uk Thu Feb 20 06:20:35 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Thu, 20 Feb 2014 11:20:35 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: <5305E503.3000506@ucl.ac.uk> Hi Simon, Really appreciate your prompt response! Indeed, I was not using FFTW. After rebuilding ITK with FFTW, I get faster reconstructions, and the time increase between the two commits reduces to a little over 2x (See below). My dataset consists of 344 projections (about 172.0 MB) Does this sound about right? The CPU utilization still looks a bit like a series of spikes for the latter commit (but different than before). Reconstructing and writing... It took 36.0746 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.59479 s Ramp filter: 19.3106 s Backprojection: 13.8042 s ***versus*** Reconstructing and writing... It took 83.4121 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.62535 s Ramp filter: 66.5537 s Backprojection: 13.8829 s Thanks again, Ben On 20/02/14 06:57, Simon Rit wrote: > Hi, > Thank you Ben for the amazing report. I can spot a few things that > could have gone wrong there but it seems to me that your > reconstruction is slow both before and after the commit... Two > potential reasons: > - you have not activated FFTW in ITK. You should definitely do that, > the FFT of ITK is (very) slow and probably not multithreaded. You must > turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent > version of ITK4, I had some issues with the first versions, see > http://www.itk.org/pipermail/insight-users/2013-April/047562.html > - you are using a huge dataset. > If you did not use FFTW, could you try again with FFTW and tell us if > you still observe a drop in performances? If you had FFTW, can you > provide the sie of the dataset you used? > Thanks, > Simon > > On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion > wrote: >> Hello, >> >> First of all, many thanks to the RTK community for this useful toolkit! >> >> While experimenting with different versions of the code (I'm a relatively >> new user), I've encountered large differences in rtkfdk (CPU) reconstruction >> speed between code versions (a newer version being substantially slower than >> an older version). >> >> To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the >> required -g, -p, -r and -o flags, but no other flags). >> >> Using git-bisect, I narrowed it down to a particular commit. The parent >> commit runs quite quickly, but the child commit shows nearly 4x >> reconstruction time, and less-uniform CPU utilization (it looks like a >> series of spikes). >> >> (See below) >> >> Looking at the diffs, it seems that in addition to adding the HannY >> functionality (which should be disabled by default?), there were some >> changes in this commit related to threading (in >> code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is >> misleading and the substantial difference consists in changing the FFT Ramp >> Kernel. >> >> I'm currently reading the source to try to understand those changes, but I >> thought I would post in case someone is able to point me in the right >> direction. Although these differences are unexpected to me, I doubt that >> they are unexpected to more experienced users...! >> >> Apologies if I've left out any critical information (or if I've provided too >> much!). >> >> Many thanks in advance, >> Ben >> >> ****** Parent Commit ****** >> commit 9df6108ae0293f86b455a2dcd4b35801e4815718 >> Author: Julien Jomier >> Date: Fri Nov 30 09:30:59 2012 +0100 >> >> ENH: Minimum CMake version is 2.8.3 >> >> ***Partial output*** >> >> Reconstructing and writing... It took 44.3992 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.67915 s >> Ramp filter: 26.3847 s >> Backprojection: 13.0447 s >> >> ***Screenshot of CPU usage attached: >> 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** >> >> ****** Child Commit ****** >> commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 >> Author: Simon Rit >> Date: Wed Dec 5 16:22:47 2012 +0100 >> >> First version of Hann windowing in the second direction (perpendicular >> to the ramp) >> >> ***Partial output*** >> Reconstructing and writing... It took 126.911 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.47678 s >> Ramp filter: 108.254 s >> Backprojection: 13.2973 s >> >> ***Screenshot of CPU usage attached: >> e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> From simon.rit at creatis.insa-lyon.fr Wed Feb 5 10:30:13 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 16:30:13 +0100 Subject: [Rtk-users] Ending ITK 3.20 compatibility Message-ID: Dear all, The RTK consortium has decided today to give up the ITK3.20 compatibility. It has been hard to maintain it lately (you may have noticed it on the dashboard) and we do not see any advantage of keeping it. Would you have any concern with this decision, please contact us quickly because it will be effective soon. Regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Feb 5 11:42:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 17:42:38 +0100 Subject: [Rtk-users] Fix the issue when use RTK on Nvidia Kepler Architecture based GPU. In-Reply-To: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> References: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> Message-ID: Dear Peng Liu, Thanks a lot, I have pushed your change right now. Don't hesitate to suggest changes in those flags, I don't think that so many people are familiar with them... Simon On Mon, Jan 20, 2014 at 10:06 AM, ?? wrote: > Hello, > > > > I find an issue when I try to use RTK on a Nvidia Kepler based GPU. > > The CUDA initializing always fails. > > And I can see an exception about _cudaMutexOperation when any CUDA > function is called in debug mode. > > > > Exception at 0x7fefd5f940d, code: 0xe06d7363: C++ exception, flags=0x1 > (execution cannot be continued) (first chance) in > cudart64_50_35!_cudaMutexOperation > > > > > > Following the guide in > > http://docs.nvidia.com/cuda/kepler-compatibility-guide/index.html > > > > This issue can be fixed by applying the patch on RTK code: > > > > > > =========================================================================== > > > > diff --git a/cmake/FindCUDA_wrap.cmake b/cmake/FindCUDA_wrap.cmake > > index e13a7c3..b40c6da 100644 > > --- a/cmake/FindCUDA_wrap.cmake > > +++ b/cmake/FindCUDA_wrap.cmake > > @@ -59,9 +59,19 @@ set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > ) > > > > if(CUDA_VERSION_MAJOR GREATER "2") > > - set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > - -gencode arch=compute_20,code=sm_20 > > - ) > > + IF(${CUDA_VERSION} LESS 5.0) > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_20,code=compute_20 > > + ) > > + ELSE() > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_30,code=sm_30 > > + -gencode arch=compute_35,code=sm_35 > > + -gencode arch=compute_35,code=compute_35 > > + ) > > + ENDIF() > > endif() > > > > if(CUDA_FOUND) > > > > > ============================================================================ > > > > Regards, > > > > Peng Liu > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 08:26:18 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 14:26:18 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? Message-ID: Hi, First thanks for the hard work on this nice toolkit. I am working on FDK reconstruction. I noticed that the InPlaneRotation seems not to be handled in some situations, such as in the DisplacedDetectorImageFilter, which is explicitly stated in the document. Furthermore, when I went through the FDKConeBeamReconstructionFilter, there seems to be no correction for the in-plane rotation to the projection images before they are send to the FFTRampImageFilter. Thus the filtering seems to be performed along the rows of the projection image but not the true horizontal direction of the projection. Did I miss anything around here? In which steps and to which extent the in-plane rotation has been taken into account? Best regards, Chao TUDelft, NL -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 09:10:10 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 15:10:10 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi, Yes, this is correct. In plane rotations are accounted for during backprojection but not in the FFT ramp filter which is done along lines. It should be modifiable if you want to. The weighting in the projection image should not sensitive to in plane rotation since it uses the distance to the center. How large are your rotations? Simon On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > Hi, > > First thanks for the hard work on this nice toolkit. > > I am working on FDK reconstruction. > I noticed that the InPlaneRotation seems not to be handled in some > situations, such as in the DisplacedDetectorImageFilter, which is > explicitly stated in the document. > Furthermore, when I went through the FDKConeBeamReconstructionFilter, > there seems to be no correction for the in-plane rotation to the projection > images before they are send to the FFTRampImageFilter. Thus the filtering > seems to be performed along the rows of the projection image but not the > true horizontal direction of the projection. > Did I miss anything around here? In which steps and to which extent the > in-plane rotation has been taken into account? > > Best regards, > Chao > > TUDelft, NL > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 10:32:57 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 16:32:57 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi Simon, Thanks for the confirmation. The rotation in my projections are less than 0.2 degrees, so the ramp filter along image line or along true horizontal direction may leads to almost identical reconstructions. I got into this subject because I was working with a displaced detector and found dark and bright regions along the axis of rotation at two side of the mid plane when the IPR is set to non-zero. After reading the document I realized that this would be due to that the IPR is not accounted when the weighting [G Wang] is performed, then later it is accounted during the FDK, so that Wang's weight function applied to opposite projections does not sum to 1. Before I make any changes to the DisplacedDetectorImageFilter I would like to see how you dealt with IPR in FDK, and suddenly I found IPR is not accounted for either in the ramp filter which is not 'mathematically correct' (but may be sufficient and efficient in practice). So now I am thinking how to solve the problem. The most straightforward way could be that I perform a pre-correction for IPR in all my displaced-detector projections, and send them to rtkfdk with an IPR=0 geometry, since this can make the behaviour of both DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less workload in coding, of course). Or modify the DisplacedDetectorImageFilter to account for IPR while leave the FFTRampImageFilter as it is. Do you have any other comments and suggestions? Thank you. Best regards, Chao 2014-02-14 15:10 GMT+01:00 Simon Rit : > Hi, > Yes, this is correct. In plane rotations are accounted for during > backprojection but not in the FFT ramp filter which is done along lines. It > should be modifiable if you want to. The weighting in the projection image > should not sensitive to in plane rotation since it uses the distance to the > center. > How large are your rotations? > Simon > > > > On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > >> Hi, >> >> First thanks for the hard work on this nice toolkit. >> >> I am working on FDK reconstruction. >> I noticed that the InPlaneRotation seems not to be handled in some >> situations, such as in the DisplacedDetectorImageFilter, which is >> explicitly stated in the document. >> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >> there seems to be no correction for the in-plane rotation to the projection >> images before they are send to the FFTRampImageFilter. Thus the filtering >> seems to be performed along the rows of the projection image but not the >> true horizontal direction of the projection. >> Did I miss anything around here? In which steps and to which extent the >> in-plane rotation has been taken into account? >> >> Best regards, >> Chao >> >> TUDelft, NL >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 10:56:56 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 16:56:56 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: The simplest is indeed to resample to a non-rotated detector. One reason I did not go into the in plane rotation stuff is that I wanted to keep the ramp filter independent of the geometry. But this could be changed if you find it useful, e.g., by adding a filtering direction. The best would be to avoid a resampling and to account for the rotation in each step. If you want to go in this direction, since it is a rather unusual geometry, I would suggest to check that you obtain relevant results for each step. There are command line tools that split rtkfdk in the 3 steps: rtkfdktwodweights, rtkrampfilter and rtkbackprojections. Let me know if I can help. If you develop something, your contribution will be welcomed! Simon On Fri, Feb 14, 2014 at 4:32 PM, Chao Wu wrote: > Hi Simon, > > Thanks for the confirmation. > The rotation in my projections are less than 0.2 degrees, so the ramp > filter along image line or along true horizontal direction may leads to > almost identical reconstructions. > > I got into this subject because I was working with a displaced detector > and found dark and bright regions along the axis of rotation at two side of > the mid plane when the IPR is set to non-zero. > After reading the document I realized that this would be due to that the > IPR is not accounted when the weighting [G Wang] is performed, then later > it is accounted during the FDK, so that Wang's weight function applied to > opposite projections does not sum to 1. Before I make any changes to the > DisplacedDetectorImageFilter I would like to see how you dealt with IPR in > FDK, and suddenly I found IPR is not accounted for either in the ramp > filter which is not 'mathematically correct' (but may be sufficient and > efficient in practice). > > So now I am thinking how to solve the problem. > The most straightforward way could be that I perform a pre-correction for > IPR in all my displaced-detector projections, and send them to rtkfdk with > an IPR=0 geometry, since this can make the behaviour of both > DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less > workload in coding, of course). > Or modify the DisplacedDetectorImageFilter to account for IPR while leave > the FFTRampImageFilter as it is. > Do you have any other comments and suggestions? Thank you. > > Best regards, > Chao > > > > 2014-02-14 15:10 GMT+01:00 Simon Rit : > > Hi, >> Yes, this is correct. In plane rotations are accounted for during >> backprojection but not in the FFT ramp filter which is done along lines. It >> should be modifiable if you want to. The weighting in the projection image >> should not sensitive to in plane rotation since it uses the distance to the >> center. >> How large are your rotations? >> Simon >> >> >> >> On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: >> >>> Hi, >>> >>> First thanks for the hard work on this nice toolkit. >>> >>> I am working on FDK reconstruction. >>> I noticed that the InPlaneRotation seems not to be handled in some >>> situations, such as in the DisplacedDetectorImageFilter, which is >>> explicitly stated in the document. >>> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >>> there seems to be no correction for the in-plane rotation to the projection >>> images before they are send to the FFTRampImageFilter. Thus the filtering >>> seems to be performed along the rows of the projection image but not the >>> true horizontal direction of the projection. >>> Did I miss anything around here? In which steps and to which extent the >>> in-plane rotation has been taken into account? >>> >>> Best regards, >>> Chao >>> >>> TUDelft, NL >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.champion.13 at ucl.ac.uk Wed Feb 19 12:35:59 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Wed, 19 Feb 2014 17:35:59 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading Message-ID: <5304EB7F.4080601@ucl.ac.uk> Hello, First of all, many thanks to the RTK community for this useful toolkit! While experimenting with different versions of the code (I'm a relatively new user), I've encountered large differences in rtkfdk (CPU) reconstruction speed between code versions (a newer version being substantially slower than an older version). To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the required -g, -p, -r and -o flags, but no other flags). Using git-bisect, I narrowed it down to a particular commit. The parent commit runs quite quickly, but the child commit shows nearly 4x reconstruction time, and less-uniform CPU utilization (it looks like a series of spikes). (See below) Looking at the diffs, it seems that in addition to adding the HannY functionality (which should be disabled by default?), there were some changes in this commit related to threading (in code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is misleading and the substantial difference consists in changing the FFT Ramp Kernel. I'm currently reading the source to try to understand those changes, but I thought I would post in case someone is able to point me in the right direction. Although these differences are unexpected to me, I doubt that they are unexpected to more experienced users...! Apologies if I've left out any critical information (or if I've provided too much!). Many thanks in advance, Ben ****** Parent Commit ****** commit 9df6108ae0293f86b455a2dcd4b35801e4815718 Author: Julien Jomier Date: Fri Nov 30 09:30:59 2012 +0100 ENH: Minimum CMake version is 2.8.3 ***Partial output*** Reconstructing and writing... It took 44.3992 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.67915 s Ramp filter: 26.3847 s Backprojection: 13.0447 s ***Screenshot of CPU usage attached: 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** ****** Child Commit ****** commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 Author: Simon Rit Date: Wed Dec 5 16:22:47 2012 +0100 First version of Hann windowing in the second direction (perpendicular to the ramp) ***Partial output*** Reconstructing and writing... It took 126.911 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.47678 s Ramp filter: 108.254 s Backprojection: 13.2973 s ***Screenshot of CPU usage attached: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** -------------- next part -------------- A non-text attachment was scrubbed... Name: 9df6108ae0293f86b455a2dcd4b35801e4815718.png Type: image/png Size: 80382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png Type: image/png Size: 75196 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 20 01:57:02 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 20 Feb 2014 07:57:02 +0100 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: <5304EB7F.4080601@ucl.ac.uk> References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: Hi, Thank you Ben for the amazing report. I can spot a few things that could have gone wrong there but it seems to me that your reconstruction is slow both before and after the commit... Two potential reasons: - you have not activated FFTW in ITK. You should definitely do that, the FFT of ITK is (very) slow and probably not multithreaded. You must turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent version of ITK4, I had some issues with the first versions, see http://www.itk.org/pipermail/insight-users/2013-April/047562.html - you are using a huge dataset. If you did not use FFTW, could you try again with FFTW and tell us if you still observe a drop in performances? If you had FFTW, can you provide the sie of the dataset you used? Thanks, Simon On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion wrote: > Hello, > > First of all, many thanks to the RTK community for this useful toolkit! > > While experimenting with different versions of the code (I'm a relatively > new user), I've encountered large differences in rtkfdk (CPU) reconstruction > speed between code versions (a newer version being substantially slower than > an older version). > > To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the > required -g, -p, -r and -o flags, but no other flags). > > Using git-bisect, I narrowed it down to a particular commit. The parent > commit runs quite quickly, but the child commit shows nearly 4x > reconstruction time, and less-uniform CPU utilization (it looks like a > series of spikes). > > (See below) > > Looking at the diffs, it seems that in addition to adding the HannY > functionality (which should be disabled by default?), there were some > changes in this commit related to threading (in > code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is > misleading and the substantial difference consists in changing the FFT Ramp > Kernel. > > I'm currently reading the source to try to understand those changes, but I > thought I would post in case someone is able to point me in the right > direction. Although these differences are unexpected to me, I doubt that > they are unexpected to more experienced users...! > > Apologies if I've left out any critical information (or if I've provided too > much!). > > Many thanks in advance, > Ben > > ****** Parent Commit ****** > commit 9df6108ae0293f86b455a2dcd4b35801e4815718 > Author: Julien Jomier > Date: Fri Nov 30 09:30:59 2012 +0100 > > ENH: Minimum CMake version is 2.8.3 > > ***Partial output*** > > Reconstructing and writing... It took 44.3992 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.67915 s > Ramp filter: 26.3847 s > Backprojection: 13.0447 s > > ***Screenshot of CPU usage attached: > 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** > > ****** Child Commit ****** > commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 > Author: Simon Rit > Date: Wed Dec 5 16:22:47 2012 +0100 > > First version of Hann windowing in the second direction (perpendicular > to the ramp) > > ***Partial output*** > Reconstructing and writing... It took 126.911 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.47678 s > Ramp filter: 108.254 s > Backprojection: 13.2973 s > > ***Screenshot of CPU usage attached: > e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From benjamin.champion.13 at ucl.ac.uk Thu Feb 20 06:20:35 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Thu, 20 Feb 2014 11:20:35 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: <5305E503.3000506@ucl.ac.uk> Hi Simon, Really appreciate your prompt response! Indeed, I was not using FFTW. After rebuilding ITK with FFTW, I get faster reconstructions, and the time increase between the two commits reduces to a little over 2x (See below). My dataset consists of 344 projections (about 172.0 MB) Does this sound about right? The CPU utilization still looks a bit like a series of spikes for the latter commit (but different than before). Reconstructing and writing... It took 36.0746 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.59479 s Ramp filter: 19.3106 s Backprojection: 13.8042 s ***versus*** Reconstructing and writing... It took 83.4121 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.62535 s Ramp filter: 66.5537 s Backprojection: 13.8829 s Thanks again, Ben On 20/02/14 06:57, Simon Rit wrote: > Hi, > Thank you Ben for the amazing report. I can spot a few things that > could have gone wrong there but it seems to me that your > reconstruction is slow both before and after the commit... Two > potential reasons: > - you have not activated FFTW in ITK. You should definitely do that, > the FFT of ITK is (very) slow and probably not multithreaded. You must > turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent > version of ITK4, I had some issues with the first versions, see > http://www.itk.org/pipermail/insight-users/2013-April/047562.html > - you are using a huge dataset. > If you did not use FFTW, could you try again with FFTW and tell us if > you still observe a drop in performances? If you had FFTW, can you > provide the sie of the dataset you used? > Thanks, > Simon > > On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion > wrote: >> Hello, >> >> First of all, many thanks to the RTK community for this useful toolkit! >> >> While experimenting with different versions of the code (I'm a relatively >> new user), I've encountered large differences in rtkfdk (CPU) reconstruction >> speed between code versions (a newer version being substantially slower than >> an older version). >> >> To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the >> required -g, -p, -r and -o flags, but no other flags). >> >> Using git-bisect, I narrowed it down to a particular commit. The parent >> commit runs quite quickly, but the child commit shows nearly 4x >> reconstruction time, and less-uniform CPU utilization (it looks like a >> series of spikes). >> >> (See below) >> >> Looking at the diffs, it seems that in addition to adding the HannY >> functionality (which should be disabled by default?), there were some >> changes in this commit related to threading (in >> code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is >> misleading and the substantial difference consists in changing the FFT Ramp >> Kernel. >> >> I'm currently reading the source to try to understand those changes, but I >> thought I would post in case someone is able to point me in the right >> direction. Although these differences are unexpected to me, I doubt that >> they are unexpected to more experienced users...! >> >> Apologies if I've left out any critical information (or if I've provided too >> much!). >> >> Many thanks in advance, >> Ben >> >> ****** Parent Commit ****** >> commit 9df6108ae0293f86b455a2dcd4b35801e4815718 >> Author: Julien Jomier >> Date: Fri Nov 30 09:30:59 2012 +0100 >> >> ENH: Minimum CMake version is 2.8.3 >> >> ***Partial output*** >> >> Reconstructing and writing... It took 44.3992 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.67915 s >> Ramp filter: 26.3847 s >> Backprojection: 13.0447 s >> >> ***Screenshot of CPU usage attached: >> 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** >> >> ****** Child Commit ****** >> commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 >> Author: Simon Rit >> Date: Wed Dec 5 16:22:47 2012 +0100 >> >> First version of Hann windowing in the second direction (perpendicular >> to the ramp) >> >> ***Partial output*** >> Reconstructing and writing... It took 126.911 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.47678 s >> Ramp filter: 108.254 s >> Backprojection: 13.2973 s >> >> ***Screenshot of CPU usage attached: >> e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> From simon.rit at creatis.insa-lyon.fr Wed Feb 5 10:30:13 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 16:30:13 +0100 Subject: [Rtk-users] Ending ITK 3.20 compatibility Message-ID: Dear all, The RTK consortium has decided today to give up the ITK3.20 compatibility. It has been hard to maintain it lately (you may have noticed it on the dashboard) and we do not see any advantage of keeping it. Would you have any concern with this decision, please contact us quickly because it will be effective soon. Regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Feb 5 11:42:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 17:42:38 +0100 Subject: [Rtk-users] Fix the issue when use RTK on Nvidia Kepler Architecture based GPU. In-Reply-To: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> References: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> Message-ID: Dear Peng Liu, Thanks a lot, I have pushed your change right now. Don't hesitate to suggest changes in those flags, I don't think that so many people are familiar with them... Simon On Mon, Jan 20, 2014 at 10:06 AM, ?? wrote: > Hello, > > > > I find an issue when I try to use RTK on a Nvidia Kepler based GPU. > > The CUDA initializing always fails. > > And I can see an exception about _cudaMutexOperation when any CUDA > function is called in debug mode. > > > > Exception at 0x7fefd5f940d, code: 0xe06d7363: C++ exception, flags=0x1 > (execution cannot be continued) (first chance) in > cudart64_50_35!_cudaMutexOperation > > > > > > Following the guide in > > http://docs.nvidia.com/cuda/kepler-compatibility-guide/index.html > > > > This issue can be fixed by applying the patch on RTK code: > > > > > > =========================================================================== > > > > diff --git a/cmake/FindCUDA_wrap.cmake b/cmake/FindCUDA_wrap.cmake > > index e13a7c3..b40c6da 100644 > > --- a/cmake/FindCUDA_wrap.cmake > > +++ b/cmake/FindCUDA_wrap.cmake > > @@ -59,9 +59,19 @@ set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > ) > > > > if(CUDA_VERSION_MAJOR GREATER "2") > > - set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > - -gencode arch=compute_20,code=sm_20 > > - ) > > + IF(${CUDA_VERSION} LESS 5.0) > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_20,code=compute_20 > > + ) > > + ELSE() > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_30,code=sm_30 > > + -gencode arch=compute_35,code=sm_35 > > + -gencode arch=compute_35,code=compute_35 > > + ) > > + ENDIF() > > endif() > > > > if(CUDA_FOUND) > > > > > ============================================================================ > > > > Regards, > > > > Peng Liu > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 08:26:18 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 14:26:18 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? Message-ID: Hi, First thanks for the hard work on this nice toolkit. I am working on FDK reconstruction. I noticed that the InPlaneRotation seems not to be handled in some situations, such as in the DisplacedDetectorImageFilter, which is explicitly stated in the document. Furthermore, when I went through the FDKConeBeamReconstructionFilter, there seems to be no correction for the in-plane rotation to the projection images before they are send to the FFTRampImageFilter. Thus the filtering seems to be performed along the rows of the projection image but not the true horizontal direction of the projection. Did I miss anything around here? In which steps and to which extent the in-plane rotation has been taken into account? Best regards, Chao TUDelft, NL -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 09:10:10 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 15:10:10 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi, Yes, this is correct. In plane rotations are accounted for during backprojection but not in the FFT ramp filter which is done along lines. It should be modifiable if you want to. The weighting in the projection image should not sensitive to in plane rotation since it uses the distance to the center. How large are your rotations? Simon On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > Hi, > > First thanks for the hard work on this nice toolkit. > > I am working on FDK reconstruction. > I noticed that the InPlaneRotation seems not to be handled in some > situations, such as in the DisplacedDetectorImageFilter, which is > explicitly stated in the document. > Furthermore, when I went through the FDKConeBeamReconstructionFilter, > there seems to be no correction for the in-plane rotation to the projection > images before they are send to the FFTRampImageFilter. Thus the filtering > seems to be performed along the rows of the projection image but not the > true horizontal direction of the projection. > Did I miss anything around here? In which steps and to which extent the > in-plane rotation has been taken into account? > > Best regards, > Chao > > TUDelft, NL > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 10:32:57 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 16:32:57 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi Simon, Thanks for the confirmation. The rotation in my projections are less than 0.2 degrees, so the ramp filter along image line or along true horizontal direction may leads to almost identical reconstructions. I got into this subject because I was working with a displaced detector and found dark and bright regions along the axis of rotation at two side of the mid plane when the IPR is set to non-zero. After reading the document I realized that this would be due to that the IPR is not accounted when the weighting [G Wang] is performed, then later it is accounted during the FDK, so that Wang's weight function applied to opposite projections does not sum to 1. Before I make any changes to the DisplacedDetectorImageFilter I would like to see how you dealt with IPR in FDK, and suddenly I found IPR is not accounted for either in the ramp filter which is not 'mathematically correct' (but may be sufficient and efficient in practice). So now I am thinking how to solve the problem. The most straightforward way could be that I perform a pre-correction for IPR in all my displaced-detector projections, and send them to rtkfdk with an IPR=0 geometry, since this can make the behaviour of both DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less workload in coding, of course). Or modify the DisplacedDetectorImageFilter to account for IPR while leave the FFTRampImageFilter as it is. Do you have any other comments and suggestions? Thank you. Best regards, Chao 2014-02-14 15:10 GMT+01:00 Simon Rit : > Hi, > Yes, this is correct. In plane rotations are accounted for during > backprojection but not in the FFT ramp filter which is done along lines. It > should be modifiable if you want to. The weighting in the projection image > should not sensitive to in plane rotation since it uses the distance to the > center. > How large are your rotations? > Simon > > > > On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > >> Hi, >> >> First thanks for the hard work on this nice toolkit. >> >> I am working on FDK reconstruction. >> I noticed that the InPlaneRotation seems not to be handled in some >> situations, such as in the DisplacedDetectorImageFilter, which is >> explicitly stated in the document. >> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >> there seems to be no correction for the in-plane rotation to the projection >> images before they are send to the FFTRampImageFilter. Thus the filtering >> seems to be performed along the rows of the projection image but not the >> true horizontal direction of the projection. >> Did I miss anything around here? In which steps and to which extent the >> in-plane rotation has been taken into account? >> >> Best regards, >> Chao >> >> TUDelft, NL >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 10:56:56 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 16:56:56 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: The simplest is indeed to resample to a non-rotated detector. One reason I did not go into the in plane rotation stuff is that I wanted to keep the ramp filter independent of the geometry. But this could be changed if you find it useful, e.g., by adding a filtering direction. The best would be to avoid a resampling and to account for the rotation in each step. If you want to go in this direction, since it is a rather unusual geometry, I would suggest to check that you obtain relevant results for each step. There are command line tools that split rtkfdk in the 3 steps: rtkfdktwodweights, rtkrampfilter and rtkbackprojections. Let me know if I can help. If you develop something, your contribution will be welcomed! Simon On Fri, Feb 14, 2014 at 4:32 PM, Chao Wu wrote: > Hi Simon, > > Thanks for the confirmation. > The rotation in my projections are less than 0.2 degrees, so the ramp > filter along image line or along true horizontal direction may leads to > almost identical reconstructions. > > I got into this subject because I was working with a displaced detector > and found dark and bright regions along the axis of rotation at two side of > the mid plane when the IPR is set to non-zero. > After reading the document I realized that this would be due to that the > IPR is not accounted when the weighting [G Wang] is performed, then later > it is accounted during the FDK, so that Wang's weight function applied to > opposite projections does not sum to 1. Before I make any changes to the > DisplacedDetectorImageFilter I would like to see how you dealt with IPR in > FDK, and suddenly I found IPR is not accounted for either in the ramp > filter which is not 'mathematically correct' (but may be sufficient and > efficient in practice). > > So now I am thinking how to solve the problem. > The most straightforward way could be that I perform a pre-correction for > IPR in all my displaced-detector projections, and send them to rtkfdk with > an IPR=0 geometry, since this can make the behaviour of both > DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less > workload in coding, of course). > Or modify the DisplacedDetectorImageFilter to account for IPR while leave > the FFTRampImageFilter as it is. > Do you have any other comments and suggestions? Thank you. > > Best regards, > Chao > > > > 2014-02-14 15:10 GMT+01:00 Simon Rit : > > Hi, >> Yes, this is correct. In plane rotations are accounted for during >> backprojection but not in the FFT ramp filter which is done along lines. It >> should be modifiable if you want to. The weighting in the projection image >> should not sensitive to in plane rotation since it uses the distance to the >> center. >> How large are your rotations? >> Simon >> >> >> >> On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: >> >>> Hi, >>> >>> First thanks for the hard work on this nice toolkit. >>> >>> I am working on FDK reconstruction. >>> I noticed that the InPlaneRotation seems not to be handled in some >>> situations, such as in the DisplacedDetectorImageFilter, which is >>> explicitly stated in the document. >>> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >>> there seems to be no correction for the in-plane rotation to the projection >>> images before they are send to the FFTRampImageFilter. Thus the filtering >>> seems to be performed along the rows of the projection image but not the >>> true horizontal direction of the projection. >>> Did I miss anything around here? In which steps and to which extent the >>> in-plane rotation has been taken into account? >>> >>> Best regards, >>> Chao >>> >>> TUDelft, NL >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.champion.13 at ucl.ac.uk Wed Feb 19 12:35:59 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Wed, 19 Feb 2014 17:35:59 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading Message-ID: <5304EB7F.4080601@ucl.ac.uk> Hello, First of all, many thanks to the RTK community for this useful toolkit! While experimenting with different versions of the code (I'm a relatively new user), I've encountered large differences in rtkfdk (CPU) reconstruction speed between code versions (a newer version being substantially slower than an older version). To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the required -g, -p, -r and -o flags, but no other flags). Using git-bisect, I narrowed it down to a particular commit. The parent commit runs quite quickly, but the child commit shows nearly 4x reconstruction time, and less-uniform CPU utilization (it looks like a series of spikes). (See below) Looking at the diffs, it seems that in addition to adding the HannY functionality (which should be disabled by default?), there were some changes in this commit related to threading (in code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is misleading and the substantial difference consists in changing the FFT Ramp Kernel. I'm currently reading the source to try to understand those changes, but I thought I would post in case someone is able to point me in the right direction. Although these differences are unexpected to me, I doubt that they are unexpected to more experienced users...! Apologies if I've left out any critical information (or if I've provided too much!). Many thanks in advance, Ben ****** Parent Commit ****** commit 9df6108ae0293f86b455a2dcd4b35801e4815718 Author: Julien Jomier Date: Fri Nov 30 09:30:59 2012 +0100 ENH: Minimum CMake version is 2.8.3 ***Partial output*** Reconstructing and writing... It took 44.3992 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.67915 s Ramp filter: 26.3847 s Backprojection: 13.0447 s ***Screenshot of CPU usage attached: 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** ****** Child Commit ****** commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 Author: Simon Rit Date: Wed Dec 5 16:22:47 2012 +0100 First version of Hann windowing in the second direction (perpendicular to the ramp) ***Partial output*** Reconstructing and writing... It took 126.911 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.47678 s Ramp filter: 108.254 s Backprojection: 13.2973 s ***Screenshot of CPU usage attached: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** -------------- next part -------------- A non-text attachment was scrubbed... Name: 9df6108ae0293f86b455a2dcd4b35801e4815718.png Type: image/png Size: 80382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png Type: image/png Size: 75196 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 20 01:57:02 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 20 Feb 2014 07:57:02 +0100 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: <5304EB7F.4080601@ucl.ac.uk> References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: Hi, Thank you Ben for the amazing report. I can spot a few things that could have gone wrong there but it seems to me that your reconstruction is slow both before and after the commit... Two potential reasons: - you have not activated FFTW in ITK. You should definitely do that, the FFT of ITK is (very) slow and probably not multithreaded. You must turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent version of ITK4, I had some issues with the first versions, see http://www.itk.org/pipermail/insight-users/2013-April/047562.html - you are using a huge dataset. If you did not use FFTW, could you try again with FFTW and tell us if you still observe a drop in performances? If you had FFTW, can you provide the sie of the dataset you used? Thanks, Simon On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion wrote: > Hello, > > First of all, many thanks to the RTK community for this useful toolkit! > > While experimenting with different versions of the code (I'm a relatively > new user), I've encountered large differences in rtkfdk (CPU) reconstruction > speed between code versions (a newer version being substantially slower than > an older version). > > To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the > required -g, -p, -r and -o flags, but no other flags). > > Using git-bisect, I narrowed it down to a particular commit. The parent > commit runs quite quickly, but the child commit shows nearly 4x > reconstruction time, and less-uniform CPU utilization (it looks like a > series of spikes). > > (See below) > > Looking at the diffs, it seems that in addition to adding the HannY > functionality (which should be disabled by default?), there were some > changes in this commit related to threading (in > code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is > misleading and the substantial difference consists in changing the FFT Ramp > Kernel. > > I'm currently reading the source to try to understand those changes, but I > thought I would post in case someone is able to point me in the right > direction. Although these differences are unexpected to me, I doubt that > they are unexpected to more experienced users...! > > Apologies if I've left out any critical information (or if I've provided too > much!). > > Many thanks in advance, > Ben > > ****** Parent Commit ****** > commit 9df6108ae0293f86b455a2dcd4b35801e4815718 > Author: Julien Jomier > Date: Fri Nov 30 09:30:59 2012 +0100 > > ENH: Minimum CMake version is 2.8.3 > > ***Partial output*** > > Reconstructing and writing... It took 44.3992 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.67915 s > Ramp filter: 26.3847 s > Backprojection: 13.0447 s > > ***Screenshot of CPU usage attached: > 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** > > ****** Child Commit ****** > commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 > Author: Simon Rit > Date: Wed Dec 5 16:22:47 2012 +0100 > > First version of Hann windowing in the second direction (perpendicular > to the ramp) > > ***Partial output*** > Reconstructing and writing... It took 126.911 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.47678 s > Ramp filter: 108.254 s > Backprojection: 13.2973 s > > ***Screenshot of CPU usage attached: > e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From benjamin.champion.13 at ucl.ac.uk Thu Feb 20 06:20:35 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Thu, 20 Feb 2014 11:20:35 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: <5305E503.3000506@ucl.ac.uk> Hi Simon, Really appreciate your prompt response! Indeed, I was not using FFTW. After rebuilding ITK with FFTW, I get faster reconstructions, and the time increase between the two commits reduces to a little over 2x (See below). My dataset consists of 344 projections (about 172.0 MB) Does this sound about right? The CPU utilization still looks a bit like a series of spikes for the latter commit (but different than before). Reconstructing and writing... It took 36.0746 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.59479 s Ramp filter: 19.3106 s Backprojection: 13.8042 s ***versus*** Reconstructing and writing... It took 83.4121 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.62535 s Ramp filter: 66.5537 s Backprojection: 13.8829 s Thanks again, Ben On 20/02/14 06:57, Simon Rit wrote: > Hi, > Thank you Ben for the amazing report. I can spot a few things that > could have gone wrong there but it seems to me that your > reconstruction is slow both before and after the commit... Two > potential reasons: > - you have not activated FFTW in ITK. You should definitely do that, > the FFT of ITK is (very) slow and probably not multithreaded. You must > turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent > version of ITK4, I had some issues with the first versions, see > http://www.itk.org/pipermail/insight-users/2013-April/047562.html > - you are using a huge dataset. > If you did not use FFTW, could you try again with FFTW and tell us if > you still observe a drop in performances? If you had FFTW, can you > provide the sie of the dataset you used? > Thanks, > Simon > > On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion > wrote: >> Hello, >> >> First of all, many thanks to the RTK community for this useful toolkit! >> >> While experimenting with different versions of the code (I'm a relatively >> new user), I've encountered large differences in rtkfdk (CPU) reconstruction >> speed between code versions (a newer version being substantially slower than >> an older version). >> >> To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the >> required -g, -p, -r and -o flags, but no other flags). >> >> Using git-bisect, I narrowed it down to a particular commit. The parent >> commit runs quite quickly, but the child commit shows nearly 4x >> reconstruction time, and less-uniform CPU utilization (it looks like a >> series of spikes). >> >> (See below) >> >> Looking at the diffs, it seems that in addition to adding the HannY >> functionality (which should be disabled by default?), there were some >> changes in this commit related to threading (in >> code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is >> misleading and the substantial difference consists in changing the FFT Ramp >> Kernel. >> >> I'm currently reading the source to try to understand those changes, but I >> thought I would post in case someone is able to point me in the right >> direction. Although these differences are unexpected to me, I doubt that >> they are unexpected to more experienced users...! >> >> Apologies if I've left out any critical information (or if I've provided too >> much!). >> >> Many thanks in advance, >> Ben >> >> ****** Parent Commit ****** >> commit 9df6108ae0293f86b455a2dcd4b35801e4815718 >> Author: Julien Jomier >> Date: Fri Nov 30 09:30:59 2012 +0100 >> >> ENH: Minimum CMake version is 2.8.3 >> >> ***Partial output*** >> >> Reconstructing and writing... It took 44.3992 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.67915 s >> Ramp filter: 26.3847 s >> Backprojection: 13.0447 s >> >> ***Screenshot of CPU usage attached: >> 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** >> >> ****** Child Commit ****** >> commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 >> Author: Simon Rit >> Date: Wed Dec 5 16:22:47 2012 +0100 >> >> First version of Hann windowing in the second direction (perpendicular >> to the ramp) >> >> ***Partial output*** >> Reconstructing and writing... It took 126.911 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.47678 s >> Ramp filter: 108.254 s >> Backprojection: 13.2973 s >> >> ***Screenshot of CPU usage attached: >> e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> From simon.rit at creatis.insa-lyon.fr Wed Feb 5 10:30:13 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 16:30:13 +0100 Subject: [Rtk-users] Ending ITK 3.20 compatibility Message-ID: Dear all, The RTK consortium has decided today to give up the ITK3.20 compatibility. It has been hard to maintain it lately (you may have noticed it on the dashboard) and we do not see any advantage of keeping it. Would you have any concern with this decision, please contact us quickly because it will be effective soon. Regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Feb 5 11:42:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 17:42:38 +0100 Subject: [Rtk-users] Fix the issue when use RTK on Nvidia Kepler Architecture based GPU. In-Reply-To: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> References: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> Message-ID: Dear Peng Liu, Thanks a lot, I have pushed your change right now. Don't hesitate to suggest changes in those flags, I don't think that so many people are familiar with them... Simon On Mon, Jan 20, 2014 at 10:06 AM, ?? wrote: > Hello, > > > > I find an issue when I try to use RTK on a Nvidia Kepler based GPU. > > The CUDA initializing always fails. > > And I can see an exception about _cudaMutexOperation when any CUDA > function is called in debug mode. > > > > Exception at 0x7fefd5f940d, code: 0xe06d7363: C++ exception, flags=0x1 > (execution cannot be continued) (first chance) in > cudart64_50_35!_cudaMutexOperation > > > > > > Following the guide in > > http://docs.nvidia.com/cuda/kepler-compatibility-guide/index.html > > > > This issue can be fixed by applying the patch on RTK code: > > > > > > =========================================================================== > > > > diff --git a/cmake/FindCUDA_wrap.cmake b/cmake/FindCUDA_wrap.cmake > > index e13a7c3..b40c6da 100644 > > --- a/cmake/FindCUDA_wrap.cmake > > +++ b/cmake/FindCUDA_wrap.cmake > > @@ -59,9 +59,19 @@ set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > ) > > > > if(CUDA_VERSION_MAJOR GREATER "2") > > - set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > - -gencode arch=compute_20,code=sm_20 > > - ) > > + IF(${CUDA_VERSION} LESS 5.0) > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_20,code=compute_20 > > + ) > > + ELSE() > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_30,code=sm_30 > > + -gencode arch=compute_35,code=sm_35 > > + -gencode arch=compute_35,code=compute_35 > > + ) > > + ENDIF() > > endif() > > > > if(CUDA_FOUND) > > > > > ============================================================================ > > > > Regards, > > > > Peng Liu > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 08:26:18 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 14:26:18 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? Message-ID: Hi, First thanks for the hard work on this nice toolkit. I am working on FDK reconstruction. I noticed that the InPlaneRotation seems not to be handled in some situations, such as in the DisplacedDetectorImageFilter, which is explicitly stated in the document. Furthermore, when I went through the FDKConeBeamReconstructionFilter, there seems to be no correction for the in-plane rotation to the projection images before they are send to the FFTRampImageFilter. Thus the filtering seems to be performed along the rows of the projection image but not the true horizontal direction of the projection. Did I miss anything around here? In which steps and to which extent the in-plane rotation has been taken into account? Best regards, Chao TUDelft, NL -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 09:10:10 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 15:10:10 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi, Yes, this is correct. In plane rotations are accounted for during backprojection but not in the FFT ramp filter which is done along lines. It should be modifiable if you want to. The weighting in the projection image should not sensitive to in plane rotation since it uses the distance to the center. How large are your rotations? Simon On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > Hi, > > First thanks for the hard work on this nice toolkit. > > I am working on FDK reconstruction. > I noticed that the InPlaneRotation seems not to be handled in some > situations, such as in the DisplacedDetectorImageFilter, which is > explicitly stated in the document. > Furthermore, when I went through the FDKConeBeamReconstructionFilter, > there seems to be no correction for the in-plane rotation to the projection > images before they are send to the FFTRampImageFilter. Thus the filtering > seems to be performed along the rows of the projection image but not the > true horizontal direction of the projection. > Did I miss anything around here? In which steps and to which extent the > in-plane rotation has been taken into account? > > Best regards, > Chao > > TUDelft, NL > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 10:32:57 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 16:32:57 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi Simon, Thanks for the confirmation. The rotation in my projections are less than 0.2 degrees, so the ramp filter along image line or along true horizontal direction may leads to almost identical reconstructions. I got into this subject because I was working with a displaced detector and found dark and bright regions along the axis of rotation at two side of the mid plane when the IPR is set to non-zero. After reading the document I realized that this would be due to that the IPR is not accounted when the weighting [G Wang] is performed, then later it is accounted during the FDK, so that Wang's weight function applied to opposite projections does not sum to 1. Before I make any changes to the DisplacedDetectorImageFilter I would like to see how you dealt with IPR in FDK, and suddenly I found IPR is not accounted for either in the ramp filter which is not 'mathematically correct' (but may be sufficient and efficient in practice). So now I am thinking how to solve the problem. The most straightforward way could be that I perform a pre-correction for IPR in all my displaced-detector projections, and send them to rtkfdk with an IPR=0 geometry, since this can make the behaviour of both DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less workload in coding, of course). Or modify the DisplacedDetectorImageFilter to account for IPR while leave the FFTRampImageFilter as it is. Do you have any other comments and suggestions? Thank you. Best regards, Chao 2014-02-14 15:10 GMT+01:00 Simon Rit : > Hi, > Yes, this is correct. In plane rotations are accounted for during > backprojection but not in the FFT ramp filter which is done along lines. It > should be modifiable if you want to. The weighting in the projection image > should not sensitive to in plane rotation since it uses the distance to the > center. > How large are your rotations? > Simon > > > > On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > >> Hi, >> >> First thanks for the hard work on this nice toolkit. >> >> I am working on FDK reconstruction. >> I noticed that the InPlaneRotation seems not to be handled in some >> situations, such as in the DisplacedDetectorImageFilter, which is >> explicitly stated in the document. >> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >> there seems to be no correction for the in-plane rotation to the projection >> images before they are send to the FFTRampImageFilter. Thus the filtering >> seems to be performed along the rows of the projection image but not the >> true horizontal direction of the projection. >> Did I miss anything around here? In which steps and to which extent the >> in-plane rotation has been taken into account? >> >> Best regards, >> Chao >> >> TUDelft, NL >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 10:56:56 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 16:56:56 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: The simplest is indeed to resample to a non-rotated detector. One reason I did not go into the in plane rotation stuff is that I wanted to keep the ramp filter independent of the geometry. But this could be changed if you find it useful, e.g., by adding a filtering direction. The best would be to avoid a resampling and to account for the rotation in each step. If you want to go in this direction, since it is a rather unusual geometry, I would suggest to check that you obtain relevant results for each step. There are command line tools that split rtkfdk in the 3 steps: rtkfdktwodweights, rtkrampfilter and rtkbackprojections. Let me know if I can help. If you develop something, your contribution will be welcomed! Simon On Fri, Feb 14, 2014 at 4:32 PM, Chao Wu wrote: > Hi Simon, > > Thanks for the confirmation. > The rotation in my projections are less than 0.2 degrees, so the ramp > filter along image line or along true horizontal direction may leads to > almost identical reconstructions. > > I got into this subject because I was working with a displaced detector > and found dark and bright regions along the axis of rotation at two side of > the mid plane when the IPR is set to non-zero. > After reading the document I realized that this would be due to that the > IPR is not accounted when the weighting [G Wang] is performed, then later > it is accounted during the FDK, so that Wang's weight function applied to > opposite projections does not sum to 1. Before I make any changes to the > DisplacedDetectorImageFilter I would like to see how you dealt with IPR in > FDK, and suddenly I found IPR is not accounted for either in the ramp > filter which is not 'mathematically correct' (but may be sufficient and > efficient in practice). > > So now I am thinking how to solve the problem. > The most straightforward way could be that I perform a pre-correction for > IPR in all my displaced-detector projections, and send them to rtkfdk with > an IPR=0 geometry, since this can make the behaviour of both > DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less > workload in coding, of course). > Or modify the DisplacedDetectorImageFilter to account for IPR while leave > the FFTRampImageFilter as it is. > Do you have any other comments and suggestions? Thank you. > > Best regards, > Chao > > > > 2014-02-14 15:10 GMT+01:00 Simon Rit : > > Hi, >> Yes, this is correct. In plane rotations are accounted for during >> backprojection but not in the FFT ramp filter which is done along lines. It >> should be modifiable if you want to. The weighting in the projection image >> should not sensitive to in plane rotation since it uses the distance to the >> center. >> How large are your rotations? >> Simon >> >> >> >> On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: >> >>> Hi, >>> >>> First thanks for the hard work on this nice toolkit. >>> >>> I am working on FDK reconstruction. >>> I noticed that the InPlaneRotation seems not to be handled in some >>> situations, such as in the DisplacedDetectorImageFilter, which is >>> explicitly stated in the document. >>> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >>> there seems to be no correction for the in-plane rotation to the projection >>> images before they are send to the FFTRampImageFilter. Thus the filtering >>> seems to be performed along the rows of the projection image but not the >>> true horizontal direction of the projection. >>> Did I miss anything around here? In which steps and to which extent the >>> in-plane rotation has been taken into account? >>> >>> Best regards, >>> Chao >>> >>> TUDelft, NL >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.champion.13 at ucl.ac.uk Wed Feb 19 12:35:59 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Wed, 19 Feb 2014 17:35:59 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading Message-ID: <5304EB7F.4080601@ucl.ac.uk> Hello, First of all, many thanks to the RTK community for this useful toolkit! While experimenting with different versions of the code (I'm a relatively new user), I've encountered large differences in rtkfdk (CPU) reconstruction speed between code versions (a newer version being substantially slower than an older version). To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the required -g, -p, -r and -o flags, but no other flags). Using git-bisect, I narrowed it down to a particular commit. The parent commit runs quite quickly, but the child commit shows nearly 4x reconstruction time, and less-uniform CPU utilization (it looks like a series of spikes). (See below) Looking at the diffs, it seems that in addition to adding the HannY functionality (which should be disabled by default?), there were some changes in this commit related to threading (in code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is misleading and the substantial difference consists in changing the FFT Ramp Kernel. I'm currently reading the source to try to understand those changes, but I thought I would post in case someone is able to point me in the right direction. Although these differences are unexpected to me, I doubt that they are unexpected to more experienced users...! Apologies if I've left out any critical information (or if I've provided too much!). Many thanks in advance, Ben ****** Parent Commit ****** commit 9df6108ae0293f86b455a2dcd4b35801e4815718 Author: Julien Jomier Date: Fri Nov 30 09:30:59 2012 +0100 ENH: Minimum CMake version is 2.8.3 ***Partial output*** Reconstructing and writing... It took 44.3992 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.67915 s Ramp filter: 26.3847 s Backprojection: 13.0447 s ***Screenshot of CPU usage attached: 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** ****** Child Commit ****** commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 Author: Simon Rit Date: Wed Dec 5 16:22:47 2012 +0100 First version of Hann windowing in the second direction (perpendicular to the ramp) ***Partial output*** Reconstructing and writing... It took 126.911 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.47678 s Ramp filter: 108.254 s Backprojection: 13.2973 s ***Screenshot of CPU usage attached: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** -------------- next part -------------- A non-text attachment was scrubbed... Name: 9df6108ae0293f86b455a2dcd4b35801e4815718.png Type: image/png Size: 80382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png Type: image/png Size: 75196 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 20 01:57:02 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 20 Feb 2014 07:57:02 +0100 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: <5304EB7F.4080601@ucl.ac.uk> References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: Hi, Thank you Ben for the amazing report. I can spot a few things that could have gone wrong there but it seems to me that your reconstruction is slow both before and after the commit... Two potential reasons: - you have not activated FFTW in ITK. You should definitely do that, the FFT of ITK is (very) slow and probably not multithreaded. You must turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent version of ITK4, I had some issues with the first versions, see http://www.itk.org/pipermail/insight-users/2013-April/047562.html - you are using a huge dataset. If you did not use FFTW, could you try again with FFTW and tell us if you still observe a drop in performances? If you had FFTW, can you provide the sie of the dataset you used? Thanks, Simon On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion wrote: > Hello, > > First of all, many thanks to the RTK community for this useful toolkit! > > While experimenting with different versions of the code (I'm a relatively > new user), I've encountered large differences in rtkfdk (CPU) reconstruction > speed between code versions (a newer version being substantially slower than > an older version). > > To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the > required -g, -p, -r and -o flags, but no other flags). > > Using git-bisect, I narrowed it down to a particular commit. The parent > commit runs quite quickly, but the child commit shows nearly 4x > reconstruction time, and less-uniform CPU utilization (it looks like a > series of spikes). > > (See below) > > Looking at the diffs, it seems that in addition to adding the HannY > functionality (which should be disabled by default?), there were some > changes in this commit related to threading (in > code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is > misleading and the substantial difference consists in changing the FFT Ramp > Kernel. > > I'm currently reading the source to try to understand those changes, but I > thought I would post in case someone is able to point me in the right > direction. Although these differences are unexpected to me, I doubt that > they are unexpected to more experienced users...! > > Apologies if I've left out any critical information (or if I've provided too > much!). > > Many thanks in advance, > Ben > > ****** Parent Commit ****** > commit 9df6108ae0293f86b455a2dcd4b35801e4815718 > Author: Julien Jomier > Date: Fri Nov 30 09:30:59 2012 +0100 > > ENH: Minimum CMake version is 2.8.3 > > ***Partial output*** > > Reconstructing and writing... It took 44.3992 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.67915 s > Ramp filter: 26.3847 s > Backprojection: 13.0447 s > > ***Screenshot of CPU usage attached: > 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** > > ****** Child Commit ****** > commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 > Author: Simon Rit > Date: Wed Dec 5 16:22:47 2012 +0100 > > First version of Hann windowing in the second direction (perpendicular > to the ramp) > > ***Partial output*** > Reconstructing and writing... It took 126.911 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.47678 s > Ramp filter: 108.254 s > Backprojection: 13.2973 s > > ***Screenshot of CPU usage attached: > e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From benjamin.champion.13 at ucl.ac.uk Thu Feb 20 06:20:35 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Thu, 20 Feb 2014 11:20:35 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: <5305E503.3000506@ucl.ac.uk> Hi Simon, Really appreciate your prompt response! Indeed, I was not using FFTW. After rebuilding ITK with FFTW, I get faster reconstructions, and the time increase between the two commits reduces to a little over 2x (See below). My dataset consists of 344 projections (about 172.0 MB) Does this sound about right? The CPU utilization still looks a bit like a series of spikes for the latter commit (but different than before). Reconstructing and writing... It took 36.0746 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.59479 s Ramp filter: 19.3106 s Backprojection: 13.8042 s ***versus*** Reconstructing and writing... It took 83.4121 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.62535 s Ramp filter: 66.5537 s Backprojection: 13.8829 s Thanks again, Ben On 20/02/14 06:57, Simon Rit wrote: > Hi, > Thank you Ben for the amazing report. I can spot a few things that > could have gone wrong there but it seems to me that your > reconstruction is slow both before and after the commit... Two > potential reasons: > - you have not activated FFTW in ITK. You should definitely do that, > the FFT of ITK is (very) slow and probably not multithreaded. You must > turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent > version of ITK4, I had some issues with the first versions, see > http://www.itk.org/pipermail/insight-users/2013-April/047562.html > - you are using a huge dataset. > If you did not use FFTW, could you try again with FFTW and tell us if > you still observe a drop in performances? If you had FFTW, can you > provide the sie of the dataset you used? > Thanks, > Simon > > On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion > wrote: >> Hello, >> >> First of all, many thanks to the RTK community for this useful toolkit! >> >> While experimenting with different versions of the code (I'm a relatively >> new user), I've encountered large differences in rtkfdk (CPU) reconstruction >> speed between code versions (a newer version being substantially slower than >> an older version). >> >> To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the >> required -g, -p, -r and -o flags, but no other flags). >> >> Using git-bisect, I narrowed it down to a particular commit. The parent >> commit runs quite quickly, but the child commit shows nearly 4x >> reconstruction time, and less-uniform CPU utilization (it looks like a >> series of spikes). >> >> (See below) >> >> Looking at the diffs, it seems that in addition to adding the HannY >> functionality (which should be disabled by default?), there were some >> changes in this commit related to threading (in >> code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is >> misleading and the substantial difference consists in changing the FFT Ramp >> Kernel. >> >> I'm currently reading the source to try to understand those changes, but I >> thought I would post in case someone is able to point me in the right >> direction. Although these differences are unexpected to me, I doubt that >> they are unexpected to more experienced users...! >> >> Apologies if I've left out any critical information (or if I've provided too >> much!). >> >> Many thanks in advance, >> Ben >> >> ****** Parent Commit ****** >> commit 9df6108ae0293f86b455a2dcd4b35801e4815718 >> Author: Julien Jomier >> Date: Fri Nov 30 09:30:59 2012 +0100 >> >> ENH: Minimum CMake version is 2.8.3 >> >> ***Partial output*** >> >> Reconstructing and writing... It took 44.3992 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.67915 s >> Ramp filter: 26.3847 s >> Backprojection: 13.0447 s >> >> ***Screenshot of CPU usage attached: >> 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** >> >> ****** Child Commit ****** >> commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 >> Author: Simon Rit >> Date: Wed Dec 5 16:22:47 2012 +0100 >> >> First version of Hann windowing in the second direction (perpendicular >> to the ramp) >> >> ***Partial output*** >> Reconstructing and writing... It took 126.911 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.47678 s >> Ramp filter: 108.254 s >> Backprojection: 13.2973 s >> >> ***Screenshot of CPU usage attached: >> e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> From simon.rit at creatis.insa-lyon.fr Wed Feb 5 10:30:13 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 16:30:13 +0100 Subject: [Rtk-users] Ending ITK 3.20 compatibility Message-ID: Dear all, The RTK consortium has decided today to give up the ITK3.20 compatibility. It has been hard to maintain it lately (you may have noticed it on the dashboard) and we do not see any advantage of keeping it. Would you have any concern with this decision, please contact us quickly because it will be effective soon. Regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Feb 5 11:42:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 17:42:38 +0100 Subject: [Rtk-users] Fix the issue when use RTK on Nvidia Kepler Architecture based GPU. In-Reply-To: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> References: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> Message-ID: Dear Peng Liu, Thanks a lot, I have pushed your change right now. Don't hesitate to suggest changes in those flags, I don't think that so many people are familiar with them... Simon On Mon, Jan 20, 2014 at 10:06 AM, ?? wrote: > Hello, > > > > I find an issue when I try to use RTK on a Nvidia Kepler based GPU. > > The CUDA initializing always fails. > > And I can see an exception about _cudaMutexOperation when any CUDA > function is called in debug mode. > > > > Exception at 0x7fefd5f940d, code: 0xe06d7363: C++ exception, flags=0x1 > (execution cannot be continued) (first chance) in > cudart64_50_35!_cudaMutexOperation > > > > > > Following the guide in > > http://docs.nvidia.com/cuda/kepler-compatibility-guide/index.html > > > > This issue can be fixed by applying the patch on RTK code: > > > > > > =========================================================================== > > > > diff --git a/cmake/FindCUDA_wrap.cmake b/cmake/FindCUDA_wrap.cmake > > index e13a7c3..b40c6da 100644 > > --- a/cmake/FindCUDA_wrap.cmake > > +++ b/cmake/FindCUDA_wrap.cmake > > @@ -59,9 +59,19 @@ set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > ) > > > > if(CUDA_VERSION_MAJOR GREATER "2") > > - set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > - -gencode arch=compute_20,code=sm_20 > > - ) > > + IF(${CUDA_VERSION} LESS 5.0) > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_20,code=compute_20 > > + ) > > + ELSE() > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_30,code=sm_30 > > + -gencode arch=compute_35,code=sm_35 > > + -gencode arch=compute_35,code=compute_35 > > + ) > > + ENDIF() > > endif() > > > > if(CUDA_FOUND) > > > > > ============================================================================ > > > > Regards, > > > > Peng Liu > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 08:26:18 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 14:26:18 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? Message-ID: Hi, First thanks for the hard work on this nice toolkit. I am working on FDK reconstruction. I noticed that the InPlaneRotation seems not to be handled in some situations, such as in the DisplacedDetectorImageFilter, which is explicitly stated in the document. Furthermore, when I went through the FDKConeBeamReconstructionFilter, there seems to be no correction for the in-plane rotation to the projection images before they are send to the FFTRampImageFilter. Thus the filtering seems to be performed along the rows of the projection image but not the true horizontal direction of the projection. Did I miss anything around here? In which steps and to which extent the in-plane rotation has been taken into account? Best regards, Chao TUDelft, NL -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 09:10:10 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 15:10:10 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi, Yes, this is correct. In plane rotations are accounted for during backprojection but not in the FFT ramp filter which is done along lines. It should be modifiable if you want to. The weighting in the projection image should not sensitive to in plane rotation since it uses the distance to the center. How large are your rotations? Simon On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > Hi, > > First thanks for the hard work on this nice toolkit. > > I am working on FDK reconstruction. > I noticed that the InPlaneRotation seems not to be handled in some > situations, such as in the DisplacedDetectorImageFilter, which is > explicitly stated in the document. > Furthermore, when I went through the FDKConeBeamReconstructionFilter, > there seems to be no correction for the in-plane rotation to the projection > images before they are send to the FFTRampImageFilter. Thus the filtering > seems to be performed along the rows of the projection image but not the > true horizontal direction of the projection. > Did I miss anything around here? In which steps and to which extent the > in-plane rotation has been taken into account? > > Best regards, > Chao > > TUDelft, NL > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 10:32:57 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 16:32:57 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi Simon, Thanks for the confirmation. The rotation in my projections are less than 0.2 degrees, so the ramp filter along image line or along true horizontal direction may leads to almost identical reconstructions. I got into this subject because I was working with a displaced detector and found dark and bright regions along the axis of rotation at two side of the mid plane when the IPR is set to non-zero. After reading the document I realized that this would be due to that the IPR is not accounted when the weighting [G Wang] is performed, then later it is accounted during the FDK, so that Wang's weight function applied to opposite projections does not sum to 1. Before I make any changes to the DisplacedDetectorImageFilter I would like to see how you dealt with IPR in FDK, and suddenly I found IPR is not accounted for either in the ramp filter which is not 'mathematically correct' (but may be sufficient and efficient in practice). So now I am thinking how to solve the problem. The most straightforward way could be that I perform a pre-correction for IPR in all my displaced-detector projections, and send them to rtkfdk with an IPR=0 geometry, since this can make the behaviour of both DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less workload in coding, of course). Or modify the DisplacedDetectorImageFilter to account for IPR while leave the FFTRampImageFilter as it is. Do you have any other comments and suggestions? Thank you. Best regards, Chao 2014-02-14 15:10 GMT+01:00 Simon Rit : > Hi, > Yes, this is correct. In plane rotations are accounted for during > backprojection but not in the FFT ramp filter which is done along lines. It > should be modifiable if you want to. The weighting in the projection image > should not sensitive to in plane rotation since it uses the distance to the > center. > How large are your rotations? > Simon > > > > On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > >> Hi, >> >> First thanks for the hard work on this nice toolkit. >> >> I am working on FDK reconstruction. >> I noticed that the InPlaneRotation seems not to be handled in some >> situations, such as in the DisplacedDetectorImageFilter, which is >> explicitly stated in the document. >> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >> there seems to be no correction for the in-plane rotation to the projection >> images before they are send to the FFTRampImageFilter. Thus the filtering >> seems to be performed along the rows of the projection image but not the >> true horizontal direction of the projection. >> Did I miss anything around here? In which steps and to which extent the >> in-plane rotation has been taken into account? >> >> Best regards, >> Chao >> >> TUDelft, NL >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 10:56:56 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 16:56:56 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: The simplest is indeed to resample to a non-rotated detector. One reason I did not go into the in plane rotation stuff is that I wanted to keep the ramp filter independent of the geometry. But this could be changed if you find it useful, e.g., by adding a filtering direction. The best would be to avoid a resampling and to account for the rotation in each step. If you want to go in this direction, since it is a rather unusual geometry, I would suggest to check that you obtain relevant results for each step. There are command line tools that split rtkfdk in the 3 steps: rtkfdktwodweights, rtkrampfilter and rtkbackprojections. Let me know if I can help. If you develop something, your contribution will be welcomed! Simon On Fri, Feb 14, 2014 at 4:32 PM, Chao Wu wrote: > Hi Simon, > > Thanks for the confirmation. > The rotation in my projections are less than 0.2 degrees, so the ramp > filter along image line or along true horizontal direction may leads to > almost identical reconstructions. > > I got into this subject because I was working with a displaced detector > and found dark and bright regions along the axis of rotation at two side of > the mid plane when the IPR is set to non-zero. > After reading the document I realized that this would be due to that the > IPR is not accounted when the weighting [G Wang] is performed, then later > it is accounted during the FDK, so that Wang's weight function applied to > opposite projections does not sum to 1. Before I make any changes to the > DisplacedDetectorImageFilter I would like to see how you dealt with IPR in > FDK, and suddenly I found IPR is not accounted for either in the ramp > filter which is not 'mathematically correct' (but may be sufficient and > efficient in practice). > > So now I am thinking how to solve the problem. > The most straightforward way could be that I perform a pre-correction for > IPR in all my displaced-detector projections, and send them to rtkfdk with > an IPR=0 geometry, since this can make the behaviour of both > DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less > workload in coding, of course). > Or modify the DisplacedDetectorImageFilter to account for IPR while leave > the FFTRampImageFilter as it is. > Do you have any other comments and suggestions? Thank you. > > Best regards, > Chao > > > > 2014-02-14 15:10 GMT+01:00 Simon Rit : > > Hi, >> Yes, this is correct. In plane rotations are accounted for during >> backprojection but not in the FFT ramp filter which is done along lines. It >> should be modifiable if you want to. The weighting in the projection image >> should not sensitive to in plane rotation since it uses the distance to the >> center. >> How large are your rotations? >> Simon >> >> >> >> On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: >> >>> Hi, >>> >>> First thanks for the hard work on this nice toolkit. >>> >>> I am working on FDK reconstruction. >>> I noticed that the InPlaneRotation seems not to be handled in some >>> situations, such as in the DisplacedDetectorImageFilter, which is >>> explicitly stated in the document. >>> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >>> there seems to be no correction for the in-plane rotation to the projection >>> images before they are send to the FFTRampImageFilter. Thus the filtering >>> seems to be performed along the rows of the projection image but not the >>> true horizontal direction of the projection. >>> Did I miss anything around here? In which steps and to which extent the >>> in-plane rotation has been taken into account? >>> >>> Best regards, >>> Chao >>> >>> TUDelft, NL >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.champion.13 at ucl.ac.uk Wed Feb 19 12:35:59 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Wed, 19 Feb 2014 17:35:59 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading Message-ID: <5304EB7F.4080601@ucl.ac.uk> Hello, First of all, many thanks to the RTK community for this useful toolkit! While experimenting with different versions of the code (I'm a relatively new user), I've encountered large differences in rtkfdk (CPU) reconstruction speed between code versions (a newer version being substantially slower than an older version). To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the required -g, -p, -r and -o flags, but no other flags). Using git-bisect, I narrowed it down to a particular commit. The parent commit runs quite quickly, but the child commit shows nearly 4x reconstruction time, and less-uniform CPU utilization (it looks like a series of spikes). (See below) Looking at the diffs, it seems that in addition to adding the HannY functionality (which should be disabled by default?), there were some changes in this commit related to threading (in code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is misleading and the substantial difference consists in changing the FFT Ramp Kernel. I'm currently reading the source to try to understand those changes, but I thought I would post in case someone is able to point me in the right direction. Although these differences are unexpected to me, I doubt that they are unexpected to more experienced users...! Apologies if I've left out any critical information (or if I've provided too much!). Many thanks in advance, Ben ****** Parent Commit ****** commit 9df6108ae0293f86b455a2dcd4b35801e4815718 Author: Julien Jomier Date: Fri Nov 30 09:30:59 2012 +0100 ENH: Minimum CMake version is 2.8.3 ***Partial output*** Reconstructing and writing... It took 44.3992 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.67915 s Ramp filter: 26.3847 s Backprojection: 13.0447 s ***Screenshot of CPU usage attached: 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** ****** Child Commit ****** commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 Author: Simon Rit Date: Wed Dec 5 16:22:47 2012 +0100 First version of Hann windowing in the second direction (perpendicular to the ramp) ***Partial output*** Reconstructing and writing... It took 126.911 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.47678 s Ramp filter: 108.254 s Backprojection: 13.2973 s ***Screenshot of CPU usage attached: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** -------------- next part -------------- A non-text attachment was scrubbed... Name: 9df6108ae0293f86b455a2dcd4b35801e4815718.png Type: image/png Size: 80382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png Type: image/png Size: 75196 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 20 01:57:02 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 20 Feb 2014 07:57:02 +0100 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: <5304EB7F.4080601@ucl.ac.uk> References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: Hi, Thank you Ben for the amazing report. I can spot a few things that could have gone wrong there but it seems to me that your reconstruction is slow both before and after the commit... Two potential reasons: - you have not activated FFTW in ITK. You should definitely do that, the FFT of ITK is (very) slow and probably not multithreaded. You must turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent version of ITK4, I had some issues with the first versions, see http://www.itk.org/pipermail/insight-users/2013-April/047562.html - you are using a huge dataset. If you did not use FFTW, could you try again with FFTW and tell us if you still observe a drop in performances? If you had FFTW, can you provide the sie of the dataset you used? Thanks, Simon On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion wrote: > Hello, > > First of all, many thanks to the RTK community for this useful toolkit! > > While experimenting with different versions of the code (I'm a relatively > new user), I've encountered large differences in rtkfdk (CPU) reconstruction > speed between code versions (a newer version being substantially slower than > an older version). > > To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the > required -g, -p, -r and -o flags, but no other flags). > > Using git-bisect, I narrowed it down to a particular commit. The parent > commit runs quite quickly, but the child commit shows nearly 4x > reconstruction time, and less-uniform CPU utilization (it looks like a > series of spikes). > > (See below) > > Looking at the diffs, it seems that in addition to adding the HannY > functionality (which should be disabled by default?), there were some > changes in this commit related to threading (in > code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is > misleading and the substantial difference consists in changing the FFT Ramp > Kernel. > > I'm currently reading the source to try to understand those changes, but I > thought I would post in case someone is able to point me in the right > direction. Although these differences are unexpected to me, I doubt that > they are unexpected to more experienced users...! > > Apologies if I've left out any critical information (or if I've provided too > much!). > > Many thanks in advance, > Ben > > ****** Parent Commit ****** > commit 9df6108ae0293f86b455a2dcd4b35801e4815718 > Author: Julien Jomier > Date: Fri Nov 30 09:30:59 2012 +0100 > > ENH: Minimum CMake version is 2.8.3 > > ***Partial output*** > > Reconstructing and writing... It took 44.3992 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.67915 s > Ramp filter: 26.3847 s > Backprojection: 13.0447 s > > ***Screenshot of CPU usage attached: > 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** > > ****** Child Commit ****** > commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 > Author: Simon Rit > Date: Wed Dec 5 16:22:47 2012 +0100 > > First version of Hann windowing in the second direction (perpendicular > to the ramp) > > ***Partial output*** > Reconstructing and writing... It took 126.911 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.47678 s > Ramp filter: 108.254 s > Backprojection: 13.2973 s > > ***Screenshot of CPU usage attached: > e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From benjamin.champion.13 at ucl.ac.uk Thu Feb 20 06:20:35 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Thu, 20 Feb 2014 11:20:35 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: <5305E503.3000506@ucl.ac.uk> Hi Simon, Really appreciate your prompt response! Indeed, I was not using FFTW. After rebuilding ITK with FFTW, I get faster reconstructions, and the time increase between the two commits reduces to a little over 2x (See below). My dataset consists of 344 projections (about 172.0 MB) Does this sound about right? The CPU utilization still looks a bit like a series of spikes for the latter commit (but different than before). Reconstructing and writing... It took 36.0746 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.59479 s Ramp filter: 19.3106 s Backprojection: 13.8042 s ***versus*** Reconstructing and writing... It took 83.4121 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.62535 s Ramp filter: 66.5537 s Backprojection: 13.8829 s Thanks again, Ben On 20/02/14 06:57, Simon Rit wrote: > Hi, > Thank you Ben for the amazing report. I can spot a few things that > could have gone wrong there but it seems to me that your > reconstruction is slow both before and after the commit... Two > potential reasons: > - you have not activated FFTW in ITK. You should definitely do that, > the FFT of ITK is (very) slow and probably not multithreaded. You must > turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent > version of ITK4, I had some issues with the first versions, see > http://www.itk.org/pipermail/insight-users/2013-April/047562.html > - you are using a huge dataset. > If you did not use FFTW, could you try again with FFTW and tell us if > you still observe a drop in performances? If you had FFTW, can you > provide the sie of the dataset you used? > Thanks, > Simon > > On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion > wrote: >> Hello, >> >> First of all, many thanks to the RTK community for this useful toolkit! >> >> While experimenting with different versions of the code (I'm a relatively >> new user), I've encountered large differences in rtkfdk (CPU) reconstruction >> speed between code versions (a newer version being substantially slower than >> an older version). >> >> To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the >> required -g, -p, -r and -o flags, but no other flags). >> >> Using git-bisect, I narrowed it down to a particular commit. The parent >> commit runs quite quickly, but the child commit shows nearly 4x >> reconstruction time, and less-uniform CPU utilization (it looks like a >> series of spikes). >> >> (See below) >> >> Looking at the diffs, it seems that in addition to adding the HannY >> functionality (which should be disabled by default?), there were some >> changes in this commit related to threading (in >> code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is >> misleading and the substantial difference consists in changing the FFT Ramp >> Kernel. >> >> I'm currently reading the source to try to understand those changes, but I >> thought I would post in case someone is able to point me in the right >> direction. Although these differences are unexpected to me, I doubt that >> they are unexpected to more experienced users...! >> >> Apologies if I've left out any critical information (or if I've provided too >> much!). >> >> Many thanks in advance, >> Ben >> >> ****** Parent Commit ****** >> commit 9df6108ae0293f86b455a2dcd4b35801e4815718 >> Author: Julien Jomier >> Date: Fri Nov 30 09:30:59 2012 +0100 >> >> ENH: Minimum CMake version is 2.8.3 >> >> ***Partial output*** >> >> Reconstructing and writing... It took 44.3992 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.67915 s >> Ramp filter: 26.3847 s >> Backprojection: 13.0447 s >> >> ***Screenshot of CPU usage attached: >> 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** >> >> ****** Child Commit ****** >> commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 >> Author: Simon Rit >> Date: Wed Dec 5 16:22:47 2012 +0100 >> >> First version of Hann windowing in the second direction (perpendicular >> to the ramp) >> >> ***Partial output*** >> Reconstructing and writing... It took 126.911 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.47678 s >> Ramp filter: 108.254 s >> Backprojection: 13.2973 s >> >> ***Screenshot of CPU usage attached: >> e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> From simon.rit at creatis.insa-lyon.fr Wed Feb 5 10:30:13 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 16:30:13 +0100 Subject: [Rtk-users] Ending ITK 3.20 compatibility Message-ID: Dear all, The RTK consortium has decided today to give up the ITK3.20 compatibility. It has been hard to maintain it lately (you may have noticed it on the dashboard) and we do not see any advantage of keeping it. Would you have any concern with this decision, please contact us quickly because it will be effective soon. Regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Feb 5 11:42:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 17:42:38 +0100 Subject: [Rtk-users] Fix the issue when use RTK on Nvidia Kepler Architecture based GPU. In-Reply-To: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> References: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> Message-ID: Dear Peng Liu, Thanks a lot, I have pushed your change right now. Don't hesitate to suggest changes in those flags, I don't think that so many people are familiar with them... Simon On Mon, Jan 20, 2014 at 10:06 AM, ?? wrote: > Hello, > > > > I find an issue when I try to use RTK on a Nvidia Kepler based GPU. > > The CUDA initializing always fails. > > And I can see an exception about _cudaMutexOperation when any CUDA > function is called in debug mode. > > > > Exception at 0x7fefd5f940d, code: 0xe06d7363: C++ exception, flags=0x1 > (execution cannot be continued) (first chance) in > cudart64_50_35!_cudaMutexOperation > > > > > > Following the guide in > > http://docs.nvidia.com/cuda/kepler-compatibility-guide/index.html > > > > This issue can be fixed by applying the patch on RTK code: > > > > > > =========================================================================== > > > > diff --git a/cmake/FindCUDA_wrap.cmake b/cmake/FindCUDA_wrap.cmake > > index e13a7c3..b40c6da 100644 > > --- a/cmake/FindCUDA_wrap.cmake > > +++ b/cmake/FindCUDA_wrap.cmake > > @@ -59,9 +59,19 @@ set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > ) > > > > if(CUDA_VERSION_MAJOR GREATER "2") > > - set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > - -gencode arch=compute_20,code=sm_20 > > - ) > > + IF(${CUDA_VERSION} LESS 5.0) > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_20,code=compute_20 > > + ) > > + ELSE() > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_30,code=sm_30 > > + -gencode arch=compute_35,code=sm_35 > > + -gencode arch=compute_35,code=compute_35 > > + ) > > + ENDIF() > > endif() > > > > if(CUDA_FOUND) > > > > > ============================================================================ > > > > Regards, > > > > Peng Liu > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 08:26:18 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 14:26:18 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? Message-ID: Hi, First thanks for the hard work on this nice toolkit. I am working on FDK reconstruction. I noticed that the InPlaneRotation seems not to be handled in some situations, such as in the DisplacedDetectorImageFilter, which is explicitly stated in the document. Furthermore, when I went through the FDKConeBeamReconstructionFilter, there seems to be no correction for the in-plane rotation to the projection images before they are send to the FFTRampImageFilter. Thus the filtering seems to be performed along the rows of the projection image but not the true horizontal direction of the projection. Did I miss anything around here? In which steps and to which extent the in-plane rotation has been taken into account? Best regards, Chao TUDelft, NL -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 09:10:10 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 15:10:10 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi, Yes, this is correct. In plane rotations are accounted for during backprojection but not in the FFT ramp filter which is done along lines. It should be modifiable if you want to. The weighting in the projection image should not sensitive to in plane rotation since it uses the distance to the center. How large are your rotations? Simon On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > Hi, > > First thanks for the hard work on this nice toolkit. > > I am working on FDK reconstruction. > I noticed that the InPlaneRotation seems not to be handled in some > situations, such as in the DisplacedDetectorImageFilter, which is > explicitly stated in the document. > Furthermore, when I went through the FDKConeBeamReconstructionFilter, > there seems to be no correction for the in-plane rotation to the projection > images before they are send to the FFTRampImageFilter. Thus the filtering > seems to be performed along the rows of the projection image but not the > true horizontal direction of the projection. > Did I miss anything around here? In which steps and to which extent the > in-plane rotation has been taken into account? > > Best regards, > Chao > > TUDelft, NL > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 10:32:57 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 16:32:57 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi Simon, Thanks for the confirmation. The rotation in my projections are less than 0.2 degrees, so the ramp filter along image line or along true horizontal direction may leads to almost identical reconstructions. I got into this subject because I was working with a displaced detector and found dark and bright regions along the axis of rotation at two side of the mid plane when the IPR is set to non-zero. After reading the document I realized that this would be due to that the IPR is not accounted when the weighting [G Wang] is performed, then later it is accounted during the FDK, so that Wang's weight function applied to opposite projections does not sum to 1. Before I make any changes to the DisplacedDetectorImageFilter I would like to see how you dealt with IPR in FDK, and suddenly I found IPR is not accounted for either in the ramp filter which is not 'mathematically correct' (but may be sufficient and efficient in practice). So now I am thinking how to solve the problem. The most straightforward way could be that I perform a pre-correction for IPR in all my displaced-detector projections, and send them to rtkfdk with an IPR=0 geometry, since this can make the behaviour of both DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less workload in coding, of course). Or modify the DisplacedDetectorImageFilter to account for IPR while leave the FFTRampImageFilter as it is. Do you have any other comments and suggestions? Thank you. Best regards, Chao 2014-02-14 15:10 GMT+01:00 Simon Rit : > Hi, > Yes, this is correct. In plane rotations are accounted for during > backprojection but not in the FFT ramp filter which is done along lines. It > should be modifiable if you want to. The weighting in the projection image > should not sensitive to in plane rotation since it uses the distance to the > center. > How large are your rotations? > Simon > > > > On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > >> Hi, >> >> First thanks for the hard work on this nice toolkit. >> >> I am working on FDK reconstruction. >> I noticed that the InPlaneRotation seems not to be handled in some >> situations, such as in the DisplacedDetectorImageFilter, which is >> explicitly stated in the document. >> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >> there seems to be no correction for the in-plane rotation to the projection >> images before they are send to the FFTRampImageFilter. Thus the filtering >> seems to be performed along the rows of the projection image but not the >> true horizontal direction of the projection. >> Did I miss anything around here? In which steps and to which extent the >> in-plane rotation has been taken into account? >> >> Best regards, >> Chao >> >> TUDelft, NL >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 10:56:56 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 16:56:56 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: The simplest is indeed to resample to a non-rotated detector. One reason I did not go into the in plane rotation stuff is that I wanted to keep the ramp filter independent of the geometry. But this could be changed if you find it useful, e.g., by adding a filtering direction. The best would be to avoid a resampling and to account for the rotation in each step. If you want to go in this direction, since it is a rather unusual geometry, I would suggest to check that you obtain relevant results for each step. There are command line tools that split rtkfdk in the 3 steps: rtkfdktwodweights, rtkrampfilter and rtkbackprojections. Let me know if I can help. If you develop something, your contribution will be welcomed! Simon On Fri, Feb 14, 2014 at 4:32 PM, Chao Wu wrote: > Hi Simon, > > Thanks for the confirmation. > The rotation in my projections are less than 0.2 degrees, so the ramp > filter along image line or along true horizontal direction may leads to > almost identical reconstructions. > > I got into this subject because I was working with a displaced detector > and found dark and bright regions along the axis of rotation at two side of > the mid plane when the IPR is set to non-zero. > After reading the document I realized that this would be due to that the > IPR is not accounted when the weighting [G Wang] is performed, then later > it is accounted during the FDK, so that Wang's weight function applied to > opposite projections does not sum to 1. Before I make any changes to the > DisplacedDetectorImageFilter I would like to see how you dealt with IPR in > FDK, and suddenly I found IPR is not accounted for either in the ramp > filter which is not 'mathematically correct' (but may be sufficient and > efficient in practice). > > So now I am thinking how to solve the problem. > The most straightforward way could be that I perform a pre-correction for > IPR in all my displaced-detector projections, and send them to rtkfdk with > an IPR=0 geometry, since this can make the behaviour of both > DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less > workload in coding, of course). > Or modify the DisplacedDetectorImageFilter to account for IPR while leave > the FFTRampImageFilter as it is. > Do you have any other comments and suggestions? Thank you. > > Best regards, > Chao > > > > 2014-02-14 15:10 GMT+01:00 Simon Rit : > > Hi, >> Yes, this is correct. In plane rotations are accounted for during >> backprojection but not in the FFT ramp filter which is done along lines. It >> should be modifiable if you want to. The weighting in the projection image >> should not sensitive to in plane rotation since it uses the distance to the >> center. >> How large are your rotations? >> Simon >> >> >> >> On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: >> >>> Hi, >>> >>> First thanks for the hard work on this nice toolkit. >>> >>> I am working on FDK reconstruction. >>> I noticed that the InPlaneRotation seems not to be handled in some >>> situations, such as in the DisplacedDetectorImageFilter, which is >>> explicitly stated in the document. >>> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >>> there seems to be no correction for the in-plane rotation to the projection >>> images before they are send to the FFTRampImageFilter. Thus the filtering >>> seems to be performed along the rows of the projection image but not the >>> true horizontal direction of the projection. >>> Did I miss anything around here? In which steps and to which extent the >>> in-plane rotation has been taken into account? >>> >>> Best regards, >>> Chao >>> >>> TUDelft, NL >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.champion.13 at ucl.ac.uk Wed Feb 19 12:35:59 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Wed, 19 Feb 2014 17:35:59 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading Message-ID: <5304EB7F.4080601@ucl.ac.uk> Hello, First of all, many thanks to the RTK community for this useful toolkit! While experimenting with different versions of the code (I'm a relatively new user), I've encountered large differences in rtkfdk (CPU) reconstruction speed between code versions (a newer version being substantially slower than an older version). To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the required -g, -p, -r and -o flags, but no other flags). Using git-bisect, I narrowed it down to a particular commit. The parent commit runs quite quickly, but the child commit shows nearly 4x reconstruction time, and less-uniform CPU utilization (it looks like a series of spikes). (See below) Looking at the diffs, it seems that in addition to adding the HannY functionality (which should be disabled by default?), there were some changes in this commit related to threading (in code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is misleading and the substantial difference consists in changing the FFT Ramp Kernel. I'm currently reading the source to try to understand those changes, but I thought I would post in case someone is able to point me in the right direction. Although these differences are unexpected to me, I doubt that they are unexpected to more experienced users...! Apologies if I've left out any critical information (or if I've provided too much!). Many thanks in advance, Ben ****** Parent Commit ****** commit 9df6108ae0293f86b455a2dcd4b35801e4815718 Author: Julien Jomier Date: Fri Nov 30 09:30:59 2012 +0100 ENH: Minimum CMake version is 2.8.3 ***Partial output*** Reconstructing and writing... It took 44.3992 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.67915 s Ramp filter: 26.3847 s Backprojection: 13.0447 s ***Screenshot of CPU usage attached: 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** ****** Child Commit ****** commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 Author: Simon Rit Date: Wed Dec 5 16:22:47 2012 +0100 First version of Hann windowing in the second direction (perpendicular to the ramp) ***Partial output*** Reconstructing and writing... It took 126.911 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.47678 s Ramp filter: 108.254 s Backprojection: 13.2973 s ***Screenshot of CPU usage attached: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** -------------- next part -------------- A non-text attachment was scrubbed... Name: 9df6108ae0293f86b455a2dcd4b35801e4815718.png Type: image/png Size: 80382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png Type: image/png Size: 75196 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 20 01:57:02 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 20 Feb 2014 07:57:02 +0100 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: <5304EB7F.4080601@ucl.ac.uk> References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: Hi, Thank you Ben for the amazing report. I can spot a few things that could have gone wrong there but it seems to me that your reconstruction is slow both before and after the commit... Two potential reasons: - you have not activated FFTW in ITK. You should definitely do that, the FFT of ITK is (very) slow and probably not multithreaded. You must turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent version of ITK4, I had some issues with the first versions, see http://www.itk.org/pipermail/insight-users/2013-April/047562.html - you are using a huge dataset. If you did not use FFTW, could you try again with FFTW and tell us if you still observe a drop in performances? If you had FFTW, can you provide the sie of the dataset you used? Thanks, Simon On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion wrote: > Hello, > > First of all, many thanks to the RTK community for this useful toolkit! > > While experimenting with different versions of the code (I'm a relatively > new user), I've encountered large differences in rtkfdk (CPU) reconstruction > speed between code versions (a newer version being substantially slower than > an older version). > > To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the > required -g, -p, -r and -o flags, but no other flags). > > Using git-bisect, I narrowed it down to a particular commit. The parent > commit runs quite quickly, but the child commit shows nearly 4x > reconstruction time, and less-uniform CPU utilization (it looks like a > series of spikes). > > (See below) > > Looking at the diffs, it seems that in addition to adding the HannY > functionality (which should be disabled by default?), there were some > changes in this commit related to threading (in > code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is > misleading and the substantial difference consists in changing the FFT Ramp > Kernel. > > I'm currently reading the source to try to understand those changes, but I > thought I would post in case someone is able to point me in the right > direction. Although these differences are unexpected to me, I doubt that > they are unexpected to more experienced users...! > > Apologies if I've left out any critical information (or if I've provided too > much!). > > Many thanks in advance, > Ben > > ****** Parent Commit ****** > commit 9df6108ae0293f86b455a2dcd4b35801e4815718 > Author: Julien Jomier > Date: Fri Nov 30 09:30:59 2012 +0100 > > ENH: Minimum CMake version is 2.8.3 > > ***Partial output*** > > Reconstructing and writing... It took 44.3992 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.67915 s > Ramp filter: 26.3847 s > Backprojection: 13.0447 s > > ***Screenshot of CPU usage attached: > 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** > > ****** Child Commit ****** > commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 > Author: Simon Rit > Date: Wed Dec 5 16:22:47 2012 +0100 > > First version of Hann windowing in the second direction (perpendicular > to the ramp) > > ***Partial output*** > Reconstructing and writing... It took 126.911 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.47678 s > Ramp filter: 108.254 s > Backprojection: 13.2973 s > > ***Screenshot of CPU usage attached: > e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From benjamin.champion.13 at ucl.ac.uk Thu Feb 20 06:20:35 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Thu, 20 Feb 2014 11:20:35 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: <5305E503.3000506@ucl.ac.uk> Hi Simon, Really appreciate your prompt response! Indeed, I was not using FFTW. After rebuilding ITK with FFTW, I get faster reconstructions, and the time increase between the two commits reduces to a little over 2x (See below). My dataset consists of 344 projections (about 172.0 MB) Does this sound about right? The CPU utilization still looks a bit like a series of spikes for the latter commit (but different than before). Reconstructing and writing... It took 36.0746 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.59479 s Ramp filter: 19.3106 s Backprojection: 13.8042 s ***versus*** Reconstructing and writing... It took 83.4121 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.62535 s Ramp filter: 66.5537 s Backprojection: 13.8829 s Thanks again, Ben On 20/02/14 06:57, Simon Rit wrote: > Hi, > Thank you Ben for the amazing report. I can spot a few things that > could have gone wrong there but it seems to me that your > reconstruction is slow both before and after the commit... Two > potential reasons: > - you have not activated FFTW in ITK. You should definitely do that, > the FFT of ITK is (very) slow and probably not multithreaded. You must > turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent > version of ITK4, I had some issues with the first versions, see > http://www.itk.org/pipermail/insight-users/2013-April/047562.html > - you are using a huge dataset. > If you did not use FFTW, could you try again with FFTW and tell us if > you still observe a drop in performances? If you had FFTW, can you > provide the sie of the dataset you used? > Thanks, > Simon > > On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion > wrote: >> Hello, >> >> First of all, many thanks to the RTK community for this useful toolkit! >> >> While experimenting with different versions of the code (I'm a relatively >> new user), I've encountered large differences in rtkfdk (CPU) reconstruction >> speed between code versions (a newer version being substantially slower than >> an older version). >> >> To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the >> required -g, -p, -r and -o flags, but no other flags). >> >> Using git-bisect, I narrowed it down to a particular commit. The parent >> commit runs quite quickly, but the child commit shows nearly 4x >> reconstruction time, and less-uniform CPU utilization (it looks like a >> series of spikes). >> >> (See below) >> >> Looking at the diffs, it seems that in addition to adding the HannY >> functionality (which should be disabled by default?), there were some >> changes in this commit related to threading (in >> code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is >> misleading and the substantial difference consists in changing the FFT Ramp >> Kernel. >> >> I'm currently reading the source to try to understand those changes, but I >> thought I would post in case someone is able to point me in the right >> direction. Although these differences are unexpected to me, I doubt that >> they are unexpected to more experienced users...! >> >> Apologies if I've left out any critical information (or if I've provided too >> much!). >> >> Many thanks in advance, >> Ben >> >> ****** Parent Commit ****** >> commit 9df6108ae0293f86b455a2dcd4b35801e4815718 >> Author: Julien Jomier >> Date: Fri Nov 30 09:30:59 2012 +0100 >> >> ENH: Minimum CMake version is 2.8.3 >> >> ***Partial output*** >> >> Reconstructing and writing... It took 44.3992 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.67915 s >> Ramp filter: 26.3847 s >> Backprojection: 13.0447 s >> >> ***Screenshot of CPU usage attached: >> 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** >> >> ****** Child Commit ****** >> commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 >> Author: Simon Rit >> Date: Wed Dec 5 16:22:47 2012 +0100 >> >> First version of Hann windowing in the second direction (perpendicular >> to the ramp) >> >> ***Partial output*** >> Reconstructing and writing... It took 126.911 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.47678 s >> Ramp filter: 108.254 s >> Backprojection: 13.2973 s >> >> ***Screenshot of CPU usage attached: >> e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> From simon.rit at creatis.insa-lyon.fr Wed Feb 5 10:30:13 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 16:30:13 +0100 Subject: [Rtk-users] Ending ITK 3.20 compatibility Message-ID: Dear all, The RTK consortium has decided today to give up the ITK3.20 compatibility. It has been hard to maintain it lately (you may have noticed it on the dashboard) and we do not see any advantage of keeping it. Would you have any concern with this decision, please contact us quickly because it will be effective soon. Regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Feb 5 11:42:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 17:42:38 +0100 Subject: [Rtk-users] Fix the issue when use RTK on Nvidia Kepler Architecture based GPU. In-Reply-To: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> References: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> Message-ID: Dear Peng Liu, Thanks a lot, I have pushed your change right now. Don't hesitate to suggest changes in those flags, I don't think that so many people are familiar with them... Simon On Mon, Jan 20, 2014 at 10:06 AM, ?? wrote: > Hello, > > > > I find an issue when I try to use RTK on a Nvidia Kepler based GPU. > > The CUDA initializing always fails. > > And I can see an exception about _cudaMutexOperation when any CUDA > function is called in debug mode. > > > > Exception at 0x7fefd5f940d, code: 0xe06d7363: C++ exception, flags=0x1 > (execution cannot be continued) (first chance) in > cudart64_50_35!_cudaMutexOperation > > > > > > Following the guide in > > http://docs.nvidia.com/cuda/kepler-compatibility-guide/index.html > > > > This issue can be fixed by applying the patch on RTK code: > > > > > > =========================================================================== > > > > diff --git a/cmake/FindCUDA_wrap.cmake b/cmake/FindCUDA_wrap.cmake > > index e13a7c3..b40c6da 100644 > > --- a/cmake/FindCUDA_wrap.cmake > > +++ b/cmake/FindCUDA_wrap.cmake > > @@ -59,9 +59,19 @@ set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > ) > > > > if(CUDA_VERSION_MAJOR GREATER "2") > > - set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > - -gencode arch=compute_20,code=sm_20 > > - ) > > + IF(${CUDA_VERSION} LESS 5.0) > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_20,code=compute_20 > > + ) > > + ELSE() > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_30,code=sm_30 > > + -gencode arch=compute_35,code=sm_35 > > + -gencode arch=compute_35,code=compute_35 > > + ) > > + ENDIF() > > endif() > > > > if(CUDA_FOUND) > > > > > ============================================================================ > > > > Regards, > > > > Peng Liu > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 08:26:18 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 14:26:18 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? Message-ID: Hi, First thanks for the hard work on this nice toolkit. I am working on FDK reconstruction. I noticed that the InPlaneRotation seems not to be handled in some situations, such as in the DisplacedDetectorImageFilter, which is explicitly stated in the document. Furthermore, when I went through the FDKConeBeamReconstructionFilter, there seems to be no correction for the in-plane rotation to the projection images before they are send to the FFTRampImageFilter. Thus the filtering seems to be performed along the rows of the projection image but not the true horizontal direction of the projection. Did I miss anything around here? In which steps and to which extent the in-plane rotation has been taken into account? Best regards, Chao TUDelft, NL -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 09:10:10 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 15:10:10 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi, Yes, this is correct. In plane rotations are accounted for during backprojection but not in the FFT ramp filter which is done along lines. It should be modifiable if you want to. The weighting in the projection image should not sensitive to in plane rotation since it uses the distance to the center. How large are your rotations? Simon On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > Hi, > > First thanks for the hard work on this nice toolkit. > > I am working on FDK reconstruction. > I noticed that the InPlaneRotation seems not to be handled in some > situations, such as in the DisplacedDetectorImageFilter, which is > explicitly stated in the document. > Furthermore, when I went through the FDKConeBeamReconstructionFilter, > there seems to be no correction for the in-plane rotation to the projection > images before they are send to the FFTRampImageFilter. Thus the filtering > seems to be performed along the rows of the projection image but not the > true horizontal direction of the projection. > Did I miss anything around here? In which steps and to which extent the > in-plane rotation has been taken into account? > > Best regards, > Chao > > TUDelft, NL > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 10:32:57 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 16:32:57 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi Simon, Thanks for the confirmation. The rotation in my projections are less than 0.2 degrees, so the ramp filter along image line or along true horizontal direction may leads to almost identical reconstructions. I got into this subject because I was working with a displaced detector and found dark and bright regions along the axis of rotation at two side of the mid plane when the IPR is set to non-zero. After reading the document I realized that this would be due to that the IPR is not accounted when the weighting [G Wang] is performed, then later it is accounted during the FDK, so that Wang's weight function applied to opposite projections does not sum to 1. Before I make any changes to the DisplacedDetectorImageFilter I would like to see how you dealt with IPR in FDK, and suddenly I found IPR is not accounted for either in the ramp filter which is not 'mathematically correct' (but may be sufficient and efficient in practice). So now I am thinking how to solve the problem. The most straightforward way could be that I perform a pre-correction for IPR in all my displaced-detector projections, and send them to rtkfdk with an IPR=0 geometry, since this can make the behaviour of both DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less workload in coding, of course). Or modify the DisplacedDetectorImageFilter to account for IPR while leave the FFTRampImageFilter as it is. Do you have any other comments and suggestions? Thank you. Best regards, Chao 2014-02-14 15:10 GMT+01:00 Simon Rit : > Hi, > Yes, this is correct. In plane rotations are accounted for during > backprojection but not in the FFT ramp filter which is done along lines. It > should be modifiable if you want to. The weighting in the projection image > should not sensitive to in plane rotation since it uses the distance to the > center. > How large are your rotations? > Simon > > > > On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > >> Hi, >> >> First thanks for the hard work on this nice toolkit. >> >> I am working on FDK reconstruction. >> I noticed that the InPlaneRotation seems not to be handled in some >> situations, such as in the DisplacedDetectorImageFilter, which is >> explicitly stated in the document. >> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >> there seems to be no correction for the in-plane rotation to the projection >> images before they are send to the FFTRampImageFilter. Thus the filtering >> seems to be performed along the rows of the projection image but not the >> true horizontal direction of the projection. >> Did I miss anything around here? In which steps and to which extent the >> in-plane rotation has been taken into account? >> >> Best regards, >> Chao >> >> TUDelft, NL >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 10:56:56 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 16:56:56 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: The simplest is indeed to resample to a non-rotated detector. One reason I did not go into the in plane rotation stuff is that I wanted to keep the ramp filter independent of the geometry. But this could be changed if you find it useful, e.g., by adding a filtering direction. The best would be to avoid a resampling and to account for the rotation in each step. If you want to go in this direction, since it is a rather unusual geometry, I would suggest to check that you obtain relevant results for each step. There are command line tools that split rtkfdk in the 3 steps: rtkfdktwodweights, rtkrampfilter and rtkbackprojections. Let me know if I can help. If you develop something, your contribution will be welcomed! Simon On Fri, Feb 14, 2014 at 4:32 PM, Chao Wu wrote: > Hi Simon, > > Thanks for the confirmation. > The rotation in my projections are less than 0.2 degrees, so the ramp > filter along image line or along true horizontal direction may leads to > almost identical reconstructions. > > I got into this subject because I was working with a displaced detector > and found dark and bright regions along the axis of rotation at two side of > the mid plane when the IPR is set to non-zero. > After reading the document I realized that this would be due to that the > IPR is not accounted when the weighting [G Wang] is performed, then later > it is accounted during the FDK, so that Wang's weight function applied to > opposite projections does not sum to 1. Before I make any changes to the > DisplacedDetectorImageFilter I would like to see how you dealt with IPR in > FDK, and suddenly I found IPR is not accounted for either in the ramp > filter which is not 'mathematically correct' (but may be sufficient and > efficient in practice). > > So now I am thinking how to solve the problem. > The most straightforward way could be that I perform a pre-correction for > IPR in all my displaced-detector projections, and send them to rtkfdk with > an IPR=0 geometry, since this can make the behaviour of both > DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less > workload in coding, of course). > Or modify the DisplacedDetectorImageFilter to account for IPR while leave > the FFTRampImageFilter as it is. > Do you have any other comments and suggestions? Thank you. > > Best regards, > Chao > > > > 2014-02-14 15:10 GMT+01:00 Simon Rit : > > Hi, >> Yes, this is correct. In plane rotations are accounted for during >> backprojection but not in the FFT ramp filter which is done along lines. It >> should be modifiable if you want to. The weighting in the projection image >> should not sensitive to in plane rotation since it uses the distance to the >> center. >> How large are your rotations? >> Simon >> >> >> >> On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: >> >>> Hi, >>> >>> First thanks for the hard work on this nice toolkit. >>> >>> I am working on FDK reconstruction. >>> I noticed that the InPlaneRotation seems not to be handled in some >>> situations, such as in the DisplacedDetectorImageFilter, which is >>> explicitly stated in the document. >>> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >>> there seems to be no correction for the in-plane rotation to the projection >>> images before they are send to the FFTRampImageFilter. Thus the filtering >>> seems to be performed along the rows of the projection image but not the >>> true horizontal direction of the projection. >>> Did I miss anything around here? In which steps and to which extent the >>> in-plane rotation has been taken into account? >>> >>> Best regards, >>> Chao >>> >>> TUDelft, NL >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.champion.13 at ucl.ac.uk Wed Feb 19 12:35:59 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Wed, 19 Feb 2014 17:35:59 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading Message-ID: <5304EB7F.4080601@ucl.ac.uk> Hello, First of all, many thanks to the RTK community for this useful toolkit! While experimenting with different versions of the code (I'm a relatively new user), I've encountered large differences in rtkfdk (CPU) reconstruction speed between code versions (a newer version being substantially slower than an older version). To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the required -g, -p, -r and -o flags, but no other flags). Using git-bisect, I narrowed it down to a particular commit. The parent commit runs quite quickly, but the child commit shows nearly 4x reconstruction time, and less-uniform CPU utilization (it looks like a series of spikes). (See below) Looking at the diffs, it seems that in addition to adding the HannY functionality (which should be disabled by default?), there were some changes in this commit related to threading (in code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is misleading and the substantial difference consists in changing the FFT Ramp Kernel. I'm currently reading the source to try to understand those changes, but I thought I would post in case someone is able to point me in the right direction. Although these differences are unexpected to me, I doubt that they are unexpected to more experienced users...! Apologies if I've left out any critical information (or if I've provided too much!). Many thanks in advance, Ben ****** Parent Commit ****** commit 9df6108ae0293f86b455a2dcd4b35801e4815718 Author: Julien Jomier Date: Fri Nov 30 09:30:59 2012 +0100 ENH: Minimum CMake version is 2.8.3 ***Partial output*** Reconstructing and writing... It took 44.3992 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.67915 s Ramp filter: 26.3847 s Backprojection: 13.0447 s ***Screenshot of CPU usage attached: 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** ****** Child Commit ****** commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 Author: Simon Rit Date: Wed Dec 5 16:22:47 2012 +0100 First version of Hann windowing in the second direction (perpendicular to the ramp) ***Partial output*** Reconstructing and writing... It took 126.911 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.47678 s Ramp filter: 108.254 s Backprojection: 13.2973 s ***Screenshot of CPU usage attached: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** -------------- next part -------------- A non-text attachment was scrubbed... Name: 9df6108ae0293f86b455a2dcd4b35801e4815718.png Type: image/png Size: 80382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png Type: image/png Size: 75196 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 20 01:57:02 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 20 Feb 2014 07:57:02 +0100 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: <5304EB7F.4080601@ucl.ac.uk> References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: Hi, Thank you Ben for the amazing report. I can spot a few things that could have gone wrong there but it seems to me that your reconstruction is slow both before and after the commit... Two potential reasons: - you have not activated FFTW in ITK. You should definitely do that, the FFT of ITK is (very) slow and probably not multithreaded. You must turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent version of ITK4, I had some issues with the first versions, see http://www.itk.org/pipermail/insight-users/2013-April/047562.html - you are using a huge dataset. If you did not use FFTW, could you try again with FFTW and tell us if you still observe a drop in performances? If you had FFTW, can you provide the sie of the dataset you used? Thanks, Simon On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion wrote: > Hello, > > First of all, many thanks to the RTK community for this useful toolkit! > > While experimenting with different versions of the code (I'm a relatively > new user), I've encountered large differences in rtkfdk (CPU) reconstruction > speed between code versions (a newer version being substantially slower than > an older version). > > To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the > required -g, -p, -r and -o flags, but no other flags). > > Using git-bisect, I narrowed it down to a particular commit. The parent > commit runs quite quickly, but the child commit shows nearly 4x > reconstruction time, and less-uniform CPU utilization (it looks like a > series of spikes). > > (See below) > > Looking at the diffs, it seems that in addition to adding the HannY > functionality (which should be disabled by default?), there were some > changes in this commit related to threading (in > code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is > misleading and the substantial difference consists in changing the FFT Ramp > Kernel. > > I'm currently reading the source to try to understand those changes, but I > thought I would post in case someone is able to point me in the right > direction. Although these differences are unexpected to me, I doubt that > they are unexpected to more experienced users...! > > Apologies if I've left out any critical information (or if I've provided too > much!). > > Many thanks in advance, > Ben > > ****** Parent Commit ****** > commit 9df6108ae0293f86b455a2dcd4b35801e4815718 > Author: Julien Jomier > Date: Fri Nov 30 09:30:59 2012 +0100 > > ENH: Minimum CMake version is 2.8.3 > > ***Partial output*** > > Reconstructing and writing... It took 44.3992 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.67915 s > Ramp filter: 26.3847 s > Backprojection: 13.0447 s > > ***Screenshot of CPU usage attached: > 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** > > ****** Child Commit ****** > commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 > Author: Simon Rit > Date: Wed Dec 5 16:22:47 2012 +0100 > > First version of Hann windowing in the second direction (perpendicular > to the ramp) > > ***Partial output*** > Reconstructing and writing... It took 126.911 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.47678 s > Ramp filter: 108.254 s > Backprojection: 13.2973 s > > ***Screenshot of CPU usage attached: > e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From benjamin.champion.13 at ucl.ac.uk Thu Feb 20 06:20:35 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Thu, 20 Feb 2014 11:20:35 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: <5305E503.3000506@ucl.ac.uk> Hi Simon, Really appreciate your prompt response! Indeed, I was not using FFTW. After rebuilding ITK with FFTW, I get faster reconstructions, and the time increase between the two commits reduces to a little over 2x (See below). My dataset consists of 344 projections (about 172.0 MB) Does this sound about right? The CPU utilization still looks a bit like a series of spikes for the latter commit (but different than before). Reconstructing and writing... It took 36.0746 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.59479 s Ramp filter: 19.3106 s Backprojection: 13.8042 s ***versus*** Reconstructing and writing... It took 83.4121 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.62535 s Ramp filter: 66.5537 s Backprojection: 13.8829 s Thanks again, Ben On 20/02/14 06:57, Simon Rit wrote: > Hi, > Thank you Ben for the amazing report. I can spot a few things that > could have gone wrong there but it seems to me that your > reconstruction is slow both before and after the commit... Two > potential reasons: > - you have not activated FFTW in ITK. You should definitely do that, > the FFT of ITK is (very) slow and probably not multithreaded. You must > turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent > version of ITK4, I had some issues with the first versions, see > http://www.itk.org/pipermail/insight-users/2013-April/047562.html > - you are using a huge dataset. > If you did not use FFTW, could you try again with FFTW and tell us if > you still observe a drop in performances? If you had FFTW, can you > provide the sie of the dataset you used? > Thanks, > Simon > > On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion > wrote: >> Hello, >> >> First of all, many thanks to the RTK community for this useful toolkit! >> >> While experimenting with different versions of the code (I'm a relatively >> new user), I've encountered large differences in rtkfdk (CPU) reconstruction >> speed between code versions (a newer version being substantially slower than >> an older version). >> >> To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the >> required -g, -p, -r and -o flags, but no other flags). >> >> Using git-bisect, I narrowed it down to a particular commit. The parent >> commit runs quite quickly, but the child commit shows nearly 4x >> reconstruction time, and less-uniform CPU utilization (it looks like a >> series of spikes). >> >> (See below) >> >> Looking at the diffs, it seems that in addition to adding the HannY >> functionality (which should be disabled by default?), there were some >> changes in this commit related to threading (in >> code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is >> misleading and the substantial difference consists in changing the FFT Ramp >> Kernel. >> >> I'm currently reading the source to try to understand those changes, but I >> thought I would post in case someone is able to point me in the right >> direction. Although these differences are unexpected to me, I doubt that >> they are unexpected to more experienced users...! >> >> Apologies if I've left out any critical information (or if I've provided too >> much!). >> >> Many thanks in advance, >> Ben >> >> ****** Parent Commit ****** >> commit 9df6108ae0293f86b455a2dcd4b35801e4815718 >> Author: Julien Jomier >> Date: Fri Nov 30 09:30:59 2012 +0100 >> >> ENH: Minimum CMake version is 2.8.3 >> >> ***Partial output*** >> >> Reconstructing and writing... It took 44.3992 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.67915 s >> Ramp filter: 26.3847 s >> Backprojection: 13.0447 s >> >> ***Screenshot of CPU usage attached: >> 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** >> >> ****** Child Commit ****** >> commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 >> Author: Simon Rit >> Date: Wed Dec 5 16:22:47 2012 +0100 >> >> First version of Hann windowing in the second direction (perpendicular >> to the ramp) >> >> ***Partial output*** >> Reconstructing and writing... It took 126.911 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.47678 s >> Ramp filter: 108.254 s >> Backprojection: 13.2973 s >> >> ***Screenshot of CPU usage attached: >> e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> From simon.rit at creatis.insa-lyon.fr Wed Feb 5 10:30:13 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 16:30:13 +0100 Subject: [Rtk-users] Ending ITK 3.20 compatibility Message-ID: Dear all, The RTK consortium has decided today to give up the ITK3.20 compatibility. It has been hard to maintain it lately (you may have noticed it on the dashboard) and we do not see any advantage of keeping it. Would you have any concern with this decision, please contact us quickly because it will be effective soon. Regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Feb 5 11:42:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 17:42:38 +0100 Subject: [Rtk-users] Fix the issue when use RTK on Nvidia Kepler Architecture based GPU. In-Reply-To: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> References: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> Message-ID: Dear Peng Liu, Thanks a lot, I have pushed your change right now. Don't hesitate to suggest changes in those flags, I don't think that so many people are familiar with them... Simon On Mon, Jan 20, 2014 at 10:06 AM, ?? wrote: > Hello, > > > > I find an issue when I try to use RTK on a Nvidia Kepler based GPU. > > The CUDA initializing always fails. > > And I can see an exception about _cudaMutexOperation when any CUDA > function is called in debug mode. > > > > Exception at 0x7fefd5f940d, code: 0xe06d7363: C++ exception, flags=0x1 > (execution cannot be continued) (first chance) in > cudart64_50_35!_cudaMutexOperation > > > > > > Following the guide in > > http://docs.nvidia.com/cuda/kepler-compatibility-guide/index.html > > > > This issue can be fixed by applying the patch on RTK code: > > > > > > =========================================================================== > > > > diff --git a/cmake/FindCUDA_wrap.cmake b/cmake/FindCUDA_wrap.cmake > > index e13a7c3..b40c6da 100644 > > --- a/cmake/FindCUDA_wrap.cmake > > +++ b/cmake/FindCUDA_wrap.cmake > > @@ -59,9 +59,19 @@ set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > ) > > > > if(CUDA_VERSION_MAJOR GREATER "2") > > - set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > - -gencode arch=compute_20,code=sm_20 > > - ) > > + IF(${CUDA_VERSION} LESS 5.0) > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_20,code=compute_20 > > + ) > > + ELSE() > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_30,code=sm_30 > > + -gencode arch=compute_35,code=sm_35 > > + -gencode arch=compute_35,code=compute_35 > > + ) > > + ENDIF() > > endif() > > > > if(CUDA_FOUND) > > > > > ============================================================================ > > > > Regards, > > > > Peng Liu > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 08:26:18 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 14:26:18 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? Message-ID: Hi, First thanks for the hard work on this nice toolkit. I am working on FDK reconstruction. I noticed that the InPlaneRotation seems not to be handled in some situations, such as in the DisplacedDetectorImageFilter, which is explicitly stated in the document. Furthermore, when I went through the FDKConeBeamReconstructionFilter, there seems to be no correction for the in-plane rotation to the projection images before they are send to the FFTRampImageFilter. Thus the filtering seems to be performed along the rows of the projection image but not the true horizontal direction of the projection. Did I miss anything around here? In which steps and to which extent the in-plane rotation has been taken into account? Best regards, Chao TUDelft, NL -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 09:10:10 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 15:10:10 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi, Yes, this is correct. In plane rotations are accounted for during backprojection but not in the FFT ramp filter which is done along lines. It should be modifiable if you want to. The weighting in the projection image should not sensitive to in plane rotation since it uses the distance to the center. How large are your rotations? Simon On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > Hi, > > First thanks for the hard work on this nice toolkit. > > I am working on FDK reconstruction. > I noticed that the InPlaneRotation seems not to be handled in some > situations, such as in the DisplacedDetectorImageFilter, which is > explicitly stated in the document. > Furthermore, when I went through the FDKConeBeamReconstructionFilter, > there seems to be no correction for the in-plane rotation to the projection > images before they are send to the FFTRampImageFilter. Thus the filtering > seems to be performed along the rows of the projection image but not the > true horizontal direction of the projection. > Did I miss anything around here? In which steps and to which extent the > in-plane rotation has been taken into account? > > Best regards, > Chao > > TUDelft, NL > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 10:32:57 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 16:32:57 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi Simon, Thanks for the confirmation. The rotation in my projections are less than 0.2 degrees, so the ramp filter along image line or along true horizontal direction may leads to almost identical reconstructions. I got into this subject because I was working with a displaced detector and found dark and bright regions along the axis of rotation at two side of the mid plane when the IPR is set to non-zero. After reading the document I realized that this would be due to that the IPR is not accounted when the weighting [G Wang] is performed, then later it is accounted during the FDK, so that Wang's weight function applied to opposite projections does not sum to 1. Before I make any changes to the DisplacedDetectorImageFilter I would like to see how you dealt with IPR in FDK, and suddenly I found IPR is not accounted for either in the ramp filter which is not 'mathematically correct' (but may be sufficient and efficient in practice). So now I am thinking how to solve the problem. The most straightforward way could be that I perform a pre-correction for IPR in all my displaced-detector projections, and send them to rtkfdk with an IPR=0 geometry, since this can make the behaviour of both DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less workload in coding, of course). Or modify the DisplacedDetectorImageFilter to account for IPR while leave the FFTRampImageFilter as it is. Do you have any other comments and suggestions? Thank you. Best regards, Chao 2014-02-14 15:10 GMT+01:00 Simon Rit : > Hi, > Yes, this is correct. In plane rotations are accounted for during > backprojection but not in the FFT ramp filter which is done along lines. It > should be modifiable if you want to. The weighting in the projection image > should not sensitive to in plane rotation since it uses the distance to the > center. > How large are your rotations? > Simon > > > > On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > >> Hi, >> >> First thanks for the hard work on this nice toolkit. >> >> I am working on FDK reconstruction. >> I noticed that the InPlaneRotation seems not to be handled in some >> situations, such as in the DisplacedDetectorImageFilter, which is >> explicitly stated in the document. >> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >> there seems to be no correction for the in-plane rotation to the projection >> images before they are send to the FFTRampImageFilter. Thus the filtering >> seems to be performed along the rows of the projection image but not the >> true horizontal direction of the projection. >> Did I miss anything around here? In which steps and to which extent the >> in-plane rotation has been taken into account? >> >> Best regards, >> Chao >> >> TUDelft, NL >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 10:56:56 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 16:56:56 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: The simplest is indeed to resample to a non-rotated detector. One reason I did not go into the in plane rotation stuff is that I wanted to keep the ramp filter independent of the geometry. But this could be changed if you find it useful, e.g., by adding a filtering direction. The best would be to avoid a resampling and to account for the rotation in each step. If you want to go in this direction, since it is a rather unusual geometry, I would suggest to check that you obtain relevant results for each step. There are command line tools that split rtkfdk in the 3 steps: rtkfdktwodweights, rtkrampfilter and rtkbackprojections. Let me know if I can help. If you develop something, your contribution will be welcomed! Simon On Fri, Feb 14, 2014 at 4:32 PM, Chao Wu wrote: > Hi Simon, > > Thanks for the confirmation. > The rotation in my projections are less than 0.2 degrees, so the ramp > filter along image line or along true horizontal direction may leads to > almost identical reconstructions. > > I got into this subject because I was working with a displaced detector > and found dark and bright regions along the axis of rotation at two side of > the mid plane when the IPR is set to non-zero. > After reading the document I realized that this would be due to that the > IPR is not accounted when the weighting [G Wang] is performed, then later > it is accounted during the FDK, so that Wang's weight function applied to > opposite projections does not sum to 1. Before I make any changes to the > DisplacedDetectorImageFilter I would like to see how you dealt with IPR in > FDK, and suddenly I found IPR is not accounted for either in the ramp > filter which is not 'mathematically correct' (but may be sufficient and > efficient in practice). > > So now I am thinking how to solve the problem. > The most straightforward way could be that I perform a pre-correction for > IPR in all my displaced-detector projections, and send them to rtkfdk with > an IPR=0 geometry, since this can make the behaviour of both > DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less > workload in coding, of course). > Or modify the DisplacedDetectorImageFilter to account for IPR while leave > the FFTRampImageFilter as it is. > Do you have any other comments and suggestions? Thank you. > > Best regards, > Chao > > > > 2014-02-14 15:10 GMT+01:00 Simon Rit : > > Hi, >> Yes, this is correct. In plane rotations are accounted for during >> backprojection but not in the FFT ramp filter which is done along lines. It >> should be modifiable if you want to. The weighting in the projection image >> should not sensitive to in plane rotation since it uses the distance to the >> center. >> How large are your rotations? >> Simon >> >> >> >> On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: >> >>> Hi, >>> >>> First thanks for the hard work on this nice toolkit. >>> >>> I am working on FDK reconstruction. >>> I noticed that the InPlaneRotation seems not to be handled in some >>> situations, such as in the DisplacedDetectorImageFilter, which is >>> explicitly stated in the document. >>> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >>> there seems to be no correction for the in-plane rotation to the projection >>> images before they are send to the FFTRampImageFilter. Thus the filtering >>> seems to be performed along the rows of the projection image but not the >>> true horizontal direction of the projection. >>> Did I miss anything around here? In which steps and to which extent the >>> in-plane rotation has been taken into account? >>> >>> Best regards, >>> Chao >>> >>> TUDelft, NL >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.champion.13 at ucl.ac.uk Wed Feb 19 12:35:59 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Wed, 19 Feb 2014 17:35:59 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading Message-ID: <5304EB7F.4080601@ucl.ac.uk> Hello, First of all, many thanks to the RTK community for this useful toolkit! While experimenting with different versions of the code (I'm a relatively new user), I've encountered large differences in rtkfdk (CPU) reconstruction speed between code versions (a newer version being substantially slower than an older version). To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the required -g, -p, -r and -o flags, but no other flags). Using git-bisect, I narrowed it down to a particular commit. The parent commit runs quite quickly, but the child commit shows nearly 4x reconstruction time, and less-uniform CPU utilization (it looks like a series of spikes). (See below) Looking at the diffs, it seems that in addition to adding the HannY functionality (which should be disabled by default?), there were some changes in this commit related to threading (in code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is misleading and the substantial difference consists in changing the FFT Ramp Kernel. I'm currently reading the source to try to understand those changes, but I thought I would post in case someone is able to point me in the right direction. Although these differences are unexpected to me, I doubt that they are unexpected to more experienced users...! Apologies if I've left out any critical information (or if I've provided too much!). Many thanks in advance, Ben ****** Parent Commit ****** commit 9df6108ae0293f86b455a2dcd4b35801e4815718 Author: Julien Jomier Date: Fri Nov 30 09:30:59 2012 +0100 ENH: Minimum CMake version is 2.8.3 ***Partial output*** Reconstructing and writing... It took 44.3992 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.67915 s Ramp filter: 26.3847 s Backprojection: 13.0447 s ***Screenshot of CPU usage attached: 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** ****** Child Commit ****** commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 Author: Simon Rit Date: Wed Dec 5 16:22:47 2012 +0100 First version of Hann windowing in the second direction (perpendicular to the ramp) ***Partial output*** Reconstructing and writing... It took 126.911 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.47678 s Ramp filter: 108.254 s Backprojection: 13.2973 s ***Screenshot of CPU usage attached: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** -------------- next part -------------- A non-text attachment was scrubbed... Name: 9df6108ae0293f86b455a2dcd4b35801e4815718.png Type: image/png Size: 80382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png Type: image/png Size: 75196 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 20 01:57:02 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 20 Feb 2014 07:57:02 +0100 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: <5304EB7F.4080601@ucl.ac.uk> References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: Hi, Thank you Ben for the amazing report. I can spot a few things that could have gone wrong there but it seems to me that your reconstruction is slow both before and after the commit... Two potential reasons: - you have not activated FFTW in ITK. You should definitely do that, the FFT of ITK is (very) slow and probably not multithreaded. You must turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent version of ITK4, I had some issues with the first versions, see http://www.itk.org/pipermail/insight-users/2013-April/047562.html - you are using a huge dataset. If you did not use FFTW, could you try again with FFTW and tell us if you still observe a drop in performances? If you had FFTW, can you provide the sie of the dataset you used? Thanks, Simon On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion wrote: > Hello, > > First of all, many thanks to the RTK community for this useful toolkit! > > While experimenting with different versions of the code (I'm a relatively > new user), I've encountered large differences in rtkfdk (CPU) reconstruction > speed between code versions (a newer version being substantially slower than > an older version). > > To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the > required -g, -p, -r and -o flags, but no other flags). > > Using git-bisect, I narrowed it down to a particular commit. The parent > commit runs quite quickly, but the child commit shows nearly 4x > reconstruction time, and less-uniform CPU utilization (it looks like a > series of spikes). > > (See below) > > Looking at the diffs, it seems that in addition to adding the HannY > functionality (which should be disabled by default?), there were some > changes in this commit related to threading (in > code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is > misleading and the substantial difference consists in changing the FFT Ramp > Kernel. > > I'm currently reading the source to try to understand those changes, but I > thought I would post in case someone is able to point me in the right > direction. Although these differences are unexpected to me, I doubt that > they are unexpected to more experienced users...! > > Apologies if I've left out any critical information (or if I've provided too > much!). > > Many thanks in advance, > Ben > > ****** Parent Commit ****** > commit 9df6108ae0293f86b455a2dcd4b35801e4815718 > Author: Julien Jomier > Date: Fri Nov 30 09:30:59 2012 +0100 > > ENH: Minimum CMake version is 2.8.3 > > ***Partial output*** > > Reconstructing and writing... It took 44.3992 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.67915 s > Ramp filter: 26.3847 s > Backprojection: 13.0447 s > > ***Screenshot of CPU usage attached: > 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** > > ****** Child Commit ****** > commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 > Author: Simon Rit > Date: Wed Dec 5 16:22:47 2012 +0100 > > First version of Hann windowing in the second direction (perpendicular > to the ramp) > > ***Partial output*** > Reconstructing and writing... It took 126.911 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.47678 s > Ramp filter: 108.254 s > Backprojection: 13.2973 s > > ***Screenshot of CPU usage attached: > e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From benjamin.champion.13 at ucl.ac.uk Thu Feb 20 06:20:35 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Thu, 20 Feb 2014 11:20:35 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: <5305E503.3000506@ucl.ac.uk> Hi Simon, Really appreciate your prompt response! Indeed, I was not using FFTW. After rebuilding ITK with FFTW, I get faster reconstructions, and the time increase between the two commits reduces to a little over 2x (See below). My dataset consists of 344 projections (about 172.0 MB) Does this sound about right? The CPU utilization still looks a bit like a series of spikes for the latter commit (but different than before). Reconstructing and writing... It took 36.0746 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.59479 s Ramp filter: 19.3106 s Backprojection: 13.8042 s ***versus*** Reconstructing and writing... It took 83.4121 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.62535 s Ramp filter: 66.5537 s Backprojection: 13.8829 s Thanks again, Ben On 20/02/14 06:57, Simon Rit wrote: > Hi, > Thank you Ben for the amazing report. I can spot a few things that > could have gone wrong there but it seems to me that your > reconstruction is slow both before and after the commit... Two > potential reasons: > - you have not activated FFTW in ITK. You should definitely do that, > the FFT of ITK is (very) slow and probably not multithreaded. You must > turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent > version of ITK4, I had some issues with the first versions, see > http://www.itk.org/pipermail/insight-users/2013-April/047562.html > - you are using a huge dataset. > If you did not use FFTW, could you try again with FFTW and tell us if > you still observe a drop in performances? If you had FFTW, can you > provide the sie of the dataset you used? > Thanks, > Simon > > On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion > wrote: >> Hello, >> >> First of all, many thanks to the RTK community for this useful toolkit! >> >> While experimenting with different versions of the code (I'm a relatively >> new user), I've encountered large differences in rtkfdk (CPU) reconstruction >> speed between code versions (a newer version being substantially slower than >> an older version). >> >> To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the >> required -g, -p, -r and -o flags, but no other flags). >> >> Using git-bisect, I narrowed it down to a particular commit. The parent >> commit runs quite quickly, but the child commit shows nearly 4x >> reconstruction time, and less-uniform CPU utilization (it looks like a >> series of spikes). >> >> (See below) >> >> Looking at the diffs, it seems that in addition to adding the HannY >> functionality (which should be disabled by default?), there were some >> changes in this commit related to threading (in >> code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is >> misleading and the substantial difference consists in changing the FFT Ramp >> Kernel. >> >> I'm currently reading the source to try to understand those changes, but I >> thought I would post in case someone is able to point me in the right >> direction. Although these differences are unexpected to me, I doubt that >> they are unexpected to more experienced users...! >> >> Apologies if I've left out any critical information (or if I've provided too >> much!). >> >> Many thanks in advance, >> Ben >> >> ****** Parent Commit ****** >> commit 9df6108ae0293f86b455a2dcd4b35801e4815718 >> Author: Julien Jomier >> Date: Fri Nov 30 09:30:59 2012 +0100 >> >> ENH: Minimum CMake version is 2.8.3 >> >> ***Partial output*** >> >> Reconstructing and writing... It took 44.3992 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.67915 s >> Ramp filter: 26.3847 s >> Backprojection: 13.0447 s >> >> ***Screenshot of CPU usage attached: >> 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** >> >> ****** Child Commit ****** >> commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 >> Author: Simon Rit >> Date: Wed Dec 5 16:22:47 2012 +0100 >> >> First version of Hann windowing in the second direction (perpendicular >> to the ramp) >> >> ***Partial output*** >> Reconstructing and writing... It took 126.911 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.47678 s >> Ramp filter: 108.254 s >> Backprojection: 13.2973 s >> >> ***Screenshot of CPU usage attached: >> e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> From simon.rit at creatis.insa-lyon.fr Wed Feb 5 10:30:13 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 16:30:13 +0100 Subject: [Rtk-users] Ending ITK 3.20 compatibility Message-ID: Dear all, The RTK consortium has decided today to give up the ITK3.20 compatibility. It has been hard to maintain it lately (you may have noticed it on the dashboard) and we do not see any advantage of keeping it. Would you have any concern with this decision, please contact us quickly because it will be effective soon. Regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Feb 5 11:42:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 5 Feb 2014 17:42:38 +0100 Subject: [Rtk-users] Fix the issue when use RTK on Nvidia Kepler Architecture based GPU. In-Reply-To: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> References: <7a65d40d.154f5.143aee6b837.Coremail.liupeng_cs@163.com> Message-ID: Dear Peng Liu, Thanks a lot, I have pushed your change right now. Don't hesitate to suggest changes in those flags, I don't think that so many people are familiar with them... Simon On Mon, Jan 20, 2014 at 10:06 AM, ?? wrote: > Hello, > > > > I find an issue when I try to use RTK on a Nvidia Kepler based GPU. > > The CUDA initializing always fails. > > And I can see an exception about _cudaMutexOperation when any CUDA > function is called in debug mode. > > > > Exception at 0x7fefd5f940d, code: 0xe06d7363: C++ exception, flags=0x1 > (execution cannot be continued) (first chance) in > cudart64_50_35!_cudaMutexOperation > > > > > > Following the guide in > > http://docs.nvidia.com/cuda/kepler-compatibility-guide/index.html > > > > This issue can be fixed by applying the patch on RTK code: > > > > > > =========================================================================== > > > > diff --git a/cmake/FindCUDA_wrap.cmake b/cmake/FindCUDA_wrap.cmake > > index e13a7c3..b40c6da 100644 > > --- a/cmake/FindCUDA_wrap.cmake > > +++ b/cmake/FindCUDA_wrap.cmake > > @@ -59,9 +59,19 @@ set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > ) > > > > if(CUDA_VERSION_MAJOR GREATER "2") > > - set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > - -gencode arch=compute_20,code=sm_20 > > - ) > > + IF(${CUDA_VERSION} LESS 5.0) > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_20,code=compute_20 > > + ) > > + ELSE() > > + set (CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} > > + -gencode arch=compute_20,code=sm_20 > > + -gencode arch=compute_30,code=sm_30 > > + -gencode arch=compute_35,code=sm_35 > > + -gencode arch=compute_35,code=compute_35 > > + ) > > + ENDIF() > > endif() > > > > if(CUDA_FOUND) > > > > > ============================================================================ > > > > Regards, > > > > Peng Liu > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 08:26:18 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 14:26:18 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? Message-ID: Hi, First thanks for the hard work on this nice toolkit. I am working on FDK reconstruction. I noticed that the InPlaneRotation seems not to be handled in some situations, such as in the DisplacedDetectorImageFilter, which is explicitly stated in the document. Furthermore, when I went through the FDKConeBeamReconstructionFilter, there seems to be no correction for the in-plane rotation to the projection images before they are send to the FFTRampImageFilter. Thus the filtering seems to be performed along the rows of the projection image but not the true horizontal direction of the projection. Did I miss anything around here? In which steps and to which extent the in-plane rotation has been taken into account? Best regards, Chao TUDelft, NL -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 09:10:10 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 15:10:10 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi, Yes, this is correct. In plane rotations are accounted for during backprojection but not in the FFT ramp filter which is done along lines. It should be modifiable if you want to. The weighting in the projection image should not sensitive to in plane rotation since it uses the distance to the center. How large are your rotations? Simon On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > Hi, > > First thanks for the hard work on this nice toolkit. > > I am working on FDK reconstruction. > I noticed that the InPlaneRotation seems not to be handled in some > situations, such as in the DisplacedDetectorImageFilter, which is > explicitly stated in the document. > Furthermore, when I went through the FDKConeBeamReconstructionFilter, > there seems to be no correction for the in-plane rotation to the projection > images before they are send to the FFTRampImageFilter. Thus the filtering > seems to be performed along the rows of the projection image but not the > true horizontal direction of the projection. > Did I miss anything around here? In which steps and to which extent the > in-plane rotation has been taken into account? > > Best regards, > Chao > > TUDelft, NL > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Feb 14 10:32:57 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 14 Feb 2014 16:32:57 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: Hi Simon, Thanks for the confirmation. The rotation in my projections are less than 0.2 degrees, so the ramp filter along image line or along true horizontal direction may leads to almost identical reconstructions. I got into this subject because I was working with a displaced detector and found dark and bright regions along the axis of rotation at two side of the mid plane when the IPR is set to non-zero. After reading the document I realized that this would be due to that the IPR is not accounted when the weighting [G Wang] is performed, then later it is accounted during the FDK, so that Wang's weight function applied to opposite projections does not sum to 1. Before I make any changes to the DisplacedDetectorImageFilter I would like to see how you dealt with IPR in FDK, and suddenly I found IPR is not accounted for either in the ramp filter which is not 'mathematically correct' (but may be sufficient and efficient in practice). So now I am thinking how to solve the problem. The most straightforward way could be that I perform a pre-correction for IPR in all my displaced-detector projections, and send them to rtkfdk with an IPR=0 geometry, since this can make the behaviour of both DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less workload in coding, of course). Or modify the DisplacedDetectorImageFilter to account for IPR while leave the FFTRampImageFilter as it is. Do you have any other comments and suggestions? Thank you. Best regards, Chao 2014-02-14 15:10 GMT+01:00 Simon Rit : > Hi, > Yes, this is correct. In plane rotations are accounted for during > backprojection but not in the FFT ramp filter which is done along lines. It > should be modifiable if you want to. The weighting in the projection image > should not sensitive to in plane rotation since it uses the distance to the > center. > How large are your rotations? > Simon > > > > On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: > >> Hi, >> >> First thanks for the hard work on this nice toolkit. >> >> I am working on FDK reconstruction. >> I noticed that the InPlaneRotation seems not to be handled in some >> situations, such as in the DisplacedDetectorImageFilter, which is >> explicitly stated in the document. >> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >> there seems to be no correction for the in-plane rotation to the projection >> images before they are send to the FFTRampImageFilter. Thus the filtering >> seems to be performed along the rows of the projection image but not the >> true horizontal direction of the projection. >> Did I miss anything around here? In which steps and to which extent the >> in-plane rotation has been taken into account? >> >> Best regards, >> Chao >> >> TUDelft, NL >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 14 10:56:56 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 14 Feb 2014 16:56:56 +0100 Subject: [Rtk-users] Correction for detector in-plane rotation? In-Reply-To: References: Message-ID: The simplest is indeed to resample to a non-rotated detector. One reason I did not go into the in plane rotation stuff is that I wanted to keep the ramp filter independent of the geometry. But this could be changed if you find it useful, e.g., by adding a filtering direction. The best would be to avoid a resampling and to account for the rotation in each step. If you want to go in this direction, since it is a rather unusual geometry, I would suggest to check that you obtain relevant results for each step. There are command line tools that split rtkfdk in the 3 steps: rtkfdktwodweights, rtkrampfilter and rtkbackprojections. Let me know if I can help. If you develop something, your contribution will be welcomed! Simon On Fri, Feb 14, 2014 at 4:32 PM, Chao Wu wrote: > Hi Simon, > > Thanks for the confirmation. > The rotation in my projections are less than 0.2 degrees, so the ramp > filter along image line or along true horizontal direction may leads to > almost identical reconstructions. > > I got into this subject because I was working with a displaced detector > and found dark and bright regions along the axis of rotation at two side of > the mid plane when the IPR is set to non-zero. > After reading the document I realized that this would be due to that the > IPR is not accounted when the weighting [G Wang] is performed, then later > it is accounted during the FDK, so that Wang's weight function applied to > opposite projections does not sum to 1. Before I make any changes to the > DisplacedDetectorImageFilter I would like to see how you dealt with IPR in > FDK, and suddenly I found IPR is not accounted for either in the ramp > filter which is not 'mathematically correct' (but may be sufficient and > efficient in practice). > > So now I am thinking how to solve the problem. > The most straightforward way could be that I perform a pre-correction for > IPR in all my displaced-detector projections, and send them to rtkfdk with > an IPR=0 geometry, since this can make the behaviour of both > DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less > workload in coding, of course). > Or modify the DisplacedDetectorImageFilter to account for IPR while leave > the FFTRampImageFilter as it is. > Do you have any other comments and suggestions? Thank you. > > Best regards, > Chao > > > > 2014-02-14 15:10 GMT+01:00 Simon Rit : > > Hi, >> Yes, this is correct. In plane rotations are accounted for during >> backprojection but not in the FFT ramp filter which is done along lines. It >> should be modifiable if you want to. The weighting in the projection image >> should not sensitive to in plane rotation since it uses the distance to the >> center. >> How large are your rotations? >> Simon >> >> >> >> On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu wrote: >> >>> Hi, >>> >>> First thanks for the hard work on this nice toolkit. >>> >>> I am working on FDK reconstruction. >>> I noticed that the InPlaneRotation seems not to be handled in some >>> situations, such as in the DisplacedDetectorImageFilter, which is >>> explicitly stated in the document. >>> Furthermore, when I went through the FDKConeBeamReconstructionFilter, >>> there seems to be no correction for the in-plane rotation to the projection >>> images before they are send to the FFTRampImageFilter. Thus the filtering >>> seems to be performed along the rows of the projection image but not the >>> true horizontal direction of the projection. >>> Did I miss anything around here? In which steps and to which extent the >>> in-plane rotation has been taken into account? >>> >>> Best regards, >>> Chao >>> >>> TUDelft, NL >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.champion.13 at ucl.ac.uk Wed Feb 19 12:35:59 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Wed, 19 Feb 2014 17:35:59 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading Message-ID: <5304EB7F.4080601@ucl.ac.uk> Hello, First of all, many thanks to the RTK community for this useful toolkit! While experimenting with different versions of the code (I'm a relatively new user), I've encountered large differences in rtkfdk (CPU) reconstruction speed between code versions (a newer version being substantially slower than an older version). To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the required -g, -p, -r and -o flags, but no other flags). Using git-bisect, I narrowed it down to a particular commit. The parent commit runs quite quickly, but the child commit shows nearly 4x reconstruction time, and less-uniform CPU utilization (it looks like a series of spikes). (See below) Looking at the diffs, it seems that in addition to adding the HannY functionality (which should be disabled by default?), there were some changes in this commit related to threading (in code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is misleading and the substantial difference consists in changing the FFT Ramp Kernel. I'm currently reading the source to try to understand those changes, but I thought I would post in case someone is able to point me in the right direction. Although these differences are unexpected to me, I doubt that they are unexpected to more experienced users...! Apologies if I've left out any critical information (or if I've provided too much!). Many thanks in advance, Ben ****** Parent Commit ****** commit 9df6108ae0293f86b455a2dcd4b35801e4815718 Author: Julien Jomier Date: Fri Nov 30 09:30:59 2012 +0100 ENH: Minimum CMake version is 2.8.3 ***Partial output*** Reconstructing and writing... It took 44.3992 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.67915 s Ramp filter: 26.3847 s Backprojection: 13.0447 s ***Screenshot of CPU usage attached: 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** ****** Child Commit ****** commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 Author: Simon Rit Date: Wed Dec 5 16:22:47 2012 +0100 First version of Hann windowing in the second direction (perpendicular to the ramp) ***Partial output*** Reconstructing and writing... It took 126.911 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.47678 s Ramp filter: 108.254 s Backprojection: 13.2973 s ***Screenshot of CPU usage attached: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** -------------- next part -------------- A non-text attachment was scrubbed... Name: 9df6108ae0293f86b455a2dcd4b35801e4815718.png Type: image/png Size: 80382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: e223a2ed2200bbd7d86966d4eb27319ed589ee00.png Type: image/png Size: 75196 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 20 01:57:02 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 20 Feb 2014 07:57:02 +0100 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: <5304EB7F.4080601@ucl.ac.uk> References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: Hi, Thank you Ben for the amazing report. I can spot a few things that could have gone wrong there but it seems to me that your reconstruction is slow both before and after the commit... Two potential reasons: - you have not activated FFTW in ITK. You should definitely do that, the FFT of ITK is (very) slow and probably not multithreaded. You must turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent version of ITK4, I had some issues with the first versions, see http://www.itk.org/pipermail/insight-users/2013-April/047562.html - you are using a huge dataset. If you did not use FFTW, could you try again with FFTW and tell us if you still observe a drop in performances? If you had FFTW, can you provide the sie of the dataset you used? Thanks, Simon On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion wrote: > Hello, > > First of all, many thanks to the RTK community for this useful toolkit! > > While experimenting with different versions of the code (I'm a relatively > new user), I've encountered large differences in rtkfdk (CPU) reconstruction > speed between code versions (a newer version being substantially slower than > an older version). > > To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the > required -g, -p, -r and -o flags, but no other flags). > > Using git-bisect, I narrowed it down to a particular commit. The parent > commit runs quite quickly, but the child commit shows nearly 4x > reconstruction time, and less-uniform CPU utilization (it looks like a > series of spikes). > > (See below) > > Looking at the diffs, it seems that in addition to adding the HannY > functionality (which should be disabled by default?), there were some > changes in this commit related to threading (in > code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is > misleading and the substantial difference consists in changing the FFT Ramp > Kernel. > > I'm currently reading the source to try to understand those changes, but I > thought I would post in case someone is able to point me in the right > direction. Although these differences are unexpected to me, I doubt that > they are unexpected to more experienced users...! > > Apologies if I've left out any critical information (or if I've provided too > much!). > > Many thanks in advance, > Ben > > ****** Parent Commit ****** > commit 9df6108ae0293f86b455a2dcd4b35801e4815718 > Author: Julien Jomier > Date: Fri Nov 30 09:30:59 2012 +0100 > > ENH: Minimum CMake version is 2.8.3 > > ***Partial output*** > > Reconstructing and writing... It took 44.3992 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.67915 s > Ramp filter: 26.3847 s > Backprojection: 13.0447 s > > ***Screenshot of CPU usage attached: > 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** > > ****** Child Commit ****** > commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 > Author: Simon Rit > Date: Wed Dec 5 16:22:47 2012 +0100 > > First version of Hann windowing in the second direction (perpendicular > to the ramp) > > ***Partial output*** > Reconstructing and writing... It took 126.911 s > FDKConeBeamReconstructionFilter timing: > Prefilter operations: 2.47678 s > Ramp filter: 108.254 s > Backprojection: 13.2973 s > > ***Screenshot of CPU usage attached: > e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From benjamin.champion.13 at ucl.ac.uk Thu Feb 20 06:20:35 2014 From: benjamin.champion.13 at ucl.ac.uk (Ben Champion) Date: Thu, 20 Feb 2014 11:20:35 +0000 Subject: [Rtk-users] Difference in rtkfdk (cpu) speed/threading In-Reply-To: References: <5304EB7F.4080601@ucl.ac.uk> Message-ID: <5305E503.3000506@ucl.ac.uk> Hi Simon, Really appreciate your prompt response! Indeed, I was not using FFTW. After rebuilding ITK with FFTW, I get faster reconstructions, and the time increase between the two commits reduces to a little over 2x (See below). My dataset consists of 344 projections (about 172.0 MB) Does this sound about right? The CPU utilization still looks a bit like a series of spikes for the latter commit (but different than before). Reconstructing and writing... It took 36.0746 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.59479 s Ramp filter: 19.3106 s Backprojection: 13.8042 s ***versus*** Reconstructing and writing... It took 83.4121 s FDKConeBeamReconstructionFilter timing: Prefilter operations: 2.62535 s Ramp filter: 66.5537 s Backprojection: 13.8829 s Thanks again, Ben On 20/02/14 06:57, Simon Rit wrote: > Hi, > Thank you Ben for the amazing report. I can spot a few things that > could have gone wrong there but it seems to me that your > reconstruction is slow both before and after the commit... Two > potential reasons: > - you have not activated FFTW in ITK. You should definitely do that, > the FFT of ITK is (very) slow and probably not multithreaded. You must > turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent > version of ITK4, I had some issues with the first versions, see > http://www.itk.org/pipermail/insight-users/2013-April/047562.html > - you are using a huge dataset. > If you did not use FFTW, could you try again with FFTW and tell us if > you still observe a drop in performances? If you had FFTW, can you > provide the sie of the dataset you used? > Thanks, > Simon > > On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion > wrote: >> Hello, >> >> First of all, many thanks to the RTK community for this useful toolkit! >> >> While experimenting with different versions of the code (I'm a relatively >> new user), I've encountered large differences in rtkfdk (CPU) reconstruction >> speed between code versions (a newer version being substantially slower than >> an older version). >> >> To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the >> required -g, -p, -r and -o flags, but no other flags). >> >> Using git-bisect, I narrowed it down to a particular commit. The parent >> commit runs quite quickly, but the child commit shows nearly 4x >> reconstruction time, and less-uniform CPU utilization (it looks like a >> series of spikes). >> >> (See below) >> >> Looking at the diffs, it seems that in addition to adding the HannY >> functionality (which should be disabled by default?), there were some >> changes in this commit related to threading (in >> code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is >> misleading and the substantial difference consists in changing the FFT Ramp >> Kernel. >> >> I'm currently reading the source to try to understand those changes, but I >> thought I would post in case someone is able to point me in the right >> direction. Although these differences are unexpected to me, I doubt that >> they are unexpected to more experienced users...! >> >> Apologies if I've left out any critical information (or if I've provided too >> much!). >> >> Many thanks in advance, >> Ben >> >> ****** Parent Commit ****** >> commit 9df6108ae0293f86b455a2dcd4b35801e4815718 >> Author: Julien Jomier >> Date: Fri Nov 30 09:30:59 2012 +0100 >> >> ENH: Minimum CMake version is 2.8.3 >> >> ***Partial output*** >> >> Reconstructing and writing... It took 44.3992 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.67915 s >> Ramp filter: 26.3847 s >> Backprojection: 13.0447 s >> >> ***Screenshot of CPU usage attached: >> 9df6108ae0293f86b455a2dcd4b35801e4815718.png *** >> >> ****** Child Commit ****** >> commit e223a2ed2200bbd7d86966d4eb27319ed589ee00 >> Author: Simon Rit >> Date: Wed Dec 5 16:22:47 2012 +0100 >> >> First version of Hann windowing in the second direction (perpendicular >> to the ramp) >> >> ***Partial output*** >> Reconstructing and writing... It took 126.911 s >> FDKConeBeamReconstructionFilter timing: >> Prefilter operations: 2.47678 s >> Ramp filter: 108.254 s >> Backprojection: 13.2973 s >> >> ***Screenshot of CPU usage attached: >> e223a2ed2200bbd7d86966d4eb27319ed589ee00.png*** >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >>