From jean.hoskovec at gmail.com Wed Dec 18 08:39:32 2013 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Wed, 18 Dec 2013 14:39:32 +0100 Subject: [Rtk-users] CUDA linking problem Message-ID: Hello, I have recently encountered a linking error while recompiling RTK on a Linux 64bit machine with CUDA 5.5 and GCC 4.7. The output was as follows: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: could not read symbols: Bad value The error message speaks about the -fPIC option, but this was only half the solution. After searchnig devtalk.nvidia.com, I found a solution which worked smoothly for me: During configuration, add -Xcompiler -fPIC to your NVCC flags. After that, the compilation worked just fine again. I hope this can be helpful for someone having run into the same problem as I did. Best regards, Jan From andreas.staude at bam.de Fri Dec 20 09:10:18 2013 From: andreas.staude at bam.de (Staude, Andreas) Date: Fri, 20 Dec 2013 14:10:18 +0000 Subject: [Rtk-users] Result from SART is worse than from FDK In-Reply-To: References: <527914C3.8030706@bam.de> <527918B5.9080709@bam.de> Message-ID: <52B44FCA.7000800@bam.de> Hi Simon, I believe it really is a problem with the sum of the weights. I first tried with the Shepp-Logan-phantom and afterwards with my data. The geometry is that of a standard cone-beam micro-CT. The data I posted before were the reconstruction of just the middle plane. As I did the same with the Shepp-Logan-phantom data, similar effects were seen. As soon as one reconstructs a larger region around the middle plane, the artefacts vanish in the inner parts of the reconstructed volume, while in the top and bottom parts artefacts remain. The program calls were: create geometry: ---------------- rtksimulatedgeometry --nproj="1200" --output="geometry.xml" --sdd="1169.59" --sid="451.645" --arc="-360" --first_angle="360" project the phantom: -------------------- rtkprojectgeometricphantom -g geometry.xml -o projections3.mha --spacing 2.5 --dimension 256 --phantomfile SheppLogan.txt do a reference FDK reconstruction: ---------------------------------- rtkfdk -p . -r projections3.mha -o shepp-logan_fdk3_3D.mha -g geometry.xml --spacing 1 --dimension 256 SART reconstruction of middle plane: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_2D.mha -g geometry.xml --spacing 1 --dimension 256,1,256 SART reconstruction of 10 planes around middle plane: ------------------------------------------------------- rtksart -p . -r projections3.mha -o shepp-logan_sart3_2.5D.mha -g geometry.xml --spacing 1 --dimension 256,10,256 SART reconstruction of whole object: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_3D.mha -g geometry.xml --spacing 1 --dimension 256 Reconstruction of more slices of the real data-set also gave a good result. Only the slices near bottom and top are not reconstructed correctly. So it seems that the normalisation does not only take the values inside the reconstructed volume into account, but also (wrong) values outside. What do you think? Cheers, Andreas On 11/05/2013 07:11 PM, Simon Rit wrote: > Hi Andreas, > Thanks for the report. We know that the implementation of SART is > imperfect, we haven't been working a lot on it... It seems that you > haven't reached convergence. One potential cause is that we use a > heuristic for the sum of the weights (denominator in the SART formula) > instead of the exact sum. The weight is constant and equals the > diagonal of your volume (see line 165 in > rtkSARTConeBeamReconstructionFilter.txx). Maybe this is completely > wrong in your case. Could you try to increase lambda to see if that > helps? > To help us do some tests, I would advise you do reproduce your > geometry with simulations of the Shepp Logan phantom (see > wiki.openrtk.org). > Simon > > On Tue, Nov 5, 2013 at 5:11 PM, Staude, Andreas wrote: >> Hello RTk-users, >> >> I try to use the SART algorithm, but the results are worse than those >> obtained with FDK (see attached images). >> >> The FDK result looks like expected, so I assume that I have the data >> format and the reconstruction geometry set properly. For SART I used the >> same parameters and already tried with different values of lambda and >> niterations. >> >> Does anyone have an idea what went wrong? Is there some kind of >> smoothing or regularisation applied in the SART implementation? >> >> Many thanks in advance! >> >> Cheers, >> >> Andreas >> >> >> -- >> >> =============================================================== >> Dr. Andreas Staude >> Fachbereich 8.5 "Mikro-ZfP", Computertomographie >> BAM Bundesanstalt f?r Materialforschung und -pr?fung >> Unter den Eichen 87 >> D-12205 Berlin >> Germany >> >> Tel.: ++49 30 8104 4140 >> Fax: ++49 30 8104 1837 >> =============================================================== >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> -- =============================================================== Dr. Andreas Staude Fachbereich 8.5 "Mikro-ZfP", Computertomographie BAM Bundesanstalt f?r Materialforschung und -pr?fung Unter den Eichen 87 D-12205 Berlin Germany Tel.: ++49 30 8104 4140 Fax: ++49 30 8104 1837 =============================================================== From jean.hoskovec at gmail.com Wed Dec 18 08:39:32 2013 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Wed, 18 Dec 2013 14:39:32 +0100 Subject: [Rtk-users] CUDA linking problem Message-ID: Hello, I have recently encountered a linking error while recompiling RTK on a Linux 64bit machine with CUDA 5.5 and GCC 4.7. The output was as follows: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: could not read symbols: Bad value The error message speaks about the -fPIC option, but this was only half the solution. After searchnig devtalk.nvidia.com, I found a solution which worked smoothly for me: During configuration, add -Xcompiler -fPIC to your NVCC flags. After that, the compilation worked just fine again. I hope this can be helpful for someone having run into the same problem as I did. Best regards, Jan From andreas.staude at bam.de Fri Dec 20 09:10:18 2013 From: andreas.staude at bam.de (Staude, Andreas) Date: Fri, 20 Dec 2013 14:10:18 +0000 Subject: [Rtk-users] Result from SART is worse than from FDK In-Reply-To: References: <527914C3.8030706@bam.de> <527918B5.9080709@bam.de> Message-ID: <52B44FCA.7000800@bam.de> Hi Simon, I believe it really is a problem with the sum of the weights. I first tried with the Shepp-Logan-phantom and afterwards with my data. The geometry is that of a standard cone-beam micro-CT. The data I posted before were the reconstruction of just the middle plane. As I did the same with the Shepp-Logan-phantom data, similar effects were seen. As soon as one reconstructs a larger region around the middle plane, the artefacts vanish in the inner parts of the reconstructed volume, while in the top and bottom parts artefacts remain. The program calls were: create geometry: ---------------- rtksimulatedgeometry --nproj="1200" --output="geometry.xml" --sdd="1169.59" --sid="451.645" --arc="-360" --first_angle="360" project the phantom: -------------------- rtkprojectgeometricphantom -g geometry.xml -o projections3.mha --spacing 2.5 --dimension 256 --phantomfile SheppLogan.txt do a reference FDK reconstruction: ---------------------------------- rtkfdk -p . -r projections3.mha -o shepp-logan_fdk3_3D.mha -g geometry.xml --spacing 1 --dimension 256 SART reconstruction of middle plane: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_2D.mha -g geometry.xml --spacing 1 --dimension 256,1,256 SART reconstruction of 10 planes around middle plane: ------------------------------------------------------- rtksart -p . -r projections3.mha -o shepp-logan_sart3_2.5D.mha -g geometry.xml --spacing 1 --dimension 256,10,256 SART reconstruction of whole object: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_3D.mha -g geometry.xml --spacing 1 --dimension 256 Reconstruction of more slices of the real data-set also gave a good result. Only the slices near bottom and top are not reconstructed correctly. So it seems that the normalisation does not only take the values inside the reconstructed volume into account, but also (wrong) values outside. What do you think? Cheers, Andreas On 11/05/2013 07:11 PM, Simon Rit wrote: > Hi Andreas, > Thanks for the report. We know that the implementation of SART is > imperfect, we haven't been working a lot on it... It seems that you > haven't reached convergence. One potential cause is that we use a > heuristic for the sum of the weights (denominator in the SART formula) > instead of the exact sum. The weight is constant and equals the > diagonal of your volume (see line 165 in > rtkSARTConeBeamReconstructionFilter.txx). Maybe this is completely > wrong in your case. Could you try to increase lambda to see if that > helps? > To help us do some tests, I would advise you do reproduce your > geometry with simulations of the Shepp Logan phantom (see > wiki.openrtk.org). > Simon > > On Tue, Nov 5, 2013 at 5:11 PM, Staude, Andreas wrote: >> Hello RTk-users, >> >> I try to use the SART algorithm, but the results are worse than those >> obtained with FDK (see attached images). >> >> The FDK result looks like expected, so I assume that I have the data >> format and the reconstruction geometry set properly. For SART I used the >> same parameters and already tried with different values of lambda and >> niterations. >> >> Does anyone have an idea what went wrong? Is there some kind of >> smoothing or regularisation applied in the SART implementation? >> >> Many thanks in advance! >> >> Cheers, >> >> Andreas >> >> >> -- >> >> =============================================================== >> Dr. Andreas Staude >> Fachbereich 8.5 "Mikro-ZfP", Computertomographie >> BAM Bundesanstalt f?r Materialforschung und -pr?fung >> Unter den Eichen 87 >> D-12205 Berlin >> Germany >> >> Tel.: ++49 30 8104 4140 >> Fax: ++49 30 8104 1837 >> =============================================================== >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> -- =============================================================== Dr. Andreas Staude Fachbereich 8.5 "Mikro-ZfP", Computertomographie BAM Bundesanstalt f?r Materialforschung und -pr?fung Unter den Eichen 87 D-12205 Berlin Germany Tel.: ++49 30 8104 4140 Fax: ++49 30 8104 1837 =============================================================== From jean.hoskovec at gmail.com Wed Dec 18 08:39:32 2013 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Wed, 18 Dec 2013 14:39:32 +0100 Subject: [Rtk-users] CUDA linking problem Message-ID: Hello, I have recently encountered a linking error while recompiling RTK on a Linux 64bit machine with CUDA 5.5 and GCC 4.7. The output was as follows: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: could not read symbols: Bad value The error message speaks about the -fPIC option, but this was only half the solution. After searchnig devtalk.nvidia.com, I found a solution which worked smoothly for me: During configuration, add -Xcompiler -fPIC to your NVCC flags. After that, the compilation worked just fine again. I hope this can be helpful for someone having run into the same problem as I did. Best regards, Jan From andreas.staude at bam.de Fri Dec 20 09:10:18 2013 From: andreas.staude at bam.de (Staude, Andreas) Date: Fri, 20 Dec 2013 14:10:18 +0000 Subject: [Rtk-users] Result from SART is worse than from FDK In-Reply-To: References: <527914C3.8030706@bam.de> <527918B5.9080709@bam.de> Message-ID: <52B44FCA.7000800@bam.de> Hi Simon, I believe it really is a problem with the sum of the weights. I first tried with the Shepp-Logan-phantom and afterwards with my data. The geometry is that of a standard cone-beam micro-CT. The data I posted before were the reconstruction of just the middle plane. As I did the same with the Shepp-Logan-phantom data, similar effects were seen. As soon as one reconstructs a larger region around the middle plane, the artefacts vanish in the inner parts of the reconstructed volume, while in the top and bottom parts artefacts remain. The program calls were: create geometry: ---------------- rtksimulatedgeometry --nproj="1200" --output="geometry.xml" --sdd="1169.59" --sid="451.645" --arc="-360" --first_angle="360" project the phantom: -------------------- rtkprojectgeometricphantom -g geometry.xml -o projections3.mha --spacing 2.5 --dimension 256 --phantomfile SheppLogan.txt do a reference FDK reconstruction: ---------------------------------- rtkfdk -p . -r projections3.mha -o shepp-logan_fdk3_3D.mha -g geometry.xml --spacing 1 --dimension 256 SART reconstruction of middle plane: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_2D.mha -g geometry.xml --spacing 1 --dimension 256,1,256 SART reconstruction of 10 planes around middle plane: ------------------------------------------------------- rtksart -p . -r projections3.mha -o shepp-logan_sart3_2.5D.mha -g geometry.xml --spacing 1 --dimension 256,10,256 SART reconstruction of whole object: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_3D.mha -g geometry.xml --spacing 1 --dimension 256 Reconstruction of more slices of the real data-set also gave a good result. Only the slices near bottom and top are not reconstructed correctly. So it seems that the normalisation does not only take the values inside the reconstructed volume into account, but also (wrong) values outside. What do you think? Cheers, Andreas On 11/05/2013 07:11 PM, Simon Rit wrote: > Hi Andreas, > Thanks for the report. We know that the implementation of SART is > imperfect, we haven't been working a lot on it... It seems that you > haven't reached convergence. One potential cause is that we use a > heuristic for the sum of the weights (denominator in the SART formula) > instead of the exact sum. The weight is constant and equals the > diagonal of your volume (see line 165 in > rtkSARTConeBeamReconstructionFilter.txx). Maybe this is completely > wrong in your case. Could you try to increase lambda to see if that > helps? > To help us do some tests, I would advise you do reproduce your > geometry with simulations of the Shepp Logan phantom (see > wiki.openrtk.org). > Simon > > On Tue, Nov 5, 2013 at 5:11 PM, Staude, Andreas wrote: >> Hello RTk-users, >> >> I try to use the SART algorithm, but the results are worse than those >> obtained with FDK (see attached images). >> >> The FDK result looks like expected, so I assume that I have the data >> format and the reconstruction geometry set properly. For SART I used the >> same parameters and already tried with different values of lambda and >> niterations. >> >> Does anyone have an idea what went wrong? Is there some kind of >> smoothing or regularisation applied in the SART implementation? >> >> Many thanks in advance! >> >> Cheers, >> >> Andreas >> >> >> -- >> >> =============================================================== >> Dr. Andreas Staude >> Fachbereich 8.5 "Mikro-ZfP", Computertomographie >> BAM Bundesanstalt f?r Materialforschung und -pr?fung >> Unter den Eichen 87 >> D-12205 Berlin >> Germany >> >> Tel.: ++49 30 8104 4140 >> Fax: ++49 30 8104 1837 >> =============================================================== >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> -- =============================================================== Dr. Andreas Staude Fachbereich 8.5 "Mikro-ZfP", Computertomographie BAM Bundesanstalt f?r Materialforschung und -pr?fung Unter den Eichen 87 D-12205 Berlin Germany Tel.: ++49 30 8104 4140 Fax: ++49 30 8104 1837 =============================================================== From jean.hoskovec at gmail.com Wed Dec 18 08:39:32 2013 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Wed, 18 Dec 2013 14:39:32 +0100 Subject: [Rtk-users] CUDA linking problem Message-ID: Hello, I have recently encountered a linking error while recompiling RTK on a Linux 64bit machine with CUDA 5.5 and GCC 4.7. The output was as follows: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: could not read symbols: Bad value The error message speaks about the -fPIC option, but this was only half the solution. After searchnig devtalk.nvidia.com, I found a solution which worked smoothly for me: During configuration, add -Xcompiler -fPIC to your NVCC flags. After that, the compilation worked just fine again. I hope this can be helpful for someone having run into the same problem as I did. Best regards, Jan From andreas.staude at bam.de Fri Dec 20 09:10:18 2013 From: andreas.staude at bam.de (Staude, Andreas) Date: Fri, 20 Dec 2013 14:10:18 +0000 Subject: [Rtk-users] Result from SART is worse than from FDK In-Reply-To: References: <527914C3.8030706@bam.de> <527918B5.9080709@bam.de> Message-ID: <52B44FCA.7000800@bam.de> Hi Simon, I believe it really is a problem with the sum of the weights. I first tried with the Shepp-Logan-phantom and afterwards with my data. The geometry is that of a standard cone-beam micro-CT. The data I posted before were the reconstruction of just the middle plane. As I did the same with the Shepp-Logan-phantom data, similar effects were seen. As soon as one reconstructs a larger region around the middle plane, the artefacts vanish in the inner parts of the reconstructed volume, while in the top and bottom parts artefacts remain. The program calls were: create geometry: ---------------- rtksimulatedgeometry --nproj="1200" --output="geometry.xml" --sdd="1169.59" --sid="451.645" --arc="-360" --first_angle="360" project the phantom: -------------------- rtkprojectgeometricphantom -g geometry.xml -o projections3.mha --spacing 2.5 --dimension 256 --phantomfile SheppLogan.txt do a reference FDK reconstruction: ---------------------------------- rtkfdk -p . -r projections3.mha -o shepp-logan_fdk3_3D.mha -g geometry.xml --spacing 1 --dimension 256 SART reconstruction of middle plane: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_2D.mha -g geometry.xml --spacing 1 --dimension 256,1,256 SART reconstruction of 10 planes around middle plane: ------------------------------------------------------- rtksart -p . -r projections3.mha -o shepp-logan_sart3_2.5D.mha -g geometry.xml --spacing 1 --dimension 256,10,256 SART reconstruction of whole object: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_3D.mha -g geometry.xml --spacing 1 --dimension 256 Reconstruction of more slices of the real data-set also gave a good result. Only the slices near bottom and top are not reconstructed correctly. So it seems that the normalisation does not only take the values inside the reconstructed volume into account, but also (wrong) values outside. What do you think? Cheers, Andreas On 11/05/2013 07:11 PM, Simon Rit wrote: > Hi Andreas, > Thanks for the report. We know that the implementation of SART is > imperfect, we haven't been working a lot on it... It seems that you > haven't reached convergence. One potential cause is that we use a > heuristic for the sum of the weights (denominator in the SART formula) > instead of the exact sum. The weight is constant and equals the > diagonal of your volume (see line 165 in > rtkSARTConeBeamReconstructionFilter.txx). Maybe this is completely > wrong in your case. Could you try to increase lambda to see if that > helps? > To help us do some tests, I would advise you do reproduce your > geometry with simulations of the Shepp Logan phantom (see > wiki.openrtk.org). > Simon > > On Tue, Nov 5, 2013 at 5:11 PM, Staude, Andreas wrote: >> Hello RTk-users, >> >> I try to use the SART algorithm, but the results are worse than those >> obtained with FDK (see attached images). >> >> The FDK result looks like expected, so I assume that I have the data >> format and the reconstruction geometry set properly. For SART I used the >> same parameters and already tried with different values of lambda and >> niterations. >> >> Does anyone have an idea what went wrong? Is there some kind of >> smoothing or regularisation applied in the SART implementation? >> >> Many thanks in advance! >> >> Cheers, >> >> Andreas >> >> >> -- >> >> =============================================================== >> Dr. Andreas Staude >> Fachbereich 8.5 "Mikro-ZfP", Computertomographie >> BAM Bundesanstalt f?r Materialforschung und -pr?fung >> Unter den Eichen 87 >> D-12205 Berlin >> Germany >> >> Tel.: ++49 30 8104 4140 >> Fax: ++49 30 8104 1837 >> =============================================================== >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> -- =============================================================== Dr. Andreas Staude Fachbereich 8.5 "Mikro-ZfP", Computertomographie BAM Bundesanstalt f?r Materialforschung und -pr?fung Unter den Eichen 87 D-12205 Berlin Germany Tel.: ++49 30 8104 4140 Fax: ++49 30 8104 1837 =============================================================== From jean.hoskovec at gmail.com Wed Dec 18 08:39:32 2013 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Wed, 18 Dec 2013 14:39:32 +0100 Subject: [Rtk-users] CUDA linking problem Message-ID: Hello, I have recently encountered a linking error while recompiling RTK on a Linux 64bit machine with CUDA 5.5 and GCC 4.7. The output was as follows: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: could not read symbols: Bad value The error message speaks about the -fPIC option, but this was only half the solution. After searchnig devtalk.nvidia.com, I found a solution which worked smoothly for me: During configuration, add -Xcompiler -fPIC to your NVCC flags. After that, the compilation worked just fine again. I hope this can be helpful for someone having run into the same problem as I did. Best regards, Jan From andreas.staude at bam.de Fri Dec 20 09:10:18 2013 From: andreas.staude at bam.de (Staude, Andreas) Date: Fri, 20 Dec 2013 14:10:18 +0000 Subject: [Rtk-users] Result from SART is worse than from FDK In-Reply-To: References: <527914C3.8030706@bam.de> <527918B5.9080709@bam.de> Message-ID: <52B44FCA.7000800@bam.de> Hi Simon, I believe it really is a problem with the sum of the weights. I first tried with the Shepp-Logan-phantom and afterwards with my data. The geometry is that of a standard cone-beam micro-CT. The data I posted before were the reconstruction of just the middle plane. As I did the same with the Shepp-Logan-phantom data, similar effects were seen. As soon as one reconstructs a larger region around the middle plane, the artefacts vanish in the inner parts of the reconstructed volume, while in the top and bottom parts artefacts remain. The program calls were: create geometry: ---------------- rtksimulatedgeometry --nproj="1200" --output="geometry.xml" --sdd="1169.59" --sid="451.645" --arc="-360" --first_angle="360" project the phantom: -------------------- rtkprojectgeometricphantom -g geometry.xml -o projections3.mha --spacing 2.5 --dimension 256 --phantomfile SheppLogan.txt do a reference FDK reconstruction: ---------------------------------- rtkfdk -p . -r projections3.mha -o shepp-logan_fdk3_3D.mha -g geometry.xml --spacing 1 --dimension 256 SART reconstruction of middle plane: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_2D.mha -g geometry.xml --spacing 1 --dimension 256,1,256 SART reconstruction of 10 planes around middle plane: ------------------------------------------------------- rtksart -p . -r projections3.mha -o shepp-logan_sart3_2.5D.mha -g geometry.xml --spacing 1 --dimension 256,10,256 SART reconstruction of whole object: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_3D.mha -g geometry.xml --spacing 1 --dimension 256 Reconstruction of more slices of the real data-set also gave a good result. Only the slices near bottom and top are not reconstructed correctly. So it seems that the normalisation does not only take the values inside the reconstructed volume into account, but also (wrong) values outside. What do you think? Cheers, Andreas On 11/05/2013 07:11 PM, Simon Rit wrote: > Hi Andreas, > Thanks for the report. We know that the implementation of SART is > imperfect, we haven't been working a lot on it... It seems that you > haven't reached convergence. One potential cause is that we use a > heuristic for the sum of the weights (denominator in the SART formula) > instead of the exact sum. The weight is constant and equals the > diagonal of your volume (see line 165 in > rtkSARTConeBeamReconstructionFilter.txx). Maybe this is completely > wrong in your case. Could you try to increase lambda to see if that > helps? > To help us do some tests, I would advise you do reproduce your > geometry with simulations of the Shepp Logan phantom (see > wiki.openrtk.org). > Simon > > On Tue, Nov 5, 2013 at 5:11 PM, Staude, Andreas wrote: >> Hello RTk-users, >> >> I try to use the SART algorithm, but the results are worse than those >> obtained with FDK (see attached images). >> >> The FDK result looks like expected, so I assume that I have the data >> format and the reconstruction geometry set properly. For SART I used the >> same parameters and already tried with different values of lambda and >> niterations. >> >> Does anyone have an idea what went wrong? Is there some kind of >> smoothing or regularisation applied in the SART implementation? >> >> Many thanks in advance! >> >> Cheers, >> >> Andreas >> >> >> -- >> >> =============================================================== >> Dr. Andreas Staude >> Fachbereich 8.5 "Mikro-ZfP", Computertomographie >> BAM Bundesanstalt f?r Materialforschung und -pr?fung >> Unter den Eichen 87 >> D-12205 Berlin >> Germany >> >> Tel.: ++49 30 8104 4140 >> Fax: ++49 30 8104 1837 >> =============================================================== >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> -- =============================================================== Dr. Andreas Staude Fachbereich 8.5 "Mikro-ZfP", Computertomographie BAM Bundesanstalt f?r Materialforschung und -pr?fung Unter den Eichen 87 D-12205 Berlin Germany Tel.: ++49 30 8104 4140 Fax: ++49 30 8104 1837 =============================================================== From jean.hoskovec at gmail.com Wed Dec 18 08:39:32 2013 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Wed, 18 Dec 2013 14:39:32 +0100 Subject: [Rtk-users] CUDA linking problem Message-ID: Hello, I have recently encountered a linking error while recompiling RTK on a Linux 64bit machine with CUDA 5.5 and GCC 4.7. The output was as follows: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: could not read symbols: Bad value The error message speaks about the -fPIC option, but this was only half the solution. After searchnig devtalk.nvidia.com, I found a solution which worked smoothly for me: During configuration, add -Xcompiler -fPIC to your NVCC flags. After that, the compilation worked just fine again. I hope this can be helpful for someone having run into the same problem as I did. Best regards, Jan From andreas.staude at bam.de Fri Dec 20 09:10:18 2013 From: andreas.staude at bam.de (Staude, Andreas) Date: Fri, 20 Dec 2013 14:10:18 +0000 Subject: [Rtk-users] Result from SART is worse than from FDK In-Reply-To: References: <527914C3.8030706@bam.de> <527918B5.9080709@bam.de> Message-ID: <52B44FCA.7000800@bam.de> Hi Simon, I believe it really is a problem with the sum of the weights. I first tried with the Shepp-Logan-phantom and afterwards with my data. The geometry is that of a standard cone-beam micro-CT. The data I posted before were the reconstruction of just the middle plane. As I did the same with the Shepp-Logan-phantom data, similar effects were seen. As soon as one reconstructs a larger region around the middle plane, the artefacts vanish in the inner parts of the reconstructed volume, while in the top and bottom parts artefacts remain. The program calls were: create geometry: ---------------- rtksimulatedgeometry --nproj="1200" --output="geometry.xml" --sdd="1169.59" --sid="451.645" --arc="-360" --first_angle="360" project the phantom: -------------------- rtkprojectgeometricphantom -g geometry.xml -o projections3.mha --spacing 2.5 --dimension 256 --phantomfile SheppLogan.txt do a reference FDK reconstruction: ---------------------------------- rtkfdk -p . -r projections3.mha -o shepp-logan_fdk3_3D.mha -g geometry.xml --spacing 1 --dimension 256 SART reconstruction of middle plane: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_2D.mha -g geometry.xml --spacing 1 --dimension 256,1,256 SART reconstruction of 10 planes around middle plane: ------------------------------------------------------- rtksart -p . -r projections3.mha -o shepp-logan_sart3_2.5D.mha -g geometry.xml --spacing 1 --dimension 256,10,256 SART reconstruction of whole object: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_3D.mha -g geometry.xml --spacing 1 --dimension 256 Reconstruction of more slices of the real data-set also gave a good result. Only the slices near bottom and top are not reconstructed correctly. So it seems that the normalisation does not only take the values inside the reconstructed volume into account, but also (wrong) values outside. What do you think? Cheers, Andreas On 11/05/2013 07:11 PM, Simon Rit wrote: > Hi Andreas, > Thanks for the report. We know that the implementation of SART is > imperfect, we haven't been working a lot on it... It seems that you > haven't reached convergence. One potential cause is that we use a > heuristic for the sum of the weights (denominator in the SART formula) > instead of the exact sum. The weight is constant and equals the > diagonal of your volume (see line 165 in > rtkSARTConeBeamReconstructionFilter.txx). Maybe this is completely > wrong in your case. Could you try to increase lambda to see if that > helps? > To help us do some tests, I would advise you do reproduce your > geometry with simulations of the Shepp Logan phantom (see > wiki.openrtk.org). > Simon > > On Tue, Nov 5, 2013 at 5:11 PM, Staude, Andreas wrote: >> Hello RTk-users, >> >> I try to use the SART algorithm, but the results are worse than those >> obtained with FDK (see attached images). >> >> The FDK result looks like expected, so I assume that I have the data >> format and the reconstruction geometry set properly. For SART I used the >> same parameters and already tried with different values of lambda and >> niterations. >> >> Does anyone have an idea what went wrong? Is there some kind of >> smoothing or regularisation applied in the SART implementation? >> >> Many thanks in advance! >> >> Cheers, >> >> Andreas >> >> >> -- >> >> =============================================================== >> Dr. Andreas Staude >> Fachbereich 8.5 "Mikro-ZfP", Computertomographie >> BAM Bundesanstalt f?r Materialforschung und -pr?fung >> Unter den Eichen 87 >> D-12205 Berlin >> Germany >> >> Tel.: ++49 30 8104 4140 >> Fax: ++49 30 8104 1837 >> =============================================================== >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> -- =============================================================== Dr. Andreas Staude Fachbereich 8.5 "Mikro-ZfP", Computertomographie BAM Bundesanstalt f?r Materialforschung und -pr?fung Unter den Eichen 87 D-12205 Berlin Germany Tel.: ++49 30 8104 4140 Fax: ++49 30 8104 1837 =============================================================== From jean.hoskovec at gmail.com Wed Dec 18 08:39:32 2013 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Wed, 18 Dec 2013 14:39:32 +0100 Subject: [Rtk-users] CUDA linking problem Message-ID: Hello, I have recently encountered a linking error while recompiling RTK on a Linux 64bit machine with CUDA 5.5 and GCC 4.7. The output was as follows: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: could not read symbols: Bad value The error message speaks about the -fPIC option, but this was only half the solution. After searchnig devtalk.nvidia.com, I found a solution which worked smoothly for me: During configuration, add -Xcompiler -fPIC to your NVCC flags. After that, the compilation worked just fine again. I hope this can be helpful for someone having run into the same problem as I did. Best regards, Jan From andreas.staude at bam.de Fri Dec 20 09:10:18 2013 From: andreas.staude at bam.de (Staude, Andreas) Date: Fri, 20 Dec 2013 14:10:18 +0000 Subject: [Rtk-users] Result from SART is worse than from FDK In-Reply-To: References: <527914C3.8030706@bam.de> <527918B5.9080709@bam.de> Message-ID: <52B44FCA.7000800@bam.de> Hi Simon, I believe it really is a problem with the sum of the weights. I first tried with the Shepp-Logan-phantom and afterwards with my data. The geometry is that of a standard cone-beam micro-CT. The data I posted before were the reconstruction of just the middle plane. As I did the same with the Shepp-Logan-phantom data, similar effects were seen. As soon as one reconstructs a larger region around the middle plane, the artefacts vanish in the inner parts of the reconstructed volume, while in the top and bottom parts artefacts remain. The program calls were: create geometry: ---------------- rtksimulatedgeometry --nproj="1200" --output="geometry.xml" --sdd="1169.59" --sid="451.645" --arc="-360" --first_angle="360" project the phantom: -------------------- rtkprojectgeometricphantom -g geometry.xml -o projections3.mha --spacing 2.5 --dimension 256 --phantomfile SheppLogan.txt do a reference FDK reconstruction: ---------------------------------- rtkfdk -p . -r projections3.mha -o shepp-logan_fdk3_3D.mha -g geometry.xml --spacing 1 --dimension 256 SART reconstruction of middle plane: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_2D.mha -g geometry.xml --spacing 1 --dimension 256,1,256 SART reconstruction of 10 planes around middle plane: ------------------------------------------------------- rtksart -p . -r projections3.mha -o shepp-logan_sart3_2.5D.mha -g geometry.xml --spacing 1 --dimension 256,10,256 SART reconstruction of whole object: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_3D.mha -g geometry.xml --spacing 1 --dimension 256 Reconstruction of more slices of the real data-set also gave a good result. Only the slices near bottom and top are not reconstructed correctly. So it seems that the normalisation does not only take the values inside the reconstructed volume into account, but also (wrong) values outside. What do you think? Cheers, Andreas On 11/05/2013 07:11 PM, Simon Rit wrote: > Hi Andreas, > Thanks for the report. We know that the implementation of SART is > imperfect, we haven't been working a lot on it... It seems that you > haven't reached convergence. One potential cause is that we use a > heuristic for the sum of the weights (denominator in the SART formula) > instead of the exact sum. The weight is constant and equals the > diagonal of your volume (see line 165 in > rtkSARTConeBeamReconstructionFilter.txx). Maybe this is completely > wrong in your case. Could you try to increase lambda to see if that > helps? > To help us do some tests, I would advise you do reproduce your > geometry with simulations of the Shepp Logan phantom (see > wiki.openrtk.org). > Simon > > On Tue, Nov 5, 2013 at 5:11 PM, Staude, Andreas wrote: >> Hello RTk-users, >> >> I try to use the SART algorithm, but the results are worse than those >> obtained with FDK (see attached images). >> >> The FDK result looks like expected, so I assume that I have the data >> format and the reconstruction geometry set properly. For SART I used the >> same parameters and already tried with different values of lambda and >> niterations. >> >> Does anyone have an idea what went wrong? Is there some kind of >> smoothing or regularisation applied in the SART implementation? >> >> Many thanks in advance! >> >> Cheers, >> >> Andreas >> >> >> -- >> >> =============================================================== >> Dr. Andreas Staude >> Fachbereich 8.5 "Mikro-ZfP", Computertomographie >> BAM Bundesanstalt f?r Materialforschung und -pr?fung >> Unter den Eichen 87 >> D-12205 Berlin >> Germany >> >> Tel.: ++49 30 8104 4140 >> Fax: ++49 30 8104 1837 >> =============================================================== >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> -- =============================================================== Dr. Andreas Staude Fachbereich 8.5 "Mikro-ZfP", Computertomographie BAM Bundesanstalt f?r Materialforschung und -pr?fung Unter den Eichen 87 D-12205 Berlin Germany Tel.: ++49 30 8104 4140 Fax: ++49 30 8104 1837 =============================================================== From jean.hoskovec at gmail.com Wed Dec 18 08:39:32 2013 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Wed, 18 Dec 2013 14:39:32 +0100 Subject: [Rtk-users] CUDA linking problem Message-ID: Hello, I have recently encountered a linking error while recompiling RTK on a Linux 64bit machine with CUDA 5.5 and GCC 4.7. The output was as follows: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: could not read symbols: Bad value The error message speaks about the -fPIC option, but this was only half the solution. After searchnig devtalk.nvidia.com, I found a solution which worked smoothly for me: During configuration, add -Xcompiler -fPIC to your NVCC flags. After that, the compilation worked just fine again. I hope this can be helpful for someone having run into the same problem as I did. Best regards, Jan From andreas.staude at bam.de Fri Dec 20 09:10:18 2013 From: andreas.staude at bam.de (Staude, Andreas) Date: Fri, 20 Dec 2013 14:10:18 +0000 Subject: [Rtk-users] Result from SART is worse than from FDK In-Reply-To: References: <527914C3.8030706@bam.de> <527918B5.9080709@bam.de> Message-ID: <52B44FCA.7000800@bam.de> Hi Simon, I believe it really is a problem with the sum of the weights. I first tried with the Shepp-Logan-phantom and afterwards with my data. The geometry is that of a standard cone-beam micro-CT. The data I posted before were the reconstruction of just the middle plane. As I did the same with the Shepp-Logan-phantom data, similar effects were seen. As soon as one reconstructs a larger region around the middle plane, the artefacts vanish in the inner parts of the reconstructed volume, while in the top and bottom parts artefacts remain. The program calls were: create geometry: ---------------- rtksimulatedgeometry --nproj="1200" --output="geometry.xml" --sdd="1169.59" --sid="451.645" --arc="-360" --first_angle="360" project the phantom: -------------------- rtkprojectgeometricphantom -g geometry.xml -o projections3.mha --spacing 2.5 --dimension 256 --phantomfile SheppLogan.txt do a reference FDK reconstruction: ---------------------------------- rtkfdk -p . -r projections3.mha -o shepp-logan_fdk3_3D.mha -g geometry.xml --spacing 1 --dimension 256 SART reconstruction of middle plane: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_2D.mha -g geometry.xml --spacing 1 --dimension 256,1,256 SART reconstruction of 10 planes around middle plane: ------------------------------------------------------- rtksart -p . -r projections3.mha -o shepp-logan_sart3_2.5D.mha -g geometry.xml --spacing 1 --dimension 256,10,256 SART reconstruction of whole object: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_3D.mha -g geometry.xml --spacing 1 --dimension 256 Reconstruction of more slices of the real data-set also gave a good result. Only the slices near bottom and top are not reconstructed correctly. So it seems that the normalisation does not only take the values inside the reconstructed volume into account, but also (wrong) values outside. What do you think? Cheers, Andreas On 11/05/2013 07:11 PM, Simon Rit wrote: > Hi Andreas, > Thanks for the report. We know that the implementation of SART is > imperfect, we haven't been working a lot on it... It seems that you > haven't reached convergence. One potential cause is that we use a > heuristic for the sum of the weights (denominator in the SART formula) > instead of the exact sum. The weight is constant and equals the > diagonal of your volume (see line 165 in > rtkSARTConeBeamReconstructionFilter.txx). Maybe this is completely > wrong in your case. Could you try to increase lambda to see if that > helps? > To help us do some tests, I would advise you do reproduce your > geometry with simulations of the Shepp Logan phantom (see > wiki.openrtk.org). > Simon > > On Tue, Nov 5, 2013 at 5:11 PM, Staude, Andreas wrote: >> Hello RTk-users, >> >> I try to use the SART algorithm, but the results are worse than those >> obtained with FDK (see attached images). >> >> The FDK result looks like expected, so I assume that I have the data >> format and the reconstruction geometry set properly. For SART I used the >> same parameters and already tried with different values of lambda and >> niterations. >> >> Does anyone have an idea what went wrong? Is there some kind of >> smoothing or regularisation applied in the SART implementation? >> >> Many thanks in advance! >> >> Cheers, >> >> Andreas >> >> >> -- >> >> =============================================================== >> Dr. Andreas Staude >> Fachbereich 8.5 "Mikro-ZfP", Computertomographie >> BAM Bundesanstalt f?r Materialforschung und -pr?fung >> Unter den Eichen 87 >> D-12205 Berlin >> Germany >> >> Tel.: ++49 30 8104 4140 >> Fax: ++49 30 8104 1837 >> =============================================================== >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> -- =============================================================== Dr. Andreas Staude Fachbereich 8.5 "Mikro-ZfP", Computertomographie BAM Bundesanstalt f?r Materialforschung und -pr?fung Unter den Eichen 87 D-12205 Berlin Germany Tel.: ++49 30 8104 4140 Fax: ++49 30 8104 1837 =============================================================== From jean.hoskovec at gmail.com Wed Dec 18 08:39:32 2013 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Wed, 18 Dec 2013 14:39:32 +0100 Subject: [Rtk-users] CUDA linking problem Message-ID: Hello, I have recently encountered a linking error while recompiling RTK on a Linux 64bit machine with CUDA 5.5 and GCC 4.7. The output was as follows: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: could not read symbols: Bad value The error message speaks about the -fPIC option, but this was only half the solution. After searchnig devtalk.nvidia.com, I found a solution which worked smoothly for me: During configuration, add -Xcompiler -fPIC to your NVCC flags. After that, the compilation worked just fine again. I hope this can be helpful for someone having run into the same problem as I did. Best regards, Jan From andreas.staude at bam.de Fri Dec 20 09:10:18 2013 From: andreas.staude at bam.de (Staude, Andreas) Date: Fri, 20 Dec 2013 14:10:18 +0000 Subject: [Rtk-users] Result from SART is worse than from FDK In-Reply-To: References: <527914C3.8030706@bam.de> <527918B5.9080709@bam.de> Message-ID: <52B44FCA.7000800@bam.de> Hi Simon, I believe it really is a problem with the sum of the weights. I first tried with the Shepp-Logan-phantom and afterwards with my data. The geometry is that of a standard cone-beam micro-CT. The data I posted before were the reconstruction of just the middle plane. As I did the same with the Shepp-Logan-phantom data, similar effects were seen. As soon as one reconstructs a larger region around the middle plane, the artefacts vanish in the inner parts of the reconstructed volume, while in the top and bottom parts artefacts remain. The program calls were: create geometry: ---------------- rtksimulatedgeometry --nproj="1200" --output="geometry.xml" --sdd="1169.59" --sid="451.645" --arc="-360" --first_angle="360" project the phantom: -------------------- rtkprojectgeometricphantom -g geometry.xml -o projections3.mha --spacing 2.5 --dimension 256 --phantomfile SheppLogan.txt do a reference FDK reconstruction: ---------------------------------- rtkfdk -p . -r projections3.mha -o shepp-logan_fdk3_3D.mha -g geometry.xml --spacing 1 --dimension 256 SART reconstruction of middle plane: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_2D.mha -g geometry.xml --spacing 1 --dimension 256,1,256 SART reconstruction of 10 planes around middle plane: ------------------------------------------------------- rtksart -p . -r projections3.mha -o shepp-logan_sart3_2.5D.mha -g geometry.xml --spacing 1 --dimension 256,10,256 SART reconstruction of whole object: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_3D.mha -g geometry.xml --spacing 1 --dimension 256 Reconstruction of more slices of the real data-set also gave a good result. Only the slices near bottom and top are not reconstructed correctly. So it seems that the normalisation does not only take the values inside the reconstructed volume into account, but also (wrong) values outside. What do you think? Cheers, Andreas On 11/05/2013 07:11 PM, Simon Rit wrote: > Hi Andreas, > Thanks for the report. We know that the implementation of SART is > imperfect, we haven't been working a lot on it... It seems that you > haven't reached convergence. One potential cause is that we use a > heuristic for the sum of the weights (denominator in the SART formula) > instead of the exact sum. The weight is constant and equals the > diagonal of your volume (see line 165 in > rtkSARTConeBeamReconstructionFilter.txx). Maybe this is completely > wrong in your case. Could you try to increase lambda to see if that > helps? > To help us do some tests, I would advise you do reproduce your > geometry with simulations of the Shepp Logan phantom (see > wiki.openrtk.org). > Simon > > On Tue, Nov 5, 2013 at 5:11 PM, Staude, Andreas wrote: >> Hello RTk-users, >> >> I try to use the SART algorithm, but the results are worse than those >> obtained with FDK (see attached images). >> >> The FDK result looks like expected, so I assume that I have the data >> format and the reconstruction geometry set properly. For SART I used the >> same parameters and already tried with different values of lambda and >> niterations. >> >> Does anyone have an idea what went wrong? Is there some kind of >> smoothing or regularisation applied in the SART implementation? >> >> Many thanks in advance! >> >> Cheers, >> >> Andreas >> >> >> -- >> >> =============================================================== >> Dr. Andreas Staude >> Fachbereich 8.5 "Mikro-ZfP", Computertomographie >> BAM Bundesanstalt f?r Materialforschung und -pr?fung >> Unter den Eichen 87 >> D-12205 Berlin >> Germany >> >> Tel.: ++49 30 8104 4140 >> Fax: ++49 30 8104 1837 >> =============================================================== >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> -- =============================================================== Dr. Andreas Staude Fachbereich 8.5 "Mikro-ZfP", Computertomographie BAM Bundesanstalt f?r Materialforschung und -pr?fung Unter den Eichen 87 D-12205 Berlin Germany Tel.: ++49 30 8104 4140 Fax: ++49 30 8104 1837 =============================================================== From jean.hoskovec at gmail.com Wed Dec 18 08:39:32 2013 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Wed, 18 Dec 2013 14:39:32 +0100 Subject: [Rtk-users] CUDA linking problem Message-ID: Hello, I have recently encountered a linking error while recompiling RTK on a Linux 64bit machine with CUDA 5.5 and GCC 4.7. The output was as follows: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaCropImageFilter.cu.o: could not read symbols: Bad value The error message speaks about the -fPIC option, but this was only half the solution. After searchnig devtalk.nvidia.com, I found a solution which worked smoothly for me: During configuration, add -Xcompiler -fPIC to your NVCC flags. After that, the compilation worked just fine again. I hope this can be helpful for someone having run into the same problem as I did. Best regards, Jan From andreas.staude at bam.de Fri Dec 20 09:10:18 2013 From: andreas.staude at bam.de (Staude, Andreas) Date: Fri, 20 Dec 2013 14:10:18 +0000 Subject: [Rtk-users] Result from SART is worse than from FDK In-Reply-To: References: <527914C3.8030706@bam.de> <527918B5.9080709@bam.de> Message-ID: <52B44FCA.7000800@bam.de> Hi Simon, I believe it really is a problem with the sum of the weights. I first tried with the Shepp-Logan-phantom and afterwards with my data. The geometry is that of a standard cone-beam micro-CT. The data I posted before were the reconstruction of just the middle plane. As I did the same with the Shepp-Logan-phantom data, similar effects were seen. As soon as one reconstructs a larger region around the middle plane, the artefacts vanish in the inner parts of the reconstructed volume, while in the top and bottom parts artefacts remain. The program calls were: create geometry: ---------------- rtksimulatedgeometry --nproj="1200" --output="geometry.xml" --sdd="1169.59" --sid="451.645" --arc="-360" --first_angle="360" project the phantom: -------------------- rtkprojectgeometricphantom -g geometry.xml -o projections3.mha --spacing 2.5 --dimension 256 --phantomfile SheppLogan.txt do a reference FDK reconstruction: ---------------------------------- rtkfdk -p . -r projections3.mha -o shepp-logan_fdk3_3D.mha -g geometry.xml --spacing 1 --dimension 256 SART reconstruction of middle plane: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_2D.mha -g geometry.xml --spacing 1 --dimension 256,1,256 SART reconstruction of 10 planes around middle plane: ------------------------------------------------------- rtksart -p . -r projections3.mha -o shepp-logan_sart3_2.5D.mha -g geometry.xml --spacing 1 --dimension 256,10,256 SART reconstruction of whole object: ------------------------------------ rtksart -p . -r projections3.mha -o shepp-logan_sart3_3D.mha -g geometry.xml --spacing 1 --dimension 256 Reconstruction of more slices of the real data-set also gave a good result. Only the slices near bottom and top are not reconstructed correctly. So it seems that the normalisation does not only take the values inside the reconstructed volume into account, but also (wrong) values outside. What do you think? Cheers, Andreas On 11/05/2013 07:11 PM, Simon Rit wrote: > Hi Andreas, > Thanks for the report. We know that the implementation of SART is > imperfect, we haven't been working a lot on it... It seems that you > haven't reached convergence. One potential cause is that we use a > heuristic for the sum of the weights (denominator in the SART formula) > instead of the exact sum. The weight is constant and equals the > diagonal of your volume (see line 165 in > rtkSARTConeBeamReconstructionFilter.txx). Maybe this is completely > wrong in your case. Could you try to increase lambda to see if that > helps? > To help us do some tests, I would advise you do reproduce your > geometry with simulations of the Shepp Logan phantom (see > wiki.openrtk.org). > Simon > > On Tue, Nov 5, 2013 at 5:11 PM, Staude, Andreas wrote: >> Hello RTk-users, >> >> I try to use the SART algorithm, but the results are worse than those >> obtained with FDK (see attached images). >> >> The FDK result looks like expected, so I assume that I have the data >> format and the reconstruction geometry set properly. For SART I used the >> same parameters and already tried with different values of lambda and >> niterations. >> >> Does anyone have an idea what went wrong? Is there some kind of >> smoothing or regularisation applied in the SART implementation? >> >> Many thanks in advance! >> >> Cheers, >> >> Andreas >> >> >> -- >> >> =============================================================== >> Dr. Andreas Staude >> Fachbereich 8.5 "Mikro-ZfP", Computertomographie >> BAM Bundesanstalt f?r Materialforschung und -pr?fung >> Unter den Eichen 87 >> D-12205 Berlin >> Germany >> >> Tel.: ++49 30 8104 4140 >> Fax: ++49 30 8104 1837 >> =============================================================== >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> -- =============================================================== Dr. Andreas Staude Fachbereich 8.5 "Mikro-ZfP", Computertomographie BAM Bundesanstalt f?r Materialforschung und -pr?fung Unter den Eichen 87 D-12205 Berlin Germany Tel.: ++49 30 8104 4140 Fax: ++49 30 8104 1837 ===============================================================