From simon.rit at creatis.insa-lyon.fr Wed Jul 1 08:45:35 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 1 Jul 2015 14:45:35 +0200 Subject: [Rtk-users] Release of RTK v1.1.0 Message-ID: Dear RTK users, RTK v1.1.0 has been released today, about 14 months after RTK v1.0.0. The main features that have been developed since the previous release are: - SimpleRTK to run RTK filters (even the CUDA ones) from python scripts, C# code, and more - new projection pre-processing options (i0 calculation, scatter correction, water pre-correction) - extraction of the respiratory phase from cone-beam projections - linear programming for field-of-view computation based on a third party software, lp solve 5.5 - management of off-center detector in iterative methods - new iterative 3D and 4D reconstruction methods with Daubechies wavelets regularization - new iterative 4D reconstruction method with motion-aware regularization - reduction of memory footprint, especially GPU memory - many new CUDA filters - more robust (many bugs and memory leaks fixed) - use of MathJax to display formulas in the documentation, e.g., here . Many thanks to the increasing number of contributors, in alphabetical order: Ben Champion, Chao Wu, Cyril Mory, I Putu Susila, Julien Jomier, Marc Vila, Mathieu Dupont, Matt Clarkson, Peter Keuschnigg, S?bastien Brousmiche, Simon Rit, Tristan Coulange, Yang K Park. We don't focus on releases since we have a public github repository that we try to keep stable, I still recommend the use of the master HEAD over releases to enjoy the new RTK developments before their release. We still have a few on-going projects for which we will use and enhance RTK. Simon (for the RTK consortium) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 1 15:39:14 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 1 Jul 2015 21:39:14 +0200 Subject: [Rtk-users] loading projection images for sart Message-ID: Hello, I got compiled the ITK and RTK with help of cmake. I also had a look at the examples coming with RTK. I want to run a simple SART and got projection images in the format PNG and BMP. So I create an instance of the ThreeDcircularProjectionGeometry, SARTConeBeamReconstructionFilter and add the geometric projection data. rtk::ThreeDCircularProjectionGeometry::Pointer geometry; geometry = rtk::ThreeDCircularProjectionGeometry::New(); geometry->AddProjection(??) rtk::SARTConeBeamReconstructionFilter::Pointer sart = rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); How to add a stack of images to the SART reconstruction, i.e. std::vector images ? I got xray projections in png format. There is a method in the SART class called SetInput. But according tot he examples it is used to set a volume. Does anybody alread wrote a small piece of code that loads some images from the disk and put them into the SART reconstruction ? Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 2 12:19:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 2 Jul 2015 18:19:36 +0200 Subject: [Rtk-users] loading projection images for sart In-Reply-To: References: Message-ID: Hi, The stack of 2D images is passed via a 3D image. Look at the rtksart application for example. A way to read this from a set of file names is to use itk::ImageSeriesReader as done in rtk::ProjectionsReader. You should be able to understand how it works by looking at the existing RTK applications in the applications subfolders. Simon On Wed, Jul 1, 2015 at 9:39 PM, Robert Callie? wrote: > Hello, > > I got compiled the ITK and RTK with help of cmake. I also had a look > > at the examples coming with RTK. I want to run a simple SART and > > got projection images in the format PNG and BMP. > > > > So I create an instance of the ThreeDcircularProjectionGeometry, > SARTConeBeamReconstructionFilter > > and add the geometric projection data. > > > > rtk::ThreeDCircularProjectionGeometry::Pointer geometry; > > geometry = rtk::ThreeDCircularProjectionGeometry::New(); > > geometry->AddProjection(??) > > > > rtk::SARTConeBeamReconstructionFilter::Pointer sart = > rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); > > > > How to add a stack of images to the SART reconstruction, i.e. > std::vector images ? > > I got xray projections in png format. > > > > There is a method in the SART class called SetInput. But according tot he > examples it is used to set a volume. > > > > Does anybody alread wrote a small piece of code that loads some images > from the disk and put them into the SART reconstruction ? > > > > Regards, > > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Fri Jul 3 16:28:11 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 3 Jul 2015 23:28:11 +0300 Subject: [Rtk-users] Remote Control Issue in new RTK version Message-ID: Dear RTK community, There is some bug in RTK 1.1 version. That?s : When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 but i did not use Cuda at all.. What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. So i think it is some problem caused by itk ?? can we fix this issue?? Thanks for help in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Sat Jul 4 10:12:03 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Sat, 4 Jul 2015 17:12:03 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. Thanks for the help, Chao. *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ---------- Forwarded message ---------- From: Chao Wu Date: 2015-07-04 0:04 GMT+03:00 Subject: Re: Remote Control Issue To: Guangming Zang Cc: rtk-users-request at public.kitware.com, Simon Rit < simon.rit at creatis.insa-lyon.fr> Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. Regards, Chao Sent from Samsung Galaxy Note 3 2015?7?3? 10:26 PM? "Guangming Zang" ??? > Dear RTK community, > > There is some bug in RTK 1.1 version. That?s : > > When i run commands In 1.1 version with my computer in the lab, RTK works > fine, but when i use my laptop at home to remote control the computer in > the lab, it does not work. i.e., no matter the command are (rtkfdk, > ADMM,SART ?), an error is always shown: > > ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 > @ unknown : Cuda Error #3 > > but i did not use Cuda at all.. > > What?s more, when i run the 1.0 version RTK , it works well and no bug in > remoter control mode. > > So i think it is some problem caused by itk ?? can we fix this issue?? > > Thanks for help in advance > > > Regards > > Guangming > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Sat Jul 4 10:19:32 2015 From: ghostcz at hotmail.com (louie L) Date: Sat, 4 Jul 2015 16:19:32 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: I think because in most cases people use their graphics in TCC mode for scientific computations or don't use gpu at all where the rtk_use_cuda is false. Cheers, Louie Sent from my iOS > On 04 Jul 2015, at 16:12, Guangming Zang wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > > 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> Dear RTK community, >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> >> Regards >> >> Guangming >> >> Guangming Zang (Alex) >> King Abdullah University of Science and Technology(KAUST) >> University of Chinese Academy of Sciences(UCAS) >> >> >> >> >> This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > > > This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Mon Jul 6 05:32:18 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 6 Jul 2015 11:32:18 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Hi Guangming and all, Thanks for reporting this change of behavior. My first answer is that what you find simple is not so simple... but you're right, v1.0.0 allowed to compile RTK with CUDA and to run it without a CUDA device. After a bit of trakcing, I found that the change of behavior has been introduced with this patch so you can blame me. It has now fixed this issue with this patch , which seems to work on my laptop, I hope it does on your computer as well. I can't help you with the fact that you can't run CUDA software with remote control. Simon On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > I think because in most cases people use their graphics in TCC mode for > scientific computations or don't use gpu at all where the rtk_use_cuda is > false. > Cheers, > > Louie > > Sent from my iOS > > On 04 Jul 2015, at 16:12, Guangming Zang > wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes > to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is > defined, then if CUDA device is not available this error will occur. When > using MS remote desktop, graphical card and driver are bypassed unless it > is Tesla cards working in TCC mode. You can either compile exes without > CUDA for remote desktop, or try other graphic-based remote desktop software > like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > 2015?7?3? 10:26 PM? "Guangming Zang" ??? > >> Dear RTK community, >> >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works >> fine, but when i use my laptop at home to remote control the computer in >> the lab, it does not work. i.e., no matter the command are (rtkfdk, >> ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >> @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in >> remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> Regards >> >> Guangming >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 6 06:19:10 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 6 Jul 2015 13:19:10 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Thanks all for your help,Simon. I will try it again when i am at home :) As for using Cuda in remote control, i can handle it:just like what Chao said, change lab computer to TCC. What confused me at the beginning is that a cuda error shown while i did not call cuda at all, and thanks for fixing it. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-06 12:32 GMT+03:00 Simon Rit : > Hi Guangming and all, > Thanks for reporting this change of behavior. My first answer is that what > you find simple is not so simple... but you're right, v1.0.0 allowed to > compile RTK with CUDA and to run it without a CUDA device. After a bit of > trakcing, I found that the change of behavior has been introduced with this > patch > > so you can blame me. It has now fixed this issue with this patch > , > which seems to work on my laptop, I hope it does on your computer as well. > I can't help you with the fact that you can't run CUDA software with > remote control. > Simon > > On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > >> I think because in most cases people use their graphics in TCC mode for >> scientific computations or don't use gpu at all where the rtk_use_cuda is >> false. >> Cheers, >> >> Louie >> >> Sent from my iOS >> >> On 04 Jul 2015, at 16:12, Guangming Zang >> wrote: >> >> Ok, i see. Though i still do not understand why in new version rtk >> changes to call cudaimages, not keeping it simple like before. >> Thanks for the help, Chao. >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ---------- Forwarded message ---------- >> From: Chao Wu >> Date: 2015-07-04 0:04 GMT+03:00 >> Subject: Re: Remote Control Issue >> To: Guangming Zang >> Cc: rtk-users-request at public.kitware.com, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> >> >> Now in many exes cudaimage is the default image type if rtk_use_cuda is >> defined, then if CUDA device is not available this error will occur. When >> using MS remote desktop, graphical card and driver are bypassed unless it >> is Tesla cards working in TCC mode. You can either compile exes without >> CUDA for remote desktop, or try other graphic-based remote desktop software >> like vnc or teamviewer. >> >> Regards, Chao >> Sent from Samsung Galaxy Note 3 >> 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> >>> Dear RTK community, >>> >>> There is some bug in RTK 1.1 version. That?s : >>> >>> When i run commands In 1.1 version with my computer in the lab, RTK >>> works fine, but when i use my laptop at home to remote control the >>> computer in the lab, it does not work. i.e., no matter the command are >>> (rtkfdk, ADMM,SART ?), an error is always shown: >>> >>> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >>> @ unknown : Cuda Error #3 >>> >>> but i did not use Cuda at all.. >>> >>> What?s more, when i run the 1.0 version RTK , it works well and no bug >>> in remoter control mode. >>> >>> So i think it is some problem caused by itk ?? can we fix this issue?? >>> >>> Thanks for help in advance >>> >>> >>> Regards >>> >>> Guangming >>> *Guangming Zang (Alex)* >>> *King Abdullah University of Science and Technology(KAUST)* >>> *University of Chinese Academy of Sciences(UCAS)* >>> >>> >>> >>> >>> ------------------------------ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete >>> this message from your computer system. Any unauthorized use or >>> distribution is prohibited. Please consider the environment before printing >>> this email. >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Wed Jul 8 22:26:29 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Wed, 8 Jul 2015 19:26:29 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question Message-ID: Hi, I have a question from you about the CT reconstruction, I would really appreciate if you can help me with this. I have the geometry as described in following and I am trying to run the rtkfdk code from RTK. % parameters % % % % % % % param.nx = 500; % number of voxels param.ny = 500; param.nz = 500; param.sx = 5000; % mm (real size) param.sy = 5000; % mm param.sz = 5000; % mm %The real detector panel pixel density (number of pixels) param.nu = 36; % number of pixels param.nv = 100; % Detector setting (real size) param.su = 7200; % mm (real size) param.sv = 9200; % mm % X-ray source and detector setting param.DSD = 32900; % Distance source to detector param.DSO = 27400; % X-ray source to object axis distance % angle setting param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) param.dang = 5; % angular step size (deg) param.deg = 0:param.dang:360-1; % you can change param.deg = param.deg*param.dir; param.nProj = length(param.deg); param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than 360 deg -> param.parker=1 param.filter='ram-lak'; % high pass filter param.dx = param.sx/param.nx; % single voxel size param.dy = param.sy/param.ny; param.dz = param.sz/param.nz; param.du = param.su/param.nu; param.dv = param.sv/param.nv; param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) % Geometry calculation % % % param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : 360). But I got confused how to set the geometry parameters in RTK I followed the rtkfdk tutorial but I can?t get any result using this method I did the following: 1- Create geometry.xml using these parameters: nproj = 72 ; first_angle = 0 ; arc = 360 ; sid = 27400 ; sdd = 32900 ; proj_iso_x = 0; proj_iso_y = 0; out_angle = 0 ; in_angle = 0 ; source_x = 0; source_y = 0 ; 2- Create my own mha file (WriteMhaFile.m) from my projection array (36*100*72) using a matlab code with following properties: Voxel size = [0.1 0.1 0.1] Offset = [1 1 1] 3- Then run the: rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 --dimension 500 Could you please tell me if I am setting the geometry correctly? Also, is there any other way to create my own mha file? Thank you in advance and looking forward to hear back from you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 02:23:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 08:23:36 +0200 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Hi, We can try to help but we need to understand your geometry... Where does it come from by the way? If I understand your geometry correctly, I would say : - sid, sdd, nproj, arc are correct, - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 and you have 36x100 pixels, then the pixel size is [200,92,1] (last dimension is not used so anything). For the volume, if your volume is 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and not 0.1. - offset of projections is probably wrong. If you want to have a centered projections, you'll need something like (-3500, -554, 0). You can set is to 0 and put those values in proj_iso_x and proj_iso_y. Regarding mha file, you can write mha files in many ways, using SimpleRTK, matlab or writing an ITK code. Good luck! Simon On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah wrote: > Hi, > > I have a question from you about the CT reconstruction, I would really > appreciate if you can help me with this. > > I have the geometry as described in following and I am trying to run the > rtkfdk code from RTK. > > > % parameters % % % % % % % > > param.nx = 500; % number of voxels > param.ny = 500; > param.nz = 500; > > > param.sx = 5000; % mm (real size) > param.sy = 5000; % mm > param.sz = 5000; % mm > > > %The real detector panel pixel density (number of pixels) > param.nu = 36; % number of pixels > param.nv = 100; > > % Detector setting (real size) > param.su = 7200; % mm (real size) > param.sv = 9200; % mm > > > % X-ray source and detector setting > param.DSD = 32900; % Distance source to detector > param.DSO = 27400; % X-ray source to object axis distance > > > % angle setting > param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) > param.dang = 5; % angular step size (deg) > param.deg = 0:param.dang:360-1; % you can change > param.deg = param.deg*param.dir; > param.nProj = length(param.deg); > > param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than > 360 deg -> param.parker=1 > > param.filter='ram-lak'; % high pass filter > > > param.dx = param.sx/param.nx; % single voxel size > param.dy = param.sy/param.ny; > param.dz = param.sz/param.nz; > param.du = param.su/param.nu; > param.dv = param.sv/param.nv; > param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) > > > % Geometry calculation % % % > param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; > param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; > param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; > param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; > param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; > > > > So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : > 360). > But I got confused how to set the geometry parameters in RTK > I followed the rtkfdk tutorial but I can?t get any result using this method > > I did the following: > > 1- Create geometry.xml using these parameters: > > nproj = 72 ; > first_angle = 0 ; > arc = 360 ; > sid = 27400 ; > sdd = 32900 ; > proj_iso_x = 0; > proj_iso_y = 0; > out_angle = 0 ; > in_angle = 0 ; > source_x = 0; > source_y = 0 ; > > 2- Create my own mha file (WriteMhaFile.m) from my projection array > (36*100*72) using a matlab code with following properties: > Voxel size = [0.1 0.1 0.1] > Offset = [1 1 1] > > > 3- Then run the: > rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 > --dimension 500 > > > Could you please tell me if I am setting the geometry correctly? > Also, is there any other way to create my own mha file? > > Thank you in advance and looking forward to hear back from you. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 12:12:01 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 18:12:01 +0200 Subject: [Rtk-users] RTK training In-Reply-To: <55816290.1010807@uclouvain.be> References: <55816290.1010807@uclouvain.be> Message-ID: Dear RTK users, We have finally set a date for the RTK training, Wednesday, Nov 18 2015 in Lyon (France). The training will be organised by Kitware, go to this page for the registration: http://formations.kitware.fr/browse/116 We will do both user and developer sessions during the training. Since it's the first time that we do the training, we will tailor the balance between the two according to the wishes of registered people. The rest of the information should be available on the website but let us know if you need more information, we are still building the webpage and we'll be happy to improve it. We're looking forward to this new training and we'll do our best to meet your expectations, Simon On Wed, Jun 17, 2015 at 2:05 PM, Cyril Mory wrote: > Dear RTK users, > > The first RTK training is being planned at this very moment. It should > take place in November in Lyon, and be hosted by Kitware. The exact date > has not yet been decided, but will be available soon. > > We need your help to decide what to focus this training on. The choice is > mainly between two options: > - if most trainees want to learn how to use RTK, then we will focus on the > command-line tools and on python + Simple RTK > - if most trainees want to learn how to develop within RTK, modify and > enrich it, then we will focus on software architecture, detailed filter > description, ITK pipeline management, CUDA filters, etc... > > Please let us know which of these choices would best suit your needs. > > Looking forward, > Cyril > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Thu Jul 9 17:59:05 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Thu, 9 Jul 2015 14:59:05 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Simon, Thank you. I think now I understand how the whole geometry is defined in RTK. The projection is based on one experiment I am doing using different simulation techniques. Again thank you for your help. Best, Ali On Wed, Jul 8, 2015 at 11:23 PM, Simon Rit wrote: > Hi, > We can try to help but we need to understand your geometry... Where does > it come from by the way? If I understand your geometry correctly, I would > say : > - sid, sdd, nproj, arc are correct, > - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 > and you have 36x100 pixels, then the pixel size is [200,92,1] (last > dimension is not used so anything). For the volume, if your volume is > 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and > not 0.1. > - offset of projections is probably wrong. If you want to have a centered > projections, you'll need something like (-3500, -554, 0). You can set is to > 0 and put those values in proj_iso_x and proj_iso_y. > Regarding mha file, you can write mha files in many ways, using SimpleRTK, > matlab or writing an ITK code. > Good luck! > Simon > > On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah > wrote: > >> Hi, >> >> I have a question from you about the CT reconstruction, I would really >> appreciate if you can help me with this. >> >> I have the geometry as described in following and I am trying to run the >> rtkfdk code from RTK. >> >> >> % parameters % % % % % % % >> >> param.nx = 500; % number of voxels >> param.ny = 500; >> param.nz = 500; >> >> >> param.sx = 5000; % mm (real size) >> param.sy = 5000; % mm >> param.sz = 5000; % mm >> >> >> %The real detector panel pixel density (number of pixels) >> param.nu = 36; % number of pixels >> param.nv = 100; >> >> % Detector setting (real size) >> param.su = 7200; % mm (real size) >> param.sv = 9200; % mm >> >> >> % X-ray source and detector setting >> param.DSD = 32900; % Distance source to detector >> param.DSO = 27400; % X-ray source to object axis distance >> >> >> % angle setting >> param.dir = +1; % gantry rotating direction (clock wise/ counter >> clockwise) >> param.dang = 5; % angular step size (deg) >> param.deg = 0:param.dang:360-1; % you can change >> param.deg = param.deg*param.dir; >> param.nProj = length(param.deg); >> >> param.parker = 0; % data with 360 deg -> param.parker = 0 , data less >> than >> 360 deg -> param.parker=1 >> >> param.filter='ram-lak'; % high pass filter >> >> >> param.dx = param.sx/param.nx; % single voxel size >> param.dy = param.sy/param.ny; >> param.dz = param.sz/param.nz; >> param.du = param.su/param.nu; >> param.dv = param.sv/param.nv; >> param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) >> >> >> % Geometry calculation % % % >> param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; >> param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; >> param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; >> param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; >> param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; >> >> >> >> So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : >> 360). >> But I got confused how to set the geometry parameters in RTK >> I followed the rtkfdk tutorial but I can?t get any result using this >> method >> >> I did the following: >> >> 1- Create geometry.xml using these parameters: >> >> nproj = 72 ; >> first_angle = 0 ; >> arc = 360 ; >> sid = 27400 ; >> sdd = 32900 ; >> proj_iso_x = 0; >> proj_iso_y = 0; >> out_angle = 0 ; >> in_angle = 0 ; >> source_x = 0; >> source_y = 0 ; >> >> 2- Create my own mha file (WriteMhaFile.m) from my projection array >> (36*100*72) using a matlab code with following properties: >> Voxel size = [0.1 0.1 0.1] >> Offset = [1 1 1] >> >> >> 3- Then run the: >> rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 >> --dimension 500 >> >> >> Could you please tell me if I am setting the geometry correctly? >> Also, is there any other way to create my own mha file? >> >> Thank you in advance and looking forward to hear back from you. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hougeamm at 126.com Thu Jul 9 18:35:09 2015 From: hougeamm at 126.com (=?GBK?B?uu645w==?=) Date: Fri, 10 Jul 2015 06:35:09 +0800 (CST) Subject: [Rtk-users] problems for elekta data Message-ID: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Hello Everyone, Why the Elekta data prompt projection doesn't match when using rtkfdk? e.g., 377 vs 389? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 10 01:43:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Jul 2015 07:43:15 +0200 Subject: [Rtk-users] problems for elekta data In-Reply-To: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> References: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Message-ID: Hi, The message that you have on the command line is the result of the files that have been found in the path (--path option) with the regular expression (--regexp option). If it found more projections than what you have, then you probably need to improve your reg exp, e.g., by a $ after the file extension to specify that the file name must end with it. Simon On Fri, Jul 10, 2015 at 12:35 AM, ?? wrote: > Hello Everyone, > Why the Elekta data prompt projection doesn't match when using > rtkfdk? e.g., 377 vs 389? > Thanks! > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From guangming.zang at kaust.edu.sa Mon Jul 13 02:48:15 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 09:48:15 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset Message-ID: Hi RTK comunity, Besides the prameters like SID and SDD , from the geometry(.xteck) file got from my scanner, i also have object (volume) information like this: VoxelsX=179 VoxelsY=163 VoxelsZ=127 VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 The X,Y and Z axis are identical to RTK's geometry , So i was really wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i can show all other parameters like: rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, but it still a slight different visualization result from what we got from scanner software. So would you help me??? File attached is the geometry file in case. Thanks in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VCC_Dome_0622.xtekct Type: application/octet-stream Size: 1813 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 13 04:38:00 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 11:38:00 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: problem fixed. because the scanned object is symmetric and i did not notice that i should -Z axis in scanner to map Z in RTK thanks. but, i still do not know in RTK how to show the OffsetZ.. :( Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-13 9:48 GMT+03:00 Guangming Zang : > Hi RTK comunity, > Besides the prameters like SID and SDD , from the geometry(.xteck) file > got from my scanner, i also have object (volume) information like this: > VoxelsX=179 VoxelsY=163 VoxelsZ=127 > VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 > OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 > The X,Y and Z axis are identical to RTK's geometry , So i was really > wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i > can show all other parameters like: > > rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing > 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 > --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 > > Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, > but it still a slight different visualization result from what we got from > scanner software. > So would you help me??? > > > File attached is the geometry file in case. Thanks in advance > Regards > Guangming > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Mon Jul 13 13:21:44 2015 From: robert.calliess at gmx.de (=?utf-8?Q?Robert_Callie=C3=9F?=) Date: Mon, 13 Jul 2015 19:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? Message-ID: Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 13 13:42:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 13 Jul 2015 19:42:43 +0200 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: Hi, OffsetZ probably refers to the coordinate of the volume in the room coordinate which we don't use in RTK. Everything is set in the tomography coordinate during reconstruction. You can always change the coordinates of your volume after if you want to put it in some other coordinate system. Simon On Mon, Jul 13, 2015 at 10:38 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > problem fixed. > because the scanned object is symmetric and i did not notice that i > should -Z axis in scanner to map Z in RTK > thanks. > but, i still do not know in RTK how to show the OffsetZ.. :( > > Guangming > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-13 9:48 GMT+03:00 Guangming Zang : > >> Hi RTK comunity, >> Besides the prameters like SID and SDD , from the geometry(.xteck) file >> got from my scanner, i also have object (volume) information like this: >> VoxelsX=179 VoxelsY=163 VoxelsZ=127 >> VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 >> OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 >> The X,Y and Z axis are identical to RTK's geometry , So i was really >> wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i >> can show all other parameters like: >> >> rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing >> 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 >> --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 >> >> Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, >> but it still a slight different visualization result from what we got from >> scanner software. >> So would you help me??? >> >> >> File attached is the geometry file in case. Thanks in advance >> Regards >> Guangming >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Tue Jul 14 03:01:14 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 14 Jul 2015 09:01:14 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 01:32:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 07:32:43 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: > Hell RTK User, > I think there is a mistake in the described approach. > Point a) and f) meight be wrong. As far as I Understand, all Pixels > that are covered by the projected voxel vertices are update > with weight * voxel_value. Where weight is the overlaping area > of the projected voxel vertices polygon on the detector plane and the > underlying detector pixels. > > Any opinions before implementing it ? > > regards, > Robert > > *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr > *Von:* "Robert Callie?" > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what > they called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can > be rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector > cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value > to back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Wed Jul 15 08:07:20 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Wed, 15 Jul 2015 14:07:20 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 08:21:44 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 14:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: > Hello Simon, > thank you for your answer. I guess you linked the wrong article. But I > know what article you are talking about. > It's the articel from 2009 with a piece of code (MapSeq). > > >> I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > detector pixels that are totally covered by the overlap are weight with > "1" and if the overlap is between detector pixels > the pixels are weighted. Do you have a copy of the original article from > the De Man and Basu ? > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > Do you agree with that or did I miss something ? > > best regards, > Robert > > *Gesendet:* Mittwoch, 15. Juli 2015 um 07:32 Uhr > *Von:* "Simon Rit" > *An:* "Robert Callie?" > *Cc:* "rtk-users at public.kitware.com" > *Betreff:* Re: [Rtk-users] distance driven projector, a simplified > approach ? > Hi, > Indeed, I have published an article > on this > projector describing my implementation, you could use it if you want, > there's even a piece of code in it although I'm pretty sure it's not the > best implementation. This implementation dealt with the case where the > rotation axis is parallel to the detector. As far as I can remember, the > original article of De Man and Basu is also quite clear. > I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > Simon > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: >> >> Hell RTK User, >> I think there is a mistake in the described approach. >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> that are covered by the projected voxel vertices are update >> with weight * voxel_value. Where weight is the overlaping area >> of the projected voxel vertices polygon on the detector plane and the >> underlying detector pixels. >> >> Any opinions before implementing it ? >> >> regards, >> Robert >> >> *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr >> *Von:* "Robert Callie?" >> *An:* rtk-users at public.kitware.com >> *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel boundaries >> onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel?s contribution (weight) is the area of this overlapping. I >> read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is what >> they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone beam >> geometry. We can >> >> either rotate the detector and source around the object or the object can >> be rotated >> >> and the detector and source are fixed. I think Simon also wrote a paper >> about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source position, >> object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector >> cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the >> corresponding detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a ? e). Value >> to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I?m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of voxel >> boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 15 15:14:13 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 15 Jul 2015 21:14:13 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hello Simon, thank you for the articles. May I ask you what do you mean by ?voxel correction factor? in the code you provided in your article ? float f) // Voxel correction factor Thank you and best regards, Robert Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit Gesendet: Mittwoch, 15. Juli 2015 14:22 An: Robert Callie? Cc: rtk-users at public.kitware.com Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: Hello Simon, thank you for your answer. I guess you linked the wrong article. But I know what article you are talking about. It's the articel from 2009 with a piece of code (MapSeq). >> I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. You're right. It is that all pixels that are related to the overlap projected voxel overlap have to taken into account. So detector pixels that are totally covered by the overlap are weight with "1" and if the overlap is between detector pixels the pixels are weighted. Do you have a copy of the original article from the De Man and Basu ? I have the opinion that it's not neccessary to project the detector pixel boundaries and voxel boundaries onto a common plane if we use a flat panel detector. Instead we could project the voxel boundaries onto the detector plane directly. Do you agree with that or did I miss something ? best regards, Robert Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr Von: "Simon Rit" An: "Robert Callie?" Cc: "rtk-users at public.kitware.com" Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: Hell RTK User, I think there is a mistake in the described approach. Point a) and f) meight be wrong. As far as I Understand, all Pixels that are covered by the projected voxel vertices are update with weight * voxel_value. Where weight is the overlaping area of the projected voxel vertices polygon on the detector plane and the underlying detector pixels. Any opinions before implementing it ? regards, Robert Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr Von: "Robert Callie?" An: rtk-users at public.kitware.com Betreff: [Rtk-users] distance driven projector, a simplified approach ? Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 15:45:23 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 21:45:23 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. Simon On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie? wrote: > Hello Simon, > > thank you for the articles. May I ask you what do you mean by > > ?voxel correction factor? in the code you provided in your article ? > > float f) // Voxel correction factor > > > > Thank you and best regards, > > Robert > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Mittwoch, 15. Juli 2015 14:22 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified > approach ? > > > > Sorry, this link indeed with the MapSeg function. And yes, I was projecting > it to the detector plane directly. > > Simon > > > > On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" > wrote: > > Hello Simon, > > thank you for your answer. I guess you linked the wrong article. But I know > what article you are talking about. > > It's the articel from 2009 with a piece of code (MapSeq). > > > >>> I don't have time to go into the details of what you have proposed but, >>> from a glance, the first step seems useless. > > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > > detector pixels that are totally covered by the overlap are weight with "1" > and if the overlap is between detector pixels > > the pixels are weighted. Do you have a copy of the original article from the > De Man and Basu ? > > > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > > Do you agree with that or did I miss something ? > > > > best regards, > > Robert > > > > Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr > Von: "Simon Rit" > An: "Robert Callie?" > Cc: "rtk-users at public.kitware.com" > Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? > > Hi, > > Indeed, I have published an article on this projector describing my > implementation, you could use it if you want, there's even a piece of code > in it although I'm pretty sure it's not the best implementation. This > implementation dealt with the case where the rotation axis is parallel to > the detector. As far as I can remember, the original article of De Man and > Basu is also quite clear. > > I don't have time to go into the details of what you have proposed but, from > a glance, the first step seems useless. > > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > > Simon > > > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: > > Hell RTK User, > > I think there is a mistake in the described approach. > > Point a) and f) meight be wrong. As far as I Understand, all Pixels > > that are covered by the projected voxel vertices are update > > with weight * voxel_value. Where weight is the overlaping area > > of the projected voxel vertices polygon on the detector plane and the > > underlying detector pixels. > > > > Any opinions before implementing it ? > > > > regards, > > Robert > > > > Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr > Von: "Robert Callie?" > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what they > called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can be > rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value to > back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From simon.rit at creatis.insa-lyon.fr Fri Jul 17 02:22:16 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 17 Jul 2015 08:22:16 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Please keep on using the mailing list, I don't see a good reason to keep this conversation private. I won't have time to go back into these details. From a quick look, I think this is correct although I would have simply said that D is the center of the detector pixel. Simon On Thu, Jul 16, 2015 at 10:24 PM, Robert Callie? wrote: > Hello, > Sorry that I have to ask again. But I want to clear this before I start. > I want to ask about the cosine weight DeMan mentioned in his article. > He wrote: > > " > (1) The intersection length of the line of interest with the image slab S, the latter being > defined as the slab parallel to the xz plane and containing voxel V. This intersection length > is given by t/(cos ? cos ? ), where t is the isotropic voxel size, and ? and ? are the in- and > out-of-plane angles of the line of interest with the y-axis. > " > > So what he actually does, is that he calculates the intersection length of the slab s (that contains the voxel) with > a ray going from xray source to the middle of two adjacent detector cell boundaries. Let's refare to Figure 5. > So the length to be considered is calculated as the intersection length of slab S with the ray going from > the source ( the black dot in figure 5) to the mid-point of D, that means the center of the two projected adjacent > detector pixel boundaries. > > > Sorry for asking again but I want it to make it clear to me. > > Best regards, > Robert > > > -----Urspr?ngliche Nachricht----- > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit > Gesendet: Mittwoch, 15. Juli 2015 21:45 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? > > "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" > So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. > Simon > > On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie wrote: >> Hello Simon, >> >> thank you for the articles. May I ask you what do you mean by >> >> voxel correction factor in the code you provided in your article ? >> >> float f) // Voxel correction factor >> >> >> >> Thank you and best regards, >> >> Robert >> >> >> >> Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von >> Simon Rit >> Gesendet: Mittwoch, 15. Juli 2015 14:22 >> An: Robert Callie >> Cc: rtk-users at public.kitware.com >> Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified >> approach ? >> >> >> >> Sorry, this link indeed with the MapSeg function. And yes, I was >> projecting it to the detector plane directly. >> >> Simon >> >> >> >> On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie " >> >> wrote: >> >> Hello Simon, >> >> thank you for your answer. I guess you linked the wrong article. But I >> know what article you are talking about. >> >> It's the articel from 2009 with a piece of code (MapSeq). >> >> >> >>>> I don't have time to go into the details of what you have proposed >>>> but, from a glance, the first step seems useless. >> >> You're right. It is that all pixels that are related to the overlap >> projected voxel overlap have to taken into account. So >> >> detector pixels that are totally covered by the overlap are weight with "1" >> and if the overlap is between detector pixels >> >> the pixels are weighted. Do you have a copy of the original article >> from the De Man and Basu ? >> >> >> >> I have the opinion that it's not neccessary to project the detector >> pixel boundaries and voxel boundaries onto a common plane >> >> if we use a flat panel detector. Instead we could project the voxel >> boundaries onto the detector plane directly. >> >> Do you agree with that or did I miss something ? >> >> >> >> best regards, >> >> Robert >> >> >> >> Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr >> Von: "Simon Rit" >> An: "Robert Callie " >> Cc: "rtk-users at public.kitware.com" >> Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hi, >> >> Indeed, I have published an article on this projector describing my >> implementation, you could use it if you want, there's even a piece of >> code in it although I'm pretty sure it's not the best implementation. >> This implementation dealt with the case where the rotation axis is >> parallel to the detector. As far as I can remember, the original >> article of De Man and Basu is also quite clear. >> >> I don't have time to go into the details of what you have proposed >> but, from a glance, the first step seems useless. >> >> Good luck in your implementation and don't hesitate to send it to us >> when you have a working RTK implementation, >> >> Simon >> >> >> >> On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie " >> >> wrote: >> >> Hell RTK User, >> >> I think there is a mistake in the described approach. >> >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> >> that are covered by the projected voxel vertices are update >> >> with weight * voxel_value. Where weight is the overlaping area >> >> of the projected voxel vertices polygon on the detector plane and the >> >> underlying detector pixels. >> >> >> >> Any opinions before implementing it ? >> >> >> >> regards, >> >> Robert >> >> >> >> Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr >> Von: "Robert Callie " >> An: rtk-users at public.kitware.com >> Betreff: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel >> boundaries onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel s contribution (weight) is the area of this >> overlapping. I read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is >> what they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone >> beam geometry. We can >> >> either rotate the detector and source around the object or the object >> can be rotated >> >> and the detector and source are fixed. I think Simon also wrote a >> paper about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source >> position, object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the corresponding >> detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a e). >> Value to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of >> voxel boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > From guangming.zang at kaust.edu.sa Sun Jul 26 18:30:42 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 01:30:42 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed Message-ID: Hi RTK community, i am using SART algorithm to reconstruct an object. But in this new RTK version, the time recording seems a little weird: the total time is 1219.12s , but adding the time cost in different stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward projection part. BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, both multi-threading i think. Can anyone tell me what's going on? Thanks Regards Guangming [image: ???? 1] *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 01:59:11 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 07:59:11 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Guangming, It's not surprising to me that the backprojection is faster than the forward projection, that's what I expect. If the total time is longer, that's probably that some individual steps are not included in the total time. Can you try to add reader->Update(); before the line itk::TimeProbe totalTimeProbe; in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? Simon On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > Hi RTK community, > i am using SART algorithm to reconstruct an object. > But in this new RTK version, the time recording seems a little weird: > the total time is 1219.12s , but adding the time cost in different stages > is not 1291.12 s. especially for "backprojection" part, only 16.6051s to > reconstruct a 128^3 volume ?? even shorter than forward projection part. > BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, > both multi-threading i think. > Can anyone tell me what's going on? > Thanks > Regards > Guangming > > [image: ???? 1] > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 27 04:41:58 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 11:41:58 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, Thanks for your reply. would you pls help and explain why backprojection is expected to take shorter time than forward projection?? because i was thinking if no caching step, the backprojection should take much longer time than sart algorithm. yes, i run rtksart for 2 times once.it took 12xxs, similar to the time consumed of 3 times's sart, which much slower than my own application. BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 shapp-logan projections(512*512 resolution each) rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 and i will try reader->Update() like what you said. Thanks Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 8:59 GMT+03:00 Simon Rit : > Hi Guangming, > It's not surprising to me that the backprojection is faster than the > forward projection, that's what I expect. If the total time is longer, > that's probably that some individual steps are not included in the total > time. Can you try to add > reader->Update(); > before the line > > itk::TimeProbe totalTimeProbe; > > in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? > > Simon > > > > On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi RTK community, >> i am using SART algorithm to reconstruct an object. >> But in this new RTK version, the time recording seems a little weird: >> the total time is 1219.12s , but adding the time cost in different >> stages is not 1291.12 s. especially for "backprojection" part, only >> 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward >> projection part. BTW, the -f and -b are Joseph and >> VoxelBasedBackProjection, respectively, both multi-threading i think. >> Can anyone tell me what's going on? >> Thanks >> Regards >> Guangming >> >> [image: ???? 1] >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 08:28:28 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 14:28:28 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: I can try. Forward and back projection have the same algorithmic complexity but voxel based backprojection benefits from several optimizations in terms of memory management and computations that makes it faster. The best is to look at the code for further details... although both have far from being optimal. And I did not get the sentence "the backprojection should take much longer time than sart algorithm." because SART contains a backprojection and other steps so SART is obviously longer than the bp alone. Your log is strange and I don't see what steps are not timed that would take most of the time. I did the same test on my computer and here is my result: OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha --dimension 512 OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.288571 s Multiplication by zero: 0.131672 s Forward projection: 34.3612 s Subtraction: 0.203409 s Multiplication by lambda: 0.146459 s Ray box intersection: 1.30755 s Division: 0.187294 s Multiplication by the gating weights: 0 s Displaced detector: 0.278408 s Back projection: 11.8456 s Volume update: 0 s It took... 53.2765 s Simon On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang wrote: > Hi Simon, > Thanks for your reply. > would you pls help and explain why backprojection is expected to take > shorter time than forward projection?? because i was thinking if no caching > step, the backprojection should take much longer time than sart algorithm. > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > consumed of 3 times's sart, which much slower than my own application. > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > shapp-logan projections(512*512 resolution each) > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > -64,-64,-64 -l 0.5 -n 3 --time 1 > > and i will try reader->Update() like what you said. > Thanks > Guangming > > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> Hi Guangming, >> It's not surprising to me that the backprojection is faster than the >> forward projection, that's what I expect. If the total time is longer, >> that's probably that some individual steps are not included in the total >> time. Can you try to add >> reader->Update(); >> before the line >> >> itk::TimeProbe totalTimeProbe; >> >> in rtksart.cxx? It may be that all the reading operations are done but not >> timed in the sart->Update(). Why they are so long, I don't know, is your D: >> drive a network drive? Do you observe the same behavior if you do rtksart 2 >> times in a row? >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> wrote: >>> >>> Hi RTK community, >>> i am using SART algorithm to reconstruct an object. >>> But in this new RTK version, the time recording seems a little weird: >>> the total time is 1219.12s , but adding the time cost in different >>> stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s >>> to reconstruct a 128^3 volume ?? even shorter than forward projection part. >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, >>> both multi-threading i think. >>> Can anyone tell me what's going on? >>> Thanks >>> Regards >>> Guangming >>> >>> >>> Guangming Zang (Alex) >>> King Abdullah University of Science and Technology(KAUST) >>> University of Chinese Academy of Sciences(UCAS) >>> >>> >>> >>> >>> ________________________________ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete this >>> message from your computer system. Any unauthorized use or distribution is >>> prohibited. Please consider the environment before printing this email. >> >> > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 08:50:48 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 15:50:48 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, sorry for the mistake, not"the backprojection should take much longer time than sart algorithm" , but "the backprojection should take much longer time than forward projection in sart algorithm". BTW, how many cores does your computer have?? Mine is 24 cores. is it can explain the reason why it takes much longer time on my computer than yours? Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 15:28 GMT+03:00 Simon Rit : > I can try. Forward and back projection have the same algorithmic > complexity but voxel based backprojection benefits from several > optimizations in terms of memory management and computations that > makes it faster. The best is to look at the code for further > details... although both have far from being optimal. And I did not > get the sentence "the backprojection should take much longer time than > sart algorithm." because SART contains a backprojection and other > steps so SART is obviously longer than the bp alone. > Your log is strange and I don't see what steps are not timed that > would take most of the time. I did the same test on my computer and > here is my result: > > OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > --dimension 512 > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.288571 s > Multiplication by zero: 0.131672 s > Forward projection: 34.3612 s > Subtraction: 0.203409 s > Multiplication by lambda: 0.146459 s > Ray box intersection: 1.30755 s > Division: 0.187294 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.278408 s > Back projection: 11.8456 s > Volume update: 0 s > It took... 53.2765 s > > Simon > > On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > wrote: > > Hi Simon, > > Thanks for your reply. > > would you pls help and explain why backprojection is expected to take > > shorter time than forward projection?? because i was thinking if no > caching > > step, the backprojection should take much longer time than sart > algorithm. > > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > > consumed of 3 times's sart, which much slower than my own application. > > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > > shapp-logan projections(512*512 resolution each) > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > > -64,-64,-64 -l 0.5 -n 3 --time 1 > > > > and i will try reader->Update() like what you said. > > Thanks > > Guangming > > > > > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> > >> Hi Guangming, > >> It's not surprising to me that the backprojection is faster than the > >> forward projection, that's what I expect. If the total time is longer, > >> that's probably that some individual steps are not included in the total > >> time. Can you try to add > >> reader->Update(); > >> before the line > >> > >> itk::TimeProbe totalTimeProbe; > >> > >> in rtksart.cxx? It may be that all the reading operations are done but > not > >> timed in the sart->Update(). Why they are so long, I don't know, is > your D: > >> drive a network drive? Do you observe the same behavior if you do > rtksart 2 > >> times in a row? > >> > >> Simon > >> > >> > >> > >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> wrote: > >>> > >>> Hi RTK community, > >>> i am using SART algorithm to reconstruct an object. > >>> But in this new RTK version, the time recording seems a little weird: > >>> the total time is 1219.12s , but adding the time cost in different > >>> stages is not 1291.12 s. especially for "backprojection" part, only > 16.6051s > >>> to reconstruct a 128^3 volume ?? even shorter than forward projection > part. > >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > respectively, > >>> both multi-threading i think. > >>> Can anyone tell me what's going on? > >>> Thanks > >>> Regards > >>> Guangming > >>> > >>> > >>> Guangming Zang (Alex) > >>> King Abdullah University of Science and Technology(KAUST) > >>> University of Chinese Academy of Sciences(UCAS) > >>> > >>> > >>> > >>> > >>> ________________________________ > >>> This message and its contents, including attachments are intended > solely > >>> for the original recipient. If you are not the intended recipient or > have > >>> received this message in error, please notify me immediately and > delete this > >>> message from your computer system. Any unauthorized use or > distribution is > >>> prohibited. Please consider the environment before printing this email. > >> > >> > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 09:02:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 15:02:03 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: No I expect forward projection to be longer than backprojection although with optimal implementations, it should take about the same time since they have the same complexity. I have 4 cores on my laptop. I don't see how it explains it, try to find out where does SART spend the time. Simon On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang wrote: > Hi Simon, > sorry for the mistake, not"the backprojection should take much longer time > than > sart algorithm" , but "the backprojection should take much longer time than > forward projection in sart algorithm". > > BTW, how many cores does your computer have?? Mine is 24 cores. > is it can explain the reason why it takes much longer time on my computer > than yours? > Regards > Guangming > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> I can try. Forward and back projection have the same algorithmic >> complexity but voxel based backprojection benefits from several >> optimizations in terms of memory management and computations that >> makes it faster. The best is to look at the code for further >> details... although both have far from being optimal. And I did not >> get the sentence "the backprojection should take much longer time than >> sart algorithm." because SART contains a backprojection and other >> steps so SART is obviously longer than the bp alone. >> Your log is strange and I don't see what steps are not timed that >> would take most of the time. I did the same test on my computer and >> here is my result: >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> --dimension 512 >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> 1 >> Recording elapsed time... >> SARTConeBeamReconstructionFilter timing: >> Extraction of projection sub-stacks: 0.288571 s >> Multiplication by zero: 0.131672 s >> Forward projection: 34.3612 s >> Subtraction: 0.203409 s >> Multiplication by lambda: 0.146459 s >> Ray box intersection: 1.30755 s >> Division: 0.187294 s >> Multiplication by the gating weights: 0 s >> Displaced detector: 0.278408 s >> Back projection: 11.8456 s >> Volume update: 0 s >> It took... 53.2765 s >> >> Simon >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> wrote: >> > Hi Simon, >> > Thanks for your reply. >> > would you pls help and explain why backprojection is expected to take >> > shorter time than forward projection?? because i was thinking if no >> > caching >> > step, the backprojection should take much longer time than sart >> > algorithm. >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time >> > consumed of 3 times's sart, which much slower than my own application. >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 >> > shapp-logan projections(512*512 resolution each) >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> > >> > and i will try reader->Update() like what you said. >> > Thanks >> > Guangming >> > >> > >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> >> >> Hi Guangming, >> >> It's not surprising to me that the backprojection is faster than the >> >> forward projection, that's what I expect. If the total time is longer, >> >> that's probably that some individual steps are not included in the >> >> total >> >> time. Can you try to add >> >> reader->Update(); >> >> before the line >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done but >> >> not >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> your D: >> >> drive a network drive? Do you observe the same behavior if you do >> >> rtksart 2 >> >> times in a row? >> >> >> >> Simon >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> wrote: >> >>> >> >>> Hi RTK community, >> >>> i am using SART algorithm to reconstruct an object. >> >>> But in this new RTK version, the time recording seems a little weird: >> >>> the total time is 1219.12s , but adding the time cost in different >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >>> 16.6051s >> >>> to reconstruct a 128^3 volume ?? even shorter than forward projection >> >>> part. >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >>> respectively, >> >>> both multi-threading i think. >> >>> Can anyone tell me what's going on? >> >>> Thanks >> >>> Regards >> >>> Guangming >> >>> >> >>> >> >>> Guangming Zang (Alex) >> >>> King Abdullah University of Science and Technology(KAUST) >> >>> University of Chinese Academy of Sciences(UCAS) >> >>> >> >>> >> >>> >> >>> >> >>> ________________________________ >> >>> This message and its contents, including attachments are intended >> >>> solely >> >>> for the original recipient. If you are not the intended recipient or >> >>> have >> >>> received this message in error, please notify me immediately and >> >>> delete this >> >>> message from your computer system. Any unauthorized use or >> >>> distribution is >> >>> prohibited. Please consider the environment before printing this >> >>> email. >> >> >> >> >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended solely >> > for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> > this >> > message from your computer system. Any unauthorized use or distribution >> > is >> > prohibited. Please consider the environment before printing this email. > > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 10:05:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:05:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, it cost 1200s for SART algorithm at first, and the command are: rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 in which, the projections data(360pro_SL_Vol128_512.mha) is not generated from rtkprojectshepploganphantom , but from my application. though it took long time, but i can got a nice result, And i just tried the command you used, i.e. generated the projections data by rtkprojectshepploganphantom : rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 --sid=500.0 rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 yes, it takes about 56s. but the reconstructed result is weird, the voxel values range from [-142186, 208146] and can not see anything when visualizing it. i believe you got the similar results, which maybe explain why it computes much faster. if i wanna use the projections generated by rtkprojectshepploganphantom , can you give me an example to get a nice results? Best regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 16:02 GMT+03:00 Simon Rit : > No I expect forward projection to be longer than backprojection > although with optimal implementations, it should take about the same > time since they have the same complexity. > I have 4 cores on my laptop. I don't see how it explains it, try to > find out where does SART spend the time. > Simon > > On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang > wrote: > > Hi Simon, > > sorry for the mistake, not"the backprojection should take much longer > time > > than > > sart algorithm" , but "the backprojection should take much longer time > than > > forward projection in sart algorithm". > > > > BTW, how many cores does your computer have?? Mine is 24 cores. > > is it can explain the reason why it takes much longer time on my computer > > than yours? > > Regards > > Guangming > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : > >> > >> I can try. Forward and back projection have the same algorithmic > >> complexity but voxel based backprojection benefits from several > >> optimizations in terms of memory management and computations that > >> makes it faster. The best is to look at the code for further > >> details... although both have far from being optimal. And I did not > >> get the sentence "the backprojection should take much longer time than > >> sart algorithm." because SART contains a backprojection and other > >> steps so SART is obviously longer than the bp alone. > >> Your log is strange and I don't see what steps are not timed that > >> would take most of the time. I did the same test on my computer and > >> here is my result: > >> > >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > >> --dimension 512 > >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > >> 1 > >> Recording elapsed time... > >> SARTConeBeamReconstructionFilter timing: > >> Extraction of projection sub-stacks: 0.288571 s > >> Multiplication by zero: 0.131672 s > >> Forward projection: 34.3612 s > >> Subtraction: 0.203409 s > >> Multiplication by lambda: 0.146459 s > >> Ray box intersection: 1.30755 s > >> Division: 0.187294 s > >> Multiplication by the gating weights: 0 s > >> Displaced detector: 0.278408 s > >> Back projection: 11.8456 s > >> Volume update: 0 s > >> It took... 53.2765 s > >> > >> Simon > >> > >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > >> wrote: > >> > Hi Simon, > >> > Thanks for your reply. > >> > would you pls help and explain why backprojection is expected to take > >> > shorter time than forward projection?? because i was thinking if no > >> > caching > >> > step, the backprojection should take much longer time than sart > >> > algorithm. > >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the > time > >> > consumed of 3 times's sart, which much slower than my own application. > >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > >> > shapp-logan projections(512*512 resolution each) > >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > >> > -64,-64,-64 -l 0.5 -n 3 --time 1 > >> > > >> > and i will try reader->Update() like what you said. > >> > Thanks > >> > Guangming > >> > > >> > > >> > > >> > Guangming Zang (Alex) > >> > King Abdullah University of Science and Technology(KAUST) > >> > University of Chinese Academy of Sciences(UCAS) > >> > > >> > > >> > > >> > > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> >> > >> >> Hi Guangming, > >> >> It's not surprising to me that the backprojection is faster than the > >> >> forward projection, that's what I expect. If the total time is > longer, > >> >> that's probably that some individual steps are not included in the > >> >> total > >> >> time. Can you try to add > >> >> reader->Update(); > >> >> before the line > >> >> > >> >> itk::TimeProbe totalTimeProbe; > >> >> > >> >> in rtksart.cxx? It may be that all the reading operations are done > but > >> >> not > >> >> timed in the sart->Update(). Why they are so long, I don't know, is > >> >> your D: > >> >> drive a network drive? Do you observe the same behavior if you do > >> >> rtksart 2 > >> >> times in a row? > >> >> > >> >> Simon > >> >> > >> >> > >> >> > >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> >> wrote: > >> >>> > >> >>> Hi RTK community, > >> >>> i am using SART algorithm to reconstruct an object. > >> >>> But in this new RTK version, the time recording seems a little > weird: > >> >>> the total time is 1219.12s , but adding the time cost in different > >> >>> stages is not 1291.12 s. especially for "backprojection" part, only > >> >>> 16.6051s > >> >>> to reconstruct a 128^3 volume ?? even shorter than forward > projection > >> >>> part. > >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > >> >>> respectively, > >> >>> both multi-threading i think. > >> >>> Can anyone tell me what's going on? > >> >>> Thanks > >> >>> Regards > >> >>> Guangming > >> >>> > >> >>> > >> >>> Guangming Zang (Alex) > >> >>> King Abdullah University of Science and Technology(KAUST) > >> >>> University of Chinese Academy of Sciences(UCAS) > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> ________________________________ > >> >>> This message and its contents, including attachments are intended > >> >>> solely > >> >>> for the original recipient. If you are not the intended recipient or > >> >>> have > >> >>> received this message in error, please notify me immediately and > >> >>> delete this > >> >>> message from your computer system. Any unauthorized use or > >> >>> distribution is > >> >>> prohibited. Please consider the environment before printing this > >> >>> email. > >> >> > >> >> > >> > > >> > > >> > ________________________________ > >> > This message and its contents, including attachments are intended > solely > >> > for > >> > the original recipient. If you are not the intended recipient or have > >> > received this message in error, please notify me immediately and > delete > >> > this > >> > message from your computer system. Any unauthorized use or > distribution > >> > is > >> > prohibited. Please consider the environment before printing this > email. > > > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 10:12:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:12:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: BTW, the projections are 512*512, and the pixel spacing is 0.5 Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:05 GMT+03:00 Guangming Zang : > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 10:20:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 16:20:12 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Obviously I hadn't looked at the result and/or checked the command line options, sorry. This is an example from the same simulated dataset that gives me a good results: OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.567773 s Multiplication by zero: 0.303715 s Forward projection: 142.305 s Subtraction: 0.445842 s Multiplication by lambda: 0.2663 s Ray box intersection: 5.40366 s Division: 0.535618 s Multiplication by the gating weights: 0 s Displaced detector: 0.415431 s Back projection: 21.3689 s Volume update: 0 s It took... 177.059 s but this doesn't change the content of my previous message. What takes time is probably in your own software, be sure that you update SART inputs before timing it. Simon On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang wrote: > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 11:12:16 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 18:12:16 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Thanks Simon, now it work fine when using projections generated by RTK itself (command rtkprojectshepploganphantom ). for 1 iteration of SART to reconstruct 128^3 size volume, it took only 19s, which gives nice results as well. Thanks again. Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:20 GMT+03:00 Simon Rit : > Obviously I hadn't looked at the result and/or checked the command line > options, sorry. This is an example from the same simulated dataset that > gives me a good results: > > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f > Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n > 3 --time 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.567773 s > Multiplication by zero: 0.303715 s > Forward projection: 142.305 s > Subtraction: 0.445842 s > Multiplication by lambda: 0.2663 s > Ray box intersection: 5.40366 s > Division: 0.535618 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.415431 s > Back projection: 21.3689 s > Volume update: 0 s > It took... 177.059 s > > but this doesn't change the content of my previous message. What takes > time is probably in your own software, be sure that you update SART inputs > before timing it. > Simon > > On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon, >> it cost 1200s for SART algorithm at first, and the command are: >> rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd= >> 725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" >> >> rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 >> >> in which, the projections data(360pro_SL_Vol128_512.mha) is not >> generated from rtkprojectshepploganphantom , but from my application. >> though it took long time, but i can got a nice result, >> >> >> And i just tried the command you used, i.e. generated the projections >> data by rtkprojectshepploganphantom : >> >> rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 >> --sid=500.0 >> rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 >> rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b >> VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 >> --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 >> yes, it takes about 56s. >> but the reconstructed result is weird, the voxel values range from >> [-142186, 208146] and can not see anything when visualizing it. >> i believe you got the similar results, which maybe explain why it >> computes much faster. >> >> if i wanna use the projections generated by rtkprojectshepploganphantom >> , can you give me an example to get a nice results? >> >> Best regards >> Guangming >> >> >> >> >> >> >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> 2015-07-27 16:02 GMT+03:00 Simon Rit : >> >>> No I expect forward projection to be longer than backprojection >>> although with optimal implementations, it should take about the same >>> time since they have the same complexity. >>> I have 4 cores on my laptop. I don't see how it explains it, try to >>> find out where does SART spend the time. >>> Simon >>> >>> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >>> wrote: >>> > Hi Simon, >>> > sorry for the mistake, not"the backprojection should take much longer >>> time >>> > than >>> > sart algorithm" , but "the backprojection should take much longer time >>> than >>> > forward projection in sart algorithm". >>> > >>> > BTW, how many cores does your computer have?? Mine is 24 cores. >>> > is it can explain the reason why it takes much longer time on my >>> computer >>> > than yours? >>> > Regards >>> > Guangming >>> > >>> > Guangming Zang (Alex) >>> > King Abdullah University of Science and Technology(KAUST) >>> > University of Chinese Academy of Sciences(UCAS) >>> > >>> > >>> > >>> > >>> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >>> >> >>> >> I can try. Forward and back projection have the same algorithmic >>> >> complexity but voxel based backprojection benefits from several >>> >> optimizations in terms of memory management and computations that >>> >> makes it faster. The best is to look at the code for further >>> >> details... although both have far from being optimal. And I did not >>> >> get the sentence "the backprojection should take much longer time than >>> >> sart algorithm." because SART contains a backprojection and other >>> >> steps so SART is obviously longer than the bp alone. >>> >> Your log is strange and I don't see what steps are not timed that >>> >> would take most of the time. I did the same test on my computer and >>> >> here is my result: >>> >> >>> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >>> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >>> >> --dimension 512 >>> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >>> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >>> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >>> >> 1 >>> >> Recording elapsed time... >>> >> SARTConeBeamReconstructionFilter timing: >>> >> Extraction of projection sub-stacks: 0.288571 s >>> >> Multiplication by zero: 0.131672 s >>> >> Forward projection: 34.3612 s >>> >> Subtraction: 0.203409 s >>> >> Multiplication by lambda: 0.146459 s >>> >> Ray box intersection: 1.30755 s >>> >> Division: 0.187294 s >>> >> Multiplication by the gating weights: 0 s >>> >> Displaced detector: 0.278408 s >>> >> Back projection: 11.8456 s >>> >> Volume update: 0 s >>> >> It took... 53.2765 s >>> >> >>> >> Simon >>> >> >>> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >>> >> wrote: >>> >> > Hi Simon, >>> >> > Thanks for your reply. >>> >> > would you pls help and explain why backprojection is expected to >>> take >>> >> > shorter time than forward projection?? because i was thinking if no >>> >> > caching >>> >> > step, the backprojection should take much longer time than sart >>> >> > algorithm. >>> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >>> time >>> >> > consumed of 3 times's sart, which much slower than my own >>> application. >>> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >>> 360 >>> >> > shapp-logan projections(512*512 resolution each) >>> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >>> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >>> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >>> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >>> >> > >>> >> > and i will try reader->Update() like what you said. >>> >> > Thanks >>> >> > Guangming >>> >> > >>> >> > >>> >> > >>> >> > Guangming Zang (Alex) >>> >> > King Abdullah University of Science and Technology(KAUST) >>> >> > University of Chinese Academy of Sciences(UCAS) >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit >> >: >>> >> >> >>> >> >> Hi Guangming, >>> >> >> It's not surprising to me that the backprojection is faster than >>> the >>> >> >> forward projection, that's what I expect. If the total time is >>> longer, >>> >> >> that's probably that some individual steps are not included in the >>> >> >> total >>> >> >> time. Can you try to add >>> >> >> reader->Update(); >>> >> >> before the line >>> >> >> >>> >> >> itk::TimeProbe totalTimeProbe; >>> >> >> >>> >> >> in rtksart.cxx? It may be that all the reading operations are done >>> but >>> >> >> not >>> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >>> >> >> your D: >>> >> >> drive a network drive? Do you observe the same behavior if you do >>> >> >> rtksart 2 >>> >> >> times in a row? >>> >> >> >>> >> >> Simon >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >>> >> >> wrote: >>> >> >>> >>> >> >>> Hi RTK community, >>> >> >>> i am using SART algorithm to reconstruct an object. >>> >> >>> But in this new RTK version, the time recording seems a little >>> weird: >>> >> >>> the total time is 1219.12s , but adding the time cost in >>> different >>> >> >>> stages is not 1291.12 s. especially for "backprojection" part, >>> only >>> >> >>> 16.6051s >>> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >>> projection >>> >> >>> part. >>> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >>> >> >>> respectively, >>> >> >>> both multi-threading i think. >>> >> >>> Can anyone tell me what's going on? >>> >> >>> Thanks >>> >> >>> Regards >>> >> >>> Guangming >>> >> >>> >>> >> >>> >>> >> >>> Guangming Zang (Alex) >>> >> >>> King Abdullah University of Science and Technology(KAUST) >>> >> >>> University of Chinese Academy of Sciences(UCAS) >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> ________________________________ >>> >> >>> This message and its contents, including attachments are intended >>> >> >>> solely >>> >> >>> for the original recipient. If you are not the intended recipient >>> or >>> >> >>> have >>> >> >>> received this message in error, please notify me immediately and >>> >> >>> delete this >>> >> >>> message from your computer system. Any unauthorized use or >>> >> >>> distribution is >>> >> >>> prohibited. Please consider the environment before printing this >>> >> >>> email. >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > ________________________________ >>> >> > This message and its contents, including attachments are intended >>> solely >>> >> > for >>> >> > the original recipient. If you are not the intended recipient or >>> have >>> >> > received this message in error, please notify me immediately and >>> delete >>> >> > this >>> >> > message from your computer system. Any unauthorized use or >>> distribution >>> >> > is >>> >> > prohibited. Please consider the environment before printing this >>> email. >>> > >>> > >>> > >>> > ________________________________ >>> > This message and its contents, including attachments are intended >>> solely for >>> > the original recipient. If you are not the intended recipient or have >>> > received this message in error, please notify me immediately and >>> delete this >>> > message from your computer system. Any unauthorized use or >>> distribution is >>> > prohibited. Please consider the environment before printing this email. >>> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From infrombox at yandex.ru Tue Jul 28 04:30:22 2015 From: infrombox at yandex.ru (1 1) Date: Tue, 28 Jul 2015 15:30:22 +0700 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: <2213081438072222@web8j.yandex.ru> Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. But program which i use reads meta images with MET_SHORT pixel type only. Is there easy way to setting it and get volume with different from MET_FLOAT pixel type ? If not, could you advice me, what the filter i should to do, for example as post process after reconstruction ala MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward operation of LUTbasedVariableI0RawToAttenuationImageFilter ? Thanks. From simon.rit at creatis.insa-lyon.fr Tue Jul 28 04:56:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 10:56:54 +0200 Subject: [Rtk-users] volume with diffieret pixel type In-Reply-To: <2213081438072222@web8j.yandex.ru> References: <2213081438072222@web8j.yandex.ru> Message-ID: Hi, This is more an ITK question than a RTK question. Yes, we use float by default in our applications. You can cast the image to any type before writing using itk::CastImageFilter but you'll have to modify the applications and, of course, there is a loss of information. If you don't want to program it, you can use any other software, e.g. in vv right clik on your image after opening and use the convert to option. Simon On Tue, Jul 28, 2015 at 10:30 AM, 1 1 wrote: > Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. > But program which i use reads meta images with MET_SHORT pixel type only. > Is there easy way to setting it and get volume with different from > MET_FLOAT pixel type ? If not, could you advice me, what the filter i > should to do, for example as post process after reconstruction ala > MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward > operation of LUTbasedVariableI0RawToAttenuationImageFilter image, float image> ? > Thanks. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pconneely020186 at gmail.com Tue Jul 28 12:05:29 2015 From: pconneely020186 at gmail.com (peter conneely) Date: Tue, 28 Jul 2015 17:05:29 +0100 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: "peter conneely" Date: 24 Jul 2015 11:07 Subject: Issue running FDK reconstruction algorithm To: Cc: Hi, I'm having trouble running the FDK reconstruction alogrithm on Elekta and Varian data sets. The algorithm does work when I try the shepp-logan example. When I initially ran the application I included the (') around .*.his. and got the following lines. [image: Inline image 1] when I try to run with the (') removed it finds the 669 files but then the application stops working. I have tried adding registry edits to run exe and have tried switching of dep. Neither of these work I am not sure what is going wrong and how to fix it. My system properties are as follows. Processor: Intel Pentium CPU P6100 @ 2.00 Ghz RAM: 3.00 GB GPU: Intel HD Graphics Systems type 64 Bit. Thanks and Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Tue Jul 28 12:46:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 18:46:17 +0200 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: Hi, I guess the quotes are OS depedent, maybe you need double quotes on Windows. It's strange that you don't get an error message. Are you sure it crashed? If yes, have you checked the elektaGeometry file? Does it have 669 projection sections as expected? Or maybe it's a memory issue, try the --lowmem option. Simon On Tue, Jul 28, 2015 at 6:05 PM, peter conneely wrote: > ---------- Forwarded message ---------- > From: "peter conneely" > Date: 24 Jul 2015 11:07 > Subject: Issue running FDK reconstruction algorithm > To: > Cc: > > Hi, > > I'm having trouble running the FDK reconstruction alogrithm on Elekta and > Varian data sets. The algorithm does work when I try the shepp-logan > example. > > When I initially ran the application I included the (') around .*.his. and > got the following lines. > [image: Inline image 1] > when I try to run with the (') removed it finds the 669 files but then the > application stops working. I have tried adding registry edits to run exe > and have tried switching of dep. Neither of these work I am not sure what > is going wrong and how to fix it. > > My system properties are as follows. > Processor: Intel Pentium CPU P6100 @ 2.00 Ghz > RAM: 3.00 GB > GPU: Intel HD Graphics > Systems type 64 Bit. > > Thanks and Regards, > Peter > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Tue Jul 28 13:38:45 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Tue, 28 Jul 2015 20:38:45 +0300 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: Hi, in ITK, the default type are described in *Utilities\MetaIO\metaTypes.h* MET_CHAR, MET_UCHAR ?,? ?? MET_SHORT, MET_USHORT, MET_INT,=20 MET_UINT,=20 MET_FLOAT,=20 MET_DOUBLE, ?and for .mha file, the header file includes information like: ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = 0 0 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 1 1 1 DimSize = 128 128 128 ElementType = MET_FLOAT ElementDataFile = LOCAL? ?And recently i just programmed to read and write .mha files. below is the code. u can just replace ElementType from ? MET_FLOAT ? to ? ? MET_SHORT ? in your application. hope this helps: #include "stdafx.h" #include #include #include #include #include #include using namespace std; int _tmain(int argc, _TCHAR* argv[]) { int m_Dims[3]; float spacing[3]; m_Dims[0]=128; m_Dims[1]=128; m_Dims[2]=128; spacing[0]=spacing[1]=spacing[2]=1.0f; ostringstream buffer, buffer1, buffer2, buf3; buffer << spacing[0]; string sp= buffer.str(); buffer1 << spacing[1]; string sp1 = buffer1.str(); buffer2 << spacing[2]; string sp2 = buffer2.str(); string ElementSpacing ="ElementSpacing= "+sp+" "+sp1+" "+sp2+"\n"; // int ss=1000; char temp[64], temp1[64],temp2[64]; string str; sprintf(temp, "%d", m_Dims[0]); sprintf(temp1, "%d", m_Dims[1]); sprintf(temp2, "%d", m_Dims[2]); string s(temp),s1(temp1),s2(temp2); string DimSize="DimSize= "+s+" "+s1+" "+s2+"\n"; string Mywritefile="ObjectType = Image\nNDims = 3\nBinaryData = True\nBinaryDataByteOrderMSB = False \nCompressedData = False \nTransformMatrix = 1 0 0 0 1 0 0 0 1 \n" ; Mywritefile+="Offset = 0 0 0 \nCenterOfRotation = 0 0 0 \nAnatomicalOrientation = RAI \n"; Mywritefile+=ElementSpacing+DimSize+"ElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; // ElementSpacing = 1 1 1 \nDimSize = 128 128 128 \nElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; int leng=Mywritefile.length(); cout< From simon.rit at creatis.insa-lyon.fr Wed Jul 29 08:53:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 29 Jul 2015 14:53:34 +0200 Subject: [Rtk-users] RTK images make the cover of Medical Physics Message-ID: See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Wed Jul 29 09:07:01 2015 From: theday79 at gmail.com (Yang K Park) Date: Wed, 29 Jul 2015 09:07:01 -0400 Subject: [Rtk-users] RTK images make the cover of Medical Physics In-Reply-To: References: Message-ID: <001801d0c9ff$76797860$636c6920$@gmail.com> Hi Simon, Thank you so much for the congrats! This is my great honor and I?d like to thank all the RTK developers and community members for their helps on this achievement! Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: Wednesday, July 29, 2015 8:54 AM To: rtk-users at public.kitware.com Subject: [Rtk-users] RTK images make the cover of Medical Physics See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Thu Jul 30 08:16:38 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Thu, 30 Jul 2015 15:16:38 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK Message-ID: Hi Simon and Chao, i am currently do some comparisons between different reconstruction methods for Shapp-Logan dataset. the commands are: rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=955.4050067 --sid=500.0 rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha --dimension 512,512 when using FDK or SART algorithm from RTK, I can got pretty good results indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 and levels as 1.04 for all results got). When running ADMMTV command below, though the geometry is as same as SART and FDK, the result got from ADMM looks weird.(pls see attached central slice of ground truth and ADMM, same contrast with other algorithm) rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 [image: ???? 1][image: ???? 2] Is it because the CG algorithm used by ADMM, or parameters setting issues here?? if it is parameters setting problem , would you help me and give a nice values for alpha and bate used here? BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already (including default value) Thanks and regards Guangming ?? *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ? -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 31 01:55:32 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 31 Jul 2015 07:55:32 +0200 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi, It looks to me that you haven't converged. I'm not the specialist of this algorithm and the specialist won't be near a computer in the coming weeks but when I try with more iterations in the data attachment term: rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 it's more satisfactory. There are rings at the top and the bottom of the cone-beam which should be reduced with more TV (greater alpha, see doc here ) or with a finer spacing (see this publication ). Simon On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang wrote: > Hi Simon and Chao, > > i am currently do some comparisons between different reconstruction > methods for Shapp-Logan dataset. > > the commands are: > > rtksimulatedgeometry -n 360 --arc -360 -o > geo.xml --sdd=955.4050067 --sid=500.0 > > rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha > --dimension 512,512 > > > > when using FDK or SART algorithm from RTK, I can got pretty good results > indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 > and levels as 1.04 for all results got). When running ADMMTV command below, > though the geometry is as same as SART and FDK, the result got from ADMM > looks weird.(pls see attached central slice of ground truth and ADMM, same > contrast with other algorithm) > > rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o > SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 > --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 > > [image: ???? 1][image: ???? 2] > > Is it because the CG algorithm used by ADMM, or parameters setting issues > here?? if it is parameters setting problem , would you help me and give a > nice values for alpha and bate used here? > > BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already > (including default value) > > Thanks and regards > > Guangming > > > ?? > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > ? > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Fri Jul 31 09:46:41 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 31 Jul 2015 16:46:41 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi simon, i see, thanks for the help and explanation. after following your advice, it works fine now. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-31 8:55 GMT+03:00 Simon Rit : > Hi, > It looks to me that you haven't converged. I'm not the specialist of this > algorithm and the specialist won't be near a computer in the coming weeks > but when I try with more iterations in the data attachment term: > rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml > --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 > it's more satisfactory. There are rings at the top and the bottom of the > cone-beam which should be reduced with more TV (greater alpha, see doc > here > ) > or with a finer spacing (see this publication > ). > Simon > > On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon and Chao, >> >> i am currently do some comparisons between different reconstruction >> methods for Shapp-Logan dataset. >> >> the commands are: >> >> rtksimulatedgeometry -n 360 --arc -360 -o >> geo.xml --sdd=955.4050067 --sid=500.0 >> >> rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha >> --dimension 512,512 >> >> >> >> when using FDK or SART algorithm from RTK, I can got pretty good results >> indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 >> and levels as 1.04 for all results got). When running ADMMTV command below, >> though the geometry is as same as SART and FDK, the result got from ADMM >> looks weird.(pls see attached central slice of ground truth and ADMM, same >> contrast with other algorithm) >> >> rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o >> SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 >> --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 >> >> [image: ???? 1][image: ???? 2] >> >> Is it because the CG algorithm used by ADMM, or parameters setting issues >> here?? if it is parameters setting problem , would you help me and give a >> nice values for alpha and bate used here? >> >> BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already >> (including default value) >> >> Thanks and regards >> >> Guangming >> >> >> ?? >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> ? >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 1 08:45:35 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 1 Jul 2015 14:45:35 +0200 Subject: [Rtk-users] Release of RTK v1.1.0 Message-ID: Dear RTK users, RTK v1.1.0 has been released today, about 14 months after RTK v1.0.0. The main features that have been developed since the previous release are: - SimpleRTK to run RTK filters (even the CUDA ones) from python scripts, C# code, and more - new projection pre-processing options (i0 calculation, scatter correction, water pre-correction) - extraction of the respiratory phase from cone-beam projections - linear programming for field-of-view computation based on a third party software, lp solve 5.5 - management of off-center detector in iterative methods - new iterative 3D and 4D reconstruction methods with Daubechies wavelets regularization - new iterative 4D reconstruction method with motion-aware regularization - reduction of memory footprint, especially GPU memory - many new CUDA filters - more robust (many bugs and memory leaks fixed) - use of MathJax to display formulas in the documentation, e.g., here . Many thanks to the increasing number of contributors, in alphabetical order: Ben Champion, Chao Wu, Cyril Mory, I Putu Susila, Julien Jomier, Marc Vila, Mathieu Dupont, Matt Clarkson, Peter Keuschnigg, S?bastien Brousmiche, Simon Rit, Tristan Coulange, Yang K Park. We don't focus on releases since we have a public github repository that we try to keep stable, I still recommend the use of the master HEAD over releases to enjoy the new RTK developments before their release. We still have a few on-going projects for which we will use and enhance RTK. Simon (for the RTK consortium) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 1 15:39:14 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 1 Jul 2015 21:39:14 +0200 Subject: [Rtk-users] loading projection images for sart Message-ID: Hello, I got compiled the ITK and RTK with help of cmake. I also had a look at the examples coming with RTK. I want to run a simple SART and got projection images in the format PNG and BMP. So I create an instance of the ThreeDcircularProjectionGeometry, SARTConeBeamReconstructionFilter and add the geometric projection data. rtk::ThreeDCircularProjectionGeometry::Pointer geometry; geometry = rtk::ThreeDCircularProjectionGeometry::New(); geometry->AddProjection(??) rtk::SARTConeBeamReconstructionFilter::Pointer sart = rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); How to add a stack of images to the SART reconstruction, i.e. std::vector images ? I got xray projections in png format. There is a method in the SART class called SetInput. But according tot he examples it is used to set a volume. Does anybody alread wrote a small piece of code that loads some images from the disk and put them into the SART reconstruction ? Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 2 12:19:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 2 Jul 2015 18:19:36 +0200 Subject: [Rtk-users] loading projection images for sart In-Reply-To: References: Message-ID: Hi, The stack of 2D images is passed via a 3D image. Look at the rtksart application for example. A way to read this from a set of file names is to use itk::ImageSeriesReader as done in rtk::ProjectionsReader. You should be able to understand how it works by looking at the existing RTK applications in the applications subfolders. Simon On Wed, Jul 1, 2015 at 9:39 PM, Robert Callie? wrote: > Hello, > > I got compiled the ITK and RTK with help of cmake. I also had a look > > at the examples coming with RTK. I want to run a simple SART and > > got projection images in the format PNG and BMP. > > > > So I create an instance of the ThreeDcircularProjectionGeometry, > SARTConeBeamReconstructionFilter > > and add the geometric projection data. > > > > rtk::ThreeDCircularProjectionGeometry::Pointer geometry; > > geometry = rtk::ThreeDCircularProjectionGeometry::New(); > > geometry->AddProjection(??) > > > > rtk::SARTConeBeamReconstructionFilter::Pointer sart = > rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); > > > > How to add a stack of images to the SART reconstruction, i.e. > std::vector images ? > > I got xray projections in png format. > > > > There is a method in the SART class called SetInput. But according tot he > examples it is used to set a volume. > > > > Does anybody alread wrote a small piece of code that loads some images > from the disk and put them into the SART reconstruction ? > > > > Regards, > > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Fri Jul 3 16:28:11 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 3 Jul 2015 23:28:11 +0300 Subject: [Rtk-users] Remote Control Issue in new RTK version Message-ID: Dear RTK community, There is some bug in RTK 1.1 version. That?s : When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 but i did not use Cuda at all.. What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. So i think it is some problem caused by itk ?? can we fix this issue?? Thanks for help in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Sat Jul 4 10:12:03 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Sat, 4 Jul 2015 17:12:03 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. Thanks for the help, Chao. *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ---------- Forwarded message ---------- From: Chao Wu Date: 2015-07-04 0:04 GMT+03:00 Subject: Re: Remote Control Issue To: Guangming Zang Cc: rtk-users-request at public.kitware.com, Simon Rit < simon.rit at creatis.insa-lyon.fr> Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. Regards, Chao Sent from Samsung Galaxy Note 3 2015?7?3? 10:26 PM? "Guangming Zang" ??? > Dear RTK community, > > There is some bug in RTK 1.1 version. That?s : > > When i run commands In 1.1 version with my computer in the lab, RTK works > fine, but when i use my laptop at home to remote control the computer in > the lab, it does not work. i.e., no matter the command are (rtkfdk, > ADMM,SART ?), an error is always shown: > > ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 > @ unknown : Cuda Error #3 > > but i did not use Cuda at all.. > > What?s more, when i run the 1.0 version RTK , it works well and no bug in > remoter control mode. > > So i think it is some problem caused by itk ?? can we fix this issue?? > > Thanks for help in advance > > > Regards > > Guangming > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Sat Jul 4 10:19:32 2015 From: ghostcz at hotmail.com (louie L) Date: Sat, 4 Jul 2015 16:19:32 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: I think because in most cases people use their graphics in TCC mode for scientific computations or don't use gpu at all where the rtk_use_cuda is false. Cheers, Louie Sent from my iOS > On 04 Jul 2015, at 16:12, Guangming Zang wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > > 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> Dear RTK community, >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> >> Regards >> >> Guangming >> >> Guangming Zang (Alex) >> King Abdullah University of Science and Technology(KAUST) >> University of Chinese Academy of Sciences(UCAS) >> >> >> >> >> This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > > > This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Mon Jul 6 05:32:18 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 6 Jul 2015 11:32:18 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Hi Guangming and all, Thanks for reporting this change of behavior. My first answer is that what you find simple is not so simple... but you're right, v1.0.0 allowed to compile RTK with CUDA and to run it without a CUDA device. After a bit of trakcing, I found that the change of behavior has been introduced with this patch so you can blame me. It has now fixed this issue with this patch , which seems to work on my laptop, I hope it does on your computer as well. I can't help you with the fact that you can't run CUDA software with remote control. Simon On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > I think because in most cases people use their graphics in TCC mode for > scientific computations or don't use gpu at all where the rtk_use_cuda is > false. > Cheers, > > Louie > > Sent from my iOS > > On 04 Jul 2015, at 16:12, Guangming Zang > wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes > to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is > defined, then if CUDA device is not available this error will occur. When > using MS remote desktop, graphical card and driver are bypassed unless it > is Tesla cards working in TCC mode. You can either compile exes without > CUDA for remote desktop, or try other graphic-based remote desktop software > like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > 2015?7?3? 10:26 PM? "Guangming Zang" ??? > >> Dear RTK community, >> >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works >> fine, but when i use my laptop at home to remote control the computer in >> the lab, it does not work. i.e., no matter the command are (rtkfdk, >> ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >> @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in >> remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> Regards >> >> Guangming >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 6 06:19:10 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 6 Jul 2015 13:19:10 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Thanks all for your help,Simon. I will try it again when i am at home :) As for using Cuda in remote control, i can handle it:just like what Chao said, change lab computer to TCC. What confused me at the beginning is that a cuda error shown while i did not call cuda at all, and thanks for fixing it. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-06 12:32 GMT+03:00 Simon Rit : > Hi Guangming and all, > Thanks for reporting this change of behavior. My first answer is that what > you find simple is not so simple... but you're right, v1.0.0 allowed to > compile RTK with CUDA and to run it without a CUDA device. After a bit of > trakcing, I found that the change of behavior has been introduced with this > patch > > so you can blame me. It has now fixed this issue with this patch > , > which seems to work on my laptop, I hope it does on your computer as well. > I can't help you with the fact that you can't run CUDA software with > remote control. > Simon > > On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > >> I think because in most cases people use their graphics in TCC mode for >> scientific computations or don't use gpu at all where the rtk_use_cuda is >> false. >> Cheers, >> >> Louie >> >> Sent from my iOS >> >> On 04 Jul 2015, at 16:12, Guangming Zang >> wrote: >> >> Ok, i see. Though i still do not understand why in new version rtk >> changes to call cudaimages, not keeping it simple like before. >> Thanks for the help, Chao. >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ---------- Forwarded message ---------- >> From: Chao Wu >> Date: 2015-07-04 0:04 GMT+03:00 >> Subject: Re: Remote Control Issue >> To: Guangming Zang >> Cc: rtk-users-request at public.kitware.com, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> >> >> Now in many exes cudaimage is the default image type if rtk_use_cuda is >> defined, then if CUDA device is not available this error will occur. When >> using MS remote desktop, graphical card and driver are bypassed unless it >> is Tesla cards working in TCC mode. You can either compile exes without >> CUDA for remote desktop, or try other graphic-based remote desktop software >> like vnc or teamviewer. >> >> Regards, Chao >> Sent from Samsung Galaxy Note 3 >> 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> >>> Dear RTK community, >>> >>> There is some bug in RTK 1.1 version. That?s : >>> >>> When i run commands In 1.1 version with my computer in the lab, RTK >>> works fine, but when i use my laptop at home to remote control the >>> computer in the lab, it does not work. i.e., no matter the command are >>> (rtkfdk, ADMM,SART ?), an error is always shown: >>> >>> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >>> @ unknown : Cuda Error #3 >>> >>> but i did not use Cuda at all.. >>> >>> What?s more, when i run the 1.0 version RTK , it works well and no bug >>> in remoter control mode. >>> >>> So i think it is some problem caused by itk ?? can we fix this issue?? >>> >>> Thanks for help in advance >>> >>> >>> Regards >>> >>> Guangming >>> *Guangming Zang (Alex)* >>> *King Abdullah University of Science and Technology(KAUST)* >>> *University of Chinese Academy of Sciences(UCAS)* >>> >>> >>> >>> >>> ------------------------------ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete >>> this message from your computer system. Any unauthorized use or >>> distribution is prohibited. Please consider the environment before printing >>> this email. >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Wed Jul 8 22:26:29 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Wed, 8 Jul 2015 19:26:29 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question Message-ID: Hi, I have a question from you about the CT reconstruction, I would really appreciate if you can help me with this. I have the geometry as described in following and I am trying to run the rtkfdk code from RTK. % parameters % % % % % % % param.nx = 500; % number of voxels param.ny = 500; param.nz = 500; param.sx = 5000; % mm (real size) param.sy = 5000; % mm param.sz = 5000; % mm %The real detector panel pixel density (number of pixels) param.nu = 36; % number of pixels param.nv = 100; % Detector setting (real size) param.su = 7200; % mm (real size) param.sv = 9200; % mm % X-ray source and detector setting param.DSD = 32900; % Distance source to detector param.DSO = 27400; % X-ray source to object axis distance % angle setting param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) param.dang = 5; % angular step size (deg) param.deg = 0:param.dang:360-1; % you can change param.deg = param.deg*param.dir; param.nProj = length(param.deg); param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than 360 deg -> param.parker=1 param.filter='ram-lak'; % high pass filter param.dx = param.sx/param.nx; % single voxel size param.dy = param.sy/param.ny; param.dz = param.sz/param.nz; param.du = param.su/param.nu; param.dv = param.sv/param.nv; param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) % Geometry calculation % % % param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : 360). But I got confused how to set the geometry parameters in RTK I followed the rtkfdk tutorial but I can?t get any result using this method I did the following: 1- Create geometry.xml using these parameters: nproj = 72 ; first_angle = 0 ; arc = 360 ; sid = 27400 ; sdd = 32900 ; proj_iso_x = 0; proj_iso_y = 0; out_angle = 0 ; in_angle = 0 ; source_x = 0; source_y = 0 ; 2- Create my own mha file (WriteMhaFile.m) from my projection array (36*100*72) using a matlab code with following properties: Voxel size = [0.1 0.1 0.1] Offset = [1 1 1] 3- Then run the: rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 --dimension 500 Could you please tell me if I am setting the geometry correctly? Also, is there any other way to create my own mha file? Thank you in advance and looking forward to hear back from you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 02:23:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 08:23:36 +0200 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Hi, We can try to help but we need to understand your geometry... Where does it come from by the way? If I understand your geometry correctly, I would say : - sid, sdd, nproj, arc are correct, - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 and you have 36x100 pixels, then the pixel size is [200,92,1] (last dimension is not used so anything). For the volume, if your volume is 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and not 0.1. - offset of projections is probably wrong. If you want to have a centered projections, you'll need something like (-3500, -554, 0). You can set is to 0 and put those values in proj_iso_x and proj_iso_y. Regarding mha file, you can write mha files in many ways, using SimpleRTK, matlab or writing an ITK code. Good luck! Simon On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah wrote: > Hi, > > I have a question from you about the CT reconstruction, I would really > appreciate if you can help me with this. > > I have the geometry as described in following and I am trying to run the > rtkfdk code from RTK. > > > % parameters % % % % % % % > > param.nx = 500; % number of voxels > param.ny = 500; > param.nz = 500; > > > param.sx = 5000; % mm (real size) > param.sy = 5000; % mm > param.sz = 5000; % mm > > > %The real detector panel pixel density (number of pixels) > param.nu = 36; % number of pixels > param.nv = 100; > > % Detector setting (real size) > param.su = 7200; % mm (real size) > param.sv = 9200; % mm > > > % X-ray source and detector setting > param.DSD = 32900; % Distance source to detector > param.DSO = 27400; % X-ray source to object axis distance > > > % angle setting > param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) > param.dang = 5; % angular step size (deg) > param.deg = 0:param.dang:360-1; % you can change > param.deg = param.deg*param.dir; > param.nProj = length(param.deg); > > param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than > 360 deg -> param.parker=1 > > param.filter='ram-lak'; % high pass filter > > > param.dx = param.sx/param.nx; % single voxel size > param.dy = param.sy/param.ny; > param.dz = param.sz/param.nz; > param.du = param.su/param.nu; > param.dv = param.sv/param.nv; > param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) > > > % Geometry calculation % % % > param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; > param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; > param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; > param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; > param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; > > > > So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : > 360). > But I got confused how to set the geometry parameters in RTK > I followed the rtkfdk tutorial but I can?t get any result using this method > > I did the following: > > 1- Create geometry.xml using these parameters: > > nproj = 72 ; > first_angle = 0 ; > arc = 360 ; > sid = 27400 ; > sdd = 32900 ; > proj_iso_x = 0; > proj_iso_y = 0; > out_angle = 0 ; > in_angle = 0 ; > source_x = 0; > source_y = 0 ; > > 2- Create my own mha file (WriteMhaFile.m) from my projection array > (36*100*72) using a matlab code with following properties: > Voxel size = [0.1 0.1 0.1] > Offset = [1 1 1] > > > 3- Then run the: > rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 > --dimension 500 > > > Could you please tell me if I am setting the geometry correctly? > Also, is there any other way to create my own mha file? > > Thank you in advance and looking forward to hear back from you. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 12:12:01 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 18:12:01 +0200 Subject: [Rtk-users] RTK training In-Reply-To: <55816290.1010807@uclouvain.be> References: <55816290.1010807@uclouvain.be> Message-ID: Dear RTK users, We have finally set a date for the RTK training, Wednesday, Nov 18 2015 in Lyon (France). The training will be organised by Kitware, go to this page for the registration: http://formations.kitware.fr/browse/116 We will do both user and developer sessions during the training. Since it's the first time that we do the training, we will tailor the balance between the two according to the wishes of registered people. The rest of the information should be available on the website but let us know if you need more information, we are still building the webpage and we'll be happy to improve it. We're looking forward to this new training and we'll do our best to meet your expectations, Simon On Wed, Jun 17, 2015 at 2:05 PM, Cyril Mory wrote: > Dear RTK users, > > The first RTK training is being planned at this very moment. It should > take place in November in Lyon, and be hosted by Kitware. The exact date > has not yet been decided, but will be available soon. > > We need your help to decide what to focus this training on. The choice is > mainly between two options: > - if most trainees want to learn how to use RTK, then we will focus on the > command-line tools and on python + Simple RTK > - if most trainees want to learn how to develop within RTK, modify and > enrich it, then we will focus on software architecture, detailed filter > description, ITK pipeline management, CUDA filters, etc... > > Please let us know which of these choices would best suit your needs. > > Looking forward, > Cyril > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Thu Jul 9 17:59:05 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Thu, 9 Jul 2015 14:59:05 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Simon, Thank you. I think now I understand how the whole geometry is defined in RTK. The projection is based on one experiment I am doing using different simulation techniques. Again thank you for your help. Best, Ali On Wed, Jul 8, 2015 at 11:23 PM, Simon Rit wrote: > Hi, > We can try to help but we need to understand your geometry... Where does > it come from by the way? If I understand your geometry correctly, I would > say : > - sid, sdd, nproj, arc are correct, > - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 > and you have 36x100 pixels, then the pixel size is [200,92,1] (last > dimension is not used so anything). For the volume, if your volume is > 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and > not 0.1. > - offset of projections is probably wrong. If you want to have a centered > projections, you'll need something like (-3500, -554, 0). You can set is to > 0 and put those values in proj_iso_x and proj_iso_y. > Regarding mha file, you can write mha files in many ways, using SimpleRTK, > matlab or writing an ITK code. > Good luck! > Simon > > On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah > wrote: > >> Hi, >> >> I have a question from you about the CT reconstruction, I would really >> appreciate if you can help me with this. >> >> I have the geometry as described in following and I am trying to run the >> rtkfdk code from RTK. >> >> >> % parameters % % % % % % % >> >> param.nx = 500; % number of voxels >> param.ny = 500; >> param.nz = 500; >> >> >> param.sx = 5000; % mm (real size) >> param.sy = 5000; % mm >> param.sz = 5000; % mm >> >> >> %The real detector panel pixel density (number of pixels) >> param.nu = 36; % number of pixels >> param.nv = 100; >> >> % Detector setting (real size) >> param.su = 7200; % mm (real size) >> param.sv = 9200; % mm >> >> >> % X-ray source and detector setting >> param.DSD = 32900; % Distance source to detector >> param.DSO = 27400; % X-ray source to object axis distance >> >> >> % angle setting >> param.dir = +1; % gantry rotating direction (clock wise/ counter >> clockwise) >> param.dang = 5; % angular step size (deg) >> param.deg = 0:param.dang:360-1; % you can change >> param.deg = param.deg*param.dir; >> param.nProj = length(param.deg); >> >> param.parker = 0; % data with 360 deg -> param.parker = 0 , data less >> than >> 360 deg -> param.parker=1 >> >> param.filter='ram-lak'; % high pass filter >> >> >> param.dx = param.sx/param.nx; % single voxel size >> param.dy = param.sy/param.ny; >> param.dz = param.sz/param.nz; >> param.du = param.su/param.nu; >> param.dv = param.sv/param.nv; >> param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) >> >> >> % Geometry calculation % % % >> param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; >> param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; >> param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; >> param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; >> param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; >> >> >> >> So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : >> 360). >> But I got confused how to set the geometry parameters in RTK >> I followed the rtkfdk tutorial but I can?t get any result using this >> method >> >> I did the following: >> >> 1- Create geometry.xml using these parameters: >> >> nproj = 72 ; >> first_angle = 0 ; >> arc = 360 ; >> sid = 27400 ; >> sdd = 32900 ; >> proj_iso_x = 0; >> proj_iso_y = 0; >> out_angle = 0 ; >> in_angle = 0 ; >> source_x = 0; >> source_y = 0 ; >> >> 2- Create my own mha file (WriteMhaFile.m) from my projection array >> (36*100*72) using a matlab code with following properties: >> Voxel size = [0.1 0.1 0.1] >> Offset = [1 1 1] >> >> >> 3- Then run the: >> rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 >> --dimension 500 >> >> >> Could you please tell me if I am setting the geometry correctly? >> Also, is there any other way to create my own mha file? >> >> Thank you in advance and looking forward to hear back from you. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hougeamm at 126.com Thu Jul 9 18:35:09 2015 From: hougeamm at 126.com (=?GBK?B?uu645w==?=) Date: Fri, 10 Jul 2015 06:35:09 +0800 (CST) Subject: [Rtk-users] problems for elekta data Message-ID: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Hello Everyone, Why the Elekta data prompt projection doesn't match when using rtkfdk? e.g., 377 vs 389? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 10 01:43:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Jul 2015 07:43:15 +0200 Subject: [Rtk-users] problems for elekta data In-Reply-To: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> References: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Message-ID: Hi, The message that you have on the command line is the result of the files that have been found in the path (--path option) with the regular expression (--regexp option). If it found more projections than what you have, then you probably need to improve your reg exp, e.g., by a $ after the file extension to specify that the file name must end with it. Simon On Fri, Jul 10, 2015 at 12:35 AM, ?? wrote: > Hello Everyone, > Why the Elekta data prompt projection doesn't match when using > rtkfdk? e.g., 377 vs 389? > Thanks! > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From guangming.zang at kaust.edu.sa Mon Jul 13 02:48:15 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 09:48:15 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset Message-ID: Hi RTK comunity, Besides the prameters like SID and SDD , from the geometry(.xteck) file got from my scanner, i also have object (volume) information like this: VoxelsX=179 VoxelsY=163 VoxelsZ=127 VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 The X,Y and Z axis are identical to RTK's geometry , So i was really wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i can show all other parameters like: rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, but it still a slight different visualization result from what we got from scanner software. So would you help me??? File attached is the geometry file in case. Thanks in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VCC_Dome_0622.xtekct Type: application/octet-stream Size: 1813 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 13 04:38:00 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 11:38:00 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: problem fixed. because the scanned object is symmetric and i did not notice that i should -Z axis in scanner to map Z in RTK thanks. but, i still do not know in RTK how to show the OffsetZ.. :( Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-13 9:48 GMT+03:00 Guangming Zang : > Hi RTK comunity, > Besides the prameters like SID and SDD , from the geometry(.xteck) file > got from my scanner, i also have object (volume) information like this: > VoxelsX=179 VoxelsY=163 VoxelsZ=127 > VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 > OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 > The X,Y and Z axis are identical to RTK's geometry , So i was really > wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i > can show all other parameters like: > > rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing > 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 > --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 > > Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, > but it still a slight different visualization result from what we got from > scanner software. > So would you help me??? > > > File attached is the geometry file in case. Thanks in advance > Regards > Guangming > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Mon Jul 13 13:21:44 2015 From: robert.calliess at gmx.de (=?utf-8?Q?Robert_Callie=C3=9F?=) Date: Mon, 13 Jul 2015 19:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? Message-ID: Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 13 13:42:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 13 Jul 2015 19:42:43 +0200 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: Hi, OffsetZ probably refers to the coordinate of the volume in the room coordinate which we don't use in RTK. Everything is set in the tomography coordinate during reconstruction. You can always change the coordinates of your volume after if you want to put it in some other coordinate system. Simon On Mon, Jul 13, 2015 at 10:38 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > problem fixed. > because the scanned object is symmetric and i did not notice that i > should -Z axis in scanner to map Z in RTK > thanks. > but, i still do not know in RTK how to show the OffsetZ.. :( > > Guangming > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-13 9:48 GMT+03:00 Guangming Zang : > >> Hi RTK comunity, >> Besides the prameters like SID and SDD , from the geometry(.xteck) file >> got from my scanner, i also have object (volume) information like this: >> VoxelsX=179 VoxelsY=163 VoxelsZ=127 >> VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 >> OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 >> The X,Y and Z axis are identical to RTK's geometry , So i was really >> wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i >> can show all other parameters like: >> >> rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing >> 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 >> --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 >> >> Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, >> but it still a slight different visualization result from what we got from >> scanner software. >> So would you help me??? >> >> >> File attached is the geometry file in case. Thanks in advance >> Regards >> Guangming >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Tue Jul 14 03:01:14 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 14 Jul 2015 09:01:14 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 01:32:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 07:32:43 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: > Hell RTK User, > I think there is a mistake in the described approach. > Point a) and f) meight be wrong. As far as I Understand, all Pixels > that are covered by the projected voxel vertices are update > with weight * voxel_value. Where weight is the overlaping area > of the projected voxel vertices polygon on the detector plane and the > underlying detector pixels. > > Any opinions before implementing it ? > > regards, > Robert > > *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr > *Von:* "Robert Callie?" > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what > they called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can > be rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector > cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value > to back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Wed Jul 15 08:07:20 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Wed, 15 Jul 2015 14:07:20 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 08:21:44 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 14:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: > Hello Simon, > thank you for your answer. I guess you linked the wrong article. But I > know what article you are talking about. > It's the articel from 2009 with a piece of code (MapSeq). > > >> I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > detector pixels that are totally covered by the overlap are weight with > "1" and if the overlap is between detector pixels > the pixels are weighted. Do you have a copy of the original article from > the De Man and Basu ? > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > Do you agree with that or did I miss something ? > > best regards, > Robert > > *Gesendet:* Mittwoch, 15. Juli 2015 um 07:32 Uhr > *Von:* "Simon Rit" > *An:* "Robert Callie?" > *Cc:* "rtk-users at public.kitware.com" > *Betreff:* Re: [Rtk-users] distance driven projector, a simplified > approach ? > Hi, > Indeed, I have published an article > on this > projector describing my implementation, you could use it if you want, > there's even a piece of code in it although I'm pretty sure it's not the > best implementation. This implementation dealt with the case where the > rotation axis is parallel to the detector. As far as I can remember, the > original article of De Man and Basu is also quite clear. > I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > Simon > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: >> >> Hell RTK User, >> I think there is a mistake in the described approach. >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> that are covered by the projected voxel vertices are update >> with weight * voxel_value. Where weight is the overlaping area >> of the projected voxel vertices polygon on the detector plane and the >> underlying detector pixels. >> >> Any opinions before implementing it ? >> >> regards, >> Robert >> >> *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr >> *Von:* "Robert Callie?" >> *An:* rtk-users at public.kitware.com >> *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel boundaries >> onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel?s contribution (weight) is the area of this overlapping. I >> read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is what >> they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone beam >> geometry. We can >> >> either rotate the detector and source around the object or the object can >> be rotated >> >> and the detector and source are fixed. I think Simon also wrote a paper >> about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source position, >> object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector >> cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the >> corresponding detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a ? e). Value >> to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I?m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of voxel >> boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 15 15:14:13 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 15 Jul 2015 21:14:13 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hello Simon, thank you for the articles. May I ask you what do you mean by ?voxel correction factor? in the code you provided in your article ? float f) // Voxel correction factor Thank you and best regards, Robert Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit Gesendet: Mittwoch, 15. Juli 2015 14:22 An: Robert Callie? Cc: rtk-users at public.kitware.com Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: Hello Simon, thank you for your answer. I guess you linked the wrong article. But I know what article you are talking about. It's the articel from 2009 with a piece of code (MapSeq). >> I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. You're right. It is that all pixels that are related to the overlap projected voxel overlap have to taken into account. So detector pixels that are totally covered by the overlap are weight with "1" and if the overlap is between detector pixels the pixels are weighted. Do you have a copy of the original article from the De Man and Basu ? I have the opinion that it's not neccessary to project the detector pixel boundaries and voxel boundaries onto a common plane if we use a flat panel detector. Instead we could project the voxel boundaries onto the detector plane directly. Do you agree with that or did I miss something ? best regards, Robert Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr Von: "Simon Rit" An: "Robert Callie?" Cc: "rtk-users at public.kitware.com" Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: Hell RTK User, I think there is a mistake in the described approach. Point a) and f) meight be wrong. As far as I Understand, all Pixels that are covered by the projected voxel vertices are update with weight * voxel_value. Where weight is the overlaping area of the projected voxel vertices polygon on the detector plane and the underlying detector pixels. Any opinions before implementing it ? regards, Robert Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr Von: "Robert Callie?" An: rtk-users at public.kitware.com Betreff: [Rtk-users] distance driven projector, a simplified approach ? Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 15:45:23 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 21:45:23 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. Simon On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie? wrote: > Hello Simon, > > thank you for the articles. May I ask you what do you mean by > > ?voxel correction factor? in the code you provided in your article ? > > float f) // Voxel correction factor > > > > Thank you and best regards, > > Robert > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Mittwoch, 15. Juli 2015 14:22 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified > approach ? > > > > Sorry, this link indeed with the MapSeg function. And yes, I was projecting > it to the detector plane directly. > > Simon > > > > On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" > wrote: > > Hello Simon, > > thank you for your answer. I guess you linked the wrong article. But I know > what article you are talking about. > > It's the articel from 2009 with a piece of code (MapSeq). > > > >>> I don't have time to go into the details of what you have proposed but, >>> from a glance, the first step seems useless. > > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > > detector pixels that are totally covered by the overlap are weight with "1" > and if the overlap is between detector pixels > > the pixels are weighted. Do you have a copy of the original article from the > De Man and Basu ? > > > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > > Do you agree with that or did I miss something ? > > > > best regards, > > Robert > > > > Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr > Von: "Simon Rit" > An: "Robert Callie?" > Cc: "rtk-users at public.kitware.com" > Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? > > Hi, > > Indeed, I have published an article on this projector describing my > implementation, you could use it if you want, there's even a piece of code > in it although I'm pretty sure it's not the best implementation. This > implementation dealt with the case where the rotation axis is parallel to > the detector. As far as I can remember, the original article of De Man and > Basu is also quite clear. > > I don't have time to go into the details of what you have proposed but, from > a glance, the first step seems useless. > > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > > Simon > > > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: > > Hell RTK User, > > I think there is a mistake in the described approach. > > Point a) and f) meight be wrong. As far as I Understand, all Pixels > > that are covered by the projected voxel vertices are update > > with weight * voxel_value. Where weight is the overlaping area > > of the projected voxel vertices polygon on the detector plane and the > > underlying detector pixels. > > > > Any opinions before implementing it ? > > > > regards, > > Robert > > > > Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr > Von: "Robert Callie?" > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what they > called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can be > rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value to > back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From simon.rit at creatis.insa-lyon.fr Fri Jul 17 02:22:16 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 17 Jul 2015 08:22:16 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Please keep on using the mailing list, I don't see a good reason to keep this conversation private. I won't have time to go back into these details. From a quick look, I think this is correct although I would have simply said that D is the center of the detector pixel. Simon On Thu, Jul 16, 2015 at 10:24 PM, Robert Callie? wrote: > Hello, > Sorry that I have to ask again. But I want to clear this before I start. > I want to ask about the cosine weight DeMan mentioned in his article. > He wrote: > > " > (1) The intersection length of the line of interest with the image slab S, the latter being > defined as the slab parallel to the xz plane and containing voxel V. This intersection length > is given by t/(cos ? cos ? ), where t is the isotropic voxel size, and ? and ? are the in- and > out-of-plane angles of the line of interest with the y-axis. > " > > So what he actually does, is that he calculates the intersection length of the slab s (that contains the voxel) with > a ray going from xray source to the middle of two adjacent detector cell boundaries. Let's refare to Figure 5. > So the length to be considered is calculated as the intersection length of slab S with the ray going from > the source ( the black dot in figure 5) to the mid-point of D, that means the center of the two projected adjacent > detector pixel boundaries. > > > Sorry for asking again but I want it to make it clear to me. > > Best regards, > Robert > > > -----Urspr?ngliche Nachricht----- > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit > Gesendet: Mittwoch, 15. Juli 2015 21:45 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? > > "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" > So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. > Simon > > On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie wrote: >> Hello Simon, >> >> thank you for the articles. May I ask you what do you mean by >> >> voxel correction factor in the code you provided in your article ? >> >> float f) // Voxel correction factor >> >> >> >> Thank you and best regards, >> >> Robert >> >> >> >> Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von >> Simon Rit >> Gesendet: Mittwoch, 15. Juli 2015 14:22 >> An: Robert Callie >> Cc: rtk-users at public.kitware.com >> Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified >> approach ? >> >> >> >> Sorry, this link indeed with the MapSeg function. And yes, I was >> projecting it to the detector plane directly. >> >> Simon >> >> >> >> On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie " >> >> wrote: >> >> Hello Simon, >> >> thank you for your answer. I guess you linked the wrong article. But I >> know what article you are talking about. >> >> It's the articel from 2009 with a piece of code (MapSeq). >> >> >> >>>> I don't have time to go into the details of what you have proposed >>>> but, from a glance, the first step seems useless. >> >> You're right. It is that all pixels that are related to the overlap >> projected voxel overlap have to taken into account. So >> >> detector pixels that are totally covered by the overlap are weight with "1" >> and if the overlap is between detector pixels >> >> the pixels are weighted. Do you have a copy of the original article >> from the De Man and Basu ? >> >> >> >> I have the opinion that it's not neccessary to project the detector >> pixel boundaries and voxel boundaries onto a common plane >> >> if we use a flat panel detector. Instead we could project the voxel >> boundaries onto the detector plane directly. >> >> Do you agree with that or did I miss something ? >> >> >> >> best regards, >> >> Robert >> >> >> >> Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr >> Von: "Simon Rit" >> An: "Robert Callie " >> Cc: "rtk-users at public.kitware.com" >> Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hi, >> >> Indeed, I have published an article on this projector describing my >> implementation, you could use it if you want, there's even a piece of >> code in it although I'm pretty sure it's not the best implementation. >> This implementation dealt with the case where the rotation axis is >> parallel to the detector. As far as I can remember, the original >> article of De Man and Basu is also quite clear. >> >> I don't have time to go into the details of what you have proposed >> but, from a glance, the first step seems useless. >> >> Good luck in your implementation and don't hesitate to send it to us >> when you have a working RTK implementation, >> >> Simon >> >> >> >> On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie " >> >> wrote: >> >> Hell RTK User, >> >> I think there is a mistake in the described approach. >> >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> >> that are covered by the projected voxel vertices are update >> >> with weight * voxel_value. Where weight is the overlaping area >> >> of the projected voxel vertices polygon on the detector plane and the >> >> underlying detector pixels. >> >> >> >> Any opinions before implementing it ? >> >> >> >> regards, >> >> Robert >> >> >> >> Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr >> Von: "Robert Callie " >> An: rtk-users at public.kitware.com >> Betreff: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel >> boundaries onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel s contribution (weight) is the area of this >> overlapping. I read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is >> what they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone >> beam geometry. We can >> >> either rotate the detector and source around the object or the object >> can be rotated >> >> and the detector and source are fixed. I think Simon also wrote a >> paper about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source >> position, object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the corresponding >> detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a e). >> Value to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of >> voxel boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > From guangming.zang at kaust.edu.sa Sun Jul 26 18:30:42 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 01:30:42 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed Message-ID: Hi RTK community, i am using SART algorithm to reconstruct an object. But in this new RTK version, the time recording seems a little weird: the total time is 1219.12s , but adding the time cost in different stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward projection part. BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, both multi-threading i think. Can anyone tell me what's going on? Thanks Regards Guangming [image: ???? 1] *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 01:59:11 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 07:59:11 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Guangming, It's not surprising to me that the backprojection is faster than the forward projection, that's what I expect. If the total time is longer, that's probably that some individual steps are not included in the total time. Can you try to add reader->Update(); before the line itk::TimeProbe totalTimeProbe; in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? Simon On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > Hi RTK community, > i am using SART algorithm to reconstruct an object. > But in this new RTK version, the time recording seems a little weird: > the total time is 1219.12s , but adding the time cost in different stages > is not 1291.12 s. especially for "backprojection" part, only 16.6051s to > reconstruct a 128^3 volume ?? even shorter than forward projection part. > BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, > both multi-threading i think. > Can anyone tell me what's going on? > Thanks > Regards > Guangming > > [image: ???? 1] > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 27 04:41:58 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 11:41:58 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, Thanks for your reply. would you pls help and explain why backprojection is expected to take shorter time than forward projection?? because i was thinking if no caching step, the backprojection should take much longer time than sart algorithm. yes, i run rtksart for 2 times once.it took 12xxs, similar to the time consumed of 3 times's sart, which much slower than my own application. BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 shapp-logan projections(512*512 resolution each) rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 and i will try reader->Update() like what you said. Thanks Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 8:59 GMT+03:00 Simon Rit : > Hi Guangming, > It's not surprising to me that the backprojection is faster than the > forward projection, that's what I expect. If the total time is longer, > that's probably that some individual steps are not included in the total > time. Can you try to add > reader->Update(); > before the line > > itk::TimeProbe totalTimeProbe; > > in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? > > Simon > > > > On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi RTK community, >> i am using SART algorithm to reconstruct an object. >> But in this new RTK version, the time recording seems a little weird: >> the total time is 1219.12s , but adding the time cost in different >> stages is not 1291.12 s. especially for "backprojection" part, only >> 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward >> projection part. BTW, the -f and -b are Joseph and >> VoxelBasedBackProjection, respectively, both multi-threading i think. >> Can anyone tell me what's going on? >> Thanks >> Regards >> Guangming >> >> [image: ???? 1] >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 08:28:28 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 14:28:28 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: I can try. Forward and back projection have the same algorithmic complexity but voxel based backprojection benefits from several optimizations in terms of memory management and computations that makes it faster. The best is to look at the code for further details... although both have far from being optimal. And I did not get the sentence "the backprojection should take much longer time than sart algorithm." because SART contains a backprojection and other steps so SART is obviously longer than the bp alone. Your log is strange and I don't see what steps are not timed that would take most of the time. I did the same test on my computer and here is my result: OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha --dimension 512 OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.288571 s Multiplication by zero: 0.131672 s Forward projection: 34.3612 s Subtraction: 0.203409 s Multiplication by lambda: 0.146459 s Ray box intersection: 1.30755 s Division: 0.187294 s Multiplication by the gating weights: 0 s Displaced detector: 0.278408 s Back projection: 11.8456 s Volume update: 0 s It took... 53.2765 s Simon On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang wrote: > Hi Simon, > Thanks for your reply. > would you pls help and explain why backprojection is expected to take > shorter time than forward projection?? because i was thinking if no caching > step, the backprojection should take much longer time than sart algorithm. > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > consumed of 3 times's sart, which much slower than my own application. > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > shapp-logan projections(512*512 resolution each) > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > -64,-64,-64 -l 0.5 -n 3 --time 1 > > and i will try reader->Update() like what you said. > Thanks > Guangming > > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> Hi Guangming, >> It's not surprising to me that the backprojection is faster than the >> forward projection, that's what I expect. If the total time is longer, >> that's probably that some individual steps are not included in the total >> time. Can you try to add >> reader->Update(); >> before the line >> >> itk::TimeProbe totalTimeProbe; >> >> in rtksart.cxx? It may be that all the reading operations are done but not >> timed in the sart->Update(). Why they are so long, I don't know, is your D: >> drive a network drive? Do you observe the same behavior if you do rtksart 2 >> times in a row? >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> wrote: >>> >>> Hi RTK community, >>> i am using SART algorithm to reconstruct an object. >>> But in this new RTK version, the time recording seems a little weird: >>> the total time is 1219.12s , but adding the time cost in different >>> stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s >>> to reconstruct a 128^3 volume ?? even shorter than forward projection part. >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, >>> both multi-threading i think. >>> Can anyone tell me what's going on? >>> Thanks >>> Regards >>> Guangming >>> >>> >>> Guangming Zang (Alex) >>> King Abdullah University of Science and Technology(KAUST) >>> University of Chinese Academy of Sciences(UCAS) >>> >>> >>> >>> >>> ________________________________ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete this >>> message from your computer system. Any unauthorized use or distribution is >>> prohibited. Please consider the environment before printing this email. >> >> > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 08:50:48 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 15:50:48 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, sorry for the mistake, not"the backprojection should take much longer time than sart algorithm" , but "the backprojection should take much longer time than forward projection in sart algorithm". BTW, how many cores does your computer have?? Mine is 24 cores. is it can explain the reason why it takes much longer time on my computer than yours? Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 15:28 GMT+03:00 Simon Rit : > I can try. Forward and back projection have the same algorithmic > complexity but voxel based backprojection benefits from several > optimizations in terms of memory management and computations that > makes it faster. The best is to look at the code for further > details... although both have far from being optimal. And I did not > get the sentence "the backprojection should take much longer time than > sart algorithm." because SART contains a backprojection and other > steps so SART is obviously longer than the bp alone. > Your log is strange and I don't see what steps are not timed that > would take most of the time. I did the same test on my computer and > here is my result: > > OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > --dimension 512 > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.288571 s > Multiplication by zero: 0.131672 s > Forward projection: 34.3612 s > Subtraction: 0.203409 s > Multiplication by lambda: 0.146459 s > Ray box intersection: 1.30755 s > Division: 0.187294 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.278408 s > Back projection: 11.8456 s > Volume update: 0 s > It took... 53.2765 s > > Simon > > On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > wrote: > > Hi Simon, > > Thanks for your reply. > > would you pls help and explain why backprojection is expected to take > > shorter time than forward projection?? because i was thinking if no > caching > > step, the backprojection should take much longer time than sart > algorithm. > > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > > consumed of 3 times's sart, which much slower than my own application. > > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > > shapp-logan projections(512*512 resolution each) > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > > -64,-64,-64 -l 0.5 -n 3 --time 1 > > > > and i will try reader->Update() like what you said. > > Thanks > > Guangming > > > > > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> > >> Hi Guangming, > >> It's not surprising to me that the backprojection is faster than the > >> forward projection, that's what I expect. If the total time is longer, > >> that's probably that some individual steps are not included in the total > >> time. Can you try to add > >> reader->Update(); > >> before the line > >> > >> itk::TimeProbe totalTimeProbe; > >> > >> in rtksart.cxx? It may be that all the reading operations are done but > not > >> timed in the sart->Update(). Why they are so long, I don't know, is > your D: > >> drive a network drive? Do you observe the same behavior if you do > rtksart 2 > >> times in a row? > >> > >> Simon > >> > >> > >> > >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> wrote: > >>> > >>> Hi RTK community, > >>> i am using SART algorithm to reconstruct an object. > >>> But in this new RTK version, the time recording seems a little weird: > >>> the total time is 1219.12s , but adding the time cost in different > >>> stages is not 1291.12 s. especially for "backprojection" part, only > 16.6051s > >>> to reconstruct a 128^3 volume ?? even shorter than forward projection > part. > >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > respectively, > >>> both multi-threading i think. > >>> Can anyone tell me what's going on? > >>> Thanks > >>> Regards > >>> Guangming > >>> > >>> > >>> Guangming Zang (Alex) > >>> King Abdullah University of Science and Technology(KAUST) > >>> University of Chinese Academy of Sciences(UCAS) > >>> > >>> > >>> > >>> > >>> ________________________________ > >>> This message and its contents, including attachments are intended > solely > >>> for the original recipient. If you are not the intended recipient or > have > >>> received this message in error, please notify me immediately and > delete this > >>> message from your computer system. Any unauthorized use or > distribution is > >>> prohibited. Please consider the environment before printing this email. > >> > >> > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 09:02:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 15:02:03 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: No I expect forward projection to be longer than backprojection although with optimal implementations, it should take about the same time since they have the same complexity. I have 4 cores on my laptop. I don't see how it explains it, try to find out where does SART spend the time. Simon On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang wrote: > Hi Simon, > sorry for the mistake, not"the backprojection should take much longer time > than > sart algorithm" , but "the backprojection should take much longer time than > forward projection in sart algorithm". > > BTW, how many cores does your computer have?? Mine is 24 cores. > is it can explain the reason why it takes much longer time on my computer > than yours? > Regards > Guangming > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> I can try. Forward and back projection have the same algorithmic >> complexity but voxel based backprojection benefits from several >> optimizations in terms of memory management and computations that >> makes it faster. The best is to look at the code for further >> details... although both have far from being optimal. And I did not >> get the sentence "the backprojection should take much longer time than >> sart algorithm." because SART contains a backprojection and other >> steps so SART is obviously longer than the bp alone. >> Your log is strange and I don't see what steps are not timed that >> would take most of the time. I did the same test on my computer and >> here is my result: >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> --dimension 512 >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> 1 >> Recording elapsed time... >> SARTConeBeamReconstructionFilter timing: >> Extraction of projection sub-stacks: 0.288571 s >> Multiplication by zero: 0.131672 s >> Forward projection: 34.3612 s >> Subtraction: 0.203409 s >> Multiplication by lambda: 0.146459 s >> Ray box intersection: 1.30755 s >> Division: 0.187294 s >> Multiplication by the gating weights: 0 s >> Displaced detector: 0.278408 s >> Back projection: 11.8456 s >> Volume update: 0 s >> It took... 53.2765 s >> >> Simon >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> wrote: >> > Hi Simon, >> > Thanks for your reply. >> > would you pls help and explain why backprojection is expected to take >> > shorter time than forward projection?? because i was thinking if no >> > caching >> > step, the backprojection should take much longer time than sart >> > algorithm. >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time >> > consumed of 3 times's sart, which much slower than my own application. >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 >> > shapp-logan projections(512*512 resolution each) >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> > >> > and i will try reader->Update() like what you said. >> > Thanks >> > Guangming >> > >> > >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> >> >> Hi Guangming, >> >> It's not surprising to me that the backprojection is faster than the >> >> forward projection, that's what I expect. If the total time is longer, >> >> that's probably that some individual steps are not included in the >> >> total >> >> time. Can you try to add >> >> reader->Update(); >> >> before the line >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done but >> >> not >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> your D: >> >> drive a network drive? Do you observe the same behavior if you do >> >> rtksart 2 >> >> times in a row? >> >> >> >> Simon >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> wrote: >> >>> >> >>> Hi RTK community, >> >>> i am using SART algorithm to reconstruct an object. >> >>> But in this new RTK version, the time recording seems a little weird: >> >>> the total time is 1219.12s , but adding the time cost in different >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >>> 16.6051s >> >>> to reconstruct a 128^3 volume ?? even shorter than forward projection >> >>> part. >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >>> respectively, >> >>> both multi-threading i think. >> >>> Can anyone tell me what's going on? >> >>> Thanks >> >>> Regards >> >>> Guangming >> >>> >> >>> >> >>> Guangming Zang (Alex) >> >>> King Abdullah University of Science and Technology(KAUST) >> >>> University of Chinese Academy of Sciences(UCAS) >> >>> >> >>> >> >>> >> >>> >> >>> ________________________________ >> >>> This message and its contents, including attachments are intended >> >>> solely >> >>> for the original recipient. If you are not the intended recipient or >> >>> have >> >>> received this message in error, please notify me immediately and >> >>> delete this >> >>> message from your computer system. Any unauthorized use or >> >>> distribution is >> >>> prohibited. Please consider the environment before printing this >> >>> email. >> >> >> >> >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended solely >> > for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> > this >> > message from your computer system. Any unauthorized use or distribution >> > is >> > prohibited. Please consider the environment before printing this email. > > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 10:05:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:05:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, it cost 1200s for SART algorithm at first, and the command are: rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 in which, the projections data(360pro_SL_Vol128_512.mha) is not generated from rtkprojectshepploganphantom , but from my application. though it took long time, but i can got a nice result, And i just tried the command you used, i.e. generated the projections data by rtkprojectshepploganphantom : rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 --sid=500.0 rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 yes, it takes about 56s. but the reconstructed result is weird, the voxel values range from [-142186, 208146] and can not see anything when visualizing it. i believe you got the similar results, which maybe explain why it computes much faster. if i wanna use the projections generated by rtkprojectshepploganphantom , can you give me an example to get a nice results? Best regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 16:02 GMT+03:00 Simon Rit : > No I expect forward projection to be longer than backprojection > although with optimal implementations, it should take about the same > time since they have the same complexity. > I have 4 cores on my laptop. I don't see how it explains it, try to > find out where does SART spend the time. > Simon > > On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang > wrote: > > Hi Simon, > > sorry for the mistake, not"the backprojection should take much longer > time > > than > > sart algorithm" , but "the backprojection should take much longer time > than > > forward projection in sart algorithm". > > > > BTW, how many cores does your computer have?? Mine is 24 cores. > > is it can explain the reason why it takes much longer time on my computer > > than yours? > > Regards > > Guangming > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : > >> > >> I can try. Forward and back projection have the same algorithmic > >> complexity but voxel based backprojection benefits from several > >> optimizations in terms of memory management and computations that > >> makes it faster. The best is to look at the code for further > >> details... although both have far from being optimal. And I did not > >> get the sentence "the backprojection should take much longer time than > >> sart algorithm." because SART contains a backprojection and other > >> steps so SART is obviously longer than the bp alone. > >> Your log is strange and I don't see what steps are not timed that > >> would take most of the time. I did the same test on my computer and > >> here is my result: > >> > >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > >> --dimension 512 > >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > >> 1 > >> Recording elapsed time... > >> SARTConeBeamReconstructionFilter timing: > >> Extraction of projection sub-stacks: 0.288571 s > >> Multiplication by zero: 0.131672 s > >> Forward projection: 34.3612 s > >> Subtraction: 0.203409 s > >> Multiplication by lambda: 0.146459 s > >> Ray box intersection: 1.30755 s > >> Division: 0.187294 s > >> Multiplication by the gating weights: 0 s > >> Displaced detector: 0.278408 s > >> Back projection: 11.8456 s > >> Volume update: 0 s > >> It took... 53.2765 s > >> > >> Simon > >> > >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > >> wrote: > >> > Hi Simon, > >> > Thanks for your reply. > >> > would you pls help and explain why backprojection is expected to take > >> > shorter time than forward projection?? because i was thinking if no > >> > caching > >> > step, the backprojection should take much longer time than sart > >> > algorithm. > >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the > time > >> > consumed of 3 times's sart, which much slower than my own application. > >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > >> > shapp-logan projections(512*512 resolution each) > >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > >> > -64,-64,-64 -l 0.5 -n 3 --time 1 > >> > > >> > and i will try reader->Update() like what you said. > >> > Thanks > >> > Guangming > >> > > >> > > >> > > >> > Guangming Zang (Alex) > >> > King Abdullah University of Science and Technology(KAUST) > >> > University of Chinese Academy of Sciences(UCAS) > >> > > >> > > >> > > >> > > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> >> > >> >> Hi Guangming, > >> >> It's not surprising to me that the backprojection is faster than the > >> >> forward projection, that's what I expect. If the total time is > longer, > >> >> that's probably that some individual steps are not included in the > >> >> total > >> >> time. Can you try to add > >> >> reader->Update(); > >> >> before the line > >> >> > >> >> itk::TimeProbe totalTimeProbe; > >> >> > >> >> in rtksart.cxx? It may be that all the reading operations are done > but > >> >> not > >> >> timed in the sart->Update(). Why they are so long, I don't know, is > >> >> your D: > >> >> drive a network drive? Do you observe the same behavior if you do > >> >> rtksart 2 > >> >> times in a row? > >> >> > >> >> Simon > >> >> > >> >> > >> >> > >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> >> wrote: > >> >>> > >> >>> Hi RTK community, > >> >>> i am using SART algorithm to reconstruct an object. > >> >>> But in this new RTK version, the time recording seems a little > weird: > >> >>> the total time is 1219.12s , but adding the time cost in different > >> >>> stages is not 1291.12 s. especially for "backprojection" part, only > >> >>> 16.6051s > >> >>> to reconstruct a 128^3 volume ?? even shorter than forward > projection > >> >>> part. > >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > >> >>> respectively, > >> >>> both multi-threading i think. > >> >>> Can anyone tell me what's going on? > >> >>> Thanks > >> >>> Regards > >> >>> Guangming > >> >>> > >> >>> > >> >>> Guangming Zang (Alex) > >> >>> King Abdullah University of Science and Technology(KAUST) > >> >>> University of Chinese Academy of Sciences(UCAS) > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> ________________________________ > >> >>> This message and its contents, including attachments are intended > >> >>> solely > >> >>> for the original recipient. If you are not the intended recipient or > >> >>> have > >> >>> received this message in error, please notify me immediately and > >> >>> delete this > >> >>> message from your computer system. Any unauthorized use or > >> >>> distribution is > >> >>> prohibited. Please consider the environment before printing this > >> >>> email. > >> >> > >> >> > >> > > >> > > >> > ________________________________ > >> > This message and its contents, including attachments are intended > solely > >> > for > >> > the original recipient. If you are not the intended recipient or have > >> > received this message in error, please notify me immediately and > delete > >> > this > >> > message from your computer system. Any unauthorized use or > distribution > >> > is > >> > prohibited. Please consider the environment before printing this > email. > > > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 10:12:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:12:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: BTW, the projections are 512*512, and the pixel spacing is 0.5 Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:05 GMT+03:00 Guangming Zang : > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 10:20:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 16:20:12 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Obviously I hadn't looked at the result and/or checked the command line options, sorry. This is an example from the same simulated dataset that gives me a good results: OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.567773 s Multiplication by zero: 0.303715 s Forward projection: 142.305 s Subtraction: 0.445842 s Multiplication by lambda: 0.2663 s Ray box intersection: 5.40366 s Division: 0.535618 s Multiplication by the gating weights: 0 s Displaced detector: 0.415431 s Back projection: 21.3689 s Volume update: 0 s It took... 177.059 s but this doesn't change the content of my previous message. What takes time is probably in your own software, be sure that you update SART inputs before timing it. Simon On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang wrote: > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 11:12:16 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 18:12:16 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Thanks Simon, now it work fine when using projections generated by RTK itself (command rtkprojectshepploganphantom ). for 1 iteration of SART to reconstruct 128^3 size volume, it took only 19s, which gives nice results as well. Thanks again. Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:20 GMT+03:00 Simon Rit : > Obviously I hadn't looked at the result and/or checked the command line > options, sorry. This is an example from the same simulated dataset that > gives me a good results: > > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f > Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n > 3 --time 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.567773 s > Multiplication by zero: 0.303715 s > Forward projection: 142.305 s > Subtraction: 0.445842 s > Multiplication by lambda: 0.2663 s > Ray box intersection: 5.40366 s > Division: 0.535618 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.415431 s > Back projection: 21.3689 s > Volume update: 0 s > It took... 177.059 s > > but this doesn't change the content of my previous message. What takes > time is probably in your own software, be sure that you update SART inputs > before timing it. > Simon > > On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon, >> it cost 1200s for SART algorithm at first, and the command are: >> rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd= >> 725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" >> >> rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 >> >> in which, the projections data(360pro_SL_Vol128_512.mha) is not >> generated from rtkprojectshepploganphantom , but from my application. >> though it took long time, but i can got a nice result, >> >> >> And i just tried the command you used, i.e. generated the projections >> data by rtkprojectshepploganphantom : >> >> rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 >> --sid=500.0 >> rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 >> rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b >> VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 >> --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 >> yes, it takes about 56s. >> but the reconstructed result is weird, the voxel values range from >> [-142186, 208146] and can not see anything when visualizing it. >> i believe you got the similar results, which maybe explain why it >> computes much faster. >> >> if i wanna use the projections generated by rtkprojectshepploganphantom >> , can you give me an example to get a nice results? >> >> Best regards >> Guangming >> >> >> >> >> >> >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> 2015-07-27 16:02 GMT+03:00 Simon Rit : >> >>> No I expect forward projection to be longer than backprojection >>> although with optimal implementations, it should take about the same >>> time since they have the same complexity. >>> I have 4 cores on my laptop. I don't see how it explains it, try to >>> find out where does SART spend the time. >>> Simon >>> >>> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >>> wrote: >>> > Hi Simon, >>> > sorry for the mistake, not"the backprojection should take much longer >>> time >>> > than >>> > sart algorithm" , but "the backprojection should take much longer time >>> than >>> > forward projection in sart algorithm". >>> > >>> > BTW, how many cores does your computer have?? Mine is 24 cores. >>> > is it can explain the reason why it takes much longer time on my >>> computer >>> > than yours? >>> > Regards >>> > Guangming >>> > >>> > Guangming Zang (Alex) >>> > King Abdullah University of Science and Technology(KAUST) >>> > University of Chinese Academy of Sciences(UCAS) >>> > >>> > >>> > >>> > >>> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >>> >> >>> >> I can try. Forward and back projection have the same algorithmic >>> >> complexity but voxel based backprojection benefits from several >>> >> optimizations in terms of memory management and computations that >>> >> makes it faster. The best is to look at the code for further >>> >> details... although both have far from being optimal. And I did not >>> >> get the sentence "the backprojection should take much longer time than >>> >> sart algorithm." because SART contains a backprojection and other >>> >> steps so SART is obviously longer than the bp alone. >>> >> Your log is strange and I don't see what steps are not timed that >>> >> would take most of the time. I did the same test on my computer and >>> >> here is my result: >>> >> >>> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >>> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >>> >> --dimension 512 >>> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >>> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >>> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >>> >> 1 >>> >> Recording elapsed time... >>> >> SARTConeBeamReconstructionFilter timing: >>> >> Extraction of projection sub-stacks: 0.288571 s >>> >> Multiplication by zero: 0.131672 s >>> >> Forward projection: 34.3612 s >>> >> Subtraction: 0.203409 s >>> >> Multiplication by lambda: 0.146459 s >>> >> Ray box intersection: 1.30755 s >>> >> Division: 0.187294 s >>> >> Multiplication by the gating weights: 0 s >>> >> Displaced detector: 0.278408 s >>> >> Back projection: 11.8456 s >>> >> Volume update: 0 s >>> >> It took... 53.2765 s >>> >> >>> >> Simon >>> >> >>> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >>> >> wrote: >>> >> > Hi Simon, >>> >> > Thanks for your reply. >>> >> > would you pls help and explain why backprojection is expected to >>> take >>> >> > shorter time than forward projection?? because i was thinking if no >>> >> > caching >>> >> > step, the backprojection should take much longer time than sart >>> >> > algorithm. >>> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >>> time >>> >> > consumed of 3 times's sart, which much slower than my own >>> application. >>> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >>> 360 >>> >> > shapp-logan projections(512*512 resolution each) >>> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >>> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >>> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >>> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >>> >> > >>> >> > and i will try reader->Update() like what you said. >>> >> > Thanks >>> >> > Guangming >>> >> > >>> >> > >>> >> > >>> >> > Guangming Zang (Alex) >>> >> > King Abdullah University of Science and Technology(KAUST) >>> >> > University of Chinese Academy of Sciences(UCAS) >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit >> >: >>> >> >> >>> >> >> Hi Guangming, >>> >> >> It's not surprising to me that the backprojection is faster than >>> the >>> >> >> forward projection, that's what I expect. If the total time is >>> longer, >>> >> >> that's probably that some individual steps are not included in the >>> >> >> total >>> >> >> time. Can you try to add >>> >> >> reader->Update(); >>> >> >> before the line >>> >> >> >>> >> >> itk::TimeProbe totalTimeProbe; >>> >> >> >>> >> >> in rtksart.cxx? It may be that all the reading operations are done >>> but >>> >> >> not >>> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >>> >> >> your D: >>> >> >> drive a network drive? Do you observe the same behavior if you do >>> >> >> rtksart 2 >>> >> >> times in a row? >>> >> >> >>> >> >> Simon >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >>> >> >> wrote: >>> >> >>> >>> >> >>> Hi RTK community, >>> >> >>> i am using SART algorithm to reconstruct an object. >>> >> >>> But in this new RTK version, the time recording seems a little >>> weird: >>> >> >>> the total time is 1219.12s , but adding the time cost in >>> different >>> >> >>> stages is not 1291.12 s. especially for "backprojection" part, >>> only >>> >> >>> 16.6051s >>> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >>> projection >>> >> >>> part. >>> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >>> >> >>> respectively, >>> >> >>> both multi-threading i think. >>> >> >>> Can anyone tell me what's going on? >>> >> >>> Thanks >>> >> >>> Regards >>> >> >>> Guangming >>> >> >>> >>> >> >>> >>> >> >>> Guangming Zang (Alex) >>> >> >>> King Abdullah University of Science and Technology(KAUST) >>> >> >>> University of Chinese Academy of Sciences(UCAS) >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> ________________________________ >>> >> >>> This message and its contents, including attachments are intended >>> >> >>> solely >>> >> >>> for the original recipient. If you are not the intended recipient >>> or >>> >> >>> have >>> >> >>> received this message in error, please notify me immediately and >>> >> >>> delete this >>> >> >>> message from your computer system. Any unauthorized use or >>> >> >>> distribution is >>> >> >>> prohibited. Please consider the environment before printing this >>> >> >>> email. >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > ________________________________ >>> >> > This message and its contents, including attachments are intended >>> solely >>> >> > for >>> >> > the original recipient. If you are not the intended recipient or >>> have >>> >> > received this message in error, please notify me immediately and >>> delete >>> >> > this >>> >> > message from your computer system. Any unauthorized use or >>> distribution >>> >> > is >>> >> > prohibited. Please consider the environment before printing this >>> email. >>> > >>> > >>> > >>> > ________________________________ >>> > This message and its contents, including attachments are intended >>> solely for >>> > the original recipient. If you are not the intended recipient or have >>> > received this message in error, please notify me immediately and >>> delete this >>> > message from your computer system. Any unauthorized use or >>> distribution is >>> > prohibited. Please consider the environment before printing this email. >>> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From infrombox at yandex.ru Tue Jul 28 04:30:22 2015 From: infrombox at yandex.ru (1 1) Date: Tue, 28 Jul 2015 15:30:22 +0700 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: <2213081438072222@web8j.yandex.ru> Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. But program which i use reads meta images with MET_SHORT pixel type only. Is there easy way to setting it and get volume with different from MET_FLOAT pixel type ? If not, could you advice me, what the filter i should to do, for example as post process after reconstruction ala MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward operation of LUTbasedVariableI0RawToAttenuationImageFilter ? Thanks. From simon.rit at creatis.insa-lyon.fr Tue Jul 28 04:56:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 10:56:54 +0200 Subject: [Rtk-users] volume with diffieret pixel type In-Reply-To: <2213081438072222@web8j.yandex.ru> References: <2213081438072222@web8j.yandex.ru> Message-ID: Hi, This is more an ITK question than a RTK question. Yes, we use float by default in our applications. You can cast the image to any type before writing using itk::CastImageFilter but you'll have to modify the applications and, of course, there is a loss of information. If you don't want to program it, you can use any other software, e.g. in vv right clik on your image after opening and use the convert to option. Simon On Tue, Jul 28, 2015 at 10:30 AM, 1 1 wrote: > Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. > But program which i use reads meta images with MET_SHORT pixel type only. > Is there easy way to setting it and get volume with different from > MET_FLOAT pixel type ? If not, could you advice me, what the filter i > should to do, for example as post process after reconstruction ala > MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward > operation of LUTbasedVariableI0RawToAttenuationImageFilter image, float image> ? > Thanks. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pconneely020186 at gmail.com Tue Jul 28 12:05:29 2015 From: pconneely020186 at gmail.com (peter conneely) Date: Tue, 28 Jul 2015 17:05:29 +0100 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: "peter conneely" Date: 24 Jul 2015 11:07 Subject: Issue running FDK reconstruction algorithm To: Cc: Hi, I'm having trouble running the FDK reconstruction alogrithm on Elekta and Varian data sets. The algorithm does work when I try the shepp-logan example. When I initially ran the application I included the (') around .*.his. and got the following lines. [image: Inline image 1] when I try to run with the (') removed it finds the 669 files but then the application stops working. I have tried adding registry edits to run exe and have tried switching of dep. Neither of these work I am not sure what is going wrong and how to fix it. My system properties are as follows. Processor: Intel Pentium CPU P6100 @ 2.00 Ghz RAM: 3.00 GB GPU: Intel HD Graphics Systems type 64 Bit. Thanks and Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Tue Jul 28 12:46:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 18:46:17 +0200 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: Hi, I guess the quotes are OS depedent, maybe you need double quotes on Windows. It's strange that you don't get an error message. Are you sure it crashed? If yes, have you checked the elektaGeometry file? Does it have 669 projection sections as expected? Or maybe it's a memory issue, try the --lowmem option. Simon On Tue, Jul 28, 2015 at 6:05 PM, peter conneely wrote: > ---------- Forwarded message ---------- > From: "peter conneely" > Date: 24 Jul 2015 11:07 > Subject: Issue running FDK reconstruction algorithm > To: > Cc: > > Hi, > > I'm having trouble running the FDK reconstruction alogrithm on Elekta and > Varian data sets. The algorithm does work when I try the shepp-logan > example. > > When I initially ran the application I included the (') around .*.his. and > got the following lines. > [image: Inline image 1] > when I try to run with the (') removed it finds the 669 files but then the > application stops working. I have tried adding registry edits to run exe > and have tried switching of dep. Neither of these work I am not sure what > is going wrong and how to fix it. > > My system properties are as follows. > Processor: Intel Pentium CPU P6100 @ 2.00 Ghz > RAM: 3.00 GB > GPU: Intel HD Graphics > Systems type 64 Bit. > > Thanks and Regards, > Peter > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Tue Jul 28 13:38:45 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Tue, 28 Jul 2015 20:38:45 +0300 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: Hi, in ITK, the default type are described in *Utilities\MetaIO\metaTypes.h* MET_CHAR, MET_UCHAR ?,? ?? MET_SHORT, MET_USHORT, MET_INT,=20 MET_UINT,=20 MET_FLOAT,=20 MET_DOUBLE, ?and for .mha file, the header file includes information like: ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = 0 0 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 1 1 1 DimSize = 128 128 128 ElementType = MET_FLOAT ElementDataFile = LOCAL? ?And recently i just programmed to read and write .mha files. below is the code. u can just replace ElementType from ? MET_FLOAT ? to ? ? MET_SHORT ? in your application. hope this helps: #include "stdafx.h" #include #include #include #include #include #include using namespace std; int _tmain(int argc, _TCHAR* argv[]) { int m_Dims[3]; float spacing[3]; m_Dims[0]=128; m_Dims[1]=128; m_Dims[2]=128; spacing[0]=spacing[1]=spacing[2]=1.0f; ostringstream buffer, buffer1, buffer2, buf3; buffer << spacing[0]; string sp= buffer.str(); buffer1 << spacing[1]; string sp1 = buffer1.str(); buffer2 << spacing[2]; string sp2 = buffer2.str(); string ElementSpacing ="ElementSpacing= "+sp+" "+sp1+" "+sp2+"\n"; // int ss=1000; char temp[64], temp1[64],temp2[64]; string str; sprintf(temp, "%d", m_Dims[0]); sprintf(temp1, "%d", m_Dims[1]); sprintf(temp2, "%d", m_Dims[2]); string s(temp),s1(temp1),s2(temp2); string DimSize="DimSize= "+s+" "+s1+" "+s2+"\n"; string Mywritefile="ObjectType = Image\nNDims = 3\nBinaryData = True\nBinaryDataByteOrderMSB = False \nCompressedData = False \nTransformMatrix = 1 0 0 0 1 0 0 0 1 \n" ; Mywritefile+="Offset = 0 0 0 \nCenterOfRotation = 0 0 0 \nAnatomicalOrientation = RAI \n"; Mywritefile+=ElementSpacing+DimSize+"ElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; // ElementSpacing = 1 1 1 \nDimSize = 128 128 128 \nElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; int leng=Mywritefile.length(); cout< From simon.rit at creatis.insa-lyon.fr Wed Jul 29 08:53:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 29 Jul 2015 14:53:34 +0200 Subject: [Rtk-users] RTK images make the cover of Medical Physics Message-ID: See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Wed Jul 29 09:07:01 2015 From: theday79 at gmail.com (Yang K Park) Date: Wed, 29 Jul 2015 09:07:01 -0400 Subject: [Rtk-users] RTK images make the cover of Medical Physics In-Reply-To: References: Message-ID: <001801d0c9ff$76797860$636c6920$@gmail.com> Hi Simon, Thank you so much for the congrats! This is my great honor and I?d like to thank all the RTK developers and community members for their helps on this achievement! Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: Wednesday, July 29, 2015 8:54 AM To: rtk-users at public.kitware.com Subject: [Rtk-users] RTK images make the cover of Medical Physics See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Thu Jul 30 08:16:38 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Thu, 30 Jul 2015 15:16:38 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK Message-ID: Hi Simon and Chao, i am currently do some comparisons between different reconstruction methods for Shapp-Logan dataset. the commands are: rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=955.4050067 --sid=500.0 rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha --dimension 512,512 when using FDK or SART algorithm from RTK, I can got pretty good results indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 and levels as 1.04 for all results got). When running ADMMTV command below, though the geometry is as same as SART and FDK, the result got from ADMM looks weird.(pls see attached central slice of ground truth and ADMM, same contrast with other algorithm) rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 [image: ???? 1][image: ???? 2] Is it because the CG algorithm used by ADMM, or parameters setting issues here?? if it is parameters setting problem , would you help me and give a nice values for alpha and bate used here? BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already (including default value) Thanks and regards Guangming ?? *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ? -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 31 01:55:32 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 31 Jul 2015 07:55:32 +0200 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi, It looks to me that you haven't converged. I'm not the specialist of this algorithm and the specialist won't be near a computer in the coming weeks but when I try with more iterations in the data attachment term: rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 it's more satisfactory. There are rings at the top and the bottom of the cone-beam which should be reduced with more TV (greater alpha, see doc here ) or with a finer spacing (see this publication ). Simon On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang wrote: > Hi Simon and Chao, > > i am currently do some comparisons between different reconstruction > methods for Shapp-Logan dataset. > > the commands are: > > rtksimulatedgeometry -n 360 --arc -360 -o > geo.xml --sdd=955.4050067 --sid=500.0 > > rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha > --dimension 512,512 > > > > when using FDK or SART algorithm from RTK, I can got pretty good results > indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 > and levels as 1.04 for all results got). When running ADMMTV command below, > though the geometry is as same as SART and FDK, the result got from ADMM > looks weird.(pls see attached central slice of ground truth and ADMM, same > contrast with other algorithm) > > rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o > SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 > --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 > > [image: ???? 1][image: ???? 2] > > Is it because the CG algorithm used by ADMM, or parameters setting issues > here?? if it is parameters setting problem , would you help me and give a > nice values for alpha and bate used here? > > BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already > (including default value) > > Thanks and regards > > Guangming > > > ?? > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > ? > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Fri Jul 31 09:46:41 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 31 Jul 2015 16:46:41 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi simon, i see, thanks for the help and explanation. after following your advice, it works fine now. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-31 8:55 GMT+03:00 Simon Rit : > Hi, > It looks to me that you haven't converged. I'm not the specialist of this > algorithm and the specialist won't be near a computer in the coming weeks > but when I try with more iterations in the data attachment term: > rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml > --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 > it's more satisfactory. There are rings at the top and the bottom of the > cone-beam which should be reduced with more TV (greater alpha, see doc > here > ) > or with a finer spacing (see this publication > ). > Simon > > On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon and Chao, >> >> i am currently do some comparisons between different reconstruction >> methods for Shapp-Logan dataset. >> >> the commands are: >> >> rtksimulatedgeometry -n 360 --arc -360 -o >> geo.xml --sdd=955.4050067 --sid=500.0 >> >> rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha >> --dimension 512,512 >> >> >> >> when using FDK or SART algorithm from RTK, I can got pretty good results >> indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 >> and levels as 1.04 for all results got). When running ADMMTV command below, >> though the geometry is as same as SART and FDK, the result got from ADMM >> looks weird.(pls see attached central slice of ground truth and ADMM, same >> contrast with other algorithm) >> >> rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o >> SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 >> --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 >> >> [image: ???? 1][image: ???? 2] >> >> Is it because the CG algorithm used by ADMM, or parameters setting issues >> here?? if it is parameters setting problem , would you help me and give a >> nice values for alpha and bate used here? >> >> BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already >> (including default value) >> >> Thanks and regards >> >> Guangming >> >> >> ?? >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> ? >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 1 08:45:35 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 1 Jul 2015 14:45:35 +0200 Subject: [Rtk-users] Release of RTK v1.1.0 Message-ID: Dear RTK users, RTK v1.1.0 has been released today, about 14 months after RTK v1.0.0. The main features that have been developed since the previous release are: - SimpleRTK to run RTK filters (even the CUDA ones) from python scripts, C# code, and more - new projection pre-processing options (i0 calculation, scatter correction, water pre-correction) - extraction of the respiratory phase from cone-beam projections - linear programming for field-of-view computation based on a third party software, lp solve 5.5 - management of off-center detector in iterative methods - new iterative 3D and 4D reconstruction methods with Daubechies wavelets regularization - new iterative 4D reconstruction method with motion-aware regularization - reduction of memory footprint, especially GPU memory - many new CUDA filters - more robust (many bugs and memory leaks fixed) - use of MathJax to display formulas in the documentation, e.g., here . Many thanks to the increasing number of contributors, in alphabetical order: Ben Champion, Chao Wu, Cyril Mory, I Putu Susila, Julien Jomier, Marc Vila, Mathieu Dupont, Matt Clarkson, Peter Keuschnigg, S?bastien Brousmiche, Simon Rit, Tristan Coulange, Yang K Park. We don't focus on releases since we have a public github repository that we try to keep stable, I still recommend the use of the master HEAD over releases to enjoy the new RTK developments before their release. We still have a few on-going projects for which we will use and enhance RTK. Simon (for the RTK consortium) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 1 15:39:14 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 1 Jul 2015 21:39:14 +0200 Subject: [Rtk-users] loading projection images for sart Message-ID: Hello, I got compiled the ITK and RTK with help of cmake. I also had a look at the examples coming with RTK. I want to run a simple SART and got projection images in the format PNG and BMP. So I create an instance of the ThreeDcircularProjectionGeometry, SARTConeBeamReconstructionFilter and add the geometric projection data. rtk::ThreeDCircularProjectionGeometry::Pointer geometry; geometry = rtk::ThreeDCircularProjectionGeometry::New(); geometry->AddProjection(??) rtk::SARTConeBeamReconstructionFilter::Pointer sart = rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); How to add a stack of images to the SART reconstruction, i.e. std::vector images ? I got xray projections in png format. There is a method in the SART class called SetInput. But according tot he examples it is used to set a volume. Does anybody alread wrote a small piece of code that loads some images from the disk and put them into the SART reconstruction ? Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 2 12:19:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 2 Jul 2015 18:19:36 +0200 Subject: [Rtk-users] loading projection images for sart In-Reply-To: References: Message-ID: Hi, The stack of 2D images is passed via a 3D image. Look at the rtksart application for example. A way to read this from a set of file names is to use itk::ImageSeriesReader as done in rtk::ProjectionsReader. You should be able to understand how it works by looking at the existing RTK applications in the applications subfolders. Simon On Wed, Jul 1, 2015 at 9:39 PM, Robert Callie? wrote: > Hello, > > I got compiled the ITK and RTK with help of cmake. I also had a look > > at the examples coming with RTK. I want to run a simple SART and > > got projection images in the format PNG and BMP. > > > > So I create an instance of the ThreeDcircularProjectionGeometry, > SARTConeBeamReconstructionFilter > > and add the geometric projection data. > > > > rtk::ThreeDCircularProjectionGeometry::Pointer geometry; > > geometry = rtk::ThreeDCircularProjectionGeometry::New(); > > geometry->AddProjection(??) > > > > rtk::SARTConeBeamReconstructionFilter::Pointer sart = > rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); > > > > How to add a stack of images to the SART reconstruction, i.e. > std::vector images ? > > I got xray projections in png format. > > > > There is a method in the SART class called SetInput. But according tot he > examples it is used to set a volume. > > > > Does anybody alread wrote a small piece of code that loads some images > from the disk and put them into the SART reconstruction ? > > > > Regards, > > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Fri Jul 3 16:28:11 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 3 Jul 2015 23:28:11 +0300 Subject: [Rtk-users] Remote Control Issue in new RTK version Message-ID: Dear RTK community, There is some bug in RTK 1.1 version. That?s : When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 but i did not use Cuda at all.. What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. So i think it is some problem caused by itk ?? can we fix this issue?? Thanks for help in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Sat Jul 4 10:12:03 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Sat, 4 Jul 2015 17:12:03 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. Thanks for the help, Chao. *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ---------- Forwarded message ---------- From: Chao Wu Date: 2015-07-04 0:04 GMT+03:00 Subject: Re: Remote Control Issue To: Guangming Zang Cc: rtk-users-request at public.kitware.com, Simon Rit < simon.rit at creatis.insa-lyon.fr> Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. Regards, Chao Sent from Samsung Galaxy Note 3 2015?7?3? 10:26 PM? "Guangming Zang" ??? > Dear RTK community, > > There is some bug in RTK 1.1 version. That?s : > > When i run commands In 1.1 version with my computer in the lab, RTK works > fine, but when i use my laptop at home to remote control the computer in > the lab, it does not work. i.e., no matter the command are (rtkfdk, > ADMM,SART ?), an error is always shown: > > ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 > @ unknown : Cuda Error #3 > > but i did not use Cuda at all.. > > What?s more, when i run the 1.0 version RTK , it works well and no bug in > remoter control mode. > > So i think it is some problem caused by itk ?? can we fix this issue?? > > Thanks for help in advance > > > Regards > > Guangming > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Sat Jul 4 10:19:32 2015 From: ghostcz at hotmail.com (louie L) Date: Sat, 4 Jul 2015 16:19:32 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: I think because in most cases people use their graphics in TCC mode for scientific computations or don't use gpu at all where the rtk_use_cuda is false. Cheers, Louie Sent from my iOS > On 04 Jul 2015, at 16:12, Guangming Zang wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > > 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> Dear RTK community, >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> >> Regards >> >> Guangming >> >> Guangming Zang (Alex) >> King Abdullah University of Science and Technology(KAUST) >> University of Chinese Academy of Sciences(UCAS) >> >> >> >> >> This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > > > This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Mon Jul 6 05:32:18 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 6 Jul 2015 11:32:18 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Hi Guangming and all, Thanks for reporting this change of behavior. My first answer is that what you find simple is not so simple... but you're right, v1.0.0 allowed to compile RTK with CUDA and to run it without a CUDA device. After a bit of trakcing, I found that the change of behavior has been introduced with this patch so you can blame me. It has now fixed this issue with this patch , which seems to work on my laptop, I hope it does on your computer as well. I can't help you with the fact that you can't run CUDA software with remote control. Simon On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > I think because in most cases people use their graphics in TCC mode for > scientific computations or don't use gpu at all where the rtk_use_cuda is > false. > Cheers, > > Louie > > Sent from my iOS > > On 04 Jul 2015, at 16:12, Guangming Zang > wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes > to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is > defined, then if CUDA device is not available this error will occur. When > using MS remote desktop, graphical card and driver are bypassed unless it > is Tesla cards working in TCC mode. You can either compile exes without > CUDA for remote desktop, or try other graphic-based remote desktop software > like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > 2015?7?3? 10:26 PM? "Guangming Zang" ??? > >> Dear RTK community, >> >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works >> fine, but when i use my laptop at home to remote control the computer in >> the lab, it does not work. i.e., no matter the command are (rtkfdk, >> ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >> @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in >> remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> Regards >> >> Guangming >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 6 06:19:10 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 6 Jul 2015 13:19:10 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Thanks all for your help,Simon. I will try it again when i am at home :) As for using Cuda in remote control, i can handle it:just like what Chao said, change lab computer to TCC. What confused me at the beginning is that a cuda error shown while i did not call cuda at all, and thanks for fixing it. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-06 12:32 GMT+03:00 Simon Rit : > Hi Guangming and all, > Thanks for reporting this change of behavior. My first answer is that what > you find simple is not so simple... but you're right, v1.0.0 allowed to > compile RTK with CUDA and to run it without a CUDA device. After a bit of > trakcing, I found that the change of behavior has been introduced with this > patch > > so you can blame me. It has now fixed this issue with this patch > , > which seems to work on my laptop, I hope it does on your computer as well. > I can't help you with the fact that you can't run CUDA software with > remote control. > Simon > > On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > >> I think because in most cases people use their graphics in TCC mode for >> scientific computations or don't use gpu at all where the rtk_use_cuda is >> false. >> Cheers, >> >> Louie >> >> Sent from my iOS >> >> On 04 Jul 2015, at 16:12, Guangming Zang >> wrote: >> >> Ok, i see. Though i still do not understand why in new version rtk >> changes to call cudaimages, not keeping it simple like before. >> Thanks for the help, Chao. >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ---------- Forwarded message ---------- >> From: Chao Wu >> Date: 2015-07-04 0:04 GMT+03:00 >> Subject: Re: Remote Control Issue >> To: Guangming Zang >> Cc: rtk-users-request at public.kitware.com, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> >> >> Now in many exes cudaimage is the default image type if rtk_use_cuda is >> defined, then if CUDA device is not available this error will occur. When >> using MS remote desktop, graphical card and driver are bypassed unless it >> is Tesla cards working in TCC mode. You can either compile exes without >> CUDA for remote desktop, or try other graphic-based remote desktop software >> like vnc or teamviewer. >> >> Regards, Chao >> Sent from Samsung Galaxy Note 3 >> 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> >>> Dear RTK community, >>> >>> There is some bug in RTK 1.1 version. That?s : >>> >>> When i run commands In 1.1 version with my computer in the lab, RTK >>> works fine, but when i use my laptop at home to remote control the >>> computer in the lab, it does not work. i.e., no matter the command are >>> (rtkfdk, ADMM,SART ?), an error is always shown: >>> >>> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >>> @ unknown : Cuda Error #3 >>> >>> but i did not use Cuda at all.. >>> >>> What?s more, when i run the 1.0 version RTK , it works well and no bug >>> in remoter control mode. >>> >>> So i think it is some problem caused by itk ?? can we fix this issue?? >>> >>> Thanks for help in advance >>> >>> >>> Regards >>> >>> Guangming >>> *Guangming Zang (Alex)* >>> *King Abdullah University of Science and Technology(KAUST)* >>> *University of Chinese Academy of Sciences(UCAS)* >>> >>> >>> >>> >>> ------------------------------ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete >>> this message from your computer system. Any unauthorized use or >>> distribution is prohibited. Please consider the environment before printing >>> this email. >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Wed Jul 8 22:26:29 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Wed, 8 Jul 2015 19:26:29 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question Message-ID: Hi, I have a question from you about the CT reconstruction, I would really appreciate if you can help me with this. I have the geometry as described in following and I am trying to run the rtkfdk code from RTK. % parameters % % % % % % % param.nx = 500; % number of voxels param.ny = 500; param.nz = 500; param.sx = 5000; % mm (real size) param.sy = 5000; % mm param.sz = 5000; % mm %The real detector panel pixel density (number of pixels) param.nu = 36; % number of pixels param.nv = 100; % Detector setting (real size) param.su = 7200; % mm (real size) param.sv = 9200; % mm % X-ray source and detector setting param.DSD = 32900; % Distance source to detector param.DSO = 27400; % X-ray source to object axis distance % angle setting param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) param.dang = 5; % angular step size (deg) param.deg = 0:param.dang:360-1; % you can change param.deg = param.deg*param.dir; param.nProj = length(param.deg); param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than 360 deg -> param.parker=1 param.filter='ram-lak'; % high pass filter param.dx = param.sx/param.nx; % single voxel size param.dy = param.sy/param.ny; param.dz = param.sz/param.nz; param.du = param.su/param.nu; param.dv = param.sv/param.nv; param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) % Geometry calculation % % % param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : 360). But I got confused how to set the geometry parameters in RTK I followed the rtkfdk tutorial but I can?t get any result using this method I did the following: 1- Create geometry.xml using these parameters: nproj = 72 ; first_angle = 0 ; arc = 360 ; sid = 27400 ; sdd = 32900 ; proj_iso_x = 0; proj_iso_y = 0; out_angle = 0 ; in_angle = 0 ; source_x = 0; source_y = 0 ; 2- Create my own mha file (WriteMhaFile.m) from my projection array (36*100*72) using a matlab code with following properties: Voxel size = [0.1 0.1 0.1] Offset = [1 1 1] 3- Then run the: rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 --dimension 500 Could you please tell me if I am setting the geometry correctly? Also, is there any other way to create my own mha file? Thank you in advance and looking forward to hear back from you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 02:23:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 08:23:36 +0200 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Hi, We can try to help but we need to understand your geometry... Where does it come from by the way? If I understand your geometry correctly, I would say : - sid, sdd, nproj, arc are correct, - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 and you have 36x100 pixels, then the pixel size is [200,92,1] (last dimension is not used so anything). For the volume, if your volume is 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and not 0.1. - offset of projections is probably wrong. If you want to have a centered projections, you'll need something like (-3500, -554, 0). You can set is to 0 and put those values in proj_iso_x and proj_iso_y. Regarding mha file, you can write mha files in many ways, using SimpleRTK, matlab or writing an ITK code. Good luck! Simon On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah wrote: > Hi, > > I have a question from you about the CT reconstruction, I would really > appreciate if you can help me with this. > > I have the geometry as described in following and I am trying to run the > rtkfdk code from RTK. > > > % parameters % % % % % % % > > param.nx = 500; % number of voxels > param.ny = 500; > param.nz = 500; > > > param.sx = 5000; % mm (real size) > param.sy = 5000; % mm > param.sz = 5000; % mm > > > %The real detector panel pixel density (number of pixels) > param.nu = 36; % number of pixels > param.nv = 100; > > % Detector setting (real size) > param.su = 7200; % mm (real size) > param.sv = 9200; % mm > > > % X-ray source and detector setting > param.DSD = 32900; % Distance source to detector > param.DSO = 27400; % X-ray source to object axis distance > > > % angle setting > param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) > param.dang = 5; % angular step size (deg) > param.deg = 0:param.dang:360-1; % you can change > param.deg = param.deg*param.dir; > param.nProj = length(param.deg); > > param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than > 360 deg -> param.parker=1 > > param.filter='ram-lak'; % high pass filter > > > param.dx = param.sx/param.nx; % single voxel size > param.dy = param.sy/param.ny; > param.dz = param.sz/param.nz; > param.du = param.su/param.nu; > param.dv = param.sv/param.nv; > param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) > > > % Geometry calculation % % % > param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; > param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; > param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; > param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; > param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; > > > > So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : > 360). > But I got confused how to set the geometry parameters in RTK > I followed the rtkfdk tutorial but I can?t get any result using this method > > I did the following: > > 1- Create geometry.xml using these parameters: > > nproj = 72 ; > first_angle = 0 ; > arc = 360 ; > sid = 27400 ; > sdd = 32900 ; > proj_iso_x = 0; > proj_iso_y = 0; > out_angle = 0 ; > in_angle = 0 ; > source_x = 0; > source_y = 0 ; > > 2- Create my own mha file (WriteMhaFile.m) from my projection array > (36*100*72) using a matlab code with following properties: > Voxel size = [0.1 0.1 0.1] > Offset = [1 1 1] > > > 3- Then run the: > rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 > --dimension 500 > > > Could you please tell me if I am setting the geometry correctly? > Also, is there any other way to create my own mha file? > > Thank you in advance and looking forward to hear back from you. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 12:12:01 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 18:12:01 +0200 Subject: [Rtk-users] RTK training In-Reply-To: <55816290.1010807@uclouvain.be> References: <55816290.1010807@uclouvain.be> Message-ID: Dear RTK users, We have finally set a date for the RTK training, Wednesday, Nov 18 2015 in Lyon (France). The training will be organised by Kitware, go to this page for the registration: http://formations.kitware.fr/browse/116 We will do both user and developer sessions during the training. Since it's the first time that we do the training, we will tailor the balance between the two according to the wishes of registered people. The rest of the information should be available on the website but let us know if you need more information, we are still building the webpage and we'll be happy to improve it. We're looking forward to this new training and we'll do our best to meet your expectations, Simon On Wed, Jun 17, 2015 at 2:05 PM, Cyril Mory wrote: > Dear RTK users, > > The first RTK training is being planned at this very moment. It should > take place in November in Lyon, and be hosted by Kitware. The exact date > has not yet been decided, but will be available soon. > > We need your help to decide what to focus this training on. The choice is > mainly between two options: > - if most trainees want to learn how to use RTK, then we will focus on the > command-line tools and on python + Simple RTK > - if most trainees want to learn how to develop within RTK, modify and > enrich it, then we will focus on software architecture, detailed filter > description, ITK pipeline management, CUDA filters, etc... > > Please let us know which of these choices would best suit your needs. > > Looking forward, > Cyril > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Thu Jul 9 17:59:05 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Thu, 9 Jul 2015 14:59:05 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Simon, Thank you. I think now I understand how the whole geometry is defined in RTK. The projection is based on one experiment I am doing using different simulation techniques. Again thank you for your help. Best, Ali On Wed, Jul 8, 2015 at 11:23 PM, Simon Rit wrote: > Hi, > We can try to help but we need to understand your geometry... Where does > it come from by the way? If I understand your geometry correctly, I would > say : > - sid, sdd, nproj, arc are correct, > - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 > and you have 36x100 pixels, then the pixel size is [200,92,1] (last > dimension is not used so anything). For the volume, if your volume is > 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and > not 0.1. > - offset of projections is probably wrong. If you want to have a centered > projections, you'll need something like (-3500, -554, 0). You can set is to > 0 and put those values in proj_iso_x and proj_iso_y. > Regarding mha file, you can write mha files in many ways, using SimpleRTK, > matlab or writing an ITK code. > Good luck! > Simon > > On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah > wrote: > >> Hi, >> >> I have a question from you about the CT reconstruction, I would really >> appreciate if you can help me with this. >> >> I have the geometry as described in following and I am trying to run the >> rtkfdk code from RTK. >> >> >> % parameters % % % % % % % >> >> param.nx = 500; % number of voxels >> param.ny = 500; >> param.nz = 500; >> >> >> param.sx = 5000; % mm (real size) >> param.sy = 5000; % mm >> param.sz = 5000; % mm >> >> >> %The real detector panel pixel density (number of pixels) >> param.nu = 36; % number of pixels >> param.nv = 100; >> >> % Detector setting (real size) >> param.su = 7200; % mm (real size) >> param.sv = 9200; % mm >> >> >> % X-ray source and detector setting >> param.DSD = 32900; % Distance source to detector >> param.DSO = 27400; % X-ray source to object axis distance >> >> >> % angle setting >> param.dir = +1; % gantry rotating direction (clock wise/ counter >> clockwise) >> param.dang = 5; % angular step size (deg) >> param.deg = 0:param.dang:360-1; % you can change >> param.deg = param.deg*param.dir; >> param.nProj = length(param.deg); >> >> param.parker = 0; % data with 360 deg -> param.parker = 0 , data less >> than >> 360 deg -> param.parker=1 >> >> param.filter='ram-lak'; % high pass filter >> >> >> param.dx = param.sx/param.nx; % single voxel size >> param.dy = param.sy/param.ny; >> param.dz = param.sz/param.nz; >> param.du = param.su/param.nu; >> param.dv = param.sv/param.nv; >> param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) >> >> >> % Geometry calculation % % % >> param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; >> param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; >> param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; >> param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; >> param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; >> >> >> >> So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : >> 360). >> But I got confused how to set the geometry parameters in RTK >> I followed the rtkfdk tutorial but I can?t get any result using this >> method >> >> I did the following: >> >> 1- Create geometry.xml using these parameters: >> >> nproj = 72 ; >> first_angle = 0 ; >> arc = 360 ; >> sid = 27400 ; >> sdd = 32900 ; >> proj_iso_x = 0; >> proj_iso_y = 0; >> out_angle = 0 ; >> in_angle = 0 ; >> source_x = 0; >> source_y = 0 ; >> >> 2- Create my own mha file (WriteMhaFile.m) from my projection array >> (36*100*72) using a matlab code with following properties: >> Voxel size = [0.1 0.1 0.1] >> Offset = [1 1 1] >> >> >> 3- Then run the: >> rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 >> --dimension 500 >> >> >> Could you please tell me if I am setting the geometry correctly? >> Also, is there any other way to create my own mha file? >> >> Thank you in advance and looking forward to hear back from you. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hougeamm at 126.com Thu Jul 9 18:35:09 2015 From: hougeamm at 126.com (=?GBK?B?uu645w==?=) Date: Fri, 10 Jul 2015 06:35:09 +0800 (CST) Subject: [Rtk-users] problems for elekta data Message-ID: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Hello Everyone, Why the Elekta data prompt projection doesn't match when using rtkfdk? e.g., 377 vs 389? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 10 01:43:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Jul 2015 07:43:15 +0200 Subject: [Rtk-users] problems for elekta data In-Reply-To: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> References: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Message-ID: Hi, The message that you have on the command line is the result of the files that have been found in the path (--path option) with the regular expression (--regexp option). If it found more projections than what you have, then you probably need to improve your reg exp, e.g., by a $ after the file extension to specify that the file name must end with it. Simon On Fri, Jul 10, 2015 at 12:35 AM, ?? wrote: > Hello Everyone, > Why the Elekta data prompt projection doesn't match when using > rtkfdk? e.g., 377 vs 389? > Thanks! > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From guangming.zang at kaust.edu.sa Mon Jul 13 02:48:15 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 09:48:15 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset Message-ID: Hi RTK comunity, Besides the prameters like SID and SDD , from the geometry(.xteck) file got from my scanner, i also have object (volume) information like this: VoxelsX=179 VoxelsY=163 VoxelsZ=127 VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 The X,Y and Z axis are identical to RTK's geometry , So i was really wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i can show all other parameters like: rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, but it still a slight different visualization result from what we got from scanner software. So would you help me??? File attached is the geometry file in case. Thanks in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VCC_Dome_0622.xtekct Type: application/octet-stream Size: 1813 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 13 04:38:00 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 11:38:00 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: problem fixed. because the scanned object is symmetric and i did not notice that i should -Z axis in scanner to map Z in RTK thanks. but, i still do not know in RTK how to show the OffsetZ.. :( Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-13 9:48 GMT+03:00 Guangming Zang : > Hi RTK comunity, > Besides the prameters like SID and SDD , from the geometry(.xteck) file > got from my scanner, i also have object (volume) information like this: > VoxelsX=179 VoxelsY=163 VoxelsZ=127 > VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 > OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 > The X,Y and Z axis are identical to RTK's geometry , So i was really > wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i > can show all other parameters like: > > rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing > 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 > --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 > > Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, > but it still a slight different visualization result from what we got from > scanner software. > So would you help me??? > > > File attached is the geometry file in case. Thanks in advance > Regards > Guangming > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Mon Jul 13 13:21:44 2015 From: robert.calliess at gmx.de (=?utf-8?Q?Robert_Callie=C3=9F?=) Date: Mon, 13 Jul 2015 19:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? Message-ID: Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 13 13:42:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 13 Jul 2015 19:42:43 +0200 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: Hi, OffsetZ probably refers to the coordinate of the volume in the room coordinate which we don't use in RTK. Everything is set in the tomography coordinate during reconstruction. You can always change the coordinates of your volume after if you want to put it in some other coordinate system. Simon On Mon, Jul 13, 2015 at 10:38 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > problem fixed. > because the scanned object is symmetric and i did not notice that i > should -Z axis in scanner to map Z in RTK > thanks. > but, i still do not know in RTK how to show the OffsetZ.. :( > > Guangming > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-13 9:48 GMT+03:00 Guangming Zang : > >> Hi RTK comunity, >> Besides the prameters like SID and SDD , from the geometry(.xteck) file >> got from my scanner, i also have object (volume) information like this: >> VoxelsX=179 VoxelsY=163 VoxelsZ=127 >> VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 >> OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 >> The X,Y and Z axis are identical to RTK's geometry , So i was really >> wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i >> can show all other parameters like: >> >> rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing >> 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 >> --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 >> >> Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, >> but it still a slight different visualization result from what we got from >> scanner software. >> So would you help me??? >> >> >> File attached is the geometry file in case. Thanks in advance >> Regards >> Guangming >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Tue Jul 14 03:01:14 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 14 Jul 2015 09:01:14 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 01:32:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 07:32:43 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: > Hell RTK User, > I think there is a mistake in the described approach. > Point a) and f) meight be wrong. As far as I Understand, all Pixels > that are covered by the projected voxel vertices are update > with weight * voxel_value. Where weight is the overlaping area > of the projected voxel vertices polygon on the detector plane and the > underlying detector pixels. > > Any opinions before implementing it ? > > regards, > Robert > > *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr > *Von:* "Robert Callie?" > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what > they called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can > be rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector > cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value > to back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Wed Jul 15 08:07:20 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Wed, 15 Jul 2015 14:07:20 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 08:21:44 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 14:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: > Hello Simon, > thank you for your answer. I guess you linked the wrong article. But I > know what article you are talking about. > It's the articel from 2009 with a piece of code (MapSeq). > > >> I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > detector pixels that are totally covered by the overlap are weight with > "1" and if the overlap is between detector pixels > the pixels are weighted. Do you have a copy of the original article from > the De Man and Basu ? > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > Do you agree with that or did I miss something ? > > best regards, > Robert > > *Gesendet:* Mittwoch, 15. Juli 2015 um 07:32 Uhr > *Von:* "Simon Rit" > *An:* "Robert Callie?" > *Cc:* "rtk-users at public.kitware.com" > *Betreff:* Re: [Rtk-users] distance driven projector, a simplified > approach ? > Hi, > Indeed, I have published an article > on this > projector describing my implementation, you could use it if you want, > there's even a piece of code in it although I'm pretty sure it's not the > best implementation. This implementation dealt with the case where the > rotation axis is parallel to the detector. As far as I can remember, the > original article of De Man and Basu is also quite clear. > I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > Simon > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: >> >> Hell RTK User, >> I think there is a mistake in the described approach. >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> that are covered by the projected voxel vertices are update >> with weight * voxel_value. Where weight is the overlaping area >> of the projected voxel vertices polygon on the detector plane and the >> underlying detector pixels. >> >> Any opinions before implementing it ? >> >> regards, >> Robert >> >> *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr >> *Von:* "Robert Callie?" >> *An:* rtk-users at public.kitware.com >> *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel boundaries >> onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel?s contribution (weight) is the area of this overlapping. I >> read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is what >> they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone beam >> geometry. We can >> >> either rotate the detector and source around the object or the object can >> be rotated >> >> and the detector and source are fixed. I think Simon also wrote a paper >> about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source position, >> object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector >> cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the >> corresponding detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a ? e). Value >> to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I?m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of voxel >> boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 15 15:14:13 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 15 Jul 2015 21:14:13 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hello Simon, thank you for the articles. May I ask you what do you mean by ?voxel correction factor? in the code you provided in your article ? float f) // Voxel correction factor Thank you and best regards, Robert Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit Gesendet: Mittwoch, 15. Juli 2015 14:22 An: Robert Callie? Cc: rtk-users at public.kitware.com Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: Hello Simon, thank you for your answer. I guess you linked the wrong article. But I know what article you are talking about. It's the articel from 2009 with a piece of code (MapSeq). >> I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. You're right. It is that all pixels that are related to the overlap projected voxel overlap have to taken into account. So detector pixels that are totally covered by the overlap are weight with "1" and if the overlap is between detector pixels the pixels are weighted. Do you have a copy of the original article from the De Man and Basu ? I have the opinion that it's not neccessary to project the detector pixel boundaries and voxel boundaries onto a common plane if we use a flat panel detector. Instead we could project the voxel boundaries onto the detector plane directly. Do you agree with that or did I miss something ? best regards, Robert Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr Von: "Simon Rit" An: "Robert Callie?" Cc: "rtk-users at public.kitware.com" Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: Hell RTK User, I think there is a mistake in the described approach. Point a) and f) meight be wrong. As far as I Understand, all Pixels that are covered by the projected voxel vertices are update with weight * voxel_value. Where weight is the overlaping area of the projected voxel vertices polygon on the detector plane and the underlying detector pixels. Any opinions before implementing it ? regards, Robert Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr Von: "Robert Callie?" An: rtk-users at public.kitware.com Betreff: [Rtk-users] distance driven projector, a simplified approach ? Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 15:45:23 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 21:45:23 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. Simon On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie? wrote: > Hello Simon, > > thank you for the articles. May I ask you what do you mean by > > ?voxel correction factor? in the code you provided in your article ? > > float f) // Voxel correction factor > > > > Thank you and best regards, > > Robert > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Mittwoch, 15. Juli 2015 14:22 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified > approach ? > > > > Sorry, this link indeed with the MapSeg function. And yes, I was projecting > it to the detector plane directly. > > Simon > > > > On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" > wrote: > > Hello Simon, > > thank you for your answer. I guess you linked the wrong article. But I know > what article you are talking about. > > It's the articel from 2009 with a piece of code (MapSeq). > > > >>> I don't have time to go into the details of what you have proposed but, >>> from a glance, the first step seems useless. > > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > > detector pixels that are totally covered by the overlap are weight with "1" > and if the overlap is between detector pixels > > the pixels are weighted. Do you have a copy of the original article from the > De Man and Basu ? > > > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > > Do you agree with that or did I miss something ? > > > > best regards, > > Robert > > > > Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr > Von: "Simon Rit" > An: "Robert Callie?" > Cc: "rtk-users at public.kitware.com" > Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? > > Hi, > > Indeed, I have published an article on this projector describing my > implementation, you could use it if you want, there's even a piece of code > in it although I'm pretty sure it's not the best implementation. This > implementation dealt with the case where the rotation axis is parallel to > the detector. As far as I can remember, the original article of De Man and > Basu is also quite clear. > > I don't have time to go into the details of what you have proposed but, from > a glance, the first step seems useless. > > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > > Simon > > > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: > > Hell RTK User, > > I think there is a mistake in the described approach. > > Point a) and f) meight be wrong. As far as I Understand, all Pixels > > that are covered by the projected voxel vertices are update > > with weight * voxel_value. Where weight is the overlaping area > > of the projected voxel vertices polygon on the detector plane and the > > underlying detector pixels. > > > > Any opinions before implementing it ? > > > > regards, > > Robert > > > > Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr > Von: "Robert Callie?" > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what they > called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can be > rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value to > back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From simon.rit at creatis.insa-lyon.fr Fri Jul 17 02:22:16 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 17 Jul 2015 08:22:16 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Please keep on using the mailing list, I don't see a good reason to keep this conversation private. I won't have time to go back into these details. From a quick look, I think this is correct although I would have simply said that D is the center of the detector pixel. Simon On Thu, Jul 16, 2015 at 10:24 PM, Robert Callie? wrote: > Hello, > Sorry that I have to ask again. But I want to clear this before I start. > I want to ask about the cosine weight DeMan mentioned in his article. > He wrote: > > " > (1) The intersection length of the line of interest with the image slab S, the latter being > defined as the slab parallel to the xz plane and containing voxel V. This intersection length > is given by t/(cos ? cos ? ), where t is the isotropic voxel size, and ? and ? are the in- and > out-of-plane angles of the line of interest with the y-axis. > " > > So what he actually does, is that he calculates the intersection length of the slab s (that contains the voxel) with > a ray going from xray source to the middle of two adjacent detector cell boundaries. Let's refare to Figure 5. > So the length to be considered is calculated as the intersection length of slab S with the ray going from > the source ( the black dot in figure 5) to the mid-point of D, that means the center of the two projected adjacent > detector pixel boundaries. > > > Sorry for asking again but I want it to make it clear to me. > > Best regards, > Robert > > > -----Urspr?ngliche Nachricht----- > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit > Gesendet: Mittwoch, 15. Juli 2015 21:45 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? > > "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" > So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. > Simon > > On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie wrote: >> Hello Simon, >> >> thank you for the articles. May I ask you what do you mean by >> >> voxel correction factor in the code you provided in your article ? >> >> float f) // Voxel correction factor >> >> >> >> Thank you and best regards, >> >> Robert >> >> >> >> Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von >> Simon Rit >> Gesendet: Mittwoch, 15. Juli 2015 14:22 >> An: Robert Callie >> Cc: rtk-users at public.kitware.com >> Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified >> approach ? >> >> >> >> Sorry, this link indeed with the MapSeg function. And yes, I was >> projecting it to the detector plane directly. >> >> Simon >> >> >> >> On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie " >> >> wrote: >> >> Hello Simon, >> >> thank you for your answer. I guess you linked the wrong article. But I >> know what article you are talking about. >> >> It's the articel from 2009 with a piece of code (MapSeq). >> >> >> >>>> I don't have time to go into the details of what you have proposed >>>> but, from a glance, the first step seems useless. >> >> You're right. It is that all pixels that are related to the overlap >> projected voxel overlap have to taken into account. So >> >> detector pixels that are totally covered by the overlap are weight with "1" >> and if the overlap is between detector pixels >> >> the pixels are weighted. Do you have a copy of the original article >> from the De Man and Basu ? >> >> >> >> I have the opinion that it's not neccessary to project the detector >> pixel boundaries and voxel boundaries onto a common plane >> >> if we use a flat panel detector. Instead we could project the voxel >> boundaries onto the detector plane directly. >> >> Do you agree with that or did I miss something ? >> >> >> >> best regards, >> >> Robert >> >> >> >> Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr >> Von: "Simon Rit" >> An: "Robert Callie " >> Cc: "rtk-users at public.kitware.com" >> Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hi, >> >> Indeed, I have published an article on this projector describing my >> implementation, you could use it if you want, there's even a piece of >> code in it although I'm pretty sure it's not the best implementation. >> This implementation dealt with the case where the rotation axis is >> parallel to the detector. As far as I can remember, the original >> article of De Man and Basu is also quite clear. >> >> I don't have time to go into the details of what you have proposed >> but, from a glance, the first step seems useless. >> >> Good luck in your implementation and don't hesitate to send it to us >> when you have a working RTK implementation, >> >> Simon >> >> >> >> On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie " >> >> wrote: >> >> Hell RTK User, >> >> I think there is a mistake in the described approach. >> >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> >> that are covered by the projected voxel vertices are update >> >> with weight * voxel_value. Where weight is the overlaping area >> >> of the projected voxel vertices polygon on the detector plane and the >> >> underlying detector pixels. >> >> >> >> Any opinions before implementing it ? >> >> >> >> regards, >> >> Robert >> >> >> >> Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr >> Von: "Robert Callie " >> An: rtk-users at public.kitware.com >> Betreff: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel >> boundaries onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel s contribution (weight) is the area of this >> overlapping. I read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is >> what they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone >> beam geometry. We can >> >> either rotate the detector and source around the object or the object >> can be rotated >> >> and the detector and source are fixed. I think Simon also wrote a >> paper about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source >> position, object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the corresponding >> detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a e). >> Value to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of >> voxel boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > From guangming.zang at kaust.edu.sa Sun Jul 26 18:30:42 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 01:30:42 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed Message-ID: Hi RTK community, i am using SART algorithm to reconstruct an object. But in this new RTK version, the time recording seems a little weird: the total time is 1219.12s , but adding the time cost in different stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward projection part. BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, both multi-threading i think. Can anyone tell me what's going on? Thanks Regards Guangming [image: ???? 1] *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 01:59:11 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 07:59:11 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Guangming, It's not surprising to me that the backprojection is faster than the forward projection, that's what I expect. If the total time is longer, that's probably that some individual steps are not included in the total time. Can you try to add reader->Update(); before the line itk::TimeProbe totalTimeProbe; in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? Simon On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > Hi RTK community, > i am using SART algorithm to reconstruct an object. > But in this new RTK version, the time recording seems a little weird: > the total time is 1219.12s , but adding the time cost in different stages > is not 1291.12 s. especially for "backprojection" part, only 16.6051s to > reconstruct a 128^3 volume ?? even shorter than forward projection part. > BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, > both multi-threading i think. > Can anyone tell me what's going on? > Thanks > Regards > Guangming > > [image: ???? 1] > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 27 04:41:58 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 11:41:58 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, Thanks for your reply. would you pls help and explain why backprojection is expected to take shorter time than forward projection?? because i was thinking if no caching step, the backprojection should take much longer time than sart algorithm. yes, i run rtksart for 2 times once.it took 12xxs, similar to the time consumed of 3 times's sart, which much slower than my own application. BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 shapp-logan projections(512*512 resolution each) rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 and i will try reader->Update() like what you said. Thanks Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 8:59 GMT+03:00 Simon Rit : > Hi Guangming, > It's not surprising to me that the backprojection is faster than the > forward projection, that's what I expect. If the total time is longer, > that's probably that some individual steps are not included in the total > time. Can you try to add > reader->Update(); > before the line > > itk::TimeProbe totalTimeProbe; > > in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? > > Simon > > > > On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi RTK community, >> i am using SART algorithm to reconstruct an object. >> But in this new RTK version, the time recording seems a little weird: >> the total time is 1219.12s , but adding the time cost in different >> stages is not 1291.12 s. especially for "backprojection" part, only >> 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward >> projection part. BTW, the -f and -b are Joseph and >> VoxelBasedBackProjection, respectively, both multi-threading i think. >> Can anyone tell me what's going on? >> Thanks >> Regards >> Guangming >> >> [image: ???? 1] >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 08:28:28 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 14:28:28 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: I can try. Forward and back projection have the same algorithmic complexity but voxel based backprojection benefits from several optimizations in terms of memory management and computations that makes it faster. The best is to look at the code for further details... although both have far from being optimal. And I did not get the sentence "the backprojection should take much longer time than sart algorithm." because SART contains a backprojection and other steps so SART is obviously longer than the bp alone. Your log is strange and I don't see what steps are not timed that would take most of the time. I did the same test on my computer and here is my result: OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha --dimension 512 OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.288571 s Multiplication by zero: 0.131672 s Forward projection: 34.3612 s Subtraction: 0.203409 s Multiplication by lambda: 0.146459 s Ray box intersection: 1.30755 s Division: 0.187294 s Multiplication by the gating weights: 0 s Displaced detector: 0.278408 s Back projection: 11.8456 s Volume update: 0 s It took... 53.2765 s Simon On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang wrote: > Hi Simon, > Thanks for your reply. > would you pls help and explain why backprojection is expected to take > shorter time than forward projection?? because i was thinking if no caching > step, the backprojection should take much longer time than sart algorithm. > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > consumed of 3 times's sart, which much slower than my own application. > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > shapp-logan projections(512*512 resolution each) > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > -64,-64,-64 -l 0.5 -n 3 --time 1 > > and i will try reader->Update() like what you said. > Thanks > Guangming > > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> Hi Guangming, >> It's not surprising to me that the backprojection is faster than the >> forward projection, that's what I expect. If the total time is longer, >> that's probably that some individual steps are not included in the total >> time. Can you try to add >> reader->Update(); >> before the line >> >> itk::TimeProbe totalTimeProbe; >> >> in rtksart.cxx? It may be that all the reading operations are done but not >> timed in the sart->Update(). Why they are so long, I don't know, is your D: >> drive a network drive? Do you observe the same behavior if you do rtksart 2 >> times in a row? >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> wrote: >>> >>> Hi RTK community, >>> i am using SART algorithm to reconstruct an object. >>> But in this new RTK version, the time recording seems a little weird: >>> the total time is 1219.12s , but adding the time cost in different >>> stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s >>> to reconstruct a 128^3 volume ?? even shorter than forward projection part. >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, >>> both multi-threading i think. >>> Can anyone tell me what's going on? >>> Thanks >>> Regards >>> Guangming >>> >>> >>> Guangming Zang (Alex) >>> King Abdullah University of Science and Technology(KAUST) >>> University of Chinese Academy of Sciences(UCAS) >>> >>> >>> >>> >>> ________________________________ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete this >>> message from your computer system. Any unauthorized use or distribution is >>> prohibited. Please consider the environment before printing this email. >> >> > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 08:50:48 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 15:50:48 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, sorry for the mistake, not"the backprojection should take much longer time than sart algorithm" , but "the backprojection should take much longer time than forward projection in sart algorithm". BTW, how many cores does your computer have?? Mine is 24 cores. is it can explain the reason why it takes much longer time on my computer than yours? Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 15:28 GMT+03:00 Simon Rit : > I can try. Forward and back projection have the same algorithmic > complexity but voxel based backprojection benefits from several > optimizations in terms of memory management and computations that > makes it faster. The best is to look at the code for further > details... although both have far from being optimal. And I did not > get the sentence "the backprojection should take much longer time than > sart algorithm." because SART contains a backprojection and other > steps so SART is obviously longer than the bp alone. > Your log is strange and I don't see what steps are not timed that > would take most of the time. I did the same test on my computer and > here is my result: > > OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > --dimension 512 > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.288571 s > Multiplication by zero: 0.131672 s > Forward projection: 34.3612 s > Subtraction: 0.203409 s > Multiplication by lambda: 0.146459 s > Ray box intersection: 1.30755 s > Division: 0.187294 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.278408 s > Back projection: 11.8456 s > Volume update: 0 s > It took... 53.2765 s > > Simon > > On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > wrote: > > Hi Simon, > > Thanks for your reply. > > would you pls help and explain why backprojection is expected to take > > shorter time than forward projection?? because i was thinking if no > caching > > step, the backprojection should take much longer time than sart > algorithm. > > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > > consumed of 3 times's sart, which much slower than my own application. > > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > > shapp-logan projections(512*512 resolution each) > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > > -64,-64,-64 -l 0.5 -n 3 --time 1 > > > > and i will try reader->Update() like what you said. > > Thanks > > Guangming > > > > > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> > >> Hi Guangming, > >> It's not surprising to me that the backprojection is faster than the > >> forward projection, that's what I expect. If the total time is longer, > >> that's probably that some individual steps are not included in the total > >> time. Can you try to add > >> reader->Update(); > >> before the line > >> > >> itk::TimeProbe totalTimeProbe; > >> > >> in rtksart.cxx? It may be that all the reading operations are done but > not > >> timed in the sart->Update(). Why they are so long, I don't know, is > your D: > >> drive a network drive? Do you observe the same behavior if you do > rtksart 2 > >> times in a row? > >> > >> Simon > >> > >> > >> > >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> wrote: > >>> > >>> Hi RTK community, > >>> i am using SART algorithm to reconstruct an object. > >>> But in this new RTK version, the time recording seems a little weird: > >>> the total time is 1219.12s , but adding the time cost in different > >>> stages is not 1291.12 s. especially for "backprojection" part, only > 16.6051s > >>> to reconstruct a 128^3 volume ?? even shorter than forward projection > part. > >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > respectively, > >>> both multi-threading i think. > >>> Can anyone tell me what's going on? > >>> Thanks > >>> Regards > >>> Guangming > >>> > >>> > >>> Guangming Zang (Alex) > >>> King Abdullah University of Science and Technology(KAUST) > >>> University of Chinese Academy of Sciences(UCAS) > >>> > >>> > >>> > >>> > >>> ________________________________ > >>> This message and its contents, including attachments are intended > solely > >>> for the original recipient. If you are not the intended recipient or > have > >>> received this message in error, please notify me immediately and > delete this > >>> message from your computer system. Any unauthorized use or > distribution is > >>> prohibited. Please consider the environment before printing this email. > >> > >> > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 09:02:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 15:02:03 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: No I expect forward projection to be longer than backprojection although with optimal implementations, it should take about the same time since they have the same complexity. I have 4 cores on my laptop. I don't see how it explains it, try to find out where does SART spend the time. Simon On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang wrote: > Hi Simon, > sorry for the mistake, not"the backprojection should take much longer time > than > sart algorithm" , but "the backprojection should take much longer time than > forward projection in sart algorithm". > > BTW, how many cores does your computer have?? Mine is 24 cores. > is it can explain the reason why it takes much longer time on my computer > than yours? > Regards > Guangming > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> I can try. Forward and back projection have the same algorithmic >> complexity but voxel based backprojection benefits from several >> optimizations in terms of memory management and computations that >> makes it faster. The best is to look at the code for further >> details... although both have far from being optimal. And I did not >> get the sentence "the backprojection should take much longer time than >> sart algorithm." because SART contains a backprojection and other >> steps so SART is obviously longer than the bp alone. >> Your log is strange and I don't see what steps are not timed that >> would take most of the time. I did the same test on my computer and >> here is my result: >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> --dimension 512 >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> 1 >> Recording elapsed time... >> SARTConeBeamReconstructionFilter timing: >> Extraction of projection sub-stacks: 0.288571 s >> Multiplication by zero: 0.131672 s >> Forward projection: 34.3612 s >> Subtraction: 0.203409 s >> Multiplication by lambda: 0.146459 s >> Ray box intersection: 1.30755 s >> Division: 0.187294 s >> Multiplication by the gating weights: 0 s >> Displaced detector: 0.278408 s >> Back projection: 11.8456 s >> Volume update: 0 s >> It took... 53.2765 s >> >> Simon >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> wrote: >> > Hi Simon, >> > Thanks for your reply. >> > would you pls help and explain why backprojection is expected to take >> > shorter time than forward projection?? because i was thinking if no >> > caching >> > step, the backprojection should take much longer time than sart >> > algorithm. >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time >> > consumed of 3 times's sart, which much slower than my own application. >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 >> > shapp-logan projections(512*512 resolution each) >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> > >> > and i will try reader->Update() like what you said. >> > Thanks >> > Guangming >> > >> > >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> >> >> Hi Guangming, >> >> It's not surprising to me that the backprojection is faster than the >> >> forward projection, that's what I expect. If the total time is longer, >> >> that's probably that some individual steps are not included in the >> >> total >> >> time. Can you try to add >> >> reader->Update(); >> >> before the line >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done but >> >> not >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> your D: >> >> drive a network drive? Do you observe the same behavior if you do >> >> rtksart 2 >> >> times in a row? >> >> >> >> Simon >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> wrote: >> >>> >> >>> Hi RTK community, >> >>> i am using SART algorithm to reconstruct an object. >> >>> But in this new RTK version, the time recording seems a little weird: >> >>> the total time is 1219.12s , but adding the time cost in different >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >>> 16.6051s >> >>> to reconstruct a 128^3 volume ?? even shorter than forward projection >> >>> part. >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >>> respectively, >> >>> both multi-threading i think. >> >>> Can anyone tell me what's going on? >> >>> Thanks >> >>> Regards >> >>> Guangming >> >>> >> >>> >> >>> Guangming Zang (Alex) >> >>> King Abdullah University of Science and Technology(KAUST) >> >>> University of Chinese Academy of Sciences(UCAS) >> >>> >> >>> >> >>> >> >>> >> >>> ________________________________ >> >>> This message and its contents, including attachments are intended >> >>> solely >> >>> for the original recipient. If you are not the intended recipient or >> >>> have >> >>> received this message in error, please notify me immediately and >> >>> delete this >> >>> message from your computer system. Any unauthorized use or >> >>> distribution is >> >>> prohibited. Please consider the environment before printing this >> >>> email. >> >> >> >> >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended solely >> > for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> > this >> > message from your computer system. Any unauthorized use or distribution >> > is >> > prohibited. Please consider the environment before printing this email. > > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 10:05:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:05:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, it cost 1200s for SART algorithm at first, and the command are: rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 in which, the projections data(360pro_SL_Vol128_512.mha) is not generated from rtkprojectshepploganphantom , but from my application. though it took long time, but i can got a nice result, And i just tried the command you used, i.e. generated the projections data by rtkprojectshepploganphantom : rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 --sid=500.0 rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 yes, it takes about 56s. but the reconstructed result is weird, the voxel values range from [-142186, 208146] and can not see anything when visualizing it. i believe you got the similar results, which maybe explain why it computes much faster. if i wanna use the projections generated by rtkprojectshepploganphantom , can you give me an example to get a nice results? Best regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 16:02 GMT+03:00 Simon Rit : > No I expect forward projection to be longer than backprojection > although with optimal implementations, it should take about the same > time since they have the same complexity. > I have 4 cores on my laptop. I don't see how it explains it, try to > find out where does SART spend the time. > Simon > > On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang > wrote: > > Hi Simon, > > sorry for the mistake, not"the backprojection should take much longer > time > > than > > sart algorithm" , but "the backprojection should take much longer time > than > > forward projection in sart algorithm". > > > > BTW, how many cores does your computer have?? Mine is 24 cores. > > is it can explain the reason why it takes much longer time on my computer > > than yours? > > Regards > > Guangming > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : > >> > >> I can try. Forward and back projection have the same algorithmic > >> complexity but voxel based backprojection benefits from several > >> optimizations in terms of memory management and computations that > >> makes it faster. The best is to look at the code for further > >> details... although both have far from being optimal. And I did not > >> get the sentence "the backprojection should take much longer time than > >> sart algorithm." because SART contains a backprojection and other > >> steps so SART is obviously longer than the bp alone. > >> Your log is strange and I don't see what steps are not timed that > >> would take most of the time. I did the same test on my computer and > >> here is my result: > >> > >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > >> --dimension 512 > >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > >> 1 > >> Recording elapsed time... > >> SARTConeBeamReconstructionFilter timing: > >> Extraction of projection sub-stacks: 0.288571 s > >> Multiplication by zero: 0.131672 s > >> Forward projection: 34.3612 s > >> Subtraction: 0.203409 s > >> Multiplication by lambda: 0.146459 s > >> Ray box intersection: 1.30755 s > >> Division: 0.187294 s > >> Multiplication by the gating weights: 0 s > >> Displaced detector: 0.278408 s > >> Back projection: 11.8456 s > >> Volume update: 0 s > >> It took... 53.2765 s > >> > >> Simon > >> > >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > >> wrote: > >> > Hi Simon, > >> > Thanks for your reply. > >> > would you pls help and explain why backprojection is expected to take > >> > shorter time than forward projection?? because i was thinking if no > >> > caching > >> > step, the backprojection should take much longer time than sart > >> > algorithm. > >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the > time > >> > consumed of 3 times's sart, which much slower than my own application. > >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > >> > shapp-logan projections(512*512 resolution each) > >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > >> > -64,-64,-64 -l 0.5 -n 3 --time 1 > >> > > >> > and i will try reader->Update() like what you said. > >> > Thanks > >> > Guangming > >> > > >> > > >> > > >> > Guangming Zang (Alex) > >> > King Abdullah University of Science and Technology(KAUST) > >> > University of Chinese Academy of Sciences(UCAS) > >> > > >> > > >> > > >> > > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> >> > >> >> Hi Guangming, > >> >> It's not surprising to me that the backprojection is faster than the > >> >> forward projection, that's what I expect. If the total time is > longer, > >> >> that's probably that some individual steps are not included in the > >> >> total > >> >> time. Can you try to add > >> >> reader->Update(); > >> >> before the line > >> >> > >> >> itk::TimeProbe totalTimeProbe; > >> >> > >> >> in rtksart.cxx? It may be that all the reading operations are done > but > >> >> not > >> >> timed in the sart->Update(). Why they are so long, I don't know, is > >> >> your D: > >> >> drive a network drive? Do you observe the same behavior if you do > >> >> rtksart 2 > >> >> times in a row? > >> >> > >> >> Simon > >> >> > >> >> > >> >> > >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> >> wrote: > >> >>> > >> >>> Hi RTK community, > >> >>> i am using SART algorithm to reconstruct an object. > >> >>> But in this new RTK version, the time recording seems a little > weird: > >> >>> the total time is 1219.12s , but adding the time cost in different > >> >>> stages is not 1291.12 s. especially for "backprojection" part, only > >> >>> 16.6051s > >> >>> to reconstruct a 128^3 volume ?? even shorter than forward > projection > >> >>> part. > >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > >> >>> respectively, > >> >>> both multi-threading i think. > >> >>> Can anyone tell me what's going on? > >> >>> Thanks > >> >>> Regards > >> >>> Guangming > >> >>> > >> >>> > >> >>> Guangming Zang (Alex) > >> >>> King Abdullah University of Science and Technology(KAUST) > >> >>> University of Chinese Academy of Sciences(UCAS) > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> ________________________________ > >> >>> This message and its contents, including attachments are intended > >> >>> solely > >> >>> for the original recipient. If you are not the intended recipient or > >> >>> have > >> >>> received this message in error, please notify me immediately and > >> >>> delete this > >> >>> message from your computer system. Any unauthorized use or > >> >>> distribution is > >> >>> prohibited. Please consider the environment before printing this > >> >>> email. > >> >> > >> >> > >> > > >> > > >> > ________________________________ > >> > This message and its contents, including attachments are intended > solely > >> > for > >> > the original recipient. If you are not the intended recipient or have > >> > received this message in error, please notify me immediately and > delete > >> > this > >> > message from your computer system. Any unauthorized use or > distribution > >> > is > >> > prohibited. Please consider the environment before printing this > email. > > > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 10:12:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:12:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: BTW, the projections are 512*512, and the pixel spacing is 0.5 Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:05 GMT+03:00 Guangming Zang : > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 10:20:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 16:20:12 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Obviously I hadn't looked at the result and/or checked the command line options, sorry. This is an example from the same simulated dataset that gives me a good results: OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.567773 s Multiplication by zero: 0.303715 s Forward projection: 142.305 s Subtraction: 0.445842 s Multiplication by lambda: 0.2663 s Ray box intersection: 5.40366 s Division: 0.535618 s Multiplication by the gating weights: 0 s Displaced detector: 0.415431 s Back projection: 21.3689 s Volume update: 0 s It took... 177.059 s but this doesn't change the content of my previous message. What takes time is probably in your own software, be sure that you update SART inputs before timing it. Simon On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang wrote: > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 11:12:16 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 18:12:16 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Thanks Simon, now it work fine when using projections generated by RTK itself (command rtkprojectshepploganphantom ). for 1 iteration of SART to reconstruct 128^3 size volume, it took only 19s, which gives nice results as well. Thanks again. Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:20 GMT+03:00 Simon Rit : > Obviously I hadn't looked at the result and/or checked the command line > options, sorry. This is an example from the same simulated dataset that > gives me a good results: > > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f > Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n > 3 --time 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.567773 s > Multiplication by zero: 0.303715 s > Forward projection: 142.305 s > Subtraction: 0.445842 s > Multiplication by lambda: 0.2663 s > Ray box intersection: 5.40366 s > Division: 0.535618 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.415431 s > Back projection: 21.3689 s > Volume update: 0 s > It took... 177.059 s > > but this doesn't change the content of my previous message. What takes > time is probably in your own software, be sure that you update SART inputs > before timing it. > Simon > > On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon, >> it cost 1200s for SART algorithm at first, and the command are: >> rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd= >> 725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" >> >> rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 >> >> in which, the projections data(360pro_SL_Vol128_512.mha) is not >> generated from rtkprojectshepploganphantom , but from my application. >> though it took long time, but i can got a nice result, >> >> >> And i just tried the command you used, i.e. generated the projections >> data by rtkprojectshepploganphantom : >> >> rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 >> --sid=500.0 >> rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 >> rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b >> VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 >> --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 >> yes, it takes about 56s. >> but the reconstructed result is weird, the voxel values range from >> [-142186, 208146] and can not see anything when visualizing it. >> i believe you got the similar results, which maybe explain why it >> computes much faster. >> >> if i wanna use the projections generated by rtkprojectshepploganphantom >> , can you give me an example to get a nice results? >> >> Best regards >> Guangming >> >> >> >> >> >> >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> 2015-07-27 16:02 GMT+03:00 Simon Rit : >> >>> No I expect forward projection to be longer than backprojection >>> although with optimal implementations, it should take about the same >>> time since they have the same complexity. >>> I have 4 cores on my laptop. I don't see how it explains it, try to >>> find out where does SART spend the time. >>> Simon >>> >>> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >>> wrote: >>> > Hi Simon, >>> > sorry for the mistake, not"the backprojection should take much longer >>> time >>> > than >>> > sart algorithm" , but "the backprojection should take much longer time >>> than >>> > forward projection in sart algorithm". >>> > >>> > BTW, how many cores does your computer have?? Mine is 24 cores. >>> > is it can explain the reason why it takes much longer time on my >>> computer >>> > than yours? >>> > Regards >>> > Guangming >>> > >>> > Guangming Zang (Alex) >>> > King Abdullah University of Science and Technology(KAUST) >>> > University of Chinese Academy of Sciences(UCAS) >>> > >>> > >>> > >>> > >>> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >>> >> >>> >> I can try. Forward and back projection have the same algorithmic >>> >> complexity but voxel based backprojection benefits from several >>> >> optimizations in terms of memory management and computations that >>> >> makes it faster. The best is to look at the code for further >>> >> details... although both have far from being optimal. And I did not >>> >> get the sentence "the backprojection should take much longer time than >>> >> sart algorithm." because SART contains a backprojection and other >>> >> steps so SART is obviously longer than the bp alone. >>> >> Your log is strange and I don't see what steps are not timed that >>> >> would take most of the time. I did the same test on my computer and >>> >> here is my result: >>> >> >>> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >>> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >>> >> --dimension 512 >>> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >>> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >>> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >>> >> 1 >>> >> Recording elapsed time... >>> >> SARTConeBeamReconstructionFilter timing: >>> >> Extraction of projection sub-stacks: 0.288571 s >>> >> Multiplication by zero: 0.131672 s >>> >> Forward projection: 34.3612 s >>> >> Subtraction: 0.203409 s >>> >> Multiplication by lambda: 0.146459 s >>> >> Ray box intersection: 1.30755 s >>> >> Division: 0.187294 s >>> >> Multiplication by the gating weights: 0 s >>> >> Displaced detector: 0.278408 s >>> >> Back projection: 11.8456 s >>> >> Volume update: 0 s >>> >> It took... 53.2765 s >>> >> >>> >> Simon >>> >> >>> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >>> >> wrote: >>> >> > Hi Simon, >>> >> > Thanks for your reply. >>> >> > would you pls help and explain why backprojection is expected to >>> take >>> >> > shorter time than forward projection?? because i was thinking if no >>> >> > caching >>> >> > step, the backprojection should take much longer time than sart >>> >> > algorithm. >>> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >>> time >>> >> > consumed of 3 times's sart, which much slower than my own >>> application. >>> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >>> 360 >>> >> > shapp-logan projections(512*512 resolution each) >>> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >>> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >>> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >>> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >>> >> > >>> >> > and i will try reader->Update() like what you said. >>> >> > Thanks >>> >> > Guangming >>> >> > >>> >> > >>> >> > >>> >> > Guangming Zang (Alex) >>> >> > King Abdullah University of Science and Technology(KAUST) >>> >> > University of Chinese Academy of Sciences(UCAS) >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit >> >: >>> >> >> >>> >> >> Hi Guangming, >>> >> >> It's not surprising to me that the backprojection is faster than >>> the >>> >> >> forward projection, that's what I expect. If the total time is >>> longer, >>> >> >> that's probably that some individual steps are not included in the >>> >> >> total >>> >> >> time. Can you try to add >>> >> >> reader->Update(); >>> >> >> before the line >>> >> >> >>> >> >> itk::TimeProbe totalTimeProbe; >>> >> >> >>> >> >> in rtksart.cxx? It may be that all the reading operations are done >>> but >>> >> >> not >>> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >>> >> >> your D: >>> >> >> drive a network drive? Do you observe the same behavior if you do >>> >> >> rtksart 2 >>> >> >> times in a row? >>> >> >> >>> >> >> Simon >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >>> >> >> wrote: >>> >> >>> >>> >> >>> Hi RTK community, >>> >> >>> i am using SART algorithm to reconstruct an object. >>> >> >>> But in this new RTK version, the time recording seems a little >>> weird: >>> >> >>> the total time is 1219.12s , but adding the time cost in >>> different >>> >> >>> stages is not 1291.12 s. especially for "backprojection" part, >>> only >>> >> >>> 16.6051s >>> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >>> projection >>> >> >>> part. >>> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >>> >> >>> respectively, >>> >> >>> both multi-threading i think. >>> >> >>> Can anyone tell me what's going on? >>> >> >>> Thanks >>> >> >>> Regards >>> >> >>> Guangming >>> >> >>> >>> >> >>> >>> >> >>> Guangming Zang (Alex) >>> >> >>> King Abdullah University of Science and Technology(KAUST) >>> >> >>> University of Chinese Academy of Sciences(UCAS) >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> ________________________________ >>> >> >>> This message and its contents, including attachments are intended >>> >> >>> solely >>> >> >>> for the original recipient. If you are not the intended recipient >>> or >>> >> >>> have >>> >> >>> received this message in error, please notify me immediately and >>> >> >>> delete this >>> >> >>> message from your computer system. Any unauthorized use or >>> >> >>> distribution is >>> >> >>> prohibited. Please consider the environment before printing this >>> >> >>> email. >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > ________________________________ >>> >> > This message and its contents, including attachments are intended >>> solely >>> >> > for >>> >> > the original recipient. If you are not the intended recipient or >>> have >>> >> > received this message in error, please notify me immediately and >>> delete >>> >> > this >>> >> > message from your computer system. Any unauthorized use or >>> distribution >>> >> > is >>> >> > prohibited. Please consider the environment before printing this >>> email. >>> > >>> > >>> > >>> > ________________________________ >>> > This message and its contents, including attachments are intended >>> solely for >>> > the original recipient. If you are not the intended recipient or have >>> > received this message in error, please notify me immediately and >>> delete this >>> > message from your computer system. Any unauthorized use or >>> distribution is >>> > prohibited. Please consider the environment before printing this email. >>> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From infrombox at yandex.ru Tue Jul 28 04:30:22 2015 From: infrombox at yandex.ru (1 1) Date: Tue, 28 Jul 2015 15:30:22 +0700 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: <2213081438072222@web8j.yandex.ru> Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. But program which i use reads meta images with MET_SHORT pixel type only. Is there easy way to setting it and get volume with different from MET_FLOAT pixel type ? If not, could you advice me, what the filter i should to do, for example as post process after reconstruction ala MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward operation of LUTbasedVariableI0RawToAttenuationImageFilter ? Thanks. From simon.rit at creatis.insa-lyon.fr Tue Jul 28 04:56:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 10:56:54 +0200 Subject: [Rtk-users] volume with diffieret pixel type In-Reply-To: <2213081438072222@web8j.yandex.ru> References: <2213081438072222@web8j.yandex.ru> Message-ID: Hi, This is more an ITK question than a RTK question. Yes, we use float by default in our applications. You can cast the image to any type before writing using itk::CastImageFilter but you'll have to modify the applications and, of course, there is a loss of information. If you don't want to program it, you can use any other software, e.g. in vv right clik on your image after opening and use the convert to option. Simon On Tue, Jul 28, 2015 at 10:30 AM, 1 1 wrote: > Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. > But program which i use reads meta images with MET_SHORT pixel type only. > Is there easy way to setting it and get volume with different from > MET_FLOAT pixel type ? If not, could you advice me, what the filter i > should to do, for example as post process after reconstruction ala > MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward > operation of LUTbasedVariableI0RawToAttenuationImageFilter image, float image> ? > Thanks. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pconneely020186 at gmail.com Tue Jul 28 12:05:29 2015 From: pconneely020186 at gmail.com (peter conneely) Date: Tue, 28 Jul 2015 17:05:29 +0100 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: "peter conneely" Date: 24 Jul 2015 11:07 Subject: Issue running FDK reconstruction algorithm To: Cc: Hi, I'm having trouble running the FDK reconstruction alogrithm on Elekta and Varian data sets. The algorithm does work when I try the shepp-logan example. When I initially ran the application I included the (') around .*.his. and got the following lines. [image: Inline image 1] when I try to run with the (') removed it finds the 669 files but then the application stops working. I have tried adding registry edits to run exe and have tried switching of dep. Neither of these work I am not sure what is going wrong and how to fix it. My system properties are as follows. Processor: Intel Pentium CPU P6100 @ 2.00 Ghz RAM: 3.00 GB GPU: Intel HD Graphics Systems type 64 Bit. Thanks and Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Tue Jul 28 12:46:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 18:46:17 +0200 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: Hi, I guess the quotes are OS depedent, maybe you need double quotes on Windows. It's strange that you don't get an error message. Are you sure it crashed? If yes, have you checked the elektaGeometry file? Does it have 669 projection sections as expected? Or maybe it's a memory issue, try the --lowmem option. Simon On Tue, Jul 28, 2015 at 6:05 PM, peter conneely wrote: > ---------- Forwarded message ---------- > From: "peter conneely" > Date: 24 Jul 2015 11:07 > Subject: Issue running FDK reconstruction algorithm > To: > Cc: > > Hi, > > I'm having trouble running the FDK reconstruction alogrithm on Elekta and > Varian data sets. The algorithm does work when I try the shepp-logan > example. > > When I initially ran the application I included the (') around .*.his. and > got the following lines. > [image: Inline image 1] > when I try to run with the (') removed it finds the 669 files but then the > application stops working. I have tried adding registry edits to run exe > and have tried switching of dep. Neither of these work I am not sure what > is going wrong and how to fix it. > > My system properties are as follows. > Processor: Intel Pentium CPU P6100 @ 2.00 Ghz > RAM: 3.00 GB > GPU: Intel HD Graphics > Systems type 64 Bit. > > Thanks and Regards, > Peter > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Tue Jul 28 13:38:45 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Tue, 28 Jul 2015 20:38:45 +0300 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: Hi, in ITK, the default type are described in *Utilities\MetaIO\metaTypes.h* MET_CHAR, MET_UCHAR ?,? ?? MET_SHORT, MET_USHORT, MET_INT,=20 MET_UINT,=20 MET_FLOAT,=20 MET_DOUBLE, ?and for .mha file, the header file includes information like: ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = 0 0 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 1 1 1 DimSize = 128 128 128 ElementType = MET_FLOAT ElementDataFile = LOCAL? ?And recently i just programmed to read and write .mha files. below is the code. u can just replace ElementType from ? MET_FLOAT ? to ? ? MET_SHORT ? in your application. hope this helps: #include "stdafx.h" #include #include #include #include #include #include using namespace std; int _tmain(int argc, _TCHAR* argv[]) { int m_Dims[3]; float spacing[3]; m_Dims[0]=128; m_Dims[1]=128; m_Dims[2]=128; spacing[0]=spacing[1]=spacing[2]=1.0f; ostringstream buffer, buffer1, buffer2, buf3; buffer << spacing[0]; string sp= buffer.str(); buffer1 << spacing[1]; string sp1 = buffer1.str(); buffer2 << spacing[2]; string sp2 = buffer2.str(); string ElementSpacing ="ElementSpacing= "+sp+" "+sp1+" "+sp2+"\n"; // int ss=1000; char temp[64], temp1[64],temp2[64]; string str; sprintf(temp, "%d", m_Dims[0]); sprintf(temp1, "%d", m_Dims[1]); sprintf(temp2, "%d", m_Dims[2]); string s(temp),s1(temp1),s2(temp2); string DimSize="DimSize= "+s+" "+s1+" "+s2+"\n"; string Mywritefile="ObjectType = Image\nNDims = 3\nBinaryData = True\nBinaryDataByteOrderMSB = False \nCompressedData = False \nTransformMatrix = 1 0 0 0 1 0 0 0 1 \n" ; Mywritefile+="Offset = 0 0 0 \nCenterOfRotation = 0 0 0 \nAnatomicalOrientation = RAI \n"; Mywritefile+=ElementSpacing+DimSize+"ElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; // ElementSpacing = 1 1 1 \nDimSize = 128 128 128 \nElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; int leng=Mywritefile.length(); cout< From simon.rit at creatis.insa-lyon.fr Wed Jul 29 08:53:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 29 Jul 2015 14:53:34 +0200 Subject: [Rtk-users] RTK images make the cover of Medical Physics Message-ID: See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Wed Jul 29 09:07:01 2015 From: theday79 at gmail.com (Yang K Park) Date: Wed, 29 Jul 2015 09:07:01 -0400 Subject: [Rtk-users] RTK images make the cover of Medical Physics In-Reply-To: References: Message-ID: <001801d0c9ff$76797860$636c6920$@gmail.com> Hi Simon, Thank you so much for the congrats! This is my great honor and I?d like to thank all the RTK developers and community members for their helps on this achievement! Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: Wednesday, July 29, 2015 8:54 AM To: rtk-users at public.kitware.com Subject: [Rtk-users] RTK images make the cover of Medical Physics See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Thu Jul 30 08:16:38 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Thu, 30 Jul 2015 15:16:38 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK Message-ID: Hi Simon and Chao, i am currently do some comparisons between different reconstruction methods for Shapp-Logan dataset. the commands are: rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=955.4050067 --sid=500.0 rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha --dimension 512,512 when using FDK or SART algorithm from RTK, I can got pretty good results indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 and levels as 1.04 for all results got). When running ADMMTV command below, though the geometry is as same as SART and FDK, the result got from ADMM looks weird.(pls see attached central slice of ground truth and ADMM, same contrast with other algorithm) rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 [image: ???? 1][image: ???? 2] Is it because the CG algorithm used by ADMM, or parameters setting issues here?? if it is parameters setting problem , would you help me and give a nice values for alpha and bate used here? BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already (including default value) Thanks and regards Guangming ?? *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ? -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 31 01:55:32 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 31 Jul 2015 07:55:32 +0200 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi, It looks to me that you haven't converged. I'm not the specialist of this algorithm and the specialist won't be near a computer in the coming weeks but when I try with more iterations in the data attachment term: rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 it's more satisfactory. There are rings at the top and the bottom of the cone-beam which should be reduced with more TV (greater alpha, see doc here ) or with a finer spacing (see this publication ). Simon On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang wrote: > Hi Simon and Chao, > > i am currently do some comparisons between different reconstruction > methods for Shapp-Logan dataset. > > the commands are: > > rtksimulatedgeometry -n 360 --arc -360 -o > geo.xml --sdd=955.4050067 --sid=500.0 > > rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha > --dimension 512,512 > > > > when using FDK or SART algorithm from RTK, I can got pretty good results > indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 > and levels as 1.04 for all results got). When running ADMMTV command below, > though the geometry is as same as SART and FDK, the result got from ADMM > looks weird.(pls see attached central slice of ground truth and ADMM, same > contrast with other algorithm) > > rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o > SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 > --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 > > [image: ???? 1][image: ???? 2] > > Is it because the CG algorithm used by ADMM, or parameters setting issues > here?? if it is parameters setting problem , would you help me and give a > nice values for alpha and bate used here? > > BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already > (including default value) > > Thanks and regards > > Guangming > > > ?? > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > ? > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Fri Jul 31 09:46:41 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 31 Jul 2015 16:46:41 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi simon, i see, thanks for the help and explanation. after following your advice, it works fine now. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-31 8:55 GMT+03:00 Simon Rit : > Hi, > It looks to me that you haven't converged. I'm not the specialist of this > algorithm and the specialist won't be near a computer in the coming weeks > but when I try with more iterations in the data attachment term: > rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml > --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 > it's more satisfactory. There are rings at the top and the bottom of the > cone-beam which should be reduced with more TV (greater alpha, see doc > here > ) > or with a finer spacing (see this publication > ). > Simon > > On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon and Chao, >> >> i am currently do some comparisons between different reconstruction >> methods for Shapp-Logan dataset. >> >> the commands are: >> >> rtksimulatedgeometry -n 360 --arc -360 -o >> geo.xml --sdd=955.4050067 --sid=500.0 >> >> rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha >> --dimension 512,512 >> >> >> >> when using FDK or SART algorithm from RTK, I can got pretty good results >> indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 >> and levels as 1.04 for all results got). When running ADMMTV command below, >> though the geometry is as same as SART and FDK, the result got from ADMM >> looks weird.(pls see attached central slice of ground truth and ADMM, same >> contrast with other algorithm) >> >> rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o >> SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 >> --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 >> >> [image: ???? 1][image: ???? 2] >> >> Is it because the CG algorithm used by ADMM, or parameters setting issues >> here?? if it is parameters setting problem , would you help me and give a >> nice values for alpha and bate used here? >> >> BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already >> (including default value) >> >> Thanks and regards >> >> Guangming >> >> >> ?? >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> ? >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 1 08:45:35 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 1 Jul 2015 14:45:35 +0200 Subject: [Rtk-users] Release of RTK v1.1.0 Message-ID: Dear RTK users, RTK v1.1.0 has been released today, about 14 months after RTK v1.0.0. The main features that have been developed since the previous release are: - SimpleRTK to run RTK filters (even the CUDA ones) from python scripts, C# code, and more - new projection pre-processing options (i0 calculation, scatter correction, water pre-correction) - extraction of the respiratory phase from cone-beam projections - linear programming for field-of-view computation based on a third party software, lp solve 5.5 - management of off-center detector in iterative methods - new iterative 3D and 4D reconstruction methods with Daubechies wavelets regularization - new iterative 4D reconstruction method with motion-aware regularization - reduction of memory footprint, especially GPU memory - many new CUDA filters - more robust (many bugs and memory leaks fixed) - use of MathJax to display formulas in the documentation, e.g., here . Many thanks to the increasing number of contributors, in alphabetical order: Ben Champion, Chao Wu, Cyril Mory, I Putu Susila, Julien Jomier, Marc Vila, Mathieu Dupont, Matt Clarkson, Peter Keuschnigg, S?bastien Brousmiche, Simon Rit, Tristan Coulange, Yang K Park. We don't focus on releases since we have a public github repository that we try to keep stable, I still recommend the use of the master HEAD over releases to enjoy the new RTK developments before their release. We still have a few on-going projects for which we will use and enhance RTK. Simon (for the RTK consortium) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 1 15:39:14 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 1 Jul 2015 21:39:14 +0200 Subject: [Rtk-users] loading projection images for sart Message-ID: Hello, I got compiled the ITK and RTK with help of cmake. I also had a look at the examples coming with RTK. I want to run a simple SART and got projection images in the format PNG and BMP. So I create an instance of the ThreeDcircularProjectionGeometry, SARTConeBeamReconstructionFilter and add the geometric projection data. rtk::ThreeDCircularProjectionGeometry::Pointer geometry; geometry = rtk::ThreeDCircularProjectionGeometry::New(); geometry->AddProjection(??) rtk::SARTConeBeamReconstructionFilter::Pointer sart = rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); How to add a stack of images to the SART reconstruction, i.e. std::vector images ? I got xray projections in png format. There is a method in the SART class called SetInput. But according tot he examples it is used to set a volume. Does anybody alread wrote a small piece of code that loads some images from the disk and put them into the SART reconstruction ? Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 2 12:19:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 2 Jul 2015 18:19:36 +0200 Subject: [Rtk-users] loading projection images for sart In-Reply-To: References: Message-ID: Hi, The stack of 2D images is passed via a 3D image. Look at the rtksart application for example. A way to read this from a set of file names is to use itk::ImageSeriesReader as done in rtk::ProjectionsReader. You should be able to understand how it works by looking at the existing RTK applications in the applications subfolders. Simon On Wed, Jul 1, 2015 at 9:39 PM, Robert Callie? wrote: > Hello, > > I got compiled the ITK and RTK with help of cmake. I also had a look > > at the examples coming with RTK. I want to run a simple SART and > > got projection images in the format PNG and BMP. > > > > So I create an instance of the ThreeDcircularProjectionGeometry, > SARTConeBeamReconstructionFilter > > and add the geometric projection data. > > > > rtk::ThreeDCircularProjectionGeometry::Pointer geometry; > > geometry = rtk::ThreeDCircularProjectionGeometry::New(); > > geometry->AddProjection(??) > > > > rtk::SARTConeBeamReconstructionFilter::Pointer sart = > rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); > > > > How to add a stack of images to the SART reconstruction, i.e. > std::vector images ? > > I got xray projections in png format. > > > > There is a method in the SART class called SetInput. But according tot he > examples it is used to set a volume. > > > > Does anybody alread wrote a small piece of code that loads some images > from the disk and put them into the SART reconstruction ? > > > > Regards, > > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Fri Jul 3 16:28:11 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 3 Jul 2015 23:28:11 +0300 Subject: [Rtk-users] Remote Control Issue in new RTK version Message-ID: Dear RTK community, There is some bug in RTK 1.1 version. That?s : When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 but i did not use Cuda at all.. What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. So i think it is some problem caused by itk ?? can we fix this issue?? Thanks for help in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Sat Jul 4 10:12:03 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Sat, 4 Jul 2015 17:12:03 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. Thanks for the help, Chao. *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ---------- Forwarded message ---------- From: Chao Wu Date: 2015-07-04 0:04 GMT+03:00 Subject: Re: Remote Control Issue To: Guangming Zang Cc: rtk-users-request at public.kitware.com, Simon Rit < simon.rit at creatis.insa-lyon.fr> Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. Regards, Chao Sent from Samsung Galaxy Note 3 2015?7?3? 10:26 PM? "Guangming Zang" ??? > Dear RTK community, > > There is some bug in RTK 1.1 version. That?s : > > When i run commands In 1.1 version with my computer in the lab, RTK works > fine, but when i use my laptop at home to remote control the computer in > the lab, it does not work. i.e., no matter the command are (rtkfdk, > ADMM,SART ?), an error is always shown: > > ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 > @ unknown : Cuda Error #3 > > but i did not use Cuda at all.. > > What?s more, when i run the 1.0 version RTK , it works well and no bug in > remoter control mode. > > So i think it is some problem caused by itk ?? can we fix this issue?? > > Thanks for help in advance > > > Regards > > Guangming > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Sat Jul 4 10:19:32 2015 From: ghostcz at hotmail.com (louie L) Date: Sat, 4 Jul 2015 16:19:32 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: I think because in most cases people use their graphics in TCC mode for scientific computations or don't use gpu at all where the rtk_use_cuda is false. Cheers, Louie Sent from my iOS > On 04 Jul 2015, at 16:12, Guangming Zang wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > > 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> Dear RTK community, >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> >> Regards >> >> Guangming >> >> Guangming Zang (Alex) >> King Abdullah University of Science and Technology(KAUST) >> University of Chinese Academy of Sciences(UCAS) >> >> >> >> >> This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > > > This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Mon Jul 6 05:32:18 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 6 Jul 2015 11:32:18 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Hi Guangming and all, Thanks for reporting this change of behavior. My first answer is that what you find simple is not so simple... but you're right, v1.0.0 allowed to compile RTK with CUDA and to run it without a CUDA device. After a bit of trakcing, I found that the change of behavior has been introduced with this patch so you can blame me. It has now fixed this issue with this patch , which seems to work on my laptop, I hope it does on your computer as well. I can't help you with the fact that you can't run CUDA software with remote control. Simon On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > I think because in most cases people use their graphics in TCC mode for > scientific computations or don't use gpu at all where the rtk_use_cuda is > false. > Cheers, > > Louie > > Sent from my iOS > > On 04 Jul 2015, at 16:12, Guangming Zang > wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes > to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is > defined, then if CUDA device is not available this error will occur. When > using MS remote desktop, graphical card and driver are bypassed unless it > is Tesla cards working in TCC mode. You can either compile exes without > CUDA for remote desktop, or try other graphic-based remote desktop software > like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > 2015?7?3? 10:26 PM? "Guangming Zang" ??? > >> Dear RTK community, >> >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works >> fine, but when i use my laptop at home to remote control the computer in >> the lab, it does not work. i.e., no matter the command are (rtkfdk, >> ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >> @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in >> remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> Regards >> >> Guangming >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 6 06:19:10 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 6 Jul 2015 13:19:10 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Thanks all for your help,Simon. I will try it again when i am at home :) As for using Cuda in remote control, i can handle it:just like what Chao said, change lab computer to TCC. What confused me at the beginning is that a cuda error shown while i did not call cuda at all, and thanks for fixing it. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-06 12:32 GMT+03:00 Simon Rit : > Hi Guangming and all, > Thanks for reporting this change of behavior. My first answer is that what > you find simple is not so simple... but you're right, v1.0.0 allowed to > compile RTK with CUDA and to run it without a CUDA device. After a bit of > trakcing, I found that the change of behavior has been introduced with this > patch > > so you can blame me. It has now fixed this issue with this patch > , > which seems to work on my laptop, I hope it does on your computer as well. > I can't help you with the fact that you can't run CUDA software with > remote control. > Simon > > On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > >> I think because in most cases people use their graphics in TCC mode for >> scientific computations or don't use gpu at all where the rtk_use_cuda is >> false. >> Cheers, >> >> Louie >> >> Sent from my iOS >> >> On 04 Jul 2015, at 16:12, Guangming Zang >> wrote: >> >> Ok, i see. Though i still do not understand why in new version rtk >> changes to call cudaimages, not keeping it simple like before. >> Thanks for the help, Chao. >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ---------- Forwarded message ---------- >> From: Chao Wu >> Date: 2015-07-04 0:04 GMT+03:00 >> Subject: Re: Remote Control Issue >> To: Guangming Zang >> Cc: rtk-users-request at public.kitware.com, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> >> >> Now in many exes cudaimage is the default image type if rtk_use_cuda is >> defined, then if CUDA device is not available this error will occur. When >> using MS remote desktop, graphical card and driver are bypassed unless it >> is Tesla cards working in TCC mode. You can either compile exes without >> CUDA for remote desktop, or try other graphic-based remote desktop software >> like vnc or teamviewer. >> >> Regards, Chao >> Sent from Samsung Galaxy Note 3 >> 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> >>> Dear RTK community, >>> >>> There is some bug in RTK 1.1 version. That?s : >>> >>> When i run commands In 1.1 version with my computer in the lab, RTK >>> works fine, but when i use my laptop at home to remote control the >>> computer in the lab, it does not work. i.e., no matter the command are >>> (rtkfdk, ADMM,SART ?), an error is always shown: >>> >>> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >>> @ unknown : Cuda Error #3 >>> >>> but i did not use Cuda at all.. >>> >>> What?s more, when i run the 1.0 version RTK , it works well and no bug >>> in remoter control mode. >>> >>> So i think it is some problem caused by itk ?? can we fix this issue?? >>> >>> Thanks for help in advance >>> >>> >>> Regards >>> >>> Guangming >>> *Guangming Zang (Alex)* >>> *King Abdullah University of Science and Technology(KAUST)* >>> *University of Chinese Academy of Sciences(UCAS)* >>> >>> >>> >>> >>> ------------------------------ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete >>> this message from your computer system. Any unauthorized use or >>> distribution is prohibited. Please consider the environment before printing >>> this email. >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Wed Jul 8 22:26:29 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Wed, 8 Jul 2015 19:26:29 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question Message-ID: Hi, I have a question from you about the CT reconstruction, I would really appreciate if you can help me with this. I have the geometry as described in following and I am trying to run the rtkfdk code from RTK. % parameters % % % % % % % param.nx = 500; % number of voxels param.ny = 500; param.nz = 500; param.sx = 5000; % mm (real size) param.sy = 5000; % mm param.sz = 5000; % mm %The real detector panel pixel density (number of pixels) param.nu = 36; % number of pixels param.nv = 100; % Detector setting (real size) param.su = 7200; % mm (real size) param.sv = 9200; % mm % X-ray source and detector setting param.DSD = 32900; % Distance source to detector param.DSO = 27400; % X-ray source to object axis distance % angle setting param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) param.dang = 5; % angular step size (deg) param.deg = 0:param.dang:360-1; % you can change param.deg = param.deg*param.dir; param.nProj = length(param.deg); param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than 360 deg -> param.parker=1 param.filter='ram-lak'; % high pass filter param.dx = param.sx/param.nx; % single voxel size param.dy = param.sy/param.ny; param.dz = param.sz/param.nz; param.du = param.su/param.nu; param.dv = param.sv/param.nv; param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) % Geometry calculation % % % param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : 360). But I got confused how to set the geometry parameters in RTK I followed the rtkfdk tutorial but I can?t get any result using this method I did the following: 1- Create geometry.xml using these parameters: nproj = 72 ; first_angle = 0 ; arc = 360 ; sid = 27400 ; sdd = 32900 ; proj_iso_x = 0; proj_iso_y = 0; out_angle = 0 ; in_angle = 0 ; source_x = 0; source_y = 0 ; 2- Create my own mha file (WriteMhaFile.m) from my projection array (36*100*72) using a matlab code with following properties: Voxel size = [0.1 0.1 0.1] Offset = [1 1 1] 3- Then run the: rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 --dimension 500 Could you please tell me if I am setting the geometry correctly? Also, is there any other way to create my own mha file? Thank you in advance and looking forward to hear back from you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 02:23:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 08:23:36 +0200 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Hi, We can try to help but we need to understand your geometry... Where does it come from by the way? If I understand your geometry correctly, I would say : - sid, sdd, nproj, arc are correct, - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 and you have 36x100 pixels, then the pixel size is [200,92,1] (last dimension is not used so anything). For the volume, if your volume is 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and not 0.1. - offset of projections is probably wrong. If you want to have a centered projections, you'll need something like (-3500, -554, 0). You can set is to 0 and put those values in proj_iso_x and proj_iso_y. Regarding mha file, you can write mha files in many ways, using SimpleRTK, matlab or writing an ITK code. Good luck! Simon On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah wrote: > Hi, > > I have a question from you about the CT reconstruction, I would really > appreciate if you can help me with this. > > I have the geometry as described in following and I am trying to run the > rtkfdk code from RTK. > > > % parameters % % % % % % % > > param.nx = 500; % number of voxels > param.ny = 500; > param.nz = 500; > > > param.sx = 5000; % mm (real size) > param.sy = 5000; % mm > param.sz = 5000; % mm > > > %The real detector panel pixel density (number of pixels) > param.nu = 36; % number of pixels > param.nv = 100; > > % Detector setting (real size) > param.su = 7200; % mm (real size) > param.sv = 9200; % mm > > > % X-ray source and detector setting > param.DSD = 32900; % Distance source to detector > param.DSO = 27400; % X-ray source to object axis distance > > > % angle setting > param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) > param.dang = 5; % angular step size (deg) > param.deg = 0:param.dang:360-1; % you can change > param.deg = param.deg*param.dir; > param.nProj = length(param.deg); > > param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than > 360 deg -> param.parker=1 > > param.filter='ram-lak'; % high pass filter > > > param.dx = param.sx/param.nx; % single voxel size > param.dy = param.sy/param.ny; > param.dz = param.sz/param.nz; > param.du = param.su/param.nu; > param.dv = param.sv/param.nv; > param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) > > > % Geometry calculation % % % > param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; > param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; > param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; > param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; > param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; > > > > So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : > 360). > But I got confused how to set the geometry parameters in RTK > I followed the rtkfdk tutorial but I can?t get any result using this method > > I did the following: > > 1- Create geometry.xml using these parameters: > > nproj = 72 ; > first_angle = 0 ; > arc = 360 ; > sid = 27400 ; > sdd = 32900 ; > proj_iso_x = 0; > proj_iso_y = 0; > out_angle = 0 ; > in_angle = 0 ; > source_x = 0; > source_y = 0 ; > > 2- Create my own mha file (WriteMhaFile.m) from my projection array > (36*100*72) using a matlab code with following properties: > Voxel size = [0.1 0.1 0.1] > Offset = [1 1 1] > > > 3- Then run the: > rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 > --dimension 500 > > > Could you please tell me if I am setting the geometry correctly? > Also, is there any other way to create my own mha file? > > Thank you in advance and looking forward to hear back from you. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 12:12:01 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 18:12:01 +0200 Subject: [Rtk-users] RTK training In-Reply-To: <55816290.1010807@uclouvain.be> References: <55816290.1010807@uclouvain.be> Message-ID: Dear RTK users, We have finally set a date for the RTK training, Wednesday, Nov 18 2015 in Lyon (France). The training will be organised by Kitware, go to this page for the registration: http://formations.kitware.fr/browse/116 We will do both user and developer sessions during the training. Since it's the first time that we do the training, we will tailor the balance between the two according to the wishes of registered people. The rest of the information should be available on the website but let us know if you need more information, we are still building the webpage and we'll be happy to improve it. We're looking forward to this new training and we'll do our best to meet your expectations, Simon On Wed, Jun 17, 2015 at 2:05 PM, Cyril Mory wrote: > Dear RTK users, > > The first RTK training is being planned at this very moment. It should > take place in November in Lyon, and be hosted by Kitware. The exact date > has not yet been decided, but will be available soon. > > We need your help to decide what to focus this training on. The choice is > mainly between two options: > - if most trainees want to learn how to use RTK, then we will focus on the > command-line tools and on python + Simple RTK > - if most trainees want to learn how to develop within RTK, modify and > enrich it, then we will focus on software architecture, detailed filter > description, ITK pipeline management, CUDA filters, etc... > > Please let us know which of these choices would best suit your needs. > > Looking forward, > Cyril > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Thu Jul 9 17:59:05 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Thu, 9 Jul 2015 14:59:05 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Simon, Thank you. I think now I understand how the whole geometry is defined in RTK. The projection is based on one experiment I am doing using different simulation techniques. Again thank you for your help. Best, Ali On Wed, Jul 8, 2015 at 11:23 PM, Simon Rit wrote: > Hi, > We can try to help but we need to understand your geometry... Where does > it come from by the way? If I understand your geometry correctly, I would > say : > - sid, sdd, nproj, arc are correct, > - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 > and you have 36x100 pixels, then the pixel size is [200,92,1] (last > dimension is not used so anything). For the volume, if your volume is > 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and > not 0.1. > - offset of projections is probably wrong. If you want to have a centered > projections, you'll need something like (-3500, -554, 0). You can set is to > 0 and put those values in proj_iso_x and proj_iso_y. > Regarding mha file, you can write mha files in many ways, using SimpleRTK, > matlab or writing an ITK code. > Good luck! > Simon > > On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah > wrote: > >> Hi, >> >> I have a question from you about the CT reconstruction, I would really >> appreciate if you can help me with this. >> >> I have the geometry as described in following and I am trying to run the >> rtkfdk code from RTK. >> >> >> % parameters % % % % % % % >> >> param.nx = 500; % number of voxels >> param.ny = 500; >> param.nz = 500; >> >> >> param.sx = 5000; % mm (real size) >> param.sy = 5000; % mm >> param.sz = 5000; % mm >> >> >> %The real detector panel pixel density (number of pixels) >> param.nu = 36; % number of pixels >> param.nv = 100; >> >> % Detector setting (real size) >> param.su = 7200; % mm (real size) >> param.sv = 9200; % mm >> >> >> % X-ray source and detector setting >> param.DSD = 32900; % Distance source to detector >> param.DSO = 27400; % X-ray source to object axis distance >> >> >> % angle setting >> param.dir = +1; % gantry rotating direction (clock wise/ counter >> clockwise) >> param.dang = 5; % angular step size (deg) >> param.deg = 0:param.dang:360-1; % you can change >> param.deg = param.deg*param.dir; >> param.nProj = length(param.deg); >> >> param.parker = 0; % data with 360 deg -> param.parker = 0 , data less >> than >> 360 deg -> param.parker=1 >> >> param.filter='ram-lak'; % high pass filter >> >> >> param.dx = param.sx/param.nx; % single voxel size >> param.dy = param.sy/param.ny; >> param.dz = param.sz/param.nz; >> param.du = param.su/param.nu; >> param.dv = param.sv/param.nv; >> param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) >> >> >> % Geometry calculation % % % >> param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; >> param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; >> param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; >> param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; >> param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; >> >> >> >> So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : >> 360). >> But I got confused how to set the geometry parameters in RTK >> I followed the rtkfdk tutorial but I can?t get any result using this >> method >> >> I did the following: >> >> 1- Create geometry.xml using these parameters: >> >> nproj = 72 ; >> first_angle = 0 ; >> arc = 360 ; >> sid = 27400 ; >> sdd = 32900 ; >> proj_iso_x = 0; >> proj_iso_y = 0; >> out_angle = 0 ; >> in_angle = 0 ; >> source_x = 0; >> source_y = 0 ; >> >> 2- Create my own mha file (WriteMhaFile.m) from my projection array >> (36*100*72) using a matlab code with following properties: >> Voxel size = [0.1 0.1 0.1] >> Offset = [1 1 1] >> >> >> 3- Then run the: >> rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 >> --dimension 500 >> >> >> Could you please tell me if I am setting the geometry correctly? >> Also, is there any other way to create my own mha file? >> >> Thank you in advance and looking forward to hear back from you. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hougeamm at 126.com Thu Jul 9 18:35:09 2015 From: hougeamm at 126.com (=?GBK?B?uu645w==?=) Date: Fri, 10 Jul 2015 06:35:09 +0800 (CST) Subject: [Rtk-users] problems for elekta data Message-ID: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Hello Everyone, Why the Elekta data prompt projection doesn't match when using rtkfdk? e.g., 377 vs 389? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 10 01:43:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Jul 2015 07:43:15 +0200 Subject: [Rtk-users] problems for elekta data In-Reply-To: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> References: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Message-ID: Hi, The message that you have on the command line is the result of the files that have been found in the path (--path option) with the regular expression (--regexp option). If it found more projections than what you have, then you probably need to improve your reg exp, e.g., by a $ after the file extension to specify that the file name must end with it. Simon On Fri, Jul 10, 2015 at 12:35 AM, ?? wrote: > Hello Everyone, > Why the Elekta data prompt projection doesn't match when using > rtkfdk? e.g., 377 vs 389? > Thanks! > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From guangming.zang at kaust.edu.sa Mon Jul 13 02:48:15 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 09:48:15 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset Message-ID: Hi RTK comunity, Besides the prameters like SID and SDD , from the geometry(.xteck) file got from my scanner, i also have object (volume) information like this: VoxelsX=179 VoxelsY=163 VoxelsZ=127 VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 The X,Y and Z axis are identical to RTK's geometry , So i was really wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i can show all other parameters like: rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, but it still a slight different visualization result from what we got from scanner software. So would you help me??? File attached is the geometry file in case. Thanks in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VCC_Dome_0622.xtekct Type: application/octet-stream Size: 1813 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 13 04:38:00 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 11:38:00 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: problem fixed. because the scanned object is symmetric and i did not notice that i should -Z axis in scanner to map Z in RTK thanks. but, i still do not know in RTK how to show the OffsetZ.. :( Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-13 9:48 GMT+03:00 Guangming Zang : > Hi RTK comunity, > Besides the prameters like SID and SDD , from the geometry(.xteck) file > got from my scanner, i also have object (volume) information like this: > VoxelsX=179 VoxelsY=163 VoxelsZ=127 > VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 > OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 > The X,Y and Z axis are identical to RTK's geometry , So i was really > wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i > can show all other parameters like: > > rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing > 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 > --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 > > Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, > but it still a slight different visualization result from what we got from > scanner software. > So would you help me??? > > > File attached is the geometry file in case. Thanks in advance > Regards > Guangming > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Mon Jul 13 13:21:44 2015 From: robert.calliess at gmx.de (=?utf-8?Q?Robert_Callie=C3=9F?=) Date: Mon, 13 Jul 2015 19:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? Message-ID: Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 13 13:42:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 13 Jul 2015 19:42:43 +0200 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: Hi, OffsetZ probably refers to the coordinate of the volume in the room coordinate which we don't use in RTK. Everything is set in the tomography coordinate during reconstruction. You can always change the coordinates of your volume after if you want to put it in some other coordinate system. Simon On Mon, Jul 13, 2015 at 10:38 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > problem fixed. > because the scanned object is symmetric and i did not notice that i > should -Z axis in scanner to map Z in RTK > thanks. > but, i still do not know in RTK how to show the OffsetZ.. :( > > Guangming > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-13 9:48 GMT+03:00 Guangming Zang : > >> Hi RTK comunity, >> Besides the prameters like SID and SDD , from the geometry(.xteck) file >> got from my scanner, i also have object (volume) information like this: >> VoxelsX=179 VoxelsY=163 VoxelsZ=127 >> VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 >> OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 >> The X,Y and Z axis are identical to RTK's geometry , So i was really >> wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i >> can show all other parameters like: >> >> rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing >> 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 >> --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 >> >> Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, >> but it still a slight different visualization result from what we got from >> scanner software. >> So would you help me??? >> >> >> File attached is the geometry file in case. Thanks in advance >> Regards >> Guangming >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Tue Jul 14 03:01:14 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 14 Jul 2015 09:01:14 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 01:32:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 07:32:43 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: > Hell RTK User, > I think there is a mistake in the described approach. > Point a) and f) meight be wrong. As far as I Understand, all Pixels > that are covered by the projected voxel vertices are update > with weight * voxel_value. Where weight is the overlaping area > of the projected voxel vertices polygon on the detector plane and the > underlying detector pixels. > > Any opinions before implementing it ? > > regards, > Robert > > *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr > *Von:* "Robert Callie?" > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what > they called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can > be rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector > cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value > to back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Wed Jul 15 08:07:20 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Wed, 15 Jul 2015 14:07:20 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 08:21:44 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 14:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: > Hello Simon, > thank you for your answer. I guess you linked the wrong article. But I > know what article you are talking about. > It's the articel from 2009 with a piece of code (MapSeq). > > >> I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > detector pixels that are totally covered by the overlap are weight with > "1" and if the overlap is between detector pixels > the pixels are weighted. Do you have a copy of the original article from > the De Man and Basu ? > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > Do you agree with that or did I miss something ? > > best regards, > Robert > > *Gesendet:* Mittwoch, 15. Juli 2015 um 07:32 Uhr > *Von:* "Simon Rit" > *An:* "Robert Callie?" > *Cc:* "rtk-users at public.kitware.com" > *Betreff:* Re: [Rtk-users] distance driven projector, a simplified > approach ? > Hi, > Indeed, I have published an article > on this > projector describing my implementation, you could use it if you want, > there's even a piece of code in it although I'm pretty sure it's not the > best implementation. This implementation dealt with the case where the > rotation axis is parallel to the detector. As far as I can remember, the > original article of De Man and Basu is also quite clear. > I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > Simon > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: >> >> Hell RTK User, >> I think there is a mistake in the described approach. >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> that are covered by the projected voxel vertices are update >> with weight * voxel_value. Where weight is the overlaping area >> of the projected voxel vertices polygon on the detector plane and the >> underlying detector pixels. >> >> Any opinions before implementing it ? >> >> regards, >> Robert >> >> *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr >> *Von:* "Robert Callie?" >> *An:* rtk-users at public.kitware.com >> *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel boundaries >> onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel?s contribution (weight) is the area of this overlapping. I >> read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is what >> they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone beam >> geometry. We can >> >> either rotate the detector and source around the object or the object can >> be rotated >> >> and the detector and source are fixed. I think Simon also wrote a paper >> about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source position, >> object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector >> cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the >> corresponding detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a ? e). Value >> to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I?m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of voxel >> boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 15 15:14:13 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 15 Jul 2015 21:14:13 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hello Simon, thank you for the articles. May I ask you what do you mean by ?voxel correction factor? in the code you provided in your article ? float f) // Voxel correction factor Thank you and best regards, Robert Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit Gesendet: Mittwoch, 15. Juli 2015 14:22 An: Robert Callie? Cc: rtk-users at public.kitware.com Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: Hello Simon, thank you for your answer. I guess you linked the wrong article. But I know what article you are talking about. It's the articel from 2009 with a piece of code (MapSeq). >> I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. You're right. It is that all pixels that are related to the overlap projected voxel overlap have to taken into account. So detector pixels that are totally covered by the overlap are weight with "1" and if the overlap is between detector pixels the pixels are weighted. Do you have a copy of the original article from the De Man and Basu ? I have the opinion that it's not neccessary to project the detector pixel boundaries and voxel boundaries onto a common plane if we use a flat panel detector. Instead we could project the voxel boundaries onto the detector plane directly. Do you agree with that or did I miss something ? best regards, Robert Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr Von: "Simon Rit" An: "Robert Callie?" Cc: "rtk-users at public.kitware.com" Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: Hell RTK User, I think there is a mistake in the described approach. Point a) and f) meight be wrong. As far as I Understand, all Pixels that are covered by the projected voxel vertices are update with weight * voxel_value. Where weight is the overlaping area of the projected voxel vertices polygon on the detector plane and the underlying detector pixels. Any opinions before implementing it ? regards, Robert Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr Von: "Robert Callie?" An: rtk-users at public.kitware.com Betreff: [Rtk-users] distance driven projector, a simplified approach ? Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 15:45:23 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 21:45:23 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. Simon On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie? wrote: > Hello Simon, > > thank you for the articles. May I ask you what do you mean by > > ?voxel correction factor? in the code you provided in your article ? > > float f) // Voxel correction factor > > > > Thank you and best regards, > > Robert > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Mittwoch, 15. Juli 2015 14:22 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified > approach ? > > > > Sorry, this link indeed with the MapSeg function. And yes, I was projecting > it to the detector plane directly. > > Simon > > > > On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" > wrote: > > Hello Simon, > > thank you for your answer. I guess you linked the wrong article. But I know > what article you are talking about. > > It's the articel from 2009 with a piece of code (MapSeq). > > > >>> I don't have time to go into the details of what you have proposed but, >>> from a glance, the first step seems useless. > > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > > detector pixels that are totally covered by the overlap are weight with "1" > and if the overlap is between detector pixels > > the pixels are weighted. Do you have a copy of the original article from the > De Man and Basu ? > > > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > > Do you agree with that or did I miss something ? > > > > best regards, > > Robert > > > > Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr > Von: "Simon Rit" > An: "Robert Callie?" > Cc: "rtk-users at public.kitware.com" > Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? > > Hi, > > Indeed, I have published an article on this projector describing my > implementation, you could use it if you want, there's even a piece of code > in it although I'm pretty sure it's not the best implementation. This > implementation dealt with the case where the rotation axis is parallel to > the detector. As far as I can remember, the original article of De Man and > Basu is also quite clear. > > I don't have time to go into the details of what you have proposed but, from > a glance, the first step seems useless. > > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > > Simon > > > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: > > Hell RTK User, > > I think there is a mistake in the described approach. > > Point a) and f) meight be wrong. As far as I Understand, all Pixels > > that are covered by the projected voxel vertices are update > > with weight * voxel_value. Where weight is the overlaping area > > of the projected voxel vertices polygon on the detector plane and the > > underlying detector pixels. > > > > Any opinions before implementing it ? > > > > regards, > > Robert > > > > Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr > Von: "Robert Callie?" > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what they > called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can be > rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value to > back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From simon.rit at creatis.insa-lyon.fr Fri Jul 17 02:22:16 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 17 Jul 2015 08:22:16 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Please keep on using the mailing list, I don't see a good reason to keep this conversation private. I won't have time to go back into these details. From a quick look, I think this is correct although I would have simply said that D is the center of the detector pixel. Simon On Thu, Jul 16, 2015 at 10:24 PM, Robert Callie? wrote: > Hello, > Sorry that I have to ask again. But I want to clear this before I start. > I want to ask about the cosine weight DeMan mentioned in his article. > He wrote: > > " > (1) The intersection length of the line of interest with the image slab S, the latter being > defined as the slab parallel to the xz plane and containing voxel V. This intersection length > is given by t/(cos ? cos ? ), where t is the isotropic voxel size, and ? and ? are the in- and > out-of-plane angles of the line of interest with the y-axis. > " > > So what he actually does, is that he calculates the intersection length of the slab s (that contains the voxel) with > a ray going from xray source to the middle of two adjacent detector cell boundaries. Let's refare to Figure 5. > So the length to be considered is calculated as the intersection length of slab S with the ray going from > the source ( the black dot in figure 5) to the mid-point of D, that means the center of the two projected adjacent > detector pixel boundaries. > > > Sorry for asking again but I want it to make it clear to me. > > Best regards, > Robert > > > -----Urspr?ngliche Nachricht----- > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit > Gesendet: Mittwoch, 15. Juli 2015 21:45 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? > > "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" > So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. > Simon > > On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie wrote: >> Hello Simon, >> >> thank you for the articles. May I ask you what do you mean by >> >> voxel correction factor in the code you provided in your article ? >> >> float f) // Voxel correction factor >> >> >> >> Thank you and best regards, >> >> Robert >> >> >> >> Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von >> Simon Rit >> Gesendet: Mittwoch, 15. Juli 2015 14:22 >> An: Robert Callie >> Cc: rtk-users at public.kitware.com >> Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified >> approach ? >> >> >> >> Sorry, this link indeed with the MapSeg function. And yes, I was >> projecting it to the detector plane directly. >> >> Simon >> >> >> >> On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie " >> >> wrote: >> >> Hello Simon, >> >> thank you for your answer. I guess you linked the wrong article. But I >> know what article you are talking about. >> >> It's the articel from 2009 with a piece of code (MapSeq). >> >> >> >>>> I don't have time to go into the details of what you have proposed >>>> but, from a glance, the first step seems useless. >> >> You're right. It is that all pixels that are related to the overlap >> projected voxel overlap have to taken into account. So >> >> detector pixels that are totally covered by the overlap are weight with "1" >> and if the overlap is between detector pixels >> >> the pixels are weighted. Do you have a copy of the original article >> from the De Man and Basu ? >> >> >> >> I have the opinion that it's not neccessary to project the detector >> pixel boundaries and voxel boundaries onto a common plane >> >> if we use a flat panel detector. Instead we could project the voxel >> boundaries onto the detector plane directly. >> >> Do you agree with that or did I miss something ? >> >> >> >> best regards, >> >> Robert >> >> >> >> Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr >> Von: "Simon Rit" >> An: "Robert Callie " >> Cc: "rtk-users at public.kitware.com" >> Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hi, >> >> Indeed, I have published an article on this projector describing my >> implementation, you could use it if you want, there's even a piece of >> code in it although I'm pretty sure it's not the best implementation. >> This implementation dealt with the case where the rotation axis is >> parallel to the detector. As far as I can remember, the original >> article of De Man and Basu is also quite clear. >> >> I don't have time to go into the details of what you have proposed >> but, from a glance, the first step seems useless. >> >> Good luck in your implementation and don't hesitate to send it to us >> when you have a working RTK implementation, >> >> Simon >> >> >> >> On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie " >> >> wrote: >> >> Hell RTK User, >> >> I think there is a mistake in the described approach. >> >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> >> that are covered by the projected voxel vertices are update >> >> with weight * voxel_value. Where weight is the overlaping area >> >> of the projected voxel vertices polygon on the detector plane and the >> >> underlying detector pixels. >> >> >> >> Any opinions before implementing it ? >> >> >> >> regards, >> >> Robert >> >> >> >> Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr >> Von: "Robert Callie " >> An: rtk-users at public.kitware.com >> Betreff: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel >> boundaries onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel s contribution (weight) is the area of this >> overlapping. I read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is >> what they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone >> beam geometry. We can >> >> either rotate the detector and source around the object or the object >> can be rotated >> >> and the detector and source are fixed. I think Simon also wrote a >> paper about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source >> position, object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the corresponding >> detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a e). >> Value to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of >> voxel boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > From guangming.zang at kaust.edu.sa Sun Jul 26 18:30:42 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 01:30:42 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed Message-ID: Hi RTK community, i am using SART algorithm to reconstruct an object. But in this new RTK version, the time recording seems a little weird: the total time is 1219.12s , but adding the time cost in different stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward projection part. BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, both multi-threading i think. Can anyone tell me what's going on? Thanks Regards Guangming [image: ???? 1] *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 01:59:11 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 07:59:11 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Guangming, It's not surprising to me that the backprojection is faster than the forward projection, that's what I expect. If the total time is longer, that's probably that some individual steps are not included in the total time. Can you try to add reader->Update(); before the line itk::TimeProbe totalTimeProbe; in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? Simon On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > Hi RTK community, > i am using SART algorithm to reconstruct an object. > But in this new RTK version, the time recording seems a little weird: > the total time is 1219.12s , but adding the time cost in different stages > is not 1291.12 s. especially for "backprojection" part, only 16.6051s to > reconstruct a 128^3 volume ?? even shorter than forward projection part. > BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, > both multi-threading i think. > Can anyone tell me what's going on? > Thanks > Regards > Guangming > > [image: ???? 1] > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 27 04:41:58 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 11:41:58 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, Thanks for your reply. would you pls help and explain why backprojection is expected to take shorter time than forward projection?? because i was thinking if no caching step, the backprojection should take much longer time than sart algorithm. yes, i run rtksart for 2 times once.it took 12xxs, similar to the time consumed of 3 times's sart, which much slower than my own application. BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 shapp-logan projections(512*512 resolution each) rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 and i will try reader->Update() like what you said. Thanks Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 8:59 GMT+03:00 Simon Rit : > Hi Guangming, > It's not surprising to me that the backprojection is faster than the > forward projection, that's what I expect. If the total time is longer, > that's probably that some individual steps are not included in the total > time. Can you try to add > reader->Update(); > before the line > > itk::TimeProbe totalTimeProbe; > > in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? > > Simon > > > > On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi RTK community, >> i am using SART algorithm to reconstruct an object. >> But in this new RTK version, the time recording seems a little weird: >> the total time is 1219.12s , but adding the time cost in different >> stages is not 1291.12 s. especially for "backprojection" part, only >> 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward >> projection part. BTW, the -f and -b are Joseph and >> VoxelBasedBackProjection, respectively, both multi-threading i think. >> Can anyone tell me what's going on? >> Thanks >> Regards >> Guangming >> >> [image: ???? 1] >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 08:28:28 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 14:28:28 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: I can try. Forward and back projection have the same algorithmic complexity but voxel based backprojection benefits from several optimizations in terms of memory management and computations that makes it faster. The best is to look at the code for further details... although both have far from being optimal. And I did not get the sentence "the backprojection should take much longer time than sart algorithm." because SART contains a backprojection and other steps so SART is obviously longer than the bp alone. Your log is strange and I don't see what steps are not timed that would take most of the time. I did the same test on my computer and here is my result: OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha --dimension 512 OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.288571 s Multiplication by zero: 0.131672 s Forward projection: 34.3612 s Subtraction: 0.203409 s Multiplication by lambda: 0.146459 s Ray box intersection: 1.30755 s Division: 0.187294 s Multiplication by the gating weights: 0 s Displaced detector: 0.278408 s Back projection: 11.8456 s Volume update: 0 s It took... 53.2765 s Simon On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang wrote: > Hi Simon, > Thanks for your reply. > would you pls help and explain why backprojection is expected to take > shorter time than forward projection?? because i was thinking if no caching > step, the backprojection should take much longer time than sart algorithm. > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > consumed of 3 times's sart, which much slower than my own application. > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > shapp-logan projections(512*512 resolution each) > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > -64,-64,-64 -l 0.5 -n 3 --time 1 > > and i will try reader->Update() like what you said. > Thanks > Guangming > > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> Hi Guangming, >> It's not surprising to me that the backprojection is faster than the >> forward projection, that's what I expect. If the total time is longer, >> that's probably that some individual steps are not included in the total >> time. Can you try to add >> reader->Update(); >> before the line >> >> itk::TimeProbe totalTimeProbe; >> >> in rtksart.cxx? It may be that all the reading operations are done but not >> timed in the sart->Update(). Why they are so long, I don't know, is your D: >> drive a network drive? Do you observe the same behavior if you do rtksart 2 >> times in a row? >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> wrote: >>> >>> Hi RTK community, >>> i am using SART algorithm to reconstruct an object. >>> But in this new RTK version, the time recording seems a little weird: >>> the total time is 1219.12s , but adding the time cost in different >>> stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s >>> to reconstruct a 128^3 volume ?? even shorter than forward projection part. >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, >>> both multi-threading i think. >>> Can anyone tell me what's going on? >>> Thanks >>> Regards >>> Guangming >>> >>> >>> Guangming Zang (Alex) >>> King Abdullah University of Science and Technology(KAUST) >>> University of Chinese Academy of Sciences(UCAS) >>> >>> >>> >>> >>> ________________________________ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete this >>> message from your computer system. Any unauthorized use or distribution is >>> prohibited. Please consider the environment before printing this email. >> >> > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 08:50:48 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 15:50:48 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, sorry for the mistake, not"the backprojection should take much longer time than sart algorithm" , but "the backprojection should take much longer time than forward projection in sart algorithm". BTW, how many cores does your computer have?? Mine is 24 cores. is it can explain the reason why it takes much longer time on my computer than yours? Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 15:28 GMT+03:00 Simon Rit : > I can try. Forward and back projection have the same algorithmic > complexity but voxel based backprojection benefits from several > optimizations in terms of memory management and computations that > makes it faster. The best is to look at the code for further > details... although both have far from being optimal. And I did not > get the sentence "the backprojection should take much longer time than > sart algorithm." because SART contains a backprojection and other > steps so SART is obviously longer than the bp alone. > Your log is strange and I don't see what steps are not timed that > would take most of the time. I did the same test on my computer and > here is my result: > > OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > --dimension 512 > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.288571 s > Multiplication by zero: 0.131672 s > Forward projection: 34.3612 s > Subtraction: 0.203409 s > Multiplication by lambda: 0.146459 s > Ray box intersection: 1.30755 s > Division: 0.187294 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.278408 s > Back projection: 11.8456 s > Volume update: 0 s > It took... 53.2765 s > > Simon > > On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > wrote: > > Hi Simon, > > Thanks for your reply. > > would you pls help and explain why backprojection is expected to take > > shorter time than forward projection?? because i was thinking if no > caching > > step, the backprojection should take much longer time than sart > algorithm. > > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > > consumed of 3 times's sart, which much slower than my own application. > > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > > shapp-logan projections(512*512 resolution each) > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > > -64,-64,-64 -l 0.5 -n 3 --time 1 > > > > and i will try reader->Update() like what you said. > > Thanks > > Guangming > > > > > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> > >> Hi Guangming, > >> It's not surprising to me that the backprojection is faster than the > >> forward projection, that's what I expect. If the total time is longer, > >> that's probably that some individual steps are not included in the total > >> time. Can you try to add > >> reader->Update(); > >> before the line > >> > >> itk::TimeProbe totalTimeProbe; > >> > >> in rtksart.cxx? It may be that all the reading operations are done but > not > >> timed in the sart->Update(). Why they are so long, I don't know, is > your D: > >> drive a network drive? Do you observe the same behavior if you do > rtksart 2 > >> times in a row? > >> > >> Simon > >> > >> > >> > >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> wrote: > >>> > >>> Hi RTK community, > >>> i am using SART algorithm to reconstruct an object. > >>> But in this new RTK version, the time recording seems a little weird: > >>> the total time is 1219.12s , but adding the time cost in different > >>> stages is not 1291.12 s. especially for "backprojection" part, only > 16.6051s > >>> to reconstruct a 128^3 volume ?? even shorter than forward projection > part. > >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > respectively, > >>> both multi-threading i think. > >>> Can anyone tell me what's going on? > >>> Thanks > >>> Regards > >>> Guangming > >>> > >>> > >>> Guangming Zang (Alex) > >>> King Abdullah University of Science and Technology(KAUST) > >>> University of Chinese Academy of Sciences(UCAS) > >>> > >>> > >>> > >>> > >>> ________________________________ > >>> This message and its contents, including attachments are intended > solely > >>> for the original recipient. If you are not the intended recipient or > have > >>> received this message in error, please notify me immediately and > delete this > >>> message from your computer system. Any unauthorized use or > distribution is > >>> prohibited. Please consider the environment before printing this email. > >> > >> > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 09:02:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 15:02:03 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: No I expect forward projection to be longer than backprojection although with optimal implementations, it should take about the same time since they have the same complexity. I have 4 cores on my laptop. I don't see how it explains it, try to find out where does SART spend the time. Simon On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang wrote: > Hi Simon, > sorry for the mistake, not"the backprojection should take much longer time > than > sart algorithm" , but "the backprojection should take much longer time than > forward projection in sart algorithm". > > BTW, how many cores does your computer have?? Mine is 24 cores. > is it can explain the reason why it takes much longer time on my computer > than yours? > Regards > Guangming > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> I can try. Forward and back projection have the same algorithmic >> complexity but voxel based backprojection benefits from several >> optimizations in terms of memory management and computations that >> makes it faster. The best is to look at the code for further >> details... although both have far from being optimal. And I did not >> get the sentence "the backprojection should take much longer time than >> sart algorithm." because SART contains a backprojection and other >> steps so SART is obviously longer than the bp alone. >> Your log is strange and I don't see what steps are not timed that >> would take most of the time. I did the same test on my computer and >> here is my result: >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> --dimension 512 >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> 1 >> Recording elapsed time... >> SARTConeBeamReconstructionFilter timing: >> Extraction of projection sub-stacks: 0.288571 s >> Multiplication by zero: 0.131672 s >> Forward projection: 34.3612 s >> Subtraction: 0.203409 s >> Multiplication by lambda: 0.146459 s >> Ray box intersection: 1.30755 s >> Division: 0.187294 s >> Multiplication by the gating weights: 0 s >> Displaced detector: 0.278408 s >> Back projection: 11.8456 s >> Volume update: 0 s >> It took... 53.2765 s >> >> Simon >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> wrote: >> > Hi Simon, >> > Thanks for your reply. >> > would you pls help and explain why backprojection is expected to take >> > shorter time than forward projection?? because i was thinking if no >> > caching >> > step, the backprojection should take much longer time than sart >> > algorithm. >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time >> > consumed of 3 times's sart, which much slower than my own application. >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 >> > shapp-logan projections(512*512 resolution each) >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> > >> > and i will try reader->Update() like what you said. >> > Thanks >> > Guangming >> > >> > >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> >> >> Hi Guangming, >> >> It's not surprising to me that the backprojection is faster than the >> >> forward projection, that's what I expect. If the total time is longer, >> >> that's probably that some individual steps are not included in the >> >> total >> >> time. Can you try to add >> >> reader->Update(); >> >> before the line >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done but >> >> not >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> your D: >> >> drive a network drive? Do you observe the same behavior if you do >> >> rtksart 2 >> >> times in a row? >> >> >> >> Simon >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> wrote: >> >>> >> >>> Hi RTK community, >> >>> i am using SART algorithm to reconstruct an object. >> >>> But in this new RTK version, the time recording seems a little weird: >> >>> the total time is 1219.12s , but adding the time cost in different >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >>> 16.6051s >> >>> to reconstruct a 128^3 volume ?? even shorter than forward projection >> >>> part. >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >>> respectively, >> >>> both multi-threading i think. >> >>> Can anyone tell me what's going on? >> >>> Thanks >> >>> Regards >> >>> Guangming >> >>> >> >>> >> >>> Guangming Zang (Alex) >> >>> King Abdullah University of Science and Technology(KAUST) >> >>> University of Chinese Academy of Sciences(UCAS) >> >>> >> >>> >> >>> >> >>> >> >>> ________________________________ >> >>> This message and its contents, including attachments are intended >> >>> solely >> >>> for the original recipient. If you are not the intended recipient or >> >>> have >> >>> received this message in error, please notify me immediately and >> >>> delete this >> >>> message from your computer system. Any unauthorized use or >> >>> distribution is >> >>> prohibited. Please consider the environment before printing this >> >>> email. >> >> >> >> >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended solely >> > for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> > this >> > message from your computer system. Any unauthorized use or distribution >> > is >> > prohibited. Please consider the environment before printing this email. > > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 10:05:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:05:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, it cost 1200s for SART algorithm at first, and the command are: rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 in which, the projections data(360pro_SL_Vol128_512.mha) is not generated from rtkprojectshepploganphantom , but from my application. though it took long time, but i can got a nice result, And i just tried the command you used, i.e. generated the projections data by rtkprojectshepploganphantom : rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 --sid=500.0 rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 yes, it takes about 56s. but the reconstructed result is weird, the voxel values range from [-142186, 208146] and can not see anything when visualizing it. i believe you got the similar results, which maybe explain why it computes much faster. if i wanna use the projections generated by rtkprojectshepploganphantom , can you give me an example to get a nice results? Best regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 16:02 GMT+03:00 Simon Rit : > No I expect forward projection to be longer than backprojection > although with optimal implementations, it should take about the same > time since they have the same complexity. > I have 4 cores on my laptop. I don't see how it explains it, try to > find out where does SART spend the time. > Simon > > On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang > wrote: > > Hi Simon, > > sorry for the mistake, not"the backprojection should take much longer > time > > than > > sart algorithm" , but "the backprojection should take much longer time > than > > forward projection in sart algorithm". > > > > BTW, how many cores does your computer have?? Mine is 24 cores. > > is it can explain the reason why it takes much longer time on my computer > > than yours? > > Regards > > Guangming > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : > >> > >> I can try. Forward and back projection have the same algorithmic > >> complexity but voxel based backprojection benefits from several > >> optimizations in terms of memory management and computations that > >> makes it faster. The best is to look at the code for further > >> details... although both have far from being optimal. And I did not > >> get the sentence "the backprojection should take much longer time than > >> sart algorithm." because SART contains a backprojection and other > >> steps so SART is obviously longer than the bp alone. > >> Your log is strange and I don't see what steps are not timed that > >> would take most of the time. I did the same test on my computer and > >> here is my result: > >> > >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > >> --dimension 512 > >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > >> 1 > >> Recording elapsed time... > >> SARTConeBeamReconstructionFilter timing: > >> Extraction of projection sub-stacks: 0.288571 s > >> Multiplication by zero: 0.131672 s > >> Forward projection: 34.3612 s > >> Subtraction: 0.203409 s > >> Multiplication by lambda: 0.146459 s > >> Ray box intersection: 1.30755 s > >> Division: 0.187294 s > >> Multiplication by the gating weights: 0 s > >> Displaced detector: 0.278408 s > >> Back projection: 11.8456 s > >> Volume update: 0 s > >> It took... 53.2765 s > >> > >> Simon > >> > >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > >> wrote: > >> > Hi Simon, > >> > Thanks for your reply. > >> > would you pls help and explain why backprojection is expected to take > >> > shorter time than forward projection?? because i was thinking if no > >> > caching > >> > step, the backprojection should take much longer time than sart > >> > algorithm. > >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the > time > >> > consumed of 3 times's sart, which much slower than my own application. > >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > >> > shapp-logan projections(512*512 resolution each) > >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > >> > -64,-64,-64 -l 0.5 -n 3 --time 1 > >> > > >> > and i will try reader->Update() like what you said. > >> > Thanks > >> > Guangming > >> > > >> > > >> > > >> > Guangming Zang (Alex) > >> > King Abdullah University of Science and Technology(KAUST) > >> > University of Chinese Academy of Sciences(UCAS) > >> > > >> > > >> > > >> > > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> >> > >> >> Hi Guangming, > >> >> It's not surprising to me that the backprojection is faster than the > >> >> forward projection, that's what I expect. If the total time is > longer, > >> >> that's probably that some individual steps are not included in the > >> >> total > >> >> time. Can you try to add > >> >> reader->Update(); > >> >> before the line > >> >> > >> >> itk::TimeProbe totalTimeProbe; > >> >> > >> >> in rtksart.cxx? It may be that all the reading operations are done > but > >> >> not > >> >> timed in the sart->Update(). Why they are so long, I don't know, is > >> >> your D: > >> >> drive a network drive? Do you observe the same behavior if you do > >> >> rtksart 2 > >> >> times in a row? > >> >> > >> >> Simon > >> >> > >> >> > >> >> > >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> >> wrote: > >> >>> > >> >>> Hi RTK community, > >> >>> i am using SART algorithm to reconstruct an object. > >> >>> But in this new RTK version, the time recording seems a little > weird: > >> >>> the total time is 1219.12s , but adding the time cost in different > >> >>> stages is not 1291.12 s. especially for "backprojection" part, only > >> >>> 16.6051s > >> >>> to reconstruct a 128^3 volume ?? even shorter than forward > projection > >> >>> part. > >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > >> >>> respectively, > >> >>> both multi-threading i think. > >> >>> Can anyone tell me what's going on? > >> >>> Thanks > >> >>> Regards > >> >>> Guangming > >> >>> > >> >>> > >> >>> Guangming Zang (Alex) > >> >>> King Abdullah University of Science and Technology(KAUST) > >> >>> University of Chinese Academy of Sciences(UCAS) > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> ________________________________ > >> >>> This message and its contents, including attachments are intended > >> >>> solely > >> >>> for the original recipient. If you are not the intended recipient or > >> >>> have > >> >>> received this message in error, please notify me immediately and > >> >>> delete this > >> >>> message from your computer system. Any unauthorized use or > >> >>> distribution is > >> >>> prohibited. Please consider the environment before printing this > >> >>> email. > >> >> > >> >> > >> > > >> > > >> > ________________________________ > >> > This message and its contents, including attachments are intended > solely > >> > for > >> > the original recipient. If you are not the intended recipient or have > >> > received this message in error, please notify me immediately and > delete > >> > this > >> > message from your computer system. Any unauthorized use or > distribution > >> > is > >> > prohibited. Please consider the environment before printing this > email. > > > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 10:12:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:12:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: BTW, the projections are 512*512, and the pixel spacing is 0.5 Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:05 GMT+03:00 Guangming Zang : > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 10:20:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 16:20:12 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Obviously I hadn't looked at the result and/or checked the command line options, sorry. This is an example from the same simulated dataset that gives me a good results: OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.567773 s Multiplication by zero: 0.303715 s Forward projection: 142.305 s Subtraction: 0.445842 s Multiplication by lambda: 0.2663 s Ray box intersection: 5.40366 s Division: 0.535618 s Multiplication by the gating weights: 0 s Displaced detector: 0.415431 s Back projection: 21.3689 s Volume update: 0 s It took... 177.059 s but this doesn't change the content of my previous message. What takes time is probably in your own software, be sure that you update SART inputs before timing it. Simon On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang wrote: > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 11:12:16 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 18:12:16 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Thanks Simon, now it work fine when using projections generated by RTK itself (command rtkprojectshepploganphantom ). for 1 iteration of SART to reconstruct 128^3 size volume, it took only 19s, which gives nice results as well. Thanks again. Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:20 GMT+03:00 Simon Rit : > Obviously I hadn't looked at the result and/or checked the command line > options, sorry. This is an example from the same simulated dataset that > gives me a good results: > > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f > Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n > 3 --time 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.567773 s > Multiplication by zero: 0.303715 s > Forward projection: 142.305 s > Subtraction: 0.445842 s > Multiplication by lambda: 0.2663 s > Ray box intersection: 5.40366 s > Division: 0.535618 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.415431 s > Back projection: 21.3689 s > Volume update: 0 s > It took... 177.059 s > > but this doesn't change the content of my previous message. What takes > time is probably in your own software, be sure that you update SART inputs > before timing it. > Simon > > On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon, >> it cost 1200s for SART algorithm at first, and the command are: >> rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd= >> 725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" >> >> rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 >> >> in which, the projections data(360pro_SL_Vol128_512.mha) is not >> generated from rtkprojectshepploganphantom , but from my application. >> though it took long time, but i can got a nice result, >> >> >> And i just tried the command you used, i.e. generated the projections >> data by rtkprojectshepploganphantom : >> >> rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 >> --sid=500.0 >> rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 >> rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b >> VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 >> --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 >> yes, it takes about 56s. >> but the reconstructed result is weird, the voxel values range from >> [-142186, 208146] and can not see anything when visualizing it. >> i believe you got the similar results, which maybe explain why it >> computes much faster. >> >> if i wanna use the projections generated by rtkprojectshepploganphantom >> , can you give me an example to get a nice results? >> >> Best regards >> Guangming >> >> >> >> >> >> >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> 2015-07-27 16:02 GMT+03:00 Simon Rit : >> >>> No I expect forward projection to be longer than backprojection >>> although with optimal implementations, it should take about the same >>> time since they have the same complexity. >>> I have 4 cores on my laptop. I don't see how it explains it, try to >>> find out where does SART spend the time. >>> Simon >>> >>> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >>> wrote: >>> > Hi Simon, >>> > sorry for the mistake, not"the backprojection should take much longer >>> time >>> > than >>> > sart algorithm" , but "the backprojection should take much longer time >>> than >>> > forward projection in sart algorithm". >>> > >>> > BTW, how many cores does your computer have?? Mine is 24 cores. >>> > is it can explain the reason why it takes much longer time on my >>> computer >>> > than yours? >>> > Regards >>> > Guangming >>> > >>> > Guangming Zang (Alex) >>> > King Abdullah University of Science and Technology(KAUST) >>> > University of Chinese Academy of Sciences(UCAS) >>> > >>> > >>> > >>> > >>> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >>> >> >>> >> I can try. Forward and back projection have the same algorithmic >>> >> complexity but voxel based backprojection benefits from several >>> >> optimizations in terms of memory management and computations that >>> >> makes it faster. The best is to look at the code for further >>> >> details... although both have far from being optimal. And I did not >>> >> get the sentence "the backprojection should take much longer time than >>> >> sart algorithm." because SART contains a backprojection and other >>> >> steps so SART is obviously longer than the bp alone. >>> >> Your log is strange and I don't see what steps are not timed that >>> >> would take most of the time. I did the same test on my computer and >>> >> here is my result: >>> >> >>> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >>> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >>> >> --dimension 512 >>> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >>> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >>> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >>> >> 1 >>> >> Recording elapsed time... >>> >> SARTConeBeamReconstructionFilter timing: >>> >> Extraction of projection sub-stacks: 0.288571 s >>> >> Multiplication by zero: 0.131672 s >>> >> Forward projection: 34.3612 s >>> >> Subtraction: 0.203409 s >>> >> Multiplication by lambda: 0.146459 s >>> >> Ray box intersection: 1.30755 s >>> >> Division: 0.187294 s >>> >> Multiplication by the gating weights: 0 s >>> >> Displaced detector: 0.278408 s >>> >> Back projection: 11.8456 s >>> >> Volume update: 0 s >>> >> It took... 53.2765 s >>> >> >>> >> Simon >>> >> >>> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >>> >> wrote: >>> >> > Hi Simon, >>> >> > Thanks for your reply. >>> >> > would you pls help and explain why backprojection is expected to >>> take >>> >> > shorter time than forward projection?? because i was thinking if no >>> >> > caching >>> >> > step, the backprojection should take much longer time than sart >>> >> > algorithm. >>> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >>> time >>> >> > consumed of 3 times's sart, which much slower than my own >>> application. >>> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >>> 360 >>> >> > shapp-logan projections(512*512 resolution each) >>> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >>> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >>> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >>> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >>> >> > >>> >> > and i will try reader->Update() like what you said. >>> >> > Thanks >>> >> > Guangming >>> >> > >>> >> > >>> >> > >>> >> > Guangming Zang (Alex) >>> >> > King Abdullah University of Science and Technology(KAUST) >>> >> > University of Chinese Academy of Sciences(UCAS) >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit >> >: >>> >> >> >>> >> >> Hi Guangming, >>> >> >> It's not surprising to me that the backprojection is faster than >>> the >>> >> >> forward projection, that's what I expect. If the total time is >>> longer, >>> >> >> that's probably that some individual steps are not included in the >>> >> >> total >>> >> >> time. Can you try to add >>> >> >> reader->Update(); >>> >> >> before the line >>> >> >> >>> >> >> itk::TimeProbe totalTimeProbe; >>> >> >> >>> >> >> in rtksart.cxx? It may be that all the reading operations are done >>> but >>> >> >> not >>> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >>> >> >> your D: >>> >> >> drive a network drive? Do you observe the same behavior if you do >>> >> >> rtksart 2 >>> >> >> times in a row? >>> >> >> >>> >> >> Simon >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >>> >> >> wrote: >>> >> >>> >>> >> >>> Hi RTK community, >>> >> >>> i am using SART algorithm to reconstruct an object. >>> >> >>> But in this new RTK version, the time recording seems a little >>> weird: >>> >> >>> the total time is 1219.12s , but adding the time cost in >>> different >>> >> >>> stages is not 1291.12 s. especially for "backprojection" part, >>> only >>> >> >>> 16.6051s >>> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >>> projection >>> >> >>> part. >>> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >>> >> >>> respectively, >>> >> >>> both multi-threading i think. >>> >> >>> Can anyone tell me what's going on? >>> >> >>> Thanks >>> >> >>> Regards >>> >> >>> Guangming >>> >> >>> >>> >> >>> >>> >> >>> Guangming Zang (Alex) >>> >> >>> King Abdullah University of Science and Technology(KAUST) >>> >> >>> University of Chinese Academy of Sciences(UCAS) >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> ________________________________ >>> >> >>> This message and its contents, including attachments are intended >>> >> >>> solely >>> >> >>> for the original recipient. If you are not the intended recipient >>> or >>> >> >>> have >>> >> >>> received this message in error, please notify me immediately and >>> >> >>> delete this >>> >> >>> message from your computer system. Any unauthorized use or >>> >> >>> distribution is >>> >> >>> prohibited. Please consider the environment before printing this >>> >> >>> email. >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > ________________________________ >>> >> > This message and its contents, including attachments are intended >>> solely >>> >> > for >>> >> > the original recipient. If you are not the intended recipient or >>> have >>> >> > received this message in error, please notify me immediately and >>> delete >>> >> > this >>> >> > message from your computer system. Any unauthorized use or >>> distribution >>> >> > is >>> >> > prohibited. Please consider the environment before printing this >>> email. >>> > >>> > >>> > >>> > ________________________________ >>> > This message and its contents, including attachments are intended >>> solely for >>> > the original recipient. If you are not the intended recipient or have >>> > received this message in error, please notify me immediately and >>> delete this >>> > message from your computer system. Any unauthorized use or >>> distribution is >>> > prohibited. Please consider the environment before printing this email. >>> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From infrombox at yandex.ru Tue Jul 28 04:30:22 2015 From: infrombox at yandex.ru (1 1) Date: Tue, 28 Jul 2015 15:30:22 +0700 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: <2213081438072222@web8j.yandex.ru> Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. But program which i use reads meta images with MET_SHORT pixel type only. Is there easy way to setting it and get volume with different from MET_FLOAT pixel type ? If not, could you advice me, what the filter i should to do, for example as post process after reconstruction ala MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward operation of LUTbasedVariableI0RawToAttenuationImageFilter ? Thanks. From simon.rit at creatis.insa-lyon.fr Tue Jul 28 04:56:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 10:56:54 +0200 Subject: [Rtk-users] volume with diffieret pixel type In-Reply-To: <2213081438072222@web8j.yandex.ru> References: <2213081438072222@web8j.yandex.ru> Message-ID: Hi, This is more an ITK question than a RTK question. Yes, we use float by default in our applications. You can cast the image to any type before writing using itk::CastImageFilter but you'll have to modify the applications and, of course, there is a loss of information. If you don't want to program it, you can use any other software, e.g. in vv right clik on your image after opening and use the convert to option. Simon On Tue, Jul 28, 2015 at 10:30 AM, 1 1 wrote: > Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. > But program which i use reads meta images with MET_SHORT pixel type only. > Is there easy way to setting it and get volume with different from > MET_FLOAT pixel type ? If not, could you advice me, what the filter i > should to do, for example as post process after reconstruction ala > MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward > operation of LUTbasedVariableI0RawToAttenuationImageFilter image, float image> ? > Thanks. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pconneely020186 at gmail.com Tue Jul 28 12:05:29 2015 From: pconneely020186 at gmail.com (peter conneely) Date: Tue, 28 Jul 2015 17:05:29 +0100 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: "peter conneely" Date: 24 Jul 2015 11:07 Subject: Issue running FDK reconstruction algorithm To: Cc: Hi, I'm having trouble running the FDK reconstruction alogrithm on Elekta and Varian data sets. The algorithm does work when I try the shepp-logan example. When I initially ran the application I included the (') around .*.his. and got the following lines. [image: Inline image 1] when I try to run with the (') removed it finds the 669 files but then the application stops working. I have tried adding registry edits to run exe and have tried switching of dep. Neither of these work I am not sure what is going wrong and how to fix it. My system properties are as follows. Processor: Intel Pentium CPU P6100 @ 2.00 Ghz RAM: 3.00 GB GPU: Intel HD Graphics Systems type 64 Bit. Thanks and Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Tue Jul 28 12:46:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 18:46:17 +0200 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: Hi, I guess the quotes are OS depedent, maybe you need double quotes on Windows. It's strange that you don't get an error message. Are you sure it crashed? If yes, have you checked the elektaGeometry file? Does it have 669 projection sections as expected? Or maybe it's a memory issue, try the --lowmem option. Simon On Tue, Jul 28, 2015 at 6:05 PM, peter conneely wrote: > ---------- Forwarded message ---------- > From: "peter conneely" > Date: 24 Jul 2015 11:07 > Subject: Issue running FDK reconstruction algorithm > To: > Cc: > > Hi, > > I'm having trouble running the FDK reconstruction alogrithm on Elekta and > Varian data sets. The algorithm does work when I try the shepp-logan > example. > > When I initially ran the application I included the (') around .*.his. and > got the following lines. > [image: Inline image 1] > when I try to run with the (') removed it finds the 669 files but then the > application stops working. I have tried adding registry edits to run exe > and have tried switching of dep. Neither of these work I am not sure what > is going wrong and how to fix it. > > My system properties are as follows. > Processor: Intel Pentium CPU P6100 @ 2.00 Ghz > RAM: 3.00 GB > GPU: Intel HD Graphics > Systems type 64 Bit. > > Thanks and Regards, > Peter > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Tue Jul 28 13:38:45 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Tue, 28 Jul 2015 20:38:45 +0300 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: Hi, in ITK, the default type are described in *Utilities\MetaIO\metaTypes.h* MET_CHAR, MET_UCHAR ?,? ?? MET_SHORT, MET_USHORT, MET_INT,=20 MET_UINT,=20 MET_FLOAT,=20 MET_DOUBLE, ?and for .mha file, the header file includes information like: ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = 0 0 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 1 1 1 DimSize = 128 128 128 ElementType = MET_FLOAT ElementDataFile = LOCAL? ?And recently i just programmed to read and write .mha files. below is the code. u can just replace ElementType from ? MET_FLOAT ? to ? ? MET_SHORT ? in your application. hope this helps: #include "stdafx.h" #include #include #include #include #include #include using namespace std; int _tmain(int argc, _TCHAR* argv[]) { int m_Dims[3]; float spacing[3]; m_Dims[0]=128; m_Dims[1]=128; m_Dims[2]=128; spacing[0]=spacing[1]=spacing[2]=1.0f; ostringstream buffer, buffer1, buffer2, buf3; buffer << spacing[0]; string sp= buffer.str(); buffer1 << spacing[1]; string sp1 = buffer1.str(); buffer2 << spacing[2]; string sp2 = buffer2.str(); string ElementSpacing ="ElementSpacing= "+sp+" "+sp1+" "+sp2+"\n"; // int ss=1000; char temp[64], temp1[64],temp2[64]; string str; sprintf(temp, "%d", m_Dims[0]); sprintf(temp1, "%d", m_Dims[1]); sprintf(temp2, "%d", m_Dims[2]); string s(temp),s1(temp1),s2(temp2); string DimSize="DimSize= "+s+" "+s1+" "+s2+"\n"; string Mywritefile="ObjectType = Image\nNDims = 3\nBinaryData = True\nBinaryDataByteOrderMSB = False \nCompressedData = False \nTransformMatrix = 1 0 0 0 1 0 0 0 1 \n" ; Mywritefile+="Offset = 0 0 0 \nCenterOfRotation = 0 0 0 \nAnatomicalOrientation = RAI \n"; Mywritefile+=ElementSpacing+DimSize+"ElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; // ElementSpacing = 1 1 1 \nDimSize = 128 128 128 \nElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; int leng=Mywritefile.length(); cout< From simon.rit at creatis.insa-lyon.fr Wed Jul 29 08:53:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 29 Jul 2015 14:53:34 +0200 Subject: [Rtk-users] RTK images make the cover of Medical Physics Message-ID: See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Wed Jul 29 09:07:01 2015 From: theday79 at gmail.com (Yang K Park) Date: Wed, 29 Jul 2015 09:07:01 -0400 Subject: [Rtk-users] RTK images make the cover of Medical Physics In-Reply-To: References: Message-ID: <001801d0c9ff$76797860$636c6920$@gmail.com> Hi Simon, Thank you so much for the congrats! This is my great honor and I?d like to thank all the RTK developers and community members for their helps on this achievement! Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: Wednesday, July 29, 2015 8:54 AM To: rtk-users at public.kitware.com Subject: [Rtk-users] RTK images make the cover of Medical Physics See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Thu Jul 30 08:16:38 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Thu, 30 Jul 2015 15:16:38 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK Message-ID: Hi Simon and Chao, i am currently do some comparisons between different reconstruction methods for Shapp-Logan dataset. the commands are: rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=955.4050067 --sid=500.0 rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha --dimension 512,512 when using FDK or SART algorithm from RTK, I can got pretty good results indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 and levels as 1.04 for all results got). When running ADMMTV command below, though the geometry is as same as SART and FDK, the result got from ADMM looks weird.(pls see attached central slice of ground truth and ADMM, same contrast with other algorithm) rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 [image: ???? 1][image: ???? 2] Is it because the CG algorithm used by ADMM, or parameters setting issues here?? if it is parameters setting problem , would you help me and give a nice values for alpha and bate used here? BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already (including default value) Thanks and regards Guangming ?? *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ? -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 31 01:55:32 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 31 Jul 2015 07:55:32 +0200 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi, It looks to me that you haven't converged. I'm not the specialist of this algorithm and the specialist won't be near a computer in the coming weeks but when I try with more iterations in the data attachment term: rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 it's more satisfactory. There are rings at the top and the bottom of the cone-beam which should be reduced with more TV (greater alpha, see doc here ) or with a finer spacing (see this publication ). Simon On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang wrote: > Hi Simon and Chao, > > i am currently do some comparisons between different reconstruction > methods for Shapp-Logan dataset. > > the commands are: > > rtksimulatedgeometry -n 360 --arc -360 -o > geo.xml --sdd=955.4050067 --sid=500.0 > > rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha > --dimension 512,512 > > > > when using FDK or SART algorithm from RTK, I can got pretty good results > indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 > and levels as 1.04 for all results got). When running ADMMTV command below, > though the geometry is as same as SART and FDK, the result got from ADMM > looks weird.(pls see attached central slice of ground truth and ADMM, same > contrast with other algorithm) > > rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o > SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 > --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 > > [image: ???? 1][image: ???? 2] > > Is it because the CG algorithm used by ADMM, or parameters setting issues > here?? if it is parameters setting problem , would you help me and give a > nice values for alpha and bate used here? > > BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already > (including default value) > > Thanks and regards > > Guangming > > > ?? > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > ? > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Fri Jul 31 09:46:41 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 31 Jul 2015 16:46:41 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi simon, i see, thanks for the help and explanation. after following your advice, it works fine now. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-31 8:55 GMT+03:00 Simon Rit : > Hi, > It looks to me that you haven't converged. I'm not the specialist of this > algorithm and the specialist won't be near a computer in the coming weeks > but when I try with more iterations in the data attachment term: > rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml > --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 > it's more satisfactory. There are rings at the top and the bottom of the > cone-beam which should be reduced with more TV (greater alpha, see doc > here > ) > or with a finer spacing (see this publication > ). > Simon > > On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon and Chao, >> >> i am currently do some comparisons between different reconstruction >> methods for Shapp-Logan dataset. >> >> the commands are: >> >> rtksimulatedgeometry -n 360 --arc -360 -o >> geo.xml --sdd=955.4050067 --sid=500.0 >> >> rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha >> --dimension 512,512 >> >> >> >> when using FDK or SART algorithm from RTK, I can got pretty good results >> indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 >> and levels as 1.04 for all results got). When running ADMMTV command below, >> though the geometry is as same as SART and FDK, the result got from ADMM >> looks weird.(pls see attached central slice of ground truth and ADMM, same >> contrast with other algorithm) >> >> rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o >> SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 >> --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 >> >> [image: ???? 1][image: ???? 2] >> >> Is it because the CG algorithm used by ADMM, or parameters setting issues >> here?? if it is parameters setting problem , would you help me and give a >> nice values for alpha and bate used here? >> >> BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already >> (including default value) >> >> Thanks and regards >> >> Guangming >> >> >> ?? >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> ? >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 1 08:45:35 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 1 Jul 2015 14:45:35 +0200 Subject: [Rtk-users] Release of RTK v1.1.0 Message-ID: Dear RTK users, RTK v1.1.0 has been released today, about 14 months after RTK v1.0.0. The main features that have been developed since the previous release are: - SimpleRTK to run RTK filters (even the CUDA ones) from python scripts, C# code, and more - new projection pre-processing options (i0 calculation, scatter correction, water pre-correction) - extraction of the respiratory phase from cone-beam projections - linear programming for field-of-view computation based on a third party software, lp solve 5.5 - management of off-center detector in iterative methods - new iterative 3D and 4D reconstruction methods with Daubechies wavelets regularization - new iterative 4D reconstruction method with motion-aware regularization - reduction of memory footprint, especially GPU memory - many new CUDA filters - more robust (many bugs and memory leaks fixed) - use of MathJax to display formulas in the documentation, e.g., here . Many thanks to the increasing number of contributors, in alphabetical order: Ben Champion, Chao Wu, Cyril Mory, I Putu Susila, Julien Jomier, Marc Vila, Mathieu Dupont, Matt Clarkson, Peter Keuschnigg, S?bastien Brousmiche, Simon Rit, Tristan Coulange, Yang K Park. We don't focus on releases since we have a public github repository that we try to keep stable, I still recommend the use of the master HEAD over releases to enjoy the new RTK developments before their release. We still have a few on-going projects for which we will use and enhance RTK. Simon (for the RTK consortium) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 1 15:39:14 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 1 Jul 2015 21:39:14 +0200 Subject: [Rtk-users] loading projection images for sart Message-ID: Hello, I got compiled the ITK and RTK with help of cmake. I also had a look at the examples coming with RTK. I want to run a simple SART and got projection images in the format PNG and BMP. So I create an instance of the ThreeDcircularProjectionGeometry, SARTConeBeamReconstructionFilter and add the geometric projection data. rtk::ThreeDCircularProjectionGeometry::Pointer geometry; geometry = rtk::ThreeDCircularProjectionGeometry::New(); geometry->AddProjection(??) rtk::SARTConeBeamReconstructionFilter::Pointer sart = rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); How to add a stack of images to the SART reconstruction, i.e. std::vector images ? I got xray projections in png format. There is a method in the SART class called SetInput. But according tot he examples it is used to set a volume. Does anybody alread wrote a small piece of code that loads some images from the disk and put them into the SART reconstruction ? Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 2 12:19:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 2 Jul 2015 18:19:36 +0200 Subject: [Rtk-users] loading projection images for sart In-Reply-To: References: Message-ID: Hi, The stack of 2D images is passed via a 3D image. Look at the rtksart application for example. A way to read this from a set of file names is to use itk::ImageSeriesReader as done in rtk::ProjectionsReader. You should be able to understand how it works by looking at the existing RTK applications in the applications subfolders. Simon On Wed, Jul 1, 2015 at 9:39 PM, Robert Callie? wrote: > Hello, > > I got compiled the ITK and RTK with help of cmake. I also had a look > > at the examples coming with RTK. I want to run a simple SART and > > got projection images in the format PNG and BMP. > > > > So I create an instance of the ThreeDcircularProjectionGeometry, > SARTConeBeamReconstructionFilter > > and add the geometric projection data. > > > > rtk::ThreeDCircularProjectionGeometry::Pointer geometry; > > geometry = rtk::ThreeDCircularProjectionGeometry::New(); > > geometry->AddProjection(??) > > > > rtk::SARTConeBeamReconstructionFilter::Pointer sart = > rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); > > > > How to add a stack of images to the SART reconstruction, i.e. > std::vector images ? > > I got xray projections in png format. > > > > There is a method in the SART class called SetInput. But according tot he > examples it is used to set a volume. > > > > Does anybody alread wrote a small piece of code that loads some images > from the disk and put them into the SART reconstruction ? > > > > Regards, > > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Fri Jul 3 16:28:11 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 3 Jul 2015 23:28:11 +0300 Subject: [Rtk-users] Remote Control Issue in new RTK version Message-ID: Dear RTK community, There is some bug in RTK 1.1 version. That?s : When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 but i did not use Cuda at all.. What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. So i think it is some problem caused by itk ?? can we fix this issue?? Thanks for help in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Sat Jul 4 10:12:03 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Sat, 4 Jul 2015 17:12:03 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. Thanks for the help, Chao. *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ---------- Forwarded message ---------- From: Chao Wu Date: 2015-07-04 0:04 GMT+03:00 Subject: Re: Remote Control Issue To: Guangming Zang Cc: rtk-users-request at public.kitware.com, Simon Rit < simon.rit at creatis.insa-lyon.fr> Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. Regards, Chao Sent from Samsung Galaxy Note 3 2015?7?3? 10:26 PM? "Guangming Zang" ??? > Dear RTK community, > > There is some bug in RTK 1.1 version. That?s : > > When i run commands In 1.1 version with my computer in the lab, RTK works > fine, but when i use my laptop at home to remote control the computer in > the lab, it does not work. i.e., no matter the command are (rtkfdk, > ADMM,SART ?), an error is always shown: > > ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 > @ unknown : Cuda Error #3 > > but i did not use Cuda at all.. > > What?s more, when i run the 1.0 version RTK , it works well and no bug in > remoter control mode. > > So i think it is some problem caused by itk ?? can we fix this issue?? > > Thanks for help in advance > > > Regards > > Guangming > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Sat Jul 4 10:19:32 2015 From: ghostcz at hotmail.com (louie L) Date: Sat, 4 Jul 2015 16:19:32 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: I think because in most cases people use their graphics in TCC mode for scientific computations or don't use gpu at all where the rtk_use_cuda is false. Cheers, Louie Sent from my iOS > On 04 Jul 2015, at 16:12, Guangming Zang wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > > 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> Dear RTK community, >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> >> Regards >> >> Guangming >> >> Guangming Zang (Alex) >> King Abdullah University of Science and Technology(KAUST) >> University of Chinese Academy of Sciences(UCAS) >> >> >> >> >> This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > > > This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Mon Jul 6 05:32:18 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 6 Jul 2015 11:32:18 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Hi Guangming and all, Thanks for reporting this change of behavior. My first answer is that what you find simple is not so simple... but you're right, v1.0.0 allowed to compile RTK with CUDA and to run it without a CUDA device. After a bit of trakcing, I found that the change of behavior has been introduced with this patch so you can blame me. It has now fixed this issue with this patch , which seems to work on my laptop, I hope it does on your computer as well. I can't help you with the fact that you can't run CUDA software with remote control. Simon On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > I think because in most cases people use their graphics in TCC mode for > scientific computations or don't use gpu at all where the rtk_use_cuda is > false. > Cheers, > > Louie > > Sent from my iOS > > On 04 Jul 2015, at 16:12, Guangming Zang > wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes > to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is > defined, then if CUDA device is not available this error will occur. When > using MS remote desktop, graphical card and driver are bypassed unless it > is Tesla cards working in TCC mode. You can either compile exes without > CUDA for remote desktop, or try other graphic-based remote desktop software > like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > 2015?7?3? 10:26 PM? "Guangming Zang" ??? > >> Dear RTK community, >> >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works >> fine, but when i use my laptop at home to remote control the computer in >> the lab, it does not work. i.e., no matter the command are (rtkfdk, >> ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >> @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in >> remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> Regards >> >> Guangming >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 6 06:19:10 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 6 Jul 2015 13:19:10 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Thanks all for your help,Simon. I will try it again when i am at home :) As for using Cuda in remote control, i can handle it:just like what Chao said, change lab computer to TCC. What confused me at the beginning is that a cuda error shown while i did not call cuda at all, and thanks for fixing it. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-06 12:32 GMT+03:00 Simon Rit : > Hi Guangming and all, > Thanks for reporting this change of behavior. My first answer is that what > you find simple is not so simple... but you're right, v1.0.0 allowed to > compile RTK with CUDA and to run it without a CUDA device. After a bit of > trakcing, I found that the change of behavior has been introduced with this > patch > > so you can blame me. It has now fixed this issue with this patch > , > which seems to work on my laptop, I hope it does on your computer as well. > I can't help you with the fact that you can't run CUDA software with > remote control. > Simon > > On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > >> I think because in most cases people use their graphics in TCC mode for >> scientific computations or don't use gpu at all where the rtk_use_cuda is >> false. >> Cheers, >> >> Louie >> >> Sent from my iOS >> >> On 04 Jul 2015, at 16:12, Guangming Zang >> wrote: >> >> Ok, i see. Though i still do not understand why in new version rtk >> changes to call cudaimages, not keeping it simple like before. >> Thanks for the help, Chao. >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ---------- Forwarded message ---------- >> From: Chao Wu >> Date: 2015-07-04 0:04 GMT+03:00 >> Subject: Re: Remote Control Issue >> To: Guangming Zang >> Cc: rtk-users-request at public.kitware.com, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> >> >> Now in many exes cudaimage is the default image type if rtk_use_cuda is >> defined, then if CUDA device is not available this error will occur. When >> using MS remote desktop, graphical card and driver are bypassed unless it >> is Tesla cards working in TCC mode. You can either compile exes without >> CUDA for remote desktop, or try other graphic-based remote desktop software >> like vnc or teamviewer. >> >> Regards, Chao >> Sent from Samsung Galaxy Note 3 >> 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> >>> Dear RTK community, >>> >>> There is some bug in RTK 1.1 version. That?s : >>> >>> When i run commands In 1.1 version with my computer in the lab, RTK >>> works fine, but when i use my laptop at home to remote control the >>> computer in the lab, it does not work. i.e., no matter the command are >>> (rtkfdk, ADMM,SART ?), an error is always shown: >>> >>> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >>> @ unknown : Cuda Error #3 >>> >>> but i did not use Cuda at all.. >>> >>> What?s more, when i run the 1.0 version RTK , it works well and no bug >>> in remoter control mode. >>> >>> So i think it is some problem caused by itk ?? can we fix this issue?? >>> >>> Thanks for help in advance >>> >>> >>> Regards >>> >>> Guangming >>> *Guangming Zang (Alex)* >>> *King Abdullah University of Science and Technology(KAUST)* >>> *University of Chinese Academy of Sciences(UCAS)* >>> >>> >>> >>> >>> ------------------------------ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete >>> this message from your computer system. Any unauthorized use or >>> distribution is prohibited. Please consider the environment before printing >>> this email. >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Wed Jul 8 22:26:29 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Wed, 8 Jul 2015 19:26:29 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question Message-ID: Hi, I have a question from you about the CT reconstruction, I would really appreciate if you can help me with this. I have the geometry as described in following and I am trying to run the rtkfdk code from RTK. % parameters % % % % % % % param.nx = 500; % number of voxels param.ny = 500; param.nz = 500; param.sx = 5000; % mm (real size) param.sy = 5000; % mm param.sz = 5000; % mm %The real detector panel pixel density (number of pixels) param.nu = 36; % number of pixels param.nv = 100; % Detector setting (real size) param.su = 7200; % mm (real size) param.sv = 9200; % mm % X-ray source and detector setting param.DSD = 32900; % Distance source to detector param.DSO = 27400; % X-ray source to object axis distance % angle setting param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) param.dang = 5; % angular step size (deg) param.deg = 0:param.dang:360-1; % you can change param.deg = param.deg*param.dir; param.nProj = length(param.deg); param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than 360 deg -> param.parker=1 param.filter='ram-lak'; % high pass filter param.dx = param.sx/param.nx; % single voxel size param.dy = param.sy/param.ny; param.dz = param.sz/param.nz; param.du = param.su/param.nu; param.dv = param.sv/param.nv; param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) % Geometry calculation % % % param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : 360). But I got confused how to set the geometry parameters in RTK I followed the rtkfdk tutorial but I can?t get any result using this method I did the following: 1- Create geometry.xml using these parameters: nproj = 72 ; first_angle = 0 ; arc = 360 ; sid = 27400 ; sdd = 32900 ; proj_iso_x = 0; proj_iso_y = 0; out_angle = 0 ; in_angle = 0 ; source_x = 0; source_y = 0 ; 2- Create my own mha file (WriteMhaFile.m) from my projection array (36*100*72) using a matlab code with following properties: Voxel size = [0.1 0.1 0.1] Offset = [1 1 1] 3- Then run the: rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 --dimension 500 Could you please tell me if I am setting the geometry correctly? Also, is there any other way to create my own mha file? Thank you in advance and looking forward to hear back from you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 02:23:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 08:23:36 +0200 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Hi, We can try to help but we need to understand your geometry... Where does it come from by the way? If I understand your geometry correctly, I would say : - sid, sdd, nproj, arc are correct, - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 and you have 36x100 pixels, then the pixel size is [200,92,1] (last dimension is not used so anything). For the volume, if your volume is 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and not 0.1. - offset of projections is probably wrong. If you want to have a centered projections, you'll need something like (-3500, -554, 0). You can set is to 0 and put those values in proj_iso_x and proj_iso_y. Regarding mha file, you can write mha files in many ways, using SimpleRTK, matlab or writing an ITK code. Good luck! Simon On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah wrote: > Hi, > > I have a question from you about the CT reconstruction, I would really > appreciate if you can help me with this. > > I have the geometry as described in following and I am trying to run the > rtkfdk code from RTK. > > > % parameters % % % % % % % > > param.nx = 500; % number of voxels > param.ny = 500; > param.nz = 500; > > > param.sx = 5000; % mm (real size) > param.sy = 5000; % mm > param.sz = 5000; % mm > > > %The real detector panel pixel density (number of pixels) > param.nu = 36; % number of pixels > param.nv = 100; > > % Detector setting (real size) > param.su = 7200; % mm (real size) > param.sv = 9200; % mm > > > % X-ray source and detector setting > param.DSD = 32900; % Distance source to detector > param.DSO = 27400; % X-ray source to object axis distance > > > % angle setting > param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) > param.dang = 5; % angular step size (deg) > param.deg = 0:param.dang:360-1; % you can change > param.deg = param.deg*param.dir; > param.nProj = length(param.deg); > > param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than > 360 deg -> param.parker=1 > > param.filter='ram-lak'; % high pass filter > > > param.dx = param.sx/param.nx; % single voxel size > param.dy = param.sy/param.ny; > param.dz = param.sz/param.nz; > param.du = param.su/param.nu; > param.dv = param.sv/param.nv; > param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) > > > % Geometry calculation % % % > param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; > param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; > param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; > param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; > param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; > > > > So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : > 360). > But I got confused how to set the geometry parameters in RTK > I followed the rtkfdk tutorial but I can?t get any result using this method > > I did the following: > > 1- Create geometry.xml using these parameters: > > nproj = 72 ; > first_angle = 0 ; > arc = 360 ; > sid = 27400 ; > sdd = 32900 ; > proj_iso_x = 0; > proj_iso_y = 0; > out_angle = 0 ; > in_angle = 0 ; > source_x = 0; > source_y = 0 ; > > 2- Create my own mha file (WriteMhaFile.m) from my projection array > (36*100*72) using a matlab code with following properties: > Voxel size = [0.1 0.1 0.1] > Offset = [1 1 1] > > > 3- Then run the: > rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 > --dimension 500 > > > Could you please tell me if I am setting the geometry correctly? > Also, is there any other way to create my own mha file? > > Thank you in advance and looking forward to hear back from you. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 12:12:01 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 18:12:01 +0200 Subject: [Rtk-users] RTK training In-Reply-To: <55816290.1010807@uclouvain.be> References: <55816290.1010807@uclouvain.be> Message-ID: Dear RTK users, We have finally set a date for the RTK training, Wednesday, Nov 18 2015 in Lyon (France). The training will be organised by Kitware, go to this page for the registration: http://formations.kitware.fr/browse/116 We will do both user and developer sessions during the training. Since it's the first time that we do the training, we will tailor the balance between the two according to the wishes of registered people. The rest of the information should be available on the website but let us know if you need more information, we are still building the webpage and we'll be happy to improve it. We're looking forward to this new training and we'll do our best to meet your expectations, Simon On Wed, Jun 17, 2015 at 2:05 PM, Cyril Mory wrote: > Dear RTK users, > > The first RTK training is being planned at this very moment. It should > take place in November in Lyon, and be hosted by Kitware. The exact date > has not yet been decided, but will be available soon. > > We need your help to decide what to focus this training on. The choice is > mainly between two options: > - if most trainees want to learn how to use RTK, then we will focus on the > command-line tools and on python + Simple RTK > - if most trainees want to learn how to develop within RTK, modify and > enrich it, then we will focus on software architecture, detailed filter > description, ITK pipeline management, CUDA filters, etc... > > Please let us know which of these choices would best suit your needs. > > Looking forward, > Cyril > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Thu Jul 9 17:59:05 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Thu, 9 Jul 2015 14:59:05 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Simon, Thank you. I think now I understand how the whole geometry is defined in RTK. The projection is based on one experiment I am doing using different simulation techniques. Again thank you for your help. Best, Ali On Wed, Jul 8, 2015 at 11:23 PM, Simon Rit wrote: > Hi, > We can try to help but we need to understand your geometry... Where does > it come from by the way? If I understand your geometry correctly, I would > say : > - sid, sdd, nproj, arc are correct, > - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 > and you have 36x100 pixels, then the pixel size is [200,92,1] (last > dimension is not used so anything). For the volume, if your volume is > 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and > not 0.1. > - offset of projections is probably wrong. If you want to have a centered > projections, you'll need something like (-3500, -554, 0). You can set is to > 0 and put those values in proj_iso_x and proj_iso_y. > Regarding mha file, you can write mha files in many ways, using SimpleRTK, > matlab or writing an ITK code. > Good luck! > Simon > > On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah > wrote: > >> Hi, >> >> I have a question from you about the CT reconstruction, I would really >> appreciate if you can help me with this. >> >> I have the geometry as described in following and I am trying to run the >> rtkfdk code from RTK. >> >> >> % parameters % % % % % % % >> >> param.nx = 500; % number of voxels >> param.ny = 500; >> param.nz = 500; >> >> >> param.sx = 5000; % mm (real size) >> param.sy = 5000; % mm >> param.sz = 5000; % mm >> >> >> %The real detector panel pixel density (number of pixels) >> param.nu = 36; % number of pixels >> param.nv = 100; >> >> % Detector setting (real size) >> param.su = 7200; % mm (real size) >> param.sv = 9200; % mm >> >> >> % X-ray source and detector setting >> param.DSD = 32900; % Distance source to detector >> param.DSO = 27400; % X-ray source to object axis distance >> >> >> % angle setting >> param.dir = +1; % gantry rotating direction (clock wise/ counter >> clockwise) >> param.dang = 5; % angular step size (deg) >> param.deg = 0:param.dang:360-1; % you can change >> param.deg = param.deg*param.dir; >> param.nProj = length(param.deg); >> >> param.parker = 0; % data with 360 deg -> param.parker = 0 , data less >> than >> 360 deg -> param.parker=1 >> >> param.filter='ram-lak'; % high pass filter >> >> >> param.dx = param.sx/param.nx; % single voxel size >> param.dy = param.sy/param.ny; >> param.dz = param.sz/param.nz; >> param.du = param.su/param.nu; >> param.dv = param.sv/param.nv; >> param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) >> >> >> % Geometry calculation % % % >> param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; >> param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; >> param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; >> param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; >> param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; >> >> >> >> So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : >> 360). >> But I got confused how to set the geometry parameters in RTK >> I followed the rtkfdk tutorial but I can?t get any result using this >> method >> >> I did the following: >> >> 1- Create geometry.xml using these parameters: >> >> nproj = 72 ; >> first_angle = 0 ; >> arc = 360 ; >> sid = 27400 ; >> sdd = 32900 ; >> proj_iso_x = 0; >> proj_iso_y = 0; >> out_angle = 0 ; >> in_angle = 0 ; >> source_x = 0; >> source_y = 0 ; >> >> 2- Create my own mha file (WriteMhaFile.m) from my projection array >> (36*100*72) using a matlab code with following properties: >> Voxel size = [0.1 0.1 0.1] >> Offset = [1 1 1] >> >> >> 3- Then run the: >> rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 >> --dimension 500 >> >> >> Could you please tell me if I am setting the geometry correctly? >> Also, is there any other way to create my own mha file? >> >> Thank you in advance and looking forward to hear back from you. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hougeamm at 126.com Thu Jul 9 18:35:09 2015 From: hougeamm at 126.com (=?GBK?B?uu645w==?=) Date: Fri, 10 Jul 2015 06:35:09 +0800 (CST) Subject: [Rtk-users] problems for elekta data Message-ID: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Hello Everyone, Why the Elekta data prompt projection doesn't match when using rtkfdk? e.g., 377 vs 389? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 10 01:43:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Jul 2015 07:43:15 +0200 Subject: [Rtk-users] problems for elekta data In-Reply-To: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> References: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Message-ID: Hi, The message that you have on the command line is the result of the files that have been found in the path (--path option) with the regular expression (--regexp option). If it found more projections than what you have, then you probably need to improve your reg exp, e.g., by a $ after the file extension to specify that the file name must end with it. Simon On Fri, Jul 10, 2015 at 12:35 AM, ?? wrote: > Hello Everyone, > Why the Elekta data prompt projection doesn't match when using > rtkfdk? e.g., 377 vs 389? > Thanks! > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From guangming.zang at kaust.edu.sa Mon Jul 13 02:48:15 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 09:48:15 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset Message-ID: Hi RTK comunity, Besides the prameters like SID and SDD , from the geometry(.xteck) file got from my scanner, i also have object (volume) information like this: VoxelsX=179 VoxelsY=163 VoxelsZ=127 VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 The X,Y and Z axis are identical to RTK's geometry , So i was really wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i can show all other parameters like: rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, but it still a slight different visualization result from what we got from scanner software. So would you help me??? File attached is the geometry file in case. Thanks in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VCC_Dome_0622.xtekct Type: application/octet-stream Size: 1813 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 13 04:38:00 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 11:38:00 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: problem fixed. because the scanned object is symmetric and i did not notice that i should -Z axis in scanner to map Z in RTK thanks. but, i still do not know in RTK how to show the OffsetZ.. :( Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-13 9:48 GMT+03:00 Guangming Zang : > Hi RTK comunity, > Besides the prameters like SID and SDD , from the geometry(.xteck) file > got from my scanner, i also have object (volume) information like this: > VoxelsX=179 VoxelsY=163 VoxelsZ=127 > VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 > OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 > The X,Y and Z axis are identical to RTK's geometry , So i was really > wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i > can show all other parameters like: > > rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing > 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 > --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 > > Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, > but it still a slight different visualization result from what we got from > scanner software. > So would you help me??? > > > File attached is the geometry file in case. Thanks in advance > Regards > Guangming > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Mon Jul 13 13:21:44 2015 From: robert.calliess at gmx.de (=?utf-8?Q?Robert_Callie=C3=9F?=) Date: Mon, 13 Jul 2015 19:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? Message-ID: Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 13 13:42:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 13 Jul 2015 19:42:43 +0200 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: Hi, OffsetZ probably refers to the coordinate of the volume in the room coordinate which we don't use in RTK. Everything is set in the tomography coordinate during reconstruction. You can always change the coordinates of your volume after if you want to put it in some other coordinate system. Simon On Mon, Jul 13, 2015 at 10:38 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > problem fixed. > because the scanned object is symmetric and i did not notice that i > should -Z axis in scanner to map Z in RTK > thanks. > but, i still do not know in RTK how to show the OffsetZ.. :( > > Guangming > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-13 9:48 GMT+03:00 Guangming Zang : > >> Hi RTK comunity, >> Besides the prameters like SID and SDD , from the geometry(.xteck) file >> got from my scanner, i also have object (volume) information like this: >> VoxelsX=179 VoxelsY=163 VoxelsZ=127 >> VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 >> OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 >> The X,Y and Z axis are identical to RTK's geometry , So i was really >> wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i >> can show all other parameters like: >> >> rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing >> 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 >> --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 >> >> Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, >> but it still a slight different visualization result from what we got from >> scanner software. >> So would you help me??? >> >> >> File attached is the geometry file in case. Thanks in advance >> Regards >> Guangming >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Tue Jul 14 03:01:14 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 14 Jul 2015 09:01:14 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 01:32:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 07:32:43 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: > Hell RTK User, > I think there is a mistake in the described approach. > Point a) and f) meight be wrong. As far as I Understand, all Pixels > that are covered by the projected voxel vertices are update > with weight * voxel_value. Where weight is the overlaping area > of the projected voxel vertices polygon on the detector plane and the > underlying detector pixels. > > Any opinions before implementing it ? > > regards, > Robert > > *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr > *Von:* "Robert Callie?" > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what > they called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can > be rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector > cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value > to back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Wed Jul 15 08:07:20 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Wed, 15 Jul 2015 14:07:20 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 08:21:44 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 14:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: > Hello Simon, > thank you for your answer. I guess you linked the wrong article. But I > know what article you are talking about. > It's the articel from 2009 with a piece of code (MapSeq). > > >> I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > detector pixels that are totally covered by the overlap are weight with > "1" and if the overlap is between detector pixels > the pixels are weighted. Do you have a copy of the original article from > the De Man and Basu ? > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > Do you agree with that or did I miss something ? > > best regards, > Robert > > *Gesendet:* Mittwoch, 15. Juli 2015 um 07:32 Uhr > *Von:* "Simon Rit" > *An:* "Robert Callie?" > *Cc:* "rtk-users at public.kitware.com" > *Betreff:* Re: [Rtk-users] distance driven projector, a simplified > approach ? > Hi, > Indeed, I have published an article > on this > projector describing my implementation, you could use it if you want, > there's even a piece of code in it although I'm pretty sure it's not the > best implementation. This implementation dealt with the case where the > rotation axis is parallel to the detector. As far as I can remember, the > original article of De Man and Basu is also quite clear. > I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > Simon > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: >> >> Hell RTK User, >> I think there is a mistake in the described approach. >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> that are covered by the projected voxel vertices are update >> with weight * voxel_value. Where weight is the overlaping area >> of the projected voxel vertices polygon on the detector plane and the >> underlying detector pixels. >> >> Any opinions before implementing it ? >> >> regards, >> Robert >> >> *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr >> *Von:* "Robert Callie?" >> *An:* rtk-users at public.kitware.com >> *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel boundaries >> onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel?s contribution (weight) is the area of this overlapping. I >> read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is what >> they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone beam >> geometry. We can >> >> either rotate the detector and source around the object or the object can >> be rotated >> >> and the detector and source are fixed. I think Simon also wrote a paper >> about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source position, >> object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector >> cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the >> corresponding detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a ? e). Value >> to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I?m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of voxel >> boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 15 15:14:13 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 15 Jul 2015 21:14:13 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hello Simon, thank you for the articles. May I ask you what do you mean by ?voxel correction factor? in the code you provided in your article ? float f) // Voxel correction factor Thank you and best regards, Robert Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit Gesendet: Mittwoch, 15. Juli 2015 14:22 An: Robert Callie? Cc: rtk-users at public.kitware.com Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: Hello Simon, thank you for your answer. I guess you linked the wrong article. But I know what article you are talking about. It's the articel from 2009 with a piece of code (MapSeq). >> I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. You're right. It is that all pixels that are related to the overlap projected voxel overlap have to taken into account. So detector pixels that are totally covered by the overlap are weight with "1" and if the overlap is between detector pixels the pixels are weighted. Do you have a copy of the original article from the De Man and Basu ? I have the opinion that it's not neccessary to project the detector pixel boundaries and voxel boundaries onto a common plane if we use a flat panel detector. Instead we could project the voxel boundaries onto the detector plane directly. Do you agree with that or did I miss something ? best regards, Robert Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr Von: "Simon Rit" An: "Robert Callie?" Cc: "rtk-users at public.kitware.com" Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: Hell RTK User, I think there is a mistake in the described approach. Point a) and f) meight be wrong. As far as I Understand, all Pixels that are covered by the projected voxel vertices are update with weight * voxel_value. Where weight is the overlaping area of the projected voxel vertices polygon on the detector plane and the underlying detector pixels. Any opinions before implementing it ? regards, Robert Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr Von: "Robert Callie?" An: rtk-users at public.kitware.com Betreff: [Rtk-users] distance driven projector, a simplified approach ? Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 15:45:23 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 21:45:23 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. Simon On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie? wrote: > Hello Simon, > > thank you for the articles. May I ask you what do you mean by > > ?voxel correction factor? in the code you provided in your article ? > > float f) // Voxel correction factor > > > > Thank you and best regards, > > Robert > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Mittwoch, 15. Juli 2015 14:22 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified > approach ? > > > > Sorry, this link indeed with the MapSeg function. And yes, I was projecting > it to the detector plane directly. > > Simon > > > > On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" > wrote: > > Hello Simon, > > thank you for your answer. I guess you linked the wrong article. But I know > what article you are talking about. > > It's the articel from 2009 with a piece of code (MapSeq). > > > >>> I don't have time to go into the details of what you have proposed but, >>> from a glance, the first step seems useless. > > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > > detector pixels that are totally covered by the overlap are weight with "1" > and if the overlap is between detector pixels > > the pixels are weighted. Do you have a copy of the original article from the > De Man and Basu ? > > > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > > Do you agree with that or did I miss something ? > > > > best regards, > > Robert > > > > Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr > Von: "Simon Rit" > An: "Robert Callie?" > Cc: "rtk-users at public.kitware.com" > Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? > > Hi, > > Indeed, I have published an article on this projector describing my > implementation, you could use it if you want, there's even a piece of code > in it although I'm pretty sure it's not the best implementation. This > implementation dealt with the case where the rotation axis is parallel to > the detector. As far as I can remember, the original article of De Man and > Basu is also quite clear. > > I don't have time to go into the details of what you have proposed but, from > a glance, the first step seems useless. > > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > > Simon > > > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: > > Hell RTK User, > > I think there is a mistake in the described approach. > > Point a) and f) meight be wrong. As far as I Understand, all Pixels > > that are covered by the projected voxel vertices are update > > with weight * voxel_value. Where weight is the overlaping area > > of the projected voxel vertices polygon on the detector plane and the > > underlying detector pixels. > > > > Any opinions before implementing it ? > > > > regards, > > Robert > > > > Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr > Von: "Robert Callie?" > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what they > called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can be > rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value to > back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From simon.rit at creatis.insa-lyon.fr Fri Jul 17 02:22:16 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 17 Jul 2015 08:22:16 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Please keep on using the mailing list, I don't see a good reason to keep this conversation private. I won't have time to go back into these details. From a quick look, I think this is correct although I would have simply said that D is the center of the detector pixel. Simon On Thu, Jul 16, 2015 at 10:24 PM, Robert Callie? wrote: > Hello, > Sorry that I have to ask again. But I want to clear this before I start. > I want to ask about the cosine weight DeMan mentioned in his article. > He wrote: > > " > (1) The intersection length of the line of interest with the image slab S, the latter being > defined as the slab parallel to the xz plane and containing voxel V. This intersection length > is given by t/(cos ? cos ? ), where t is the isotropic voxel size, and ? and ? are the in- and > out-of-plane angles of the line of interest with the y-axis. > " > > So what he actually does, is that he calculates the intersection length of the slab s (that contains the voxel) with > a ray going from xray source to the middle of two adjacent detector cell boundaries. Let's refare to Figure 5. > So the length to be considered is calculated as the intersection length of slab S with the ray going from > the source ( the black dot in figure 5) to the mid-point of D, that means the center of the two projected adjacent > detector pixel boundaries. > > > Sorry for asking again but I want it to make it clear to me. > > Best regards, > Robert > > > -----Urspr?ngliche Nachricht----- > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit > Gesendet: Mittwoch, 15. Juli 2015 21:45 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? > > "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" > So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. > Simon > > On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie wrote: >> Hello Simon, >> >> thank you for the articles. May I ask you what do you mean by >> >> voxel correction factor in the code you provided in your article ? >> >> float f) // Voxel correction factor >> >> >> >> Thank you and best regards, >> >> Robert >> >> >> >> Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von >> Simon Rit >> Gesendet: Mittwoch, 15. Juli 2015 14:22 >> An: Robert Callie >> Cc: rtk-users at public.kitware.com >> Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified >> approach ? >> >> >> >> Sorry, this link indeed with the MapSeg function. And yes, I was >> projecting it to the detector plane directly. >> >> Simon >> >> >> >> On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie " >> >> wrote: >> >> Hello Simon, >> >> thank you for your answer. I guess you linked the wrong article. But I >> know what article you are talking about. >> >> It's the articel from 2009 with a piece of code (MapSeq). >> >> >> >>>> I don't have time to go into the details of what you have proposed >>>> but, from a glance, the first step seems useless. >> >> You're right. It is that all pixels that are related to the overlap >> projected voxel overlap have to taken into account. So >> >> detector pixels that are totally covered by the overlap are weight with "1" >> and if the overlap is between detector pixels >> >> the pixels are weighted. Do you have a copy of the original article >> from the De Man and Basu ? >> >> >> >> I have the opinion that it's not neccessary to project the detector >> pixel boundaries and voxel boundaries onto a common plane >> >> if we use a flat panel detector. Instead we could project the voxel >> boundaries onto the detector plane directly. >> >> Do you agree with that or did I miss something ? >> >> >> >> best regards, >> >> Robert >> >> >> >> Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr >> Von: "Simon Rit" >> An: "Robert Callie " >> Cc: "rtk-users at public.kitware.com" >> Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hi, >> >> Indeed, I have published an article on this projector describing my >> implementation, you could use it if you want, there's even a piece of >> code in it although I'm pretty sure it's not the best implementation. >> This implementation dealt with the case where the rotation axis is >> parallel to the detector. As far as I can remember, the original >> article of De Man and Basu is also quite clear. >> >> I don't have time to go into the details of what you have proposed >> but, from a glance, the first step seems useless. >> >> Good luck in your implementation and don't hesitate to send it to us >> when you have a working RTK implementation, >> >> Simon >> >> >> >> On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie " >> >> wrote: >> >> Hell RTK User, >> >> I think there is a mistake in the described approach. >> >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> >> that are covered by the projected voxel vertices are update >> >> with weight * voxel_value. Where weight is the overlaping area >> >> of the projected voxel vertices polygon on the detector plane and the >> >> underlying detector pixels. >> >> >> >> Any opinions before implementing it ? >> >> >> >> regards, >> >> Robert >> >> >> >> Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr >> Von: "Robert Callie " >> An: rtk-users at public.kitware.com >> Betreff: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel >> boundaries onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel s contribution (weight) is the area of this >> overlapping. I read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is >> what they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone >> beam geometry. We can >> >> either rotate the detector and source around the object or the object >> can be rotated >> >> and the detector and source are fixed. I think Simon also wrote a >> paper about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source >> position, object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the corresponding >> detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a e). >> Value to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of >> voxel boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > From guangming.zang at kaust.edu.sa Sun Jul 26 18:30:42 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 01:30:42 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed Message-ID: Hi RTK community, i am using SART algorithm to reconstruct an object. But in this new RTK version, the time recording seems a little weird: the total time is 1219.12s , but adding the time cost in different stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward projection part. BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, both multi-threading i think. Can anyone tell me what's going on? Thanks Regards Guangming [image: ???? 1] *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 01:59:11 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 07:59:11 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Guangming, It's not surprising to me that the backprojection is faster than the forward projection, that's what I expect. If the total time is longer, that's probably that some individual steps are not included in the total time. Can you try to add reader->Update(); before the line itk::TimeProbe totalTimeProbe; in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? Simon On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > Hi RTK community, > i am using SART algorithm to reconstruct an object. > But in this new RTK version, the time recording seems a little weird: > the total time is 1219.12s , but adding the time cost in different stages > is not 1291.12 s. especially for "backprojection" part, only 16.6051s to > reconstruct a 128^3 volume ?? even shorter than forward projection part. > BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, > both multi-threading i think. > Can anyone tell me what's going on? > Thanks > Regards > Guangming > > [image: ???? 1] > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 27 04:41:58 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 11:41:58 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, Thanks for your reply. would you pls help and explain why backprojection is expected to take shorter time than forward projection?? because i was thinking if no caching step, the backprojection should take much longer time than sart algorithm. yes, i run rtksart for 2 times once.it took 12xxs, similar to the time consumed of 3 times's sart, which much slower than my own application. BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 shapp-logan projections(512*512 resolution each) rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 and i will try reader->Update() like what you said. Thanks Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 8:59 GMT+03:00 Simon Rit : > Hi Guangming, > It's not surprising to me that the backprojection is faster than the > forward projection, that's what I expect. If the total time is longer, > that's probably that some individual steps are not included in the total > time. Can you try to add > reader->Update(); > before the line > > itk::TimeProbe totalTimeProbe; > > in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? > > Simon > > > > On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi RTK community, >> i am using SART algorithm to reconstruct an object. >> But in this new RTK version, the time recording seems a little weird: >> the total time is 1219.12s , but adding the time cost in different >> stages is not 1291.12 s. especially for "backprojection" part, only >> 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward >> projection part. BTW, the -f and -b are Joseph and >> VoxelBasedBackProjection, respectively, both multi-threading i think. >> Can anyone tell me what's going on? >> Thanks >> Regards >> Guangming >> >> [image: ???? 1] >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 08:28:28 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 14:28:28 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: I can try. Forward and back projection have the same algorithmic complexity but voxel based backprojection benefits from several optimizations in terms of memory management and computations that makes it faster. The best is to look at the code for further details... although both have far from being optimal. And I did not get the sentence "the backprojection should take much longer time than sart algorithm." because SART contains a backprojection and other steps so SART is obviously longer than the bp alone. Your log is strange and I don't see what steps are not timed that would take most of the time. I did the same test on my computer and here is my result: OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha --dimension 512 OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.288571 s Multiplication by zero: 0.131672 s Forward projection: 34.3612 s Subtraction: 0.203409 s Multiplication by lambda: 0.146459 s Ray box intersection: 1.30755 s Division: 0.187294 s Multiplication by the gating weights: 0 s Displaced detector: 0.278408 s Back projection: 11.8456 s Volume update: 0 s It took... 53.2765 s Simon On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang wrote: > Hi Simon, > Thanks for your reply. > would you pls help and explain why backprojection is expected to take > shorter time than forward projection?? because i was thinking if no caching > step, the backprojection should take much longer time than sart algorithm. > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > consumed of 3 times's sart, which much slower than my own application. > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > shapp-logan projections(512*512 resolution each) > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > -64,-64,-64 -l 0.5 -n 3 --time 1 > > and i will try reader->Update() like what you said. > Thanks > Guangming > > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> Hi Guangming, >> It's not surprising to me that the backprojection is faster than the >> forward projection, that's what I expect. If the total time is longer, >> that's probably that some individual steps are not included in the total >> time. Can you try to add >> reader->Update(); >> before the line >> >> itk::TimeProbe totalTimeProbe; >> >> in rtksart.cxx? It may be that all the reading operations are done but not >> timed in the sart->Update(). Why they are so long, I don't know, is your D: >> drive a network drive? Do you observe the same behavior if you do rtksart 2 >> times in a row? >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> wrote: >>> >>> Hi RTK community, >>> i am using SART algorithm to reconstruct an object. >>> But in this new RTK version, the time recording seems a little weird: >>> the total time is 1219.12s , but adding the time cost in different >>> stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s >>> to reconstruct a 128^3 volume ?? even shorter than forward projection part. >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, >>> both multi-threading i think. >>> Can anyone tell me what's going on? >>> Thanks >>> Regards >>> Guangming >>> >>> >>> Guangming Zang (Alex) >>> King Abdullah University of Science and Technology(KAUST) >>> University of Chinese Academy of Sciences(UCAS) >>> >>> >>> >>> >>> ________________________________ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete this >>> message from your computer system. Any unauthorized use or distribution is >>> prohibited. Please consider the environment before printing this email. >> >> > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 08:50:48 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 15:50:48 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, sorry for the mistake, not"the backprojection should take much longer time than sart algorithm" , but "the backprojection should take much longer time than forward projection in sart algorithm". BTW, how many cores does your computer have?? Mine is 24 cores. is it can explain the reason why it takes much longer time on my computer than yours? Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 15:28 GMT+03:00 Simon Rit : > I can try. Forward and back projection have the same algorithmic > complexity but voxel based backprojection benefits from several > optimizations in terms of memory management and computations that > makes it faster. The best is to look at the code for further > details... although both have far from being optimal. And I did not > get the sentence "the backprojection should take much longer time than > sart algorithm." because SART contains a backprojection and other > steps so SART is obviously longer than the bp alone. > Your log is strange and I don't see what steps are not timed that > would take most of the time. I did the same test on my computer and > here is my result: > > OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > --dimension 512 > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.288571 s > Multiplication by zero: 0.131672 s > Forward projection: 34.3612 s > Subtraction: 0.203409 s > Multiplication by lambda: 0.146459 s > Ray box intersection: 1.30755 s > Division: 0.187294 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.278408 s > Back projection: 11.8456 s > Volume update: 0 s > It took... 53.2765 s > > Simon > > On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > wrote: > > Hi Simon, > > Thanks for your reply. > > would you pls help and explain why backprojection is expected to take > > shorter time than forward projection?? because i was thinking if no > caching > > step, the backprojection should take much longer time than sart > algorithm. > > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > > consumed of 3 times's sart, which much slower than my own application. > > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > > shapp-logan projections(512*512 resolution each) > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > > -64,-64,-64 -l 0.5 -n 3 --time 1 > > > > and i will try reader->Update() like what you said. > > Thanks > > Guangming > > > > > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> > >> Hi Guangming, > >> It's not surprising to me that the backprojection is faster than the > >> forward projection, that's what I expect. If the total time is longer, > >> that's probably that some individual steps are not included in the total > >> time. Can you try to add > >> reader->Update(); > >> before the line > >> > >> itk::TimeProbe totalTimeProbe; > >> > >> in rtksart.cxx? It may be that all the reading operations are done but > not > >> timed in the sart->Update(). Why they are so long, I don't know, is > your D: > >> drive a network drive? Do you observe the same behavior if you do > rtksart 2 > >> times in a row? > >> > >> Simon > >> > >> > >> > >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> wrote: > >>> > >>> Hi RTK community, > >>> i am using SART algorithm to reconstruct an object. > >>> But in this new RTK version, the time recording seems a little weird: > >>> the total time is 1219.12s , but adding the time cost in different > >>> stages is not 1291.12 s. especially for "backprojection" part, only > 16.6051s > >>> to reconstruct a 128^3 volume ?? even shorter than forward projection > part. > >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > respectively, > >>> both multi-threading i think. > >>> Can anyone tell me what's going on? > >>> Thanks > >>> Regards > >>> Guangming > >>> > >>> > >>> Guangming Zang (Alex) > >>> King Abdullah University of Science and Technology(KAUST) > >>> University of Chinese Academy of Sciences(UCAS) > >>> > >>> > >>> > >>> > >>> ________________________________ > >>> This message and its contents, including attachments are intended > solely > >>> for the original recipient. If you are not the intended recipient or > have > >>> received this message in error, please notify me immediately and > delete this > >>> message from your computer system. Any unauthorized use or > distribution is > >>> prohibited. Please consider the environment before printing this email. > >> > >> > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 09:02:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 15:02:03 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: No I expect forward projection to be longer than backprojection although with optimal implementations, it should take about the same time since they have the same complexity. I have 4 cores on my laptop. I don't see how it explains it, try to find out where does SART spend the time. Simon On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang wrote: > Hi Simon, > sorry for the mistake, not"the backprojection should take much longer time > than > sart algorithm" , but "the backprojection should take much longer time than > forward projection in sart algorithm". > > BTW, how many cores does your computer have?? Mine is 24 cores. > is it can explain the reason why it takes much longer time on my computer > than yours? > Regards > Guangming > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> I can try. Forward and back projection have the same algorithmic >> complexity but voxel based backprojection benefits from several >> optimizations in terms of memory management and computations that >> makes it faster. The best is to look at the code for further >> details... although both have far from being optimal. And I did not >> get the sentence "the backprojection should take much longer time than >> sart algorithm." because SART contains a backprojection and other >> steps so SART is obviously longer than the bp alone. >> Your log is strange and I don't see what steps are not timed that >> would take most of the time. I did the same test on my computer and >> here is my result: >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> --dimension 512 >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> 1 >> Recording elapsed time... >> SARTConeBeamReconstructionFilter timing: >> Extraction of projection sub-stacks: 0.288571 s >> Multiplication by zero: 0.131672 s >> Forward projection: 34.3612 s >> Subtraction: 0.203409 s >> Multiplication by lambda: 0.146459 s >> Ray box intersection: 1.30755 s >> Division: 0.187294 s >> Multiplication by the gating weights: 0 s >> Displaced detector: 0.278408 s >> Back projection: 11.8456 s >> Volume update: 0 s >> It took... 53.2765 s >> >> Simon >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> wrote: >> > Hi Simon, >> > Thanks for your reply. >> > would you pls help and explain why backprojection is expected to take >> > shorter time than forward projection?? because i was thinking if no >> > caching >> > step, the backprojection should take much longer time than sart >> > algorithm. >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time >> > consumed of 3 times's sart, which much slower than my own application. >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 >> > shapp-logan projections(512*512 resolution each) >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> > >> > and i will try reader->Update() like what you said. >> > Thanks >> > Guangming >> > >> > >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> >> >> Hi Guangming, >> >> It's not surprising to me that the backprojection is faster than the >> >> forward projection, that's what I expect. If the total time is longer, >> >> that's probably that some individual steps are not included in the >> >> total >> >> time. Can you try to add >> >> reader->Update(); >> >> before the line >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done but >> >> not >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> your D: >> >> drive a network drive? Do you observe the same behavior if you do >> >> rtksart 2 >> >> times in a row? >> >> >> >> Simon >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> wrote: >> >>> >> >>> Hi RTK community, >> >>> i am using SART algorithm to reconstruct an object. >> >>> But in this new RTK version, the time recording seems a little weird: >> >>> the total time is 1219.12s , but adding the time cost in different >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >>> 16.6051s >> >>> to reconstruct a 128^3 volume ?? even shorter than forward projection >> >>> part. >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >>> respectively, >> >>> both multi-threading i think. >> >>> Can anyone tell me what's going on? >> >>> Thanks >> >>> Regards >> >>> Guangming >> >>> >> >>> >> >>> Guangming Zang (Alex) >> >>> King Abdullah University of Science and Technology(KAUST) >> >>> University of Chinese Academy of Sciences(UCAS) >> >>> >> >>> >> >>> >> >>> >> >>> ________________________________ >> >>> This message and its contents, including attachments are intended >> >>> solely >> >>> for the original recipient. If you are not the intended recipient or >> >>> have >> >>> received this message in error, please notify me immediately and >> >>> delete this >> >>> message from your computer system. Any unauthorized use or >> >>> distribution is >> >>> prohibited. Please consider the environment before printing this >> >>> email. >> >> >> >> >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended solely >> > for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> > this >> > message from your computer system. Any unauthorized use or distribution >> > is >> > prohibited. Please consider the environment before printing this email. > > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 10:05:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:05:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, it cost 1200s for SART algorithm at first, and the command are: rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 in which, the projections data(360pro_SL_Vol128_512.mha) is not generated from rtkprojectshepploganphantom , but from my application. though it took long time, but i can got a nice result, And i just tried the command you used, i.e. generated the projections data by rtkprojectshepploganphantom : rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 --sid=500.0 rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 yes, it takes about 56s. but the reconstructed result is weird, the voxel values range from [-142186, 208146] and can not see anything when visualizing it. i believe you got the similar results, which maybe explain why it computes much faster. if i wanna use the projections generated by rtkprojectshepploganphantom , can you give me an example to get a nice results? Best regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 16:02 GMT+03:00 Simon Rit : > No I expect forward projection to be longer than backprojection > although with optimal implementations, it should take about the same > time since they have the same complexity. > I have 4 cores on my laptop. I don't see how it explains it, try to > find out where does SART spend the time. > Simon > > On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang > wrote: > > Hi Simon, > > sorry for the mistake, not"the backprojection should take much longer > time > > than > > sart algorithm" , but "the backprojection should take much longer time > than > > forward projection in sart algorithm". > > > > BTW, how many cores does your computer have?? Mine is 24 cores. > > is it can explain the reason why it takes much longer time on my computer > > than yours? > > Regards > > Guangming > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : > >> > >> I can try. Forward and back projection have the same algorithmic > >> complexity but voxel based backprojection benefits from several > >> optimizations in terms of memory management and computations that > >> makes it faster. The best is to look at the code for further > >> details... although both have far from being optimal. And I did not > >> get the sentence "the backprojection should take much longer time than > >> sart algorithm." because SART contains a backprojection and other > >> steps so SART is obviously longer than the bp alone. > >> Your log is strange and I don't see what steps are not timed that > >> would take most of the time. I did the same test on my computer and > >> here is my result: > >> > >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > >> --dimension 512 > >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > >> 1 > >> Recording elapsed time... > >> SARTConeBeamReconstructionFilter timing: > >> Extraction of projection sub-stacks: 0.288571 s > >> Multiplication by zero: 0.131672 s > >> Forward projection: 34.3612 s > >> Subtraction: 0.203409 s > >> Multiplication by lambda: 0.146459 s > >> Ray box intersection: 1.30755 s > >> Division: 0.187294 s > >> Multiplication by the gating weights: 0 s > >> Displaced detector: 0.278408 s > >> Back projection: 11.8456 s > >> Volume update: 0 s > >> It took... 53.2765 s > >> > >> Simon > >> > >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > >> wrote: > >> > Hi Simon, > >> > Thanks for your reply. > >> > would you pls help and explain why backprojection is expected to take > >> > shorter time than forward projection?? because i was thinking if no > >> > caching > >> > step, the backprojection should take much longer time than sart > >> > algorithm. > >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the > time > >> > consumed of 3 times's sart, which much slower than my own application. > >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > >> > shapp-logan projections(512*512 resolution each) > >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > >> > -64,-64,-64 -l 0.5 -n 3 --time 1 > >> > > >> > and i will try reader->Update() like what you said. > >> > Thanks > >> > Guangming > >> > > >> > > >> > > >> > Guangming Zang (Alex) > >> > King Abdullah University of Science and Technology(KAUST) > >> > University of Chinese Academy of Sciences(UCAS) > >> > > >> > > >> > > >> > > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> >> > >> >> Hi Guangming, > >> >> It's not surprising to me that the backprojection is faster than the > >> >> forward projection, that's what I expect. If the total time is > longer, > >> >> that's probably that some individual steps are not included in the > >> >> total > >> >> time. Can you try to add > >> >> reader->Update(); > >> >> before the line > >> >> > >> >> itk::TimeProbe totalTimeProbe; > >> >> > >> >> in rtksart.cxx? It may be that all the reading operations are done > but > >> >> not > >> >> timed in the sart->Update(). Why they are so long, I don't know, is > >> >> your D: > >> >> drive a network drive? Do you observe the same behavior if you do > >> >> rtksart 2 > >> >> times in a row? > >> >> > >> >> Simon > >> >> > >> >> > >> >> > >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> >> wrote: > >> >>> > >> >>> Hi RTK community, > >> >>> i am using SART algorithm to reconstruct an object. > >> >>> But in this new RTK version, the time recording seems a little > weird: > >> >>> the total time is 1219.12s , but adding the time cost in different > >> >>> stages is not 1291.12 s. especially for "backprojection" part, only > >> >>> 16.6051s > >> >>> to reconstruct a 128^3 volume ?? even shorter than forward > projection > >> >>> part. > >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > >> >>> respectively, > >> >>> both multi-threading i think. > >> >>> Can anyone tell me what's going on? > >> >>> Thanks > >> >>> Regards > >> >>> Guangming > >> >>> > >> >>> > >> >>> Guangming Zang (Alex) > >> >>> King Abdullah University of Science and Technology(KAUST) > >> >>> University of Chinese Academy of Sciences(UCAS) > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> ________________________________ > >> >>> This message and its contents, including attachments are intended > >> >>> solely > >> >>> for the original recipient. If you are not the intended recipient or > >> >>> have > >> >>> received this message in error, please notify me immediately and > >> >>> delete this > >> >>> message from your computer system. Any unauthorized use or > >> >>> distribution is > >> >>> prohibited. Please consider the environment before printing this > >> >>> email. > >> >> > >> >> > >> > > >> > > >> > ________________________________ > >> > This message and its contents, including attachments are intended > solely > >> > for > >> > the original recipient. If you are not the intended recipient or have > >> > received this message in error, please notify me immediately and > delete > >> > this > >> > message from your computer system. Any unauthorized use or > distribution > >> > is > >> > prohibited. Please consider the environment before printing this > email. > > > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 10:12:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:12:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: BTW, the projections are 512*512, and the pixel spacing is 0.5 Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:05 GMT+03:00 Guangming Zang : > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 10:20:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 16:20:12 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Obviously I hadn't looked at the result and/or checked the command line options, sorry. This is an example from the same simulated dataset that gives me a good results: OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.567773 s Multiplication by zero: 0.303715 s Forward projection: 142.305 s Subtraction: 0.445842 s Multiplication by lambda: 0.2663 s Ray box intersection: 5.40366 s Division: 0.535618 s Multiplication by the gating weights: 0 s Displaced detector: 0.415431 s Back projection: 21.3689 s Volume update: 0 s It took... 177.059 s but this doesn't change the content of my previous message. What takes time is probably in your own software, be sure that you update SART inputs before timing it. Simon On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang wrote: > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 11:12:16 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 18:12:16 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Thanks Simon, now it work fine when using projections generated by RTK itself (command rtkprojectshepploganphantom ). for 1 iteration of SART to reconstruct 128^3 size volume, it took only 19s, which gives nice results as well. Thanks again. Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:20 GMT+03:00 Simon Rit : > Obviously I hadn't looked at the result and/or checked the command line > options, sorry. This is an example from the same simulated dataset that > gives me a good results: > > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f > Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n > 3 --time 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.567773 s > Multiplication by zero: 0.303715 s > Forward projection: 142.305 s > Subtraction: 0.445842 s > Multiplication by lambda: 0.2663 s > Ray box intersection: 5.40366 s > Division: 0.535618 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.415431 s > Back projection: 21.3689 s > Volume update: 0 s > It took... 177.059 s > > but this doesn't change the content of my previous message. What takes > time is probably in your own software, be sure that you update SART inputs > before timing it. > Simon > > On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon, >> it cost 1200s for SART algorithm at first, and the command are: >> rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd= >> 725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" >> >> rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 >> >> in which, the projections data(360pro_SL_Vol128_512.mha) is not >> generated from rtkprojectshepploganphantom , but from my application. >> though it took long time, but i can got a nice result, >> >> >> And i just tried the command you used, i.e. generated the projections >> data by rtkprojectshepploganphantom : >> >> rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 >> --sid=500.0 >> rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 >> rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b >> VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 >> --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 >> yes, it takes about 56s. >> but the reconstructed result is weird, the voxel values range from >> [-142186, 208146] and can not see anything when visualizing it. >> i believe you got the similar results, which maybe explain why it >> computes much faster. >> >> if i wanna use the projections generated by rtkprojectshepploganphantom >> , can you give me an example to get a nice results? >> >> Best regards >> Guangming >> >> >> >> >> >> >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> 2015-07-27 16:02 GMT+03:00 Simon Rit : >> >>> No I expect forward projection to be longer than backprojection >>> although with optimal implementations, it should take about the same >>> time since they have the same complexity. >>> I have 4 cores on my laptop. I don't see how it explains it, try to >>> find out where does SART spend the time. >>> Simon >>> >>> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >>> wrote: >>> > Hi Simon, >>> > sorry for the mistake, not"the backprojection should take much longer >>> time >>> > than >>> > sart algorithm" , but "the backprojection should take much longer time >>> than >>> > forward projection in sart algorithm". >>> > >>> > BTW, how many cores does your computer have?? Mine is 24 cores. >>> > is it can explain the reason why it takes much longer time on my >>> computer >>> > than yours? >>> > Regards >>> > Guangming >>> > >>> > Guangming Zang (Alex) >>> > King Abdullah University of Science and Technology(KAUST) >>> > University of Chinese Academy of Sciences(UCAS) >>> > >>> > >>> > >>> > >>> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >>> >> >>> >> I can try. Forward and back projection have the same algorithmic >>> >> complexity but voxel based backprojection benefits from several >>> >> optimizations in terms of memory management and computations that >>> >> makes it faster. The best is to look at the code for further >>> >> details... although both have far from being optimal. And I did not >>> >> get the sentence "the backprojection should take much longer time than >>> >> sart algorithm." because SART contains a backprojection and other >>> >> steps so SART is obviously longer than the bp alone. >>> >> Your log is strange and I don't see what steps are not timed that >>> >> would take most of the time. I did the same test on my computer and >>> >> here is my result: >>> >> >>> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >>> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >>> >> --dimension 512 >>> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >>> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >>> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >>> >> 1 >>> >> Recording elapsed time... >>> >> SARTConeBeamReconstructionFilter timing: >>> >> Extraction of projection sub-stacks: 0.288571 s >>> >> Multiplication by zero: 0.131672 s >>> >> Forward projection: 34.3612 s >>> >> Subtraction: 0.203409 s >>> >> Multiplication by lambda: 0.146459 s >>> >> Ray box intersection: 1.30755 s >>> >> Division: 0.187294 s >>> >> Multiplication by the gating weights: 0 s >>> >> Displaced detector: 0.278408 s >>> >> Back projection: 11.8456 s >>> >> Volume update: 0 s >>> >> It took... 53.2765 s >>> >> >>> >> Simon >>> >> >>> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >>> >> wrote: >>> >> > Hi Simon, >>> >> > Thanks for your reply. >>> >> > would you pls help and explain why backprojection is expected to >>> take >>> >> > shorter time than forward projection?? because i was thinking if no >>> >> > caching >>> >> > step, the backprojection should take much longer time than sart >>> >> > algorithm. >>> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >>> time >>> >> > consumed of 3 times's sart, which much slower than my own >>> application. >>> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >>> 360 >>> >> > shapp-logan projections(512*512 resolution each) >>> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >>> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >>> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >>> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >>> >> > >>> >> > and i will try reader->Update() like what you said. >>> >> > Thanks >>> >> > Guangming >>> >> > >>> >> > >>> >> > >>> >> > Guangming Zang (Alex) >>> >> > King Abdullah University of Science and Technology(KAUST) >>> >> > University of Chinese Academy of Sciences(UCAS) >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit >> >: >>> >> >> >>> >> >> Hi Guangming, >>> >> >> It's not surprising to me that the backprojection is faster than >>> the >>> >> >> forward projection, that's what I expect. If the total time is >>> longer, >>> >> >> that's probably that some individual steps are not included in the >>> >> >> total >>> >> >> time. Can you try to add >>> >> >> reader->Update(); >>> >> >> before the line >>> >> >> >>> >> >> itk::TimeProbe totalTimeProbe; >>> >> >> >>> >> >> in rtksart.cxx? It may be that all the reading operations are done >>> but >>> >> >> not >>> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >>> >> >> your D: >>> >> >> drive a network drive? Do you observe the same behavior if you do >>> >> >> rtksart 2 >>> >> >> times in a row? >>> >> >> >>> >> >> Simon >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >>> >> >> wrote: >>> >> >>> >>> >> >>> Hi RTK community, >>> >> >>> i am using SART algorithm to reconstruct an object. >>> >> >>> But in this new RTK version, the time recording seems a little >>> weird: >>> >> >>> the total time is 1219.12s , but adding the time cost in >>> different >>> >> >>> stages is not 1291.12 s. especially for "backprojection" part, >>> only >>> >> >>> 16.6051s >>> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >>> projection >>> >> >>> part. >>> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >>> >> >>> respectively, >>> >> >>> both multi-threading i think. >>> >> >>> Can anyone tell me what's going on? >>> >> >>> Thanks >>> >> >>> Regards >>> >> >>> Guangming >>> >> >>> >>> >> >>> >>> >> >>> Guangming Zang (Alex) >>> >> >>> King Abdullah University of Science and Technology(KAUST) >>> >> >>> University of Chinese Academy of Sciences(UCAS) >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> ________________________________ >>> >> >>> This message and its contents, including attachments are intended >>> >> >>> solely >>> >> >>> for the original recipient. If you are not the intended recipient >>> or >>> >> >>> have >>> >> >>> received this message in error, please notify me immediately and >>> >> >>> delete this >>> >> >>> message from your computer system. Any unauthorized use or >>> >> >>> distribution is >>> >> >>> prohibited. Please consider the environment before printing this >>> >> >>> email. >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > ________________________________ >>> >> > This message and its contents, including attachments are intended >>> solely >>> >> > for >>> >> > the original recipient. If you are not the intended recipient or >>> have >>> >> > received this message in error, please notify me immediately and >>> delete >>> >> > this >>> >> > message from your computer system. Any unauthorized use or >>> distribution >>> >> > is >>> >> > prohibited. Please consider the environment before printing this >>> email. >>> > >>> > >>> > >>> > ________________________________ >>> > This message and its contents, including attachments are intended >>> solely for >>> > the original recipient. If you are not the intended recipient or have >>> > received this message in error, please notify me immediately and >>> delete this >>> > message from your computer system. Any unauthorized use or >>> distribution is >>> > prohibited. Please consider the environment before printing this email. >>> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From infrombox at yandex.ru Tue Jul 28 04:30:22 2015 From: infrombox at yandex.ru (1 1) Date: Tue, 28 Jul 2015 15:30:22 +0700 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: <2213081438072222@web8j.yandex.ru> Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. But program which i use reads meta images with MET_SHORT pixel type only. Is there easy way to setting it and get volume with different from MET_FLOAT pixel type ? If not, could you advice me, what the filter i should to do, for example as post process after reconstruction ala MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward operation of LUTbasedVariableI0RawToAttenuationImageFilter ? Thanks. From simon.rit at creatis.insa-lyon.fr Tue Jul 28 04:56:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 10:56:54 +0200 Subject: [Rtk-users] volume with diffieret pixel type In-Reply-To: <2213081438072222@web8j.yandex.ru> References: <2213081438072222@web8j.yandex.ru> Message-ID: Hi, This is more an ITK question than a RTK question. Yes, we use float by default in our applications. You can cast the image to any type before writing using itk::CastImageFilter but you'll have to modify the applications and, of course, there is a loss of information. If you don't want to program it, you can use any other software, e.g. in vv right clik on your image after opening and use the convert to option. Simon On Tue, Jul 28, 2015 at 10:30 AM, 1 1 wrote: > Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. > But program which i use reads meta images with MET_SHORT pixel type only. > Is there easy way to setting it and get volume with different from > MET_FLOAT pixel type ? If not, could you advice me, what the filter i > should to do, for example as post process after reconstruction ala > MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward > operation of LUTbasedVariableI0RawToAttenuationImageFilter image, float image> ? > Thanks. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pconneely020186 at gmail.com Tue Jul 28 12:05:29 2015 From: pconneely020186 at gmail.com (peter conneely) Date: Tue, 28 Jul 2015 17:05:29 +0100 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: "peter conneely" Date: 24 Jul 2015 11:07 Subject: Issue running FDK reconstruction algorithm To: Cc: Hi, I'm having trouble running the FDK reconstruction alogrithm on Elekta and Varian data sets. The algorithm does work when I try the shepp-logan example. When I initially ran the application I included the (') around .*.his. and got the following lines. [image: Inline image 1] when I try to run with the (') removed it finds the 669 files but then the application stops working. I have tried adding registry edits to run exe and have tried switching of dep. Neither of these work I am not sure what is going wrong and how to fix it. My system properties are as follows. Processor: Intel Pentium CPU P6100 @ 2.00 Ghz RAM: 3.00 GB GPU: Intel HD Graphics Systems type 64 Bit. Thanks and Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Tue Jul 28 12:46:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 18:46:17 +0200 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: Hi, I guess the quotes are OS depedent, maybe you need double quotes on Windows. It's strange that you don't get an error message. Are you sure it crashed? If yes, have you checked the elektaGeometry file? Does it have 669 projection sections as expected? Or maybe it's a memory issue, try the --lowmem option. Simon On Tue, Jul 28, 2015 at 6:05 PM, peter conneely wrote: > ---------- Forwarded message ---------- > From: "peter conneely" > Date: 24 Jul 2015 11:07 > Subject: Issue running FDK reconstruction algorithm > To: > Cc: > > Hi, > > I'm having trouble running the FDK reconstruction alogrithm on Elekta and > Varian data sets. The algorithm does work when I try the shepp-logan > example. > > When I initially ran the application I included the (') around .*.his. and > got the following lines. > [image: Inline image 1] > when I try to run with the (') removed it finds the 669 files but then the > application stops working. I have tried adding registry edits to run exe > and have tried switching of dep. Neither of these work I am not sure what > is going wrong and how to fix it. > > My system properties are as follows. > Processor: Intel Pentium CPU P6100 @ 2.00 Ghz > RAM: 3.00 GB > GPU: Intel HD Graphics > Systems type 64 Bit. > > Thanks and Regards, > Peter > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Tue Jul 28 13:38:45 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Tue, 28 Jul 2015 20:38:45 +0300 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: Hi, in ITK, the default type are described in *Utilities\MetaIO\metaTypes.h* MET_CHAR, MET_UCHAR ?,? ?? MET_SHORT, MET_USHORT, MET_INT,=20 MET_UINT,=20 MET_FLOAT,=20 MET_DOUBLE, ?and for .mha file, the header file includes information like: ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = 0 0 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 1 1 1 DimSize = 128 128 128 ElementType = MET_FLOAT ElementDataFile = LOCAL? ?And recently i just programmed to read and write .mha files. below is the code. u can just replace ElementType from ? MET_FLOAT ? to ? ? MET_SHORT ? in your application. hope this helps: #include "stdafx.h" #include #include #include #include #include #include using namespace std; int _tmain(int argc, _TCHAR* argv[]) { int m_Dims[3]; float spacing[3]; m_Dims[0]=128; m_Dims[1]=128; m_Dims[2]=128; spacing[0]=spacing[1]=spacing[2]=1.0f; ostringstream buffer, buffer1, buffer2, buf3; buffer << spacing[0]; string sp= buffer.str(); buffer1 << spacing[1]; string sp1 = buffer1.str(); buffer2 << spacing[2]; string sp2 = buffer2.str(); string ElementSpacing ="ElementSpacing= "+sp+" "+sp1+" "+sp2+"\n"; // int ss=1000; char temp[64], temp1[64],temp2[64]; string str; sprintf(temp, "%d", m_Dims[0]); sprintf(temp1, "%d", m_Dims[1]); sprintf(temp2, "%d", m_Dims[2]); string s(temp),s1(temp1),s2(temp2); string DimSize="DimSize= "+s+" "+s1+" "+s2+"\n"; string Mywritefile="ObjectType = Image\nNDims = 3\nBinaryData = True\nBinaryDataByteOrderMSB = False \nCompressedData = False \nTransformMatrix = 1 0 0 0 1 0 0 0 1 \n" ; Mywritefile+="Offset = 0 0 0 \nCenterOfRotation = 0 0 0 \nAnatomicalOrientation = RAI \n"; Mywritefile+=ElementSpacing+DimSize+"ElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; // ElementSpacing = 1 1 1 \nDimSize = 128 128 128 \nElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; int leng=Mywritefile.length(); cout< From simon.rit at creatis.insa-lyon.fr Wed Jul 29 08:53:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 29 Jul 2015 14:53:34 +0200 Subject: [Rtk-users] RTK images make the cover of Medical Physics Message-ID: See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Wed Jul 29 09:07:01 2015 From: theday79 at gmail.com (Yang K Park) Date: Wed, 29 Jul 2015 09:07:01 -0400 Subject: [Rtk-users] RTK images make the cover of Medical Physics In-Reply-To: References: Message-ID: <001801d0c9ff$76797860$636c6920$@gmail.com> Hi Simon, Thank you so much for the congrats! This is my great honor and I?d like to thank all the RTK developers and community members for their helps on this achievement! Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: Wednesday, July 29, 2015 8:54 AM To: rtk-users at public.kitware.com Subject: [Rtk-users] RTK images make the cover of Medical Physics See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Thu Jul 30 08:16:38 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Thu, 30 Jul 2015 15:16:38 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK Message-ID: Hi Simon and Chao, i am currently do some comparisons between different reconstruction methods for Shapp-Logan dataset. the commands are: rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=955.4050067 --sid=500.0 rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha --dimension 512,512 when using FDK or SART algorithm from RTK, I can got pretty good results indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 and levels as 1.04 for all results got). When running ADMMTV command below, though the geometry is as same as SART and FDK, the result got from ADMM looks weird.(pls see attached central slice of ground truth and ADMM, same contrast with other algorithm) rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 [image: ???? 1][image: ???? 2] Is it because the CG algorithm used by ADMM, or parameters setting issues here?? if it is parameters setting problem , would you help me and give a nice values for alpha and bate used here? BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already (including default value) Thanks and regards Guangming ?? *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ? -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 31 01:55:32 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 31 Jul 2015 07:55:32 +0200 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi, It looks to me that you haven't converged. I'm not the specialist of this algorithm and the specialist won't be near a computer in the coming weeks but when I try with more iterations in the data attachment term: rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 it's more satisfactory. There are rings at the top and the bottom of the cone-beam which should be reduced with more TV (greater alpha, see doc here ) or with a finer spacing (see this publication ). Simon On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang wrote: > Hi Simon and Chao, > > i am currently do some comparisons between different reconstruction > methods for Shapp-Logan dataset. > > the commands are: > > rtksimulatedgeometry -n 360 --arc -360 -o > geo.xml --sdd=955.4050067 --sid=500.0 > > rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha > --dimension 512,512 > > > > when using FDK or SART algorithm from RTK, I can got pretty good results > indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 > and levels as 1.04 for all results got). When running ADMMTV command below, > though the geometry is as same as SART and FDK, the result got from ADMM > looks weird.(pls see attached central slice of ground truth and ADMM, same > contrast with other algorithm) > > rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o > SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 > --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 > > [image: ???? 1][image: ???? 2] > > Is it because the CG algorithm used by ADMM, or parameters setting issues > here?? if it is parameters setting problem , would you help me and give a > nice values for alpha and bate used here? > > BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already > (including default value) > > Thanks and regards > > Guangming > > > ?? > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > ? > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Fri Jul 31 09:46:41 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 31 Jul 2015 16:46:41 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi simon, i see, thanks for the help and explanation. after following your advice, it works fine now. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-31 8:55 GMT+03:00 Simon Rit : > Hi, > It looks to me that you haven't converged. I'm not the specialist of this > algorithm and the specialist won't be near a computer in the coming weeks > but when I try with more iterations in the data attachment term: > rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml > --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 > it's more satisfactory. There are rings at the top and the bottom of the > cone-beam which should be reduced with more TV (greater alpha, see doc > here > ) > or with a finer spacing (see this publication > ). > Simon > > On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon and Chao, >> >> i am currently do some comparisons between different reconstruction >> methods for Shapp-Logan dataset. >> >> the commands are: >> >> rtksimulatedgeometry -n 360 --arc -360 -o >> geo.xml --sdd=955.4050067 --sid=500.0 >> >> rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha >> --dimension 512,512 >> >> >> >> when using FDK or SART algorithm from RTK, I can got pretty good results >> indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 >> and levels as 1.04 for all results got). When running ADMMTV command below, >> though the geometry is as same as SART and FDK, the result got from ADMM >> looks weird.(pls see attached central slice of ground truth and ADMM, same >> contrast with other algorithm) >> >> rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o >> SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 >> --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 >> >> [image: ???? 1][image: ???? 2] >> >> Is it because the CG algorithm used by ADMM, or parameters setting issues >> here?? if it is parameters setting problem , would you help me and give a >> nice values for alpha and bate used here? >> >> BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already >> (including default value) >> >> Thanks and regards >> >> Guangming >> >> >> ?? >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> ? >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 1 08:45:35 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 1 Jul 2015 14:45:35 +0200 Subject: [Rtk-users] Release of RTK v1.1.0 Message-ID: Dear RTK users, RTK v1.1.0 has been released today, about 14 months after RTK v1.0.0. The main features that have been developed since the previous release are: - SimpleRTK to run RTK filters (even the CUDA ones) from python scripts, C# code, and more - new projection pre-processing options (i0 calculation, scatter correction, water pre-correction) - extraction of the respiratory phase from cone-beam projections - linear programming for field-of-view computation based on a third party software, lp solve 5.5 - management of off-center detector in iterative methods - new iterative 3D and 4D reconstruction methods with Daubechies wavelets regularization - new iterative 4D reconstruction method with motion-aware regularization - reduction of memory footprint, especially GPU memory - many new CUDA filters - more robust (many bugs and memory leaks fixed) - use of MathJax to display formulas in the documentation, e.g., here . Many thanks to the increasing number of contributors, in alphabetical order: Ben Champion, Chao Wu, Cyril Mory, I Putu Susila, Julien Jomier, Marc Vila, Mathieu Dupont, Matt Clarkson, Peter Keuschnigg, S?bastien Brousmiche, Simon Rit, Tristan Coulange, Yang K Park. We don't focus on releases since we have a public github repository that we try to keep stable, I still recommend the use of the master HEAD over releases to enjoy the new RTK developments before their release. We still have a few on-going projects for which we will use and enhance RTK. Simon (for the RTK consortium) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 1 15:39:14 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 1 Jul 2015 21:39:14 +0200 Subject: [Rtk-users] loading projection images for sart Message-ID: Hello, I got compiled the ITK and RTK with help of cmake. I also had a look at the examples coming with RTK. I want to run a simple SART and got projection images in the format PNG and BMP. So I create an instance of the ThreeDcircularProjectionGeometry, SARTConeBeamReconstructionFilter and add the geometric projection data. rtk::ThreeDCircularProjectionGeometry::Pointer geometry; geometry = rtk::ThreeDCircularProjectionGeometry::New(); geometry->AddProjection(??) rtk::SARTConeBeamReconstructionFilter::Pointer sart = rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); How to add a stack of images to the SART reconstruction, i.e. std::vector images ? I got xray projections in png format. There is a method in the SART class called SetInput. But according tot he examples it is used to set a volume. Does anybody alread wrote a small piece of code that loads some images from the disk and put them into the SART reconstruction ? Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 2 12:19:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 2 Jul 2015 18:19:36 +0200 Subject: [Rtk-users] loading projection images for sart In-Reply-To: References: Message-ID: Hi, The stack of 2D images is passed via a 3D image. Look at the rtksart application for example. A way to read this from a set of file names is to use itk::ImageSeriesReader as done in rtk::ProjectionsReader. You should be able to understand how it works by looking at the existing RTK applications in the applications subfolders. Simon On Wed, Jul 1, 2015 at 9:39 PM, Robert Callie? wrote: > Hello, > > I got compiled the ITK and RTK with help of cmake. I also had a look > > at the examples coming with RTK. I want to run a simple SART and > > got projection images in the format PNG and BMP. > > > > So I create an instance of the ThreeDcircularProjectionGeometry, > SARTConeBeamReconstructionFilter > > and add the geometric projection data. > > > > rtk::ThreeDCircularProjectionGeometry::Pointer geometry; > > geometry = rtk::ThreeDCircularProjectionGeometry::New(); > > geometry->AddProjection(??) > > > > rtk::SARTConeBeamReconstructionFilter::Pointer sart = > rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); > > > > How to add a stack of images to the SART reconstruction, i.e. > std::vector images ? > > I got xray projections in png format. > > > > There is a method in the SART class called SetInput. But according tot he > examples it is used to set a volume. > > > > Does anybody alread wrote a small piece of code that loads some images > from the disk and put them into the SART reconstruction ? > > > > Regards, > > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Fri Jul 3 16:28:11 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 3 Jul 2015 23:28:11 +0300 Subject: [Rtk-users] Remote Control Issue in new RTK version Message-ID: Dear RTK community, There is some bug in RTK 1.1 version. That?s : When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 but i did not use Cuda at all.. What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. So i think it is some problem caused by itk ?? can we fix this issue?? Thanks for help in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Sat Jul 4 10:12:03 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Sat, 4 Jul 2015 17:12:03 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. Thanks for the help, Chao. *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ---------- Forwarded message ---------- From: Chao Wu Date: 2015-07-04 0:04 GMT+03:00 Subject: Re: Remote Control Issue To: Guangming Zang Cc: rtk-users-request at public.kitware.com, Simon Rit < simon.rit at creatis.insa-lyon.fr> Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. Regards, Chao Sent from Samsung Galaxy Note 3 2015?7?3? 10:26 PM? "Guangming Zang" ??? > Dear RTK community, > > There is some bug in RTK 1.1 version. That?s : > > When i run commands In 1.1 version with my computer in the lab, RTK works > fine, but when i use my laptop at home to remote control the computer in > the lab, it does not work. i.e., no matter the command are (rtkfdk, > ADMM,SART ?), an error is always shown: > > ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 > @ unknown : Cuda Error #3 > > but i did not use Cuda at all.. > > What?s more, when i run the 1.0 version RTK , it works well and no bug in > remoter control mode. > > So i think it is some problem caused by itk ?? can we fix this issue?? > > Thanks for help in advance > > > Regards > > Guangming > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Sat Jul 4 10:19:32 2015 From: ghostcz at hotmail.com (louie L) Date: Sat, 4 Jul 2015 16:19:32 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: I think because in most cases people use their graphics in TCC mode for scientific computations or don't use gpu at all where the rtk_use_cuda is false. Cheers, Louie Sent from my iOS > On 04 Jul 2015, at 16:12, Guangming Zang wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > > 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> Dear RTK community, >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> >> Regards >> >> Guangming >> >> Guangming Zang (Alex) >> King Abdullah University of Science and Technology(KAUST) >> University of Chinese Academy of Sciences(UCAS) >> >> >> >> >> This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > > > This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Mon Jul 6 05:32:18 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 6 Jul 2015 11:32:18 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Hi Guangming and all, Thanks for reporting this change of behavior. My first answer is that what you find simple is not so simple... but you're right, v1.0.0 allowed to compile RTK with CUDA and to run it without a CUDA device. After a bit of trakcing, I found that the change of behavior has been introduced with this patch so you can blame me. It has now fixed this issue with this patch , which seems to work on my laptop, I hope it does on your computer as well. I can't help you with the fact that you can't run CUDA software with remote control. Simon On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > I think because in most cases people use their graphics in TCC mode for > scientific computations or don't use gpu at all where the rtk_use_cuda is > false. > Cheers, > > Louie > > Sent from my iOS > > On 04 Jul 2015, at 16:12, Guangming Zang > wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes > to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is > defined, then if CUDA device is not available this error will occur. When > using MS remote desktop, graphical card and driver are bypassed unless it > is Tesla cards working in TCC mode. You can either compile exes without > CUDA for remote desktop, or try other graphic-based remote desktop software > like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > 2015?7?3? 10:26 PM? "Guangming Zang" ??? > >> Dear RTK community, >> >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works >> fine, but when i use my laptop at home to remote control the computer in >> the lab, it does not work. i.e., no matter the command are (rtkfdk, >> ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >> @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in >> remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> Regards >> >> Guangming >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 6 06:19:10 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 6 Jul 2015 13:19:10 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Thanks all for your help,Simon. I will try it again when i am at home :) As for using Cuda in remote control, i can handle it:just like what Chao said, change lab computer to TCC. What confused me at the beginning is that a cuda error shown while i did not call cuda at all, and thanks for fixing it. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-06 12:32 GMT+03:00 Simon Rit : > Hi Guangming and all, > Thanks for reporting this change of behavior. My first answer is that what > you find simple is not so simple... but you're right, v1.0.0 allowed to > compile RTK with CUDA and to run it without a CUDA device. After a bit of > trakcing, I found that the change of behavior has been introduced with this > patch > > so you can blame me. It has now fixed this issue with this patch > , > which seems to work on my laptop, I hope it does on your computer as well. > I can't help you with the fact that you can't run CUDA software with > remote control. > Simon > > On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > >> I think because in most cases people use their graphics in TCC mode for >> scientific computations or don't use gpu at all where the rtk_use_cuda is >> false. >> Cheers, >> >> Louie >> >> Sent from my iOS >> >> On 04 Jul 2015, at 16:12, Guangming Zang >> wrote: >> >> Ok, i see. Though i still do not understand why in new version rtk >> changes to call cudaimages, not keeping it simple like before. >> Thanks for the help, Chao. >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ---------- Forwarded message ---------- >> From: Chao Wu >> Date: 2015-07-04 0:04 GMT+03:00 >> Subject: Re: Remote Control Issue >> To: Guangming Zang >> Cc: rtk-users-request at public.kitware.com, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> >> >> Now in many exes cudaimage is the default image type if rtk_use_cuda is >> defined, then if CUDA device is not available this error will occur. When >> using MS remote desktop, graphical card and driver are bypassed unless it >> is Tesla cards working in TCC mode. You can either compile exes without >> CUDA for remote desktop, or try other graphic-based remote desktop software >> like vnc or teamviewer. >> >> Regards, Chao >> Sent from Samsung Galaxy Note 3 >> 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> >>> Dear RTK community, >>> >>> There is some bug in RTK 1.1 version. That?s : >>> >>> When i run commands In 1.1 version with my computer in the lab, RTK >>> works fine, but when i use my laptop at home to remote control the >>> computer in the lab, it does not work. i.e., no matter the command are >>> (rtkfdk, ADMM,SART ?), an error is always shown: >>> >>> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >>> @ unknown : Cuda Error #3 >>> >>> but i did not use Cuda at all.. >>> >>> What?s more, when i run the 1.0 version RTK , it works well and no bug >>> in remoter control mode. >>> >>> So i think it is some problem caused by itk ?? can we fix this issue?? >>> >>> Thanks for help in advance >>> >>> >>> Regards >>> >>> Guangming >>> *Guangming Zang (Alex)* >>> *King Abdullah University of Science and Technology(KAUST)* >>> *University of Chinese Academy of Sciences(UCAS)* >>> >>> >>> >>> >>> ------------------------------ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete >>> this message from your computer system. Any unauthorized use or >>> distribution is prohibited. Please consider the environment before printing >>> this email. >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Wed Jul 8 22:26:29 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Wed, 8 Jul 2015 19:26:29 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question Message-ID: Hi, I have a question from you about the CT reconstruction, I would really appreciate if you can help me with this. I have the geometry as described in following and I am trying to run the rtkfdk code from RTK. % parameters % % % % % % % param.nx = 500; % number of voxels param.ny = 500; param.nz = 500; param.sx = 5000; % mm (real size) param.sy = 5000; % mm param.sz = 5000; % mm %The real detector panel pixel density (number of pixels) param.nu = 36; % number of pixels param.nv = 100; % Detector setting (real size) param.su = 7200; % mm (real size) param.sv = 9200; % mm % X-ray source and detector setting param.DSD = 32900; % Distance source to detector param.DSO = 27400; % X-ray source to object axis distance % angle setting param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) param.dang = 5; % angular step size (deg) param.deg = 0:param.dang:360-1; % you can change param.deg = param.deg*param.dir; param.nProj = length(param.deg); param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than 360 deg -> param.parker=1 param.filter='ram-lak'; % high pass filter param.dx = param.sx/param.nx; % single voxel size param.dy = param.sy/param.ny; param.dz = param.sz/param.nz; param.du = param.su/param.nu; param.dv = param.sv/param.nv; param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) % Geometry calculation % % % param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : 360). But I got confused how to set the geometry parameters in RTK I followed the rtkfdk tutorial but I can?t get any result using this method I did the following: 1- Create geometry.xml using these parameters: nproj = 72 ; first_angle = 0 ; arc = 360 ; sid = 27400 ; sdd = 32900 ; proj_iso_x = 0; proj_iso_y = 0; out_angle = 0 ; in_angle = 0 ; source_x = 0; source_y = 0 ; 2- Create my own mha file (WriteMhaFile.m) from my projection array (36*100*72) using a matlab code with following properties: Voxel size = [0.1 0.1 0.1] Offset = [1 1 1] 3- Then run the: rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 --dimension 500 Could you please tell me if I am setting the geometry correctly? Also, is there any other way to create my own mha file? Thank you in advance and looking forward to hear back from you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 02:23:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 08:23:36 +0200 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Hi, We can try to help but we need to understand your geometry... Where does it come from by the way? If I understand your geometry correctly, I would say : - sid, sdd, nproj, arc are correct, - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 and you have 36x100 pixels, then the pixel size is [200,92,1] (last dimension is not used so anything). For the volume, if your volume is 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and not 0.1. - offset of projections is probably wrong. If you want to have a centered projections, you'll need something like (-3500, -554, 0). You can set is to 0 and put those values in proj_iso_x and proj_iso_y. Regarding mha file, you can write mha files in many ways, using SimpleRTK, matlab or writing an ITK code. Good luck! Simon On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah wrote: > Hi, > > I have a question from you about the CT reconstruction, I would really > appreciate if you can help me with this. > > I have the geometry as described in following and I am trying to run the > rtkfdk code from RTK. > > > % parameters % % % % % % % > > param.nx = 500; % number of voxels > param.ny = 500; > param.nz = 500; > > > param.sx = 5000; % mm (real size) > param.sy = 5000; % mm > param.sz = 5000; % mm > > > %The real detector panel pixel density (number of pixels) > param.nu = 36; % number of pixels > param.nv = 100; > > % Detector setting (real size) > param.su = 7200; % mm (real size) > param.sv = 9200; % mm > > > % X-ray source and detector setting > param.DSD = 32900; % Distance source to detector > param.DSO = 27400; % X-ray source to object axis distance > > > % angle setting > param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) > param.dang = 5; % angular step size (deg) > param.deg = 0:param.dang:360-1; % you can change > param.deg = param.deg*param.dir; > param.nProj = length(param.deg); > > param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than > 360 deg -> param.parker=1 > > param.filter='ram-lak'; % high pass filter > > > param.dx = param.sx/param.nx; % single voxel size > param.dy = param.sy/param.ny; > param.dz = param.sz/param.nz; > param.du = param.su/param.nu; > param.dv = param.sv/param.nv; > param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) > > > % Geometry calculation % % % > param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; > param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; > param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; > param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; > param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; > > > > So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : > 360). > But I got confused how to set the geometry parameters in RTK > I followed the rtkfdk tutorial but I can?t get any result using this method > > I did the following: > > 1- Create geometry.xml using these parameters: > > nproj = 72 ; > first_angle = 0 ; > arc = 360 ; > sid = 27400 ; > sdd = 32900 ; > proj_iso_x = 0; > proj_iso_y = 0; > out_angle = 0 ; > in_angle = 0 ; > source_x = 0; > source_y = 0 ; > > 2- Create my own mha file (WriteMhaFile.m) from my projection array > (36*100*72) using a matlab code with following properties: > Voxel size = [0.1 0.1 0.1] > Offset = [1 1 1] > > > 3- Then run the: > rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 > --dimension 500 > > > Could you please tell me if I am setting the geometry correctly? > Also, is there any other way to create my own mha file? > > Thank you in advance and looking forward to hear back from you. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 12:12:01 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 18:12:01 +0200 Subject: [Rtk-users] RTK training In-Reply-To: <55816290.1010807@uclouvain.be> References: <55816290.1010807@uclouvain.be> Message-ID: Dear RTK users, We have finally set a date for the RTK training, Wednesday, Nov 18 2015 in Lyon (France). The training will be organised by Kitware, go to this page for the registration: http://formations.kitware.fr/browse/116 We will do both user and developer sessions during the training. Since it's the first time that we do the training, we will tailor the balance between the two according to the wishes of registered people. The rest of the information should be available on the website but let us know if you need more information, we are still building the webpage and we'll be happy to improve it. We're looking forward to this new training and we'll do our best to meet your expectations, Simon On Wed, Jun 17, 2015 at 2:05 PM, Cyril Mory wrote: > Dear RTK users, > > The first RTK training is being planned at this very moment. It should > take place in November in Lyon, and be hosted by Kitware. The exact date > has not yet been decided, but will be available soon. > > We need your help to decide what to focus this training on. The choice is > mainly between two options: > - if most trainees want to learn how to use RTK, then we will focus on the > command-line tools and on python + Simple RTK > - if most trainees want to learn how to develop within RTK, modify and > enrich it, then we will focus on software architecture, detailed filter > description, ITK pipeline management, CUDA filters, etc... > > Please let us know which of these choices would best suit your needs. > > Looking forward, > Cyril > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Thu Jul 9 17:59:05 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Thu, 9 Jul 2015 14:59:05 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Simon, Thank you. I think now I understand how the whole geometry is defined in RTK. The projection is based on one experiment I am doing using different simulation techniques. Again thank you for your help. Best, Ali On Wed, Jul 8, 2015 at 11:23 PM, Simon Rit wrote: > Hi, > We can try to help but we need to understand your geometry... Where does > it come from by the way? If I understand your geometry correctly, I would > say : > - sid, sdd, nproj, arc are correct, > - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 > and you have 36x100 pixels, then the pixel size is [200,92,1] (last > dimension is not used so anything). For the volume, if your volume is > 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and > not 0.1. > - offset of projections is probably wrong. If you want to have a centered > projections, you'll need something like (-3500, -554, 0). You can set is to > 0 and put those values in proj_iso_x and proj_iso_y. > Regarding mha file, you can write mha files in many ways, using SimpleRTK, > matlab or writing an ITK code. > Good luck! > Simon > > On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah > wrote: > >> Hi, >> >> I have a question from you about the CT reconstruction, I would really >> appreciate if you can help me with this. >> >> I have the geometry as described in following and I am trying to run the >> rtkfdk code from RTK. >> >> >> % parameters % % % % % % % >> >> param.nx = 500; % number of voxels >> param.ny = 500; >> param.nz = 500; >> >> >> param.sx = 5000; % mm (real size) >> param.sy = 5000; % mm >> param.sz = 5000; % mm >> >> >> %The real detector panel pixel density (number of pixels) >> param.nu = 36; % number of pixels >> param.nv = 100; >> >> % Detector setting (real size) >> param.su = 7200; % mm (real size) >> param.sv = 9200; % mm >> >> >> % X-ray source and detector setting >> param.DSD = 32900; % Distance source to detector >> param.DSO = 27400; % X-ray source to object axis distance >> >> >> % angle setting >> param.dir = +1; % gantry rotating direction (clock wise/ counter >> clockwise) >> param.dang = 5; % angular step size (deg) >> param.deg = 0:param.dang:360-1; % you can change >> param.deg = param.deg*param.dir; >> param.nProj = length(param.deg); >> >> param.parker = 0; % data with 360 deg -> param.parker = 0 , data less >> than >> 360 deg -> param.parker=1 >> >> param.filter='ram-lak'; % high pass filter >> >> >> param.dx = param.sx/param.nx; % single voxel size >> param.dy = param.sy/param.ny; >> param.dz = param.sz/param.nz; >> param.du = param.su/param.nu; >> param.dv = param.sv/param.nv; >> param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) >> >> >> % Geometry calculation % % % >> param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; >> param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; >> param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; >> param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; >> param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; >> >> >> >> So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : >> 360). >> But I got confused how to set the geometry parameters in RTK >> I followed the rtkfdk tutorial but I can?t get any result using this >> method >> >> I did the following: >> >> 1- Create geometry.xml using these parameters: >> >> nproj = 72 ; >> first_angle = 0 ; >> arc = 360 ; >> sid = 27400 ; >> sdd = 32900 ; >> proj_iso_x = 0; >> proj_iso_y = 0; >> out_angle = 0 ; >> in_angle = 0 ; >> source_x = 0; >> source_y = 0 ; >> >> 2- Create my own mha file (WriteMhaFile.m) from my projection array >> (36*100*72) using a matlab code with following properties: >> Voxel size = [0.1 0.1 0.1] >> Offset = [1 1 1] >> >> >> 3- Then run the: >> rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 >> --dimension 500 >> >> >> Could you please tell me if I am setting the geometry correctly? >> Also, is there any other way to create my own mha file? >> >> Thank you in advance and looking forward to hear back from you. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hougeamm at 126.com Thu Jul 9 18:35:09 2015 From: hougeamm at 126.com (=?GBK?B?uu645w==?=) Date: Fri, 10 Jul 2015 06:35:09 +0800 (CST) Subject: [Rtk-users] problems for elekta data Message-ID: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Hello Everyone, Why the Elekta data prompt projection doesn't match when using rtkfdk? e.g., 377 vs 389? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 10 01:43:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Jul 2015 07:43:15 +0200 Subject: [Rtk-users] problems for elekta data In-Reply-To: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> References: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Message-ID: Hi, The message that you have on the command line is the result of the files that have been found in the path (--path option) with the regular expression (--regexp option). If it found more projections than what you have, then you probably need to improve your reg exp, e.g., by a $ after the file extension to specify that the file name must end with it. Simon On Fri, Jul 10, 2015 at 12:35 AM, ?? wrote: > Hello Everyone, > Why the Elekta data prompt projection doesn't match when using > rtkfdk? e.g., 377 vs 389? > Thanks! > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From guangming.zang at kaust.edu.sa Mon Jul 13 02:48:15 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 09:48:15 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset Message-ID: Hi RTK comunity, Besides the prameters like SID and SDD , from the geometry(.xteck) file got from my scanner, i also have object (volume) information like this: VoxelsX=179 VoxelsY=163 VoxelsZ=127 VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 The X,Y and Z axis are identical to RTK's geometry , So i was really wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i can show all other parameters like: rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, but it still a slight different visualization result from what we got from scanner software. So would you help me??? File attached is the geometry file in case. Thanks in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VCC_Dome_0622.xtekct Type: application/octet-stream Size: 1813 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 13 04:38:00 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 11:38:00 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: problem fixed. because the scanned object is symmetric and i did not notice that i should -Z axis in scanner to map Z in RTK thanks. but, i still do not know in RTK how to show the OffsetZ.. :( Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-13 9:48 GMT+03:00 Guangming Zang : > Hi RTK comunity, > Besides the prameters like SID and SDD , from the geometry(.xteck) file > got from my scanner, i also have object (volume) information like this: > VoxelsX=179 VoxelsY=163 VoxelsZ=127 > VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 > OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 > The X,Y and Z axis are identical to RTK's geometry , So i was really > wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i > can show all other parameters like: > > rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing > 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 > --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 > > Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, > but it still a slight different visualization result from what we got from > scanner software. > So would you help me??? > > > File attached is the geometry file in case. Thanks in advance > Regards > Guangming > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Mon Jul 13 13:21:44 2015 From: robert.calliess at gmx.de (=?utf-8?Q?Robert_Callie=C3=9F?=) Date: Mon, 13 Jul 2015 19:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? Message-ID: Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 13 13:42:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 13 Jul 2015 19:42:43 +0200 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: Hi, OffsetZ probably refers to the coordinate of the volume in the room coordinate which we don't use in RTK. Everything is set in the tomography coordinate during reconstruction. You can always change the coordinates of your volume after if you want to put it in some other coordinate system. Simon On Mon, Jul 13, 2015 at 10:38 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > problem fixed. > because the scanned object is symmetric and i did not notice that i > should -Z axis in scanner to map Z in RTK > thanks. > but, i still do not know in RTK how to show the OffsetZ.. :( > > Guangming > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-13 9:48 GMT+03:00 Guangming Zang : > >> Hi RTK comunity, >> Besides the prameters like SID and SDD , from the geometry(.xteck) file >> got from my scanner, i also have object (volume) information like this: >> VoxelsX=179 VoxelsY=163 VoxelsZ=127 >> VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 >> OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 >> The X,Y and Z axis are identical to RTK's geometry , So i was really >> wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i >> can show all other parameters like: >> >> rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing >> 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 >> --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 >> >> Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, >> but it still a slight different visualization result from what we got from >> scanner software. >> So would you help me??? >> >> >> File attached is the geometry file in case. Thanks in advance >> Regards >> Guangming >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Tue Jul 14 03:01:14 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 14 Jul 2015 09:01:14 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 01:32:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 07:32:43 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: > Hell RTK User, > I think there is a mistake in the described approach. > Point a) and f) meight be wrong. As far as I Understand, all Pixels > that are covered by the projected voxel vertices are update > with weight * voxel_value. Where weight is the overlaping area > of the projected voxel vertices polygon on the detector plane and the > underlying detector pixels. > > Any opinions before implementing it ? > > regards, > Robert > > *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr > *Von:* "Robert Callie?" > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what > they called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can > be rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector > cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value > to back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Wed Jul 15 08:07:20 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Wed, 15 Jul 2015 14:07:20 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 08:21:44 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 14:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: > Hello Simon, > thank you for your answer. I guess you linked the wrong article. But I > know what article you are talking about. > It's the articel from 2009 with a piece of code (MapSeq). > > >> I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > detector pixels that are totally covered by the overlap are weight with > "1" and if the overlap is between detector pixels > the pixels are weighted. Do you have a copy of the original article from > the De Man and Basu ? > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > Do you agree with that or did I miss something ? > > best regards, > Robert > > *Gesendet:* Mittwoch, 15. Juli 2015 um 07:32 Uhr > *Von:* "Simon Rit" > *An:* "Robert Callie?" > *Cc:* "rtk-users at public.kitware.com" > *Betreff:* Re: [Rtk-users] distance driven projector, a simplified > approach ? > Hi, > Indeed, I have published an article > on this > projector describing my implementation, you could use it if you want, > there's even a piece of code in it although I'm pretty sure it's not the > best implementation. This implementation dealt with the case where the > rotation axis is parallel to the detector. As far as I can remember, the > original article of De Man and Basu is also quite clear. > I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > Simon > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: >> >> Hell RTK User, >> I think there is a mistake in the described approach. >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> that are covered by the projected voxel vertices are update >> with weight * voxel_value. Where weight is the overlaping area >> of the projected voxel vertices polygon on the detector plane and the >> underlying detector pixels. >> >> Any opinions before implementing it ? >> >> regards, >> Robert >> >> *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr >> *Von:* "Robert Callie?" >> *An:* rtk-users at public.kitware.com >> *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel boundaries >> onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel?s contribution (weight) is the area of this overlapping. I >> read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is what >> they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone beam >> geometry. We can >> >> either rotate the detector and source around the object or the object can >> be rotated >> >> and the detector and source are fixed. I think Simon also wrote a paper >> about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source position, >> object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector >> cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the >> corresponding detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a ? e). Value >> to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I?m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of voxel >> boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 15 15:14:13 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 15 Jul 2015 21:14:13 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hello Simon, thank you for the articles. May I ask you what do you mean by ?voxel correction factor? in the code you provided in your article ? float f) // Voxel correction factor Thank you and best regards, Robert Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit Gesendet: Mittwoch, 15. Juli 2015 14:22 An: Robert Callie? Cc: rtk-users at public.kitware.com Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: Hello Simon, thank you for your answer. I guess you linked the wrong article. But I know what article you are talking about. It's the articel from 2009 with a piece of code (MapSeq). >> I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. You're right. It is that all pixels that are related to the overlap projected voxel overlap have to taken into account. So detector pixels that are totally covered by the overlap are weight with "1" and if the overlap is between detector pixels the pixels are weighted. Do you have a copy of the original article from the De Man and Basu ? I have the opinion that it's not neccessary to project the detector pixel boundaries and voxel boundaries onto a common plane if we use a flat panel detector. Instead we could project the voxel boundaries onto the detector plane directly. Do you agree with that or did I miss something ? best regards, Robert Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr Von: "Simon Rit" An: "Robert Callie?" Cc: "rtk-users at public.kitware.com" Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: Hell RTK User, I think there is a mistake in the described approach. Point a) and f) meight be wrong. As far as I Understand, all Pixels that are covered by the projected voxel vertices are update with weight * voxel_value. Where weight is the overlaping area of the projected voxel vertices polygon on the detector plane and the underlying detector pixels. Any opinions before implementing it ? regards, Robert Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr Von: "Robert Callie?" An: rtk-users at public.kitware.com Betreff: [Rtk-users] distance driven projector, a simplified approach ? Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 15:45:23 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 21:45:23 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. Simon On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie? wrote: > Hello Simon, > > thank you for the articles. May I ask you what do you mean by > > ?voxel correction factor? in the code you provided in your article ? > > float f) // Voxel correction factor > > > > Thank you and best regards, > > Robert > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Mittwoch, 15. Juli 2015 14:22 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified > approach ? > > > > Sorry, this link indeed with the MapSeg function. And yes, I was projecting > it to the detector plane directly. > > Simon > > > > On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" > wrote: > > Hello Simon, > > thank you for your answer. I guess you linked the wrong article. But I know > what article you are talking about. > > It's the articel from 2009 with a piece of code (MapSeq). > > > >>> I don't have time to go into the details of what you have proposed but, >>> from a glance, the first step seems useless. > > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > > detector pixels that are totally covered by the overlap are weight with "1" > and if the overlap is between detector pixels > > the pixels are weighted. Do you have a copy of the original article from the > De Man and Basu ? > > > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > > Do you agree with that or did I miss something ? > > > > best regards, > > Robert > > > > Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr > Von: "Simon Rit" > An: "Robert Callie?" > Cc: "rtk-users at public.kitware.com" > Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? > > Hi, > > Indeed, I have published an article on this projector describing my > implementation, you could use it if you want, there's even a piece of code > in it although I'm pretty sure it's not the best implementation. This > implementation dealt with the case where the rotation axis is parallel to > the detector. As far as I can remember, the original article of De Man and > Basu is also quite clear. > > I don't have time to go into the details of what you have proposed but, from > a glance, the first step seems useless. > > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > > Simon > > > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: > > Hell RTK User, > > I think there is a mistake in the described approach. > > Point a) and f) meight be wrong. As far as I Understand, all Pixels > > that are covered by the projected voxel vertices are update > > with weight * voxel_value. Where weight is the overlaping area > > of the projected voxel vertices polygon on the detector plane and the > > underlying detector pixels. > > > > Any opinions before implementing it ? > > > > regards, > > Robert > > > > Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr > Von: "Robert Callie?" > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what they > called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can be > rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value to > back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From simon.rit at creatis.insa-lyon.fr Fri Jul 17 02:22:16 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 17 Jul 2015 08:22:16 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Please keep on using the mailing list, I don't see a good reason to keep this conversation private. I won't have time to go back into these details. From a quick look, I think this is correct although I would have simply said that D is the center of the detector pixel. Simon On Thu, Jul 16, 2015 at 10:24 PM, Robert Callie? wrote: > Hello, > Sorry that I have to ask again. But I want to clear this before I start. > I want to ask about the cosine weight DeMan mentioned in his article. > He wrote: > > " > (1) The intersection length of the line of interest with the image slab S, the latter being > defined as the slab parallel to the xz plane and containing voxel V. This intersection length > is given by t/(cos ? cos ? ), where t is the isotropic voxel size, and ? and ? are the in- and > out-of-plane angles of the line of interest with the y-axis. > " > > So what he actually does, is that he calculates the intersection length of the slab s (that contains the voxel) with > a ray going from xray source to the middle of two adjacent detector cell boundaries. Let's refare to Figure 5. > So the length to be considered is calculated as the intersection length of slab S with the ray going from > the source ( the black dot in figure 5) to the mid-point of D, that means the center of the two projected adjacent > detector pixel boundaries. > > > Sorry for asking again but I want it to make it clear to me. > > Best regards, > Robert > > > -----Urspr?ngliche Nachricht----- > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit > Gesendet: Mittwoch, 15. Juli 2015 21:45 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? > > "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" > So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. > Simon > > On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie wrote: >> Hello Simon, >> >> thank you for the articles. May I ask you what do you mean by >> >> voxel correction factor in the code you provided in your article ? >> >> float f) // Voxel correction factor >> >> >> >> Thank you and best regards, >> >> Robert >> >> >> >> Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von >> Simon Rit >> Gesendet: Mittwoch, 15. Juli 2015 14:22 >> An: Robert Callie >> Cc: rtk-users at public.kitware.com >> Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified >> approach ? >> >> >> >> Sorry, this link indeed with the MapSeg function. And yes, I was >> projecting it to the detector plane directly. >> >> Simon >> >> >> >> On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie " >> >> wrote: >> >> Hello Simon, >> >> thank you for your answer. I guess you linked the wrong article. But I >> know what article you are talking about. >> >> It's the articel from 2009 with a piece of code (MapSeq). >> >> >> >>>> I don't have time to go into the details of what you have proposed >>>> but, from a glance, the first step seems useless. >> >> You're right. It is that all pixels that are related to the overlap >> projected voxel overlap have to taken into account. So >> >> detector pixels that are totally covered by the overlap are weight with "1" >> and if the overlap is between detector pixels >> >> the pixels are weighted. Do you have a copy of the original article >> from the De Man and Basu ? >> >> >> >> I have the opinion that it's not neccessary to project the detector >> pixel boundaries and voxel boundaries onto a common plane >> >> if we use a flat panel detector. Instead we could project the voxel >> boundaries onto the detector plane directly. >> >> Do you agree with that or did I miss something ? >> >> >> >> best regards, >> >> Robert >> >> >> >> Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr >> Von: "Simon Rit" >> An: "Robert Callie " >> Cc: "rtk-users at public.kitware.com" >> Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hi, >> >> Indeed, I have published an article on this projector describing my >> implementation, you could use it if you want, there's even a piece of >> code in it although I'm pretty sure it's not the best implementation. >> This implementation dealt with the case where the rotation axis is >> parallel to the detector. As far as I can remember, the original >> article of De Man and Basu is also quite clear. >> >> I don't have time to go into the details of what you have proposed >> but, from a glance, the first step seems useless. >> >> Good luck in your implementation and don't hesitate to send it to us >> when you have a working RTK implementation, >> >> Simon >> >> >> >> On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie " >> >> wrote: >> >> Hell RTK User, >> >> I think there is a mistake in the described approach. >> >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> >> that are covered by the projected voxel vertices are update >> >> with weight * voxel_value. Where weight is the overlaping area >> >> of the projected voxel vertices polygon on the detector plane and the >> >> underlying detector pixels. >> >> >> >> Any opinions before implementing it ? >> >> >> >> regards, >> >> Robert >> >> >> >> Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr >> Von: "Robert Callie " >> An: rtk-users at public.kitware.com >> Betreff: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel >> boundaries onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel s contribution (weight) is the area of this >> overlapping. I read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is >> what they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone >> beam geometry. We can >> >> either rotate the detector and source around the object or the object >> can be rotated >> >> and the detector and source are fixed. I think Simon also wrote a >> paper about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source >> position, object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the corresponding >> detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a e). >> Value to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of >> voxel boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > From guangming.zang at kaust.edu.sa Sun Jul 26 18:30:42 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 01:30:42 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed Message-ID: Hi RTK community, i am using SART algorithm to reconstruct an object. But in this new RTK version, the time recording seems a little weird: the total time is 1219.12s , but adding the time cost in different stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward projection part. BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, both multi-threading i think. Can anyone tell me what's going on? Thanks Regards Guangming [image: ???? 1] *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 01:59:11 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 07:59:11 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Guangming, It's not surprising to me that the backprojection is faster than the forward projection, that's what I expect. If the total time is longer, that's probably that some individual steps are not included in the total time. Can you try to add reader->Update(); before the line itk::TimeProbe totalTimeProbe; in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? Simon On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > Hi RTK community, > i am using SART algorithm to reconstruct an object. > But in this new RTK version, the time recording seems a little weird: > the total time is 1219.12s , but adding the time cost in different stages > is not 1291.12 s. especially for "backprojection" part, only 16.6051s to > reconstruct a 128^3 volume ?? even shorter than forward projection part. > BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, > both multi-threading i think. > Can anyone tell me what's going on? > Thanks > Regards > Guangming > > [image: ???? 1] > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 27 04:41:58 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 11:41:58 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, Thanks for your reply. would you pls help and explain why backprojection is expected to take shorter time than forward projection?? because i was thinking if no caching step, the backprojection should take much longer time than sart algorithm. yes, i run rtksart for 2 times once.it took 12xxs, similar to the time consumed of 3 times's sart, which much slower than my own application. BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 shapp-logan projections(512*512 resolution each) rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 and i will try reader->Update() like what you said. Thanks Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 8:59 GMT+03:00 Simon Rit : > Hi Guangming, > It's not surprising to me that the backprojection is faster than the > forward projection, that's what I expect. If the total time is longer, > that's probably that some individual steps are not included in the total > time. Can you try to add > reader->Update(); > before the line > > itk::TimeProbe totalTimeProbe; > > in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? > > Simon > > > > On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi RTK community, >> i am using SART algorithm to reconstruct an object. >> But in this new RTK version, the time recording seems a little weird: >> the total time is 1219.12s , but adding the time cost in different >> stages is not 1291.12 s. especially for "backprojection" part, only >> 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward >> projection part. BTW, the -f and -b are Joseph and >> VoxelBasedBackProjection, respectively, both multi-threading i think. >> Can anyone tell me what's going on? >> Thanks >> Regards >> Guangming >> >> [image: ???? 1] >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 08:28:28 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 14:28:28 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: I can try. Forward and back projection have the same algorithmic complexity but voxel based backprojection benefits from several optimizations in terms of memory management and computations that makes it faster. The best is to look at the code for further details... although both have far from being optimal. And I did not get the sentence "the backprojection should take much longer time than sart algorithm." because SART contains a backprojection and other steps so SART is obviously longer than the bp alone. Your log is strange and I don't see what steps are not timed that would take most of the time. I did the same test on my computer and here is my result: OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha --dimension 512 OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.288571 s Multiplication by zero: 0.131672 s Forward projection: 34.3612 s Subtraction: 0.203409 s Multiplication by lambda: 0.146459 s Ray box intersection: 1.30755 s Division: 0.187294 s Multiplication by the gating weights: 0 s Displaced detector: 0.278408 s Back projection: 11.8456 s Volume update: 0 s It took... 53.2765 s Simon On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang wrote: > Hi Simon, > Thanks for your reply. > would you pls help and explain why backprojection is expected to take > shorter time than forward projection?? because i was thinking if no caching > step, the backprojection should take much longer time than sart algorithm. > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > consumed of 3 times's sart, which much slower than my own application. > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > shapp-logan projections(512*512 resolution each) > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > -64,-64,-64 -l 0.5 -n 3 --time 1 > > and i will try reader->Update() like what you said. > Thanks > Guangming > > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> Hi Guangming, >> It's not surprising to me that the backprojection is faster than the >> forward projection, that's what I expect. If the total time is longer, >> that's probably that some individual steps are not included in the total >> time. Can you try to add >> reader->Update(); >> before the line >> >> itk::TimeProbe totalTimeProbe; >> >> in rtksart.cxx? It may be that all the reading operations are done but not >> timed in the sart->Update(). Why they are so long, I don't know, is your D: >> drive a network drive? Do you observe the same behavior if you do rtksart 2 >> times in a row? >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> wrote: >>> >>> Hi RTK community, >>> i am using SART algorithm to reconstruct an object. >>> But in this new RTK version, the time recording seems a little weird: >>> the total time is 1219.12s , but adding the time cost in different >>> stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s >>> to reconstruct a 128^3 volume ?? even shorter than forward projection part. >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, >>> both multi-threading i think. >>> Can anyone tell me what's going on? >>> Thanks >>> Regards >>> Guangming >>> >>> >>> Guangming Zang (Alex) >>> King Abdullah University of Science and Technology(KAUST) >>> University of Chinese Academy of Sciences(UCAS) >>> >>> >>> >>> >>> ________________________________ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete this >>> message from your computer system. Any unauthorized use or distribution is >>> prohibited. Please consider the environment before printing this email. >> >> > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 08:50:48 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 15:50:48 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, sorry for the mistake, not"the backprojection should take much longer time than sart algorithm" , but "the backprojection should take much longer time than forward projection in sart algorithm". BTW, how many cores does your computer have?? Mine is 24 cores. is it can explain the reason why it takes much longer time on my computer than yours? Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 15:28 GMT+03:00 Simon Rit : > I can try. Forward and back projection have the same algorithmic > complexity but voxel based backprojection benefits from several > optimizations in terms of memory management and computations that > makes it faster. The best is to look at the code for further > details... although both have far from being optimal. And I did not > get the sentence "the backprojection should take much longer time than > sart algorithm." because SART contains a backprojection and other > steps so SART is obviously longer than the bp alone. > Your log is strange and I don't see what steps are not timed that > would take most of the time. I did the same test on my computer and > here is my result: > > OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > --dimension 512 > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.288571 s > Multiplication by zero: 0.131672 s > Forward projection: 34.3612 s > Subtraction: 0.203409 s > Multiplication by lambda: 0.146459 s > Ray box intersection: 1.30755 s > Division: 0.187294 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.278408 s > Back projection: 11.8456 s > Volume update: 0 s > It took... 53.2765 s > > Simon > > On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > wrote: > > Hi Simon, > > Thanks for your reply. > > would you pls help and explain why backprojection is expected to take > > shorter time than forward projection?? because i was thinking if no > caching > > step, the backprojection should take much longer time than sart > algorithm. > > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > > consumed of 3 times's sart, which much slower than my own application. > > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > > shapp-logan projections(512*512 resolution each) > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > > -64,-64,-64 -l 0.5 -n 3 --time 1 > > > > and i will try reader->Update() like what you said. > > Thanks > > Guangming > > > > > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> > >> Hi Guangming, > >> It's not surprising to me that the backprojection is faster than the > >> forward projection, that's what I expect. If the total time is longer, > >> that's probably that some individual steps are not included in the total > >> time. Can you try to add > >> reader->Update(); > >> before the line > >> > >> itk::TimeProbe totalTimeProbe; > >> > >> in rtksart.cxx? It may be that all the reading operations are done but > not > >> timed in the sart->Update(). Why they are so long, I don't know, is > your D: > >> drive a network drive? Do you observe the same behavior if you do > rtksart 2 > >> times in a row? > >> > >> Simon > >> > >> > >> > >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> wrote: > >>> > >>> Hi RTK community, > >>> i am using SART algorithm to reconstruct an object. > >>> But in this new RTK version, the time recording seems a little weird: > >>> the total time is 1219.12s , but adding the time cost in different > >>> stages is not 1291.12 s. especially for "backprojection" part, only > 16.6051s > >>> to reconstruct a 128^3 volume ?? even shorter than forward projection > part. > >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > respectively, > >>> both multi-threading i think. > >>> Can anyone tell me what's going on? > >>> Thanks > >>> Regards > >>> Guangming > >>> > >>> > >>> Guangming Zang (Alex) > >>> King Abdullah University of Science and Technology(KAUST) > >>> University of Chinese Academy of Sciences(UCAS) > >>> > >>> > >>> > >>> > >>> ________________________________ > >>> This message and its contents, including attachments are intended > solely > >>> for the original recipient. If you are not the intended recipient or > have > >>> received this message in error, please notify me immediately and > delete this > >>> message from your computer system. Any unauthorized use or > distribution is > >>> prohibited. Please consider the environment before printing this email. > >> > >> > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 09:02:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 15:02:03 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: No I expect forward projection to be longer than backprojection although with optimal implementations, it should take about the same time since they have the same complexity. I have 4 cores on my laptop. I don't see how it explains it, try to find out where does SART spend the time. Simon On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang wrote: > Hi Simon, > sorry for the mistake, not"the backprojection should take much longer time > than > sart algorithm" , but "the backprojection should take much longer time than > forward projection in sart algorithm". > > BTW, how many cores does your computer have?? Mine is 24 cores. > is it can explain the reason why it takes much longer time on my computer > than yours? > Regards > Guangming > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> I can try. Forward and back projection have the same algorithmic >> complexity but voxel based backprojection benefits from several >> optimizations in terms of memory management and computations that >> makes it faster. The best is to look at the code for further >> details... although both have far from being optimal. And I did not >> get the sentence "the backprojection should take much longer time than >> sart algorithm." because SART contains a backprojection and other >> steps so SART is obviously longer than the bp alone. >> Your log is strange and I don't see what steps are not timed that >> would take most of the time. I did the same test on my computer and >> here is my result: >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> --dimension 512 >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> 1 >> Recording elapsed time... >> SARTConeBeamReconstructionFilter timing: >> Extraction of projection sub-stacks: 0.288571 s >> Multiplication by zero: 0.131672 s >> Forward projection: 34.3612 s >> Subtraction: 0.203409 s >> Multiplication by lambda: 0.146459 s >> Ray box intersection: 1.30755 s >> Division: 0.187294 s >> Multiplication by the gating weights: 0 s >> Displaced detector: 0.278408 s >> Back projection: 11.8456 s >> Volume update: 0 s >> It took... 53.2765 s >> >> Simon >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> wrote: >> > Hi Simon, >> > Thanks for your reply. >> > would you pls help and explain why backprojection is expected to take >> > shorter time than forward projection?? because i was thinking if no >> > caching >> > step, the backprojection should take much longer time than sart >> > algorithm. >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time >> > consumed of 3 times's sart, which much slower than my own application. >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 >> > shapp-logan projections(512*512 resolution each) >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> > >> > and i will try reader->Update() like what you said. >> > Thanks >> > Guangming >> > >> > >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> >> >> Hi Guangming, >> >> It's not surprising to me that the backprojection is faster than the >> >> forward projection, that's what I expect. If the total time is longer, >> >> that's probably that some individual steps are not included in the >> >> total >> >> time. Can you try to add >> >> reader->Update(); >> >> before the line >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done but >> >> not >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> your D: >> >> drive a network drive? Do you observe the same behavior if you do >> >> rtksart 2 >> >> times in a row? >> >> >> >> Simon >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> wrote: >> >>> >> >>> Hi RTK community, >> >>> i am using SART algorithm to reconstruct an object. >> >>> But in this new RTK version, the time recording seems a little weird: >> >>> the total time is 1219.12s , but adding the time cost in different >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >>> 16.6051s >> >>> to reconstruct a 128^3 volume ?? even shorter than forward projection >> >>> part. >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >>> respectively, >> >>> both multi-threading i think. >> >>> Can anyone tell me what's going on? >> >>> Thanks >> >>> Regards >> >>> Guangming >> >>> >> >>> >> >>> Guangming Zang (Alex) >> >>> King Abdullah University of Science and Technology(KAUST) >> >>> University of Chinese Academy of Sciences(UCAS) >> >>> >> >>> >> >>> >> >>> >> >>> ________________________________ >> >>> This message and its contents, including attachments are intended >> >>> solely >> >>> for the original recipient. If you are not the intended recipient or >> >>> have >> >>> received this message in error, please notify me immediately and >> >>> delete this >> >>> message from your computer system. Any unauthorized use or >> >>> distribution is >> >>> prohibited. Please consider the environment before printing this >> >>> email. >> >> >> >> >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended solely >> > for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> > this >> > message from your computer system. Any unauthorized use or distribution >> > is >> > prohibited. Please consider the environment before printing this email. > > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 10:05:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:05:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, it cost 1200s for SART algorithm at first, and the command are: rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 in which, the projections data(360pro_SL_Vol128_512.mha) is not generated from rtkprojectshepploganphantom , but from my application. though it took long time, but i can got a nice result, And i just tried the command you used, i.e. generated the projections data by rtkprojectshepploganphantom : rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 --sid=500.0 rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 yes, it takes about 56s. but the reconstructed result is weird, the voxel values range from [-142186, 208146] and can not see anything when visualizing it. i believe you got the similar results, which maybe explain why it computes much faster. if i wanna use the projections generated by rtkprojectshepploganphantom , can you give me an example to get a nice results? Best regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 16:02 GMT+03:00 Simon Rit : > No I expect forward projection to be longer than backprojection > although with optimal implementations, it should take about the same > time since they have the same complexity. > I have 4 cores on my laptop. I don't see how it explains it, try to > find out where does SART spend the time. > Simon > > On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang > wrote: > > Hi Simon, > > sorry for the mistake, not"the backprojection should take much longer > time > > than > > sart algorithm" , but "the backprojection should take much longer time > than > > forward projection in sart algorithm". > > > > BTW, how many cores does your computer have?? Mine is 24 cores. > > is it can explain the reason why it takes much longer time on my computer > > than yours? > > Regards > > Guangming > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : > >> > >> I can try. Forward and back projection have the same algorithmic > >> complexity but voxel based backprojection benefits from several > >> optimizations in terms of memory management and computations that > >> makes it faster. The best is to look at the code for further > >> details... although both have far from being optimal. And I did not > >> get the sentence "the backprojection should take much longer time than > >> sart algorithm." because SART contains a backprojection and other > >> steps so SART is obviously longer than the bp alone. > >> Your log is strange and I don't see what steps are not timed that > >> would take most of the time. I did the same test on my computer and > >> here is my result: > >> > >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > >> --dimension 512 > >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > >> 1 > >> Recording elapsed time... > >> SARTConeBeamReconstructionFilter timing: > >> Extraction of projection sub-stacks: 0.288571 s > >> Multiplication by zero: 0.131672 s > >> Forward projection: 34.3612 s > >> Subtraction: 0.203409 s > >> Multiplication by lambda: 0.146459 s > >> Ray box intersection: 1.30755 s > >> Division: 0.187294 s > >> Multiplication by the gating weights: 0 s > >> Displaced detector: 0.278408 s > >> Back projection: 11.8456 s > >> Volume update: 0 s > >> It took... 53.2765 s > >> > >> Simon > >> > >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > >> wrote: > >> > Hi Simon, > >> > Thanks for your reply. > >> > would you pls help and explain why backprojection is expected to take > >> > shorter time than forward projection?? because i was thinking if no > >> > caching > >> > step, the backprojection should take much longer time than sart > >> > algorithm. > >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the > time > >> > consumed of 3 times's sart, which much slower than my own application. > >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > >> > shapp-logan projections(512*512 resolution each) > >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > >> > -64,-64,-64 -l 0.5 -n 3 --time 1 > >> > > >> > and i will try reader->Update() like what you said. > >> > Thanks > >> > Guangming > >> > > >> > > >> > > >> > Guangming Zang (Alex) > >> > King Abdullah University of Science and Technology(KAUST) > >> > University of Chinese Academy of Sciences(UCAS) > >> > > >> > > >> > > >> > > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> >> > >> >> Hi Guangming, > >> >> It's not surprising to me that the backprojection is faster than the > >> >> forward projection, that's what I expect. If the total time is > longer, > >> >> that's probably that some individual steps are not included in the > >> >> total > >> >> time. Can you try to add > >> >> reader->Update(); > >> >> before the line > >> >> > >> >> itk::TimeProbe totalTimeProbe; > >> >> > >> >> in rtksart.cxx? It may be that all the reading operations are done > but > >> >> not > >> >> timed in the sart->Update(). Why they are so long, I don't know, is > >> >> your D: > >> >> drive a network drive? Do you observe the same behavior if you do > >> >> rtksart 2 > >> >> times in a row? > >> >> > >> >> Simon > >> >> > >> >> > >> >> > >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> >> wrote: > >> >>> > >> >>> Hi RTK community, > >> >>> i am using SART algorithm to reconstruct an object. > >> >>> But in this new RTK version, the time recording seems a little > weird: > >> >>> the total time is 1219.12s , but adding the time cost in different > >> >>> stages is not 1291.12 s. especially for "backprojection" part, only > >> >>> 16.6051s > >> >>> to reconstruct a 128^3 volume ?? even shorter than forward > projection > >> >>> part. > >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > >> >>> respectively, > >> >>> both multi-threading i think. > >> >>> Can anyone tell me what's going on? > >> >>> Thanks > >> >>> Regards > >> >>> Guangming > >> >>> > >> >>> > >> >>> Guangming Zang (Alex) > >> >>> King Abdullah University of Science and Technology(KAUST) > >> >>> University of Chinese Academy of Sciences(UCAS) > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> ________________________________ > >> >>> This message and its contents, including attachments are intended > >> >>> solely > >> >>> for the original recipient. If you are not the intended recipient or > >> >>> have > >> >>> received this message in error, please notify me immediately and > >> >>> delete this > >> >>> message from your computer system. Any unauthorized use or > >> >>> distribution is > >> >>> prohibited. Please consider the environment before printing this > >> >>> email. > >> >> > >> >> > >> > > >> > > >> > ________________________________ > >> > This message and its contents, including attachments are intended > solely > >> > for > >> > the original recipient. If you are not the intended recipient or have > >> > received this message in error, please notify me immediately and > delete > >> > this > >> > message from your computer system. Any unauthorized use or > distribution > >> > is > >> > prohibited. Please consider the environment before printing this > email. > > > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 10:12:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:12:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: BTW, the projections are 512*512, and the pixel spacing is 0.5 Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:05 GMT+03:00 Guangming Zang : > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 10:20:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 16:20:12 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Obviously I hadn't looked at the result and/or checked the command line options, sorry. This is an example from the same simulated dataset that gives me a good results: OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.567773 s Multiplication by zero: 0.303715 s Forward projection: 142.305 s Subtraction: 0.445842 s Multiplication by lambda: 0.2663 s Ray box intersection: 5.40366 s Division: 0.535618 s Multiplication by the gating weights: 0 s Displaced detector: 0.415431 s Back projection: 21.3689 s Volume update: 0 s It took... 177.059 s but this doesn't change the content of my previous message. What takes time is probably in your own software, be sure that you update SART inputs before timing it. Simon On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang wrote: > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 11:12:16 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 18:12:16 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Thanks Simon, now it work fine when using projections generated by RTK itself (command rtkprojectshepploganphantom ). for 1 iteration of SART to reconstruct 128^3 size volume, it took only 19s, which gives nice results as well. Thanks again. Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:20 GMT+03:00 Simon Rit : > Obviously I hadn't looked at the result and/or checked the command line > options, sorry. This is an example from the same simulated dataset that > gives me a good results: > > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f > Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n > 3 --time 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.567773 s > Multiplication by zero: 0.303715 s > Forward projection: 142.305 s > Subtraction: 0.445842 s > Multiplication by lambda: 0.2663 s > Ray box intersection: 5.40366 s > Division: 0.535618 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.415431 s > Back projection: 21.3689 s > Volume update: 0 s > It took... 177.059 s > > but this doesn't change the content of my previous message. What takes > time is probably in your own software, be sure that you update SART inputs > before timing it. > Simon > > On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon, >> it cost 1200s for SART algorithm at first, and the command are: >> rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd= >> 725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" >> >> rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 >> >> in which, the projections data(360pro_SL_Vol128_512.mha) is not >> generated from rtkprojectshepploganphantom , but from my application. >> though it took long time, but i can got a nice result, >> >> >> And i just tried the command you used, i.e. generated the projections >> data by rtkprojectshepploganphantom : >> >> rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 >> --sid=500.0 >> rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 >> rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b >> VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 >> --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 >> yes, it takes about 56s. >> but the reconstructed result is weird, the voxel values range from >> [-142186, 208146] and can not see anything when visualizing it. >> i believe you got the similar results, which maybe explain why it >> computes much faster. >> >> if i wanna use the projections generated by rtkprojectshepploganphantom >> , can you give me an example to get a nice results? >> >> Best regards >> Guangming >> >> >> >> >> >> >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> 2015-07-27 16:02 GMT+03:00 Simon Rit : >> >>> No I expect forward projection to be longer than backprojection >>> although with optimal implementations, it should take about the same >>> time since they have the same complexity. >>> I have 4 cores on my laptop. I don't see how it explains it, try to >>> find out where does SART spend the time. >>> Simon >>> >>> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >>> wrote: >>> > Hi Simon, >>> > sorry for the mistake, not"the backprojection should take much longer >>> time >>> > than >>> > sart algorithm" , but "the backprojection should take much longer time >>> than >>> > forward projection in sart algorithm". >>> > >>> > BTW, how many cores does your computer have?? Mine is 24 cores. >>> > is it can explain the reason why it takes much longer time on my >>> computer >>> > than yours? >>> > Regards >>> > Guangming >>> > >>> > Guangming Zang (Alex) >>> > King Abdullah University of Science and Technology(KAUST) >>> > University of Chinese Academy of Sciences(UCAS) >>> > >>> > >>> > >>> > >>> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >>> >> >>> >> I can try. Forward and back projection have the same algorithmic >>> >> complexity but voxel based backprojection benefits from several >>> >> optimizations in terms of memory management and computations that >>> >> makes it faster. The best is to look at the code for further >>> >> details... although both have far from being optimal. And I did not >>> >> get the sentence "the backprojection should take much longer time than >>> >> sart algorithm." because SART contains a backprojection and other >>> >> steps so SART is obviously longer than the bp alone. >>> >> Your log is strange and I don't see what steps are not timed that >>> >> would take most of the time. I did the same test on my computer and >>> >> here is my result: >>> >> >>> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >>> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >>> >> --dimension 512 >>> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >>> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >>> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >>> >> 1 >>> >> Recording elapsed time... >>> >> SARTConeBeamReconstructionFilter timing: >>> >> Extraction of projection sub-stacks: 0.288571 s >>> >> Multiplication by zero: 0.131672 s >>> >> Forward projection: 34.3612 s >>> >> Subtraction: 0.203409 s >>> >> Multiplication by lambda: 0.146459 s >>> >> Ray box intersection: 1.30755 s >>> >> Division: 0.187294 s >>> >> Multiplication by the gating weights: 0 s >>> >> Displaced detector: 0.278408 s >>> >> Back projection: 11.8456 s >>> >> Volume update: 0 s >>> >> It took... 53.2765 s >>> >> >>> >> Simon >>> >> >>> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >>> >> wrote: >>> >> > Hi Simon, >>> >> > Thanks for your reply. >>> >> > would you pls help and explain why backprojection is expected to >>> take >>> >> > shorter time than forward projection?? because i was thinking if no >>> >> > caching >>> >> > step, the backprojection should take much longer time than sart >>> >> > algorithm. >>> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >>> time >>> >> > consumed of 3 times's sart, which much slower than my own >>> application. >>> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >>> 360 >>> >> > shapp-logan projections(512*512 resolution each) >>> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >>> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >>> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >>> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >>> >> > >>> >> > and i will try reader->Update() like what you said. >>> >> > Thanks >>> >> > Guangming >>> >> > >>> >> > >>> >> > >>> >> > Guangming Zang (Alex) >>> >> > King Abdullah University of Science and Technology(KAUST) >>> >> > University of Chinese Academy of Sciences(UCAS) >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit >> >: >>> >> >> >>> >> >> Hi Guangming, >>> >> >> It's not surprising to me that the backprojection is faster than >>> the >>> >> >> forward projection, that's what I expect. If the total time is >>> longer, >>> >> >> that's probably that some individual steps are not included in the >>> >> >> total >>> >> >> time. Can you try to add >>> >> >> reader->Update(); >>> >> >> before the line >>> >> >> >>> >> >> itk::TimeProbe totalTimeProbe; >>> >> >> >>> >> >> in rtksart.cxx? It may be that all the reading operations are done >>> but >>> >> >> not >>> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >>> >> >> your D: >>> >> >> drive a network drive? Do you observe the same behavior if you do >>> >> >> rtksart 2 >>> >> >> times in a row? >>> >> >> >>> >> >> Simon >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >>> >> >> wrote: >>> >> >>> >>> >> >>> Hi RTK community, >>> >> >>> i am using SART algorithm to reconstruct an object. >>> >> >>> But in this new RTK version, the time recording seems a little >>> weird: >>> >> >>> the total time is 1219.12s , but adding the time cost in >>> different >>> >> >>> stages is not 1291.12 s. especially for "backprojection" part, >>> only >>> >> >>> 16.6051s >>> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >>> projection >>> >> >>> part. >>> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >>> >> >>> respectively, >>> >> >>> both multi-threading i think. >>> >> >>> Can anyone tell me what's going on? >>> >> >>> Thanks >>> >> >>> Regards >>> >> >>> Guangming >>> >> >>> >>> >> >>> >>> >> >>> Guangming Zang (Alex) >>> >> >>> King Abdullah University of Science and Technology(KAUST) >>> >> >>> University of Chinese Academy of Sciences(UCAS) >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> ________________________________ >>> >> >>> This message and its contents, including attachments are intended >>> >> >>> solely >>> >> >>> for the original recipient. If you are not the intended recipient >>> or >>> >> >>> have >>> >> >>> received this message in error, please notify me immediately and >>> >> >>> delete this >>> >> >>> message from your computer system. Any unauthorized use or >>> >> >>> distribution is >>> >> >>> prohibited. Please consider the environment before printing this >>> >> >>> email. >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > ________________________________ >>> >> > This message and its contents, including attachments are intended >>> solely >>> >> > for >>> >> > the original recipient. If you are not the intended recipient or >>> have >>> >> > received this message in error, please notify me immediately and >>> delete >>> >> > this >>> >> > message from your computer system. Any unauthorized use or >>> distribution >>> >> > is >>> >> > prohibited. Please consider the environment before printing this >>> email. >>> > >>> > >>> > >>> > ________________________________ >>> > This message and its contents, including attachments are intended >>> solely for >>> > the original recipient. If you are not the intended recipient or have >>> > received this message in error, please notify me immediately and >>> delete this >>> > message from your computer system. Any unauthorized use or >>> distribution is >>> > prohibited. Please consider the environment before printing this email. >>> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From infrombox at yandex.ru Tue Jul 28 04:30:22 2015 From: infrombox at yandex.ru (1 1) Date: Tue, 28 Jul 2015 15:30:22 +0700 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: <2213081438072222@web8j.yandex.ru> Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. But program which i use reads meta images with MET_SHORT pixel type only. Is there easy way to setting it and get volume with different from MET_FLOAT pixel type ? If not, could you advice me, what the filter i should to do, for example as post process after reconstruction ala MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward operation of LUTbasedVariableI0RawToAttenuationImageFilter ? Thanks. From simon.rit at creatis.insa-lyon.fr Tue Jul 28 04:56:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 10:56:54 +0200 Subject: [Rtk-users] volume with diffieret pixel type In-Reply-To: <2213081438072222@web8j.yandex.ru> References: <2213081438072222@web8j.yandex.ru> Message-ID: Hi, This is more an ITK question than a RTK question. Yes, we use float by default in our applications. You can cast the image to any type before writing using itk::CastImageFilter but you'll have to modify the applications and, of course, there is a loss of information. If you don't want to program it, you can use any other software, e.g. in vv right clik on your image after opening and use the convert to option. Simon On Tue, Jul 28, 2015 at 10:30 AM, 1 1 wrote: > Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. > But program which i use reads meta images with MET_SHORT pixel type only. > Is there easy way to setting it and get volume with different from > MET_FLOAT pixel type ? If not, could you advice me, what the filter i > should to do, for example as post process after reconstruction ala > MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward > operation of LUTbasedVariableI0RawToAttenuationImageFilter image, float image> ? > Thanks. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pconneely020186 at gmail.com Tue Jul 28 12:05:29 2015 From: pconneely020186 at gmail.com (peter conneely) Date: Tue, 28 Jul 2015 17:05:29 +0100 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: "peter conneely" Date: 24 Jul 2015 11:07 Subject: Issue running FDK reconstruction algorithm To: Cc: Hi, I'm having trouble running the FDK reconstruction alogrithm on Elekta and Varian data sets. The algorithm does work when I try the shepp-logan example. When I initially ran the application I included the (') around .*.his. and got the following lines. [image: Inline image 1] when I try to run with the (') removed it finds the 669 files but then the application stops working. I have tried adding registry edits to run exe and have tried switching of dep. Neither of these work I am not sure what is going wrong and how to fix it. My system properties are as follows. Processor: Intel Pentium CPU P6100 @ 2.00 Ghz RAM: 3.00 GB GPU: Intel HD Graphics Systems type 64 Bit. Thanks and Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Tue Jul 28 12:46:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 18:46:17 +0200 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: Hi, I guess the quotes are OS depedent, maybe you need double quotes on Windows. It's strange that you don't get an error message. Are you sure it crashed? If yes, have you checked the elektaGeometry file? Does it have 669 projection sections as expected? Or maybe it's a memory issue, try the --lowmem option. Simon On Tue, Jul 28, 2015 at 6:05 PM, peter conneely wrote: > ---------- Forwarded message ---------- > From: "peter conneely" > Date: 24 Jul 2015 11:07 > Subject: Issue running FDK reconstruction algorithm > To: > Cc: > > Hi, > > I'm having trouble running the FDK reconstruction alogrithm on Elekta and > Varian data sets. The algorithm does work when I try the shepp-logan > example. > > When I initially ran the application I included the (') around .*.his. and > got the following lines. > [image: Inline image 1] > when I try to run with the (') removed it finds the 669 files but then the > application stops working. I have tried adding registry edits to run exe > and have tried switching of dep. Neither of these work I am not sure what > is going wrong and how to fix it. > > My system properties are as follows. > Processor: Intel Pentium CPU P6100 @ 2.00 Ghz > RAM: 3.00 GB > GPU: Intel HD Graphics > Systems type 64 Bit. > > Thanks and Regards, > Peter > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Tue Jul 28 13:38:45 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Tue, 28 Jul 2015 20:38:45 +0300 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: Hi, in ITK, the default type are described in *Utilities\MetaIO\metaTypes.h* MET_CHAR, MET_UCHAR ?,? ?? MET_SHORT, MET_USHORT, MET_INT,=20 MET_UINT,=20 MET_FLOAT,=20 MET_DOUBLE, ?and for .mha file, the header file includes information like: ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = 0 0 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 1 1 1 DimSize = 128 128 128 ElementType = MET_FLOAT ElementDataFile = LOCAL? ?And recently i just programmed to read and write .mha files. below is the code. u can just replace ElementType from ? MET_FLOAT ? to ? ? MET_SHORT ? in your application. hope this helps: #include "stdafx.h" #include #include #include #include #include #include using namespace std; int _tmain(int argc, _TCHAR* argv[]) { int m_Dims[3]; float spacing[3]; m_Dims[0]=128; m_Dims[1]=128; m_Dims[2]=128; spacing[0]=spacing[1]=spacing[2]=1.0f; ostringstream buffer, buffer1, buffer2, buf3; buffer << spacing[0]; string sp= buffer.str(); buffer1 << spacing[1]; string sp1 = buffer1.str(); buffer2 << spacing[2]; string sp2 = buffer2.str(); string ElementSpacing ="ElementSpacing= "+sp+" "+sp1+" "+sp2+"\n"; // int ss=1000; char temp[64], temp1[64],temp2[64]; string str; sprintf(temp, "%d", m_Dims[0]); sprintf(temp1, "%d", m_Dims[1]); sprintf(temp2, "%d", m_Dims[2]); string s(temp),s1(temp1),s2(temp2); string DimSize="DimSize= "+s+" "+s1+" "+s2+"\n"; string Mywritefile="ObjectType = Image\nNDims = 3\nBinaryData = True\nBinaryDataByteOrderMSB = False \nCompressedData = False \nTransformMatrix = 1 0 0 0 1 0 0 0 1 \n" ; Mywritefile+="Offset = 0 0 0 \nCenterOfRotation = 0 0 0 \nAnatomicalOrientation = RAI \n"; Mywritefile+=ElementSpacing+DimSize+"ElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; // ElementSpacing = 1 1 1 \nDimSize = 128 128 128 \nElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; int leng=Mywritefile.length(); cout< From simon.rit at creatis.insa-lyon.fr Wed Jul 29 08:53:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 29 Jul 2015 14:53:34 +0200 Subject: [Rtk-users] RTK images make the cover of Medical Physics Message-ID: See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Wed Jul 29 09:07:01 2015 From: theday79 at gmail.com (Yang K Park) Date: Wed, 29 Jul 2015 09:07:01 -0400 Subject: [Rtk-users] RTK images make the cover of Medical Physics In-Reply-To: References: Message-ID: <001801d0c9ff$76797860$636c6920$@gmail.com> Hi Simon, Thank you so much for the congrats! This is my great honor and I?d like to thank all the RTK developers and community members for their helps on this achievement! Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: Wednesday, July 29, 2015 8:54 AM To: rtk-users at public.kitware.com Subject: [Rtk-users] RTK images make the cover of Medical Physics See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Thu Jul 30 08:16:38 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Thu, 30 Jul 2015 15:16:38 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK Message-ID: Hi Simon and Chao, i am currently do some comparisons between different reconstruction methods for Shapp-Logan dataset. the commands are: rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=955.4050067 --sid=500.0 rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha --dimension 512,512 when using FDK or SART algorithm from RTK, I can got pretty good results indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 and levels as 1.04 for all results got). When running ADMMTV command below, though the geometry is as same as SART and FDK, the result got from ADMM looks weird.(pls see attached central slice of ground truth and ADMM, same contrast with other algorithm) rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 [image: ???? 1][image: ???? 2] Is it because the CG algorithm used by ADMM, or parameters setting issues here?? if it is parameters setting problem , would you help me and give a nice values for alpha and bate used here? BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already (including default value) Thanks and regards Guangming ?? *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ? -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 31 01:55:32 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 31 Jul 2015 07:55:32 +0200 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi, It looks to me that you haven't converged. I'm not the specialist of this algorithm and the specialist won't be near a computer in the coming weeks but when I try with more iterations in the data attachment term: rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 it's more satisfactory. There are rings at the top and the bottom of the cone-beam which should be reduced with more TV (greater alpha, see doc here ) or with a finer spacing (see this publication ). Simon On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang wrote: > Hi Simon and Chao, > > i am currently do some comparisons between different reconstruction > methods for Shapp-Logan dataset. > > the commands are: > > rtksimulatedgeometry -n 360 --arc -360 -o > geo.xml --sdd=955.4050067 --sid=500.0 > > rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha > --dimension 512,512 > > > > when using FDK or SART algorithm from RTK, I can got pretty good results > indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 > and levels as 1.04 for all results got). When running ADMMTV command below, > though the geometry is as same as SART and FDK, the result got from ADMM > looks weird.(pls see attached central slice of ground truth and ADMM, same > contrast with other algorithm) > > rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o > SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 > --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 > > [image: ???? 1][image: ???? 2] > > Is it because the CG algorithm used by ADMM, or parameters setting issues > here?? if it is parameters setting problem , would you help me and give a > nice values for alpha and bate used here? > > BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already > (including default value) > > Thanks and regards > > Guangming > > > ?? > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > ? > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Fri Jul 31 09:46:41 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 31 Jul 2015 16:46:41 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi simon, i see, thanks for the help and explanation. after following your advice, it works fine now. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-31 8:55 GMT+03:00 Simon Rit : > Hi, > It looks to me that you haven't converged. I'm not the specialist of this > algorithm and the specialist won't be near a computer in the coming weeks > but when I try with more iterations in the data attachment term: > rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml > --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 > it's more satisfactory. There are rings at the top and the bottom of the > cone-beam which should be reduced with more TV (greater alpha, see doc > here > ) > or with a finer spacing (see this publication > ). > Simon > > On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon and Chao, >> >> i am currently do some comparisons between different reconstruction >> methods for Shapp-Logan dataset. >> >> the commands are: >> >> rtksimulatedgeometry -n 360 --arc -360 -o >> geo.xml --sdd=955.4050067 --sid=500.0 >> >> rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha >> --dimension 512,512 >> >> >> >> when using FDK or SART algorithm from RTK, I can got pretty good results >> indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 >> and levels as 1.04 for all results got). When running ADMMTV command below, >> though the geometry is as same as SART and FDK, the result got from ADMM >> looks weird.(pls see attached central slice of ground truth and ADMM, same >> contrast with other algorithm) >> >> rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o >> SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 >> --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 >> >> [image: ???? 1][image: ???? 2] >> >> Is it because the CG algorithm used by ADMM, or parameters setting issues >> here?? if it is parameters setting problem , would you help me and give a >> nice values for alpha and bate used here? >> >> BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already >> (including default value) >> >> Thanks and regards >> >> Guangming >> >> >> ?? >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> ? >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 1 08:45:35 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 1 Jul 2015 14:45:35 +0200 Subject: [Rtk-users] Release of RTK v1.1.0 Message-ID: Dear RTK users, RTK v1.1.0 has been released today, about 14 months after RTK v1.0.0. The main features that have been developed since the previous release are: - SimpleRTK to run RTK filters (even the CUDA ones) from python scripts, C# code, and more - new projection pre-processing options (i0 calculation, scatter correction, water pre-correction) - extraction of the respiratory phase from cone-beam projections - linear programming for field-of-view computation based on a third party software, lp solve 5.5 - management of off-center detector in iterative methods - new iterative 3D and 4D reconstruction methods with Daubechies wavelets regularization - new iterative 4D reconstruction method with motion-aware regularization - reduction of memory footprint, especially GPU memory - many new CUDA filters - more robust (many bugs and memory leaks fixed) - use of MathJax to display formulas in the documentation, e.g., here . Many thanks to the increasing number of contributors, in alphabetical order: Ben Champion, Chao Wu, Cyril Mory, I Putu Susila, Julien Jomier, Marc Vila, Mathieu Dupont, Matt Clarkson, Peter Keuschnigg, S?bastien Brousmiche, Simon Rit, Tristan Coulange, Yang K Park. We don't focus on releases since we have a public github repository that we try to keep stable, I still recommend the use of the master HEAD over releases to enjoy the new RTK developments before their release. We still have a few on-going projects for which we will use and enhance RTK. Simon (for the RTK consortium) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 1 15:39:14 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 1 Jul 2015 21:39:14 +0200 Subject: [Rtk-users] loading projection images for sart Message-ID: Hello, I got compiled the ITK and RTK with help of cmake. I also had a look at the examples coming with RTK. I want to run a simple SART and got projection images in the format PNG and BMP. So I create an instance of the ThreeDcircularProjectionGeometry, SARTConeBeamReconstructionFilter and add the geometric projection data. rtk::ThreeDCircularProjectionGeometry::Pointer geometry; geometry = rtk::ThreeDCircularProjectionGeometry::New(); geometry->AddProjection(??) rtk::SARTConeBeamReconstructionFilter::Pointer sart = rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); How to add a stack of images to the SART reconstruction, i.e. std::vector images ? I got xray projections in png format. There is a method in the SART class called SetInput. But according tot he examples it is used to set a volume. Does anybody alread wrote a small piece of code that loads some images from the disk and put them into the SART reconstruction ? Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 2 12:19:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 2 Jul 2015 18:19:36 +0200 Subject: [Rtk-users] loading projection images for sart In-Reply-To: References: Message-ID: Hi, The stack of 2D images is passed via a 3D image. Look at the rtksart application for example. A way to read this from a set of file names is to use itk::ImageSeriesReader as done in rtk::ProjectionsReader. You should be able to understand how it works by looking at the existing RTK applications in the applications subfolders. Simon On Wed, Jul 1, 2015 at 9:39 PM, Robert Callie? wrote: > Hello, > > I got compiled the ITK and RTK with help of cmake. I also had a look > > at the examples coming with RTK. I want to run a simple SART and > > got projection images in the format PNG and BMP. > > > > So I create an instance of the ThreeDcircularProjectionGeometry, > SARTConeBeamReconstructionFilter > > and add the geometric projection data. > > > > rtk::ThreeDCircularProjectionGeometry::Pointer geometry; > > geometry = rtk::ThreeDCircularProjectionGeometry::New(); > > geometry->AddProjection(??) > > > > rtk::SARTConeBeamReconstructionFilter::Pointer sart = > rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); > > > > How to add a stack of images to the SART reconstruction, i.e. > std::vector images ? > > I got xray projections in png format. > > > > There is a method in the SART class called SetInput. But according tot he > examples it is used to set a volume. > > > > Does anybody alread wrote a small piece of code that loads some images > from the disk and put them into the SART reconstruction ? > > > > Regards, > > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Fri Jul 3 16:28:11 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 3 Jul 2015 23:28:11 +0300 Subject: [Rtk-users] Remote Control Issue in new RTK version Message-ID: Dear RTK community, There is some bug in RTK 1.1 version. That?s : When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 but i did not use Cuda at all.. What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. So i think it is some problem caused by itk ?? can we fix this issue?? Thanks for help in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Sat Jul 4 10:12:03 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Sat, 4 Jul 2015 17:12:03 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. Thanks for the help, Chao. *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ---------- Forwarded message ---------- From: Chao Wu Date: 2015-07-04 0:04 GMT+03:00 Subject: Re: Remote Control Issue To: Guangming Zang Cc: rtk-users-request at public.kitware.com, Simon Rit < simon.rit at creatis.insa-lyon.fr> Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. Regards, Chao Sent from Samsung Galaxy Note 3 2015?7?3? 10:26 PM? "Guangming Zang" ??? > Dear RTK community, > > There is some bug in RTK 1.1 version. That?s : > > When i run commands In 1.1 version with my computer in the lab, RTK works > fine, but when i use my laptop at home to remote control the computer in > the lab, it does not work. i.e., no matter the command are (rtkfdk, > ADMM,SART ?), an error is always shown: > > ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 > @ unknown : Cuda Error #3 > > but i did not use Cuda at all.. > > What?s more, when i run the 1.0 version RTK , it works well and no bug in > remoter control mode. > > So i think it is some problem caused by itk ?? can we fix this issue?? > > Thanks for help in advance > > > Regards > > Guangming > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Sat Jul 4 10:19:32 2015 From: ghostcz at hotmail.com (louie L) Date: Sat, 4 Jul 2015 16:19:32 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: I think because in most cases people use their graphics in TCC mode for scientific computations or don't use gpu at all where the rtk_use_cuda is false. Cheers, Louie Sent from my iOS > On 04 Jul 2015, at 16:12, Guangming Zang wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > > 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> Dear RTK community, >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> >> Regards >> >> Guangming >> >> Guangming Zang (Alex) >> King Abdullah University of Science and Technology(KAUST) >> University of Chinese Academy of Sciences(UCAS) >> >> >> >> >> This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > > > This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Mon Jul 6 05:32:18 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 6 Jul 2015 11:32:18 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Hi Guangming and all, Thanks for reporting this change of behavior. My first answer is that what you find simple is not so simple... but you're right, v1.0.0 allowed to compile RTK with CUDA and to run it without a CUDA device. After a bit of trakcing, I found that the change of behavior has been introduced with this patch so you can blame me. It has now fixed this issue with this patch , which seems to work on my laptop, I hope it does on your computer as well. I can't help you with the fact that you can't run CUDA software with remote control. Simon On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > I think because in most cases people use their graphics in TCC mode for > scientific computations or don't use gpu at all where the rtk_use_cuda is > false. > Cheers, > > Louie > > Sent from my iOS > > On 04 Jul 2015, at 16:12, Guangming Zang > wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes > to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is > defined, then if CUDA device is not available this error will occur. When > using MS remote desktop, graphical card and driver are bypassed unless it > is Tesla cards working in TCC mode. You can either compile exes without > CUDA for remote desktop, or try other graphic-based remote desktop software > like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > 2015?7?3? 10:26 PM? "Guangming Zang" ??? > >> Dear RTK community, >> >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works >> fine, but when i use my laptop at home to remote control the computer in >> the lab, it does not work. i.e., no matter the command are (rtkfdk, >> ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >> @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in >> remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> Regards >> >> Guangming >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 6 06:19:10 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 6 Jul 2015 13:19:10 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Thanks all for your help,Simon. I will try it again when i am at home :) As for using Cuda in remote control, i can handle it:just like what Chao said, change lab computer to TCC. What confused me at the beginning is that a cuda error shown while i did not call cuda at all, and thanks for fixing it. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-06 12:32 GMT+03:00 Simon Rit : > Hi Guangming and all, > Thanks for reporting this change of behavior. My first answer is that what > you find simple is not so simple... but you're right, v1.0.0 allowed to > compile RTK with CUDA and to run it without a CUDA device. After a bit of > trakcing, I found that the change of behavior has been introduced with this > patch > > so you can blame me. It has now fixed this issue with this patch > , > which seems to work on my laptop, I hope it does on your computer as well. > I can't help you with the fact that you can't run CUDA software with > remote control. > Simon > > On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > >> I think because in most cases people use their graphics in TCC mode for >> scientific computations or don't use gpu at all where the rtk_use_cuda is >> false. >> Cheers, >> >> Louie >> >> Sent from my iOS >> >> On 04 Jul 2015, at 16:12, Guangming Zang >> wrote: >> >> Ok, i see. Though i still do not understand why in new version rtk >> changes to call cudaimages, not keeping it simple like before. >> Thanks for the help, Chao. >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ---------- Forwarded message ---------- >> From: Chao Wu >> Date: 2015-07-04 0:04 GMT+03:00 >> Subject: Re: Remote Control Issue >> To: Guangming Zang >> Cc: rtk-users-request at public.kitware.com, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> >> >> Now in many exes cudaimage is the default image type if rtk_use_cuda is >> defined, then if CUDA device is not available this error will occur. When >> using MS remote desktop, graphical card and driver are bypassed unless it >> is Tesla cards working in TCC mode. You can either compile exes without >> CUDA for remote desktop, or try other graphic-based remote desktop software >> like vnc or teamviewer. >> >> Regards, Chao >> Sent from Samsung Galaxy Note 3 >> 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> >>> Dear RTK community, >>> >>> There is some bug in RTK 1.1 version. That?s : >>> >>> When i run commands In 1.1 version with my computer in the lab, RTK >>> works fine, but when i use my laptop at home to remote control the >>> computer in the lab, it does not work. i.e., no matter the command are >>> (rtkfdk, ADMM,SART ?), an error is always shown: >>> >>> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >>> @ unknown : Cuda Error #3 >>> >>> but i did not use Cuda at all.. >>> >>> What?s more, when i run the 1.0 version RTK , it works well and no bug >>> in remoter control mode. >>> >>> So i think it is some problem caused by itk ?? can we fix this issue?? >>> >>> Thanks for help in advance >>> >>> >>> Regards >>> >>> Guangming >>> *Guangming Zang (Alex)* >>> *King Abdullah University of Science and Technology(KAUST)* >>> *University of Chinese Academy of Sciences(UCAS)* >>> >>> >>> >>> >>> ------------------------------ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete >>> this message from your computer system. Any unauthorized use or >>> distribution is prohibited. Please consider the environment before printing >>> this email. >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Wed Jul 8 22:26:29 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Wed, 8 Jul 2015 19:26:29 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question Message-ID: Hi, I have a question from you about the CT reconstruction, I would really appreciate if you can help me with this. I have the geometry as described in following and I am trying to run the rtkfdk code from RTK. % parameters % % % % % % % param.nx = 500; % number of voxels param.ny = 500; param.nz = 500; param.sx = 5000; % mm (real size) param.sy = 5000; % mm param.sz = 5000; % mm %The real detector panel pixel density (number of pixels) param.nu = 36; % number of pixels param.nv = 100; % Detector setting (real size) param.su = 7200; % mm (real size) param.sv = 9200; % mm % X-ray source and detector setting param.DSD = 32900; % Distance source to detector param.DSO = 27400; % X-ray source to object axis distance % angle setting param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) param.dang = 5; % angular step size (deg) param.deg = 0:param.dang:360-1; % you can change param.deg = param.deg*param.dir; param.nProj = length(param.deg); param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than 360 deg -> param.parker=1 param.filter='ram-lak'; % high pass filter param.dx = param.sx/param.nx; % single voxel size param.dy = param.sy/param.ny; param.dz = param.sz/param.nz; param.du = param.su/param.nu; param.dv = param.sv/param.nv; param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) % Geometry calculation % % % param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : 360). But I got confused how to set the geometry parameters in RTK I followed the rtkfdk tutorial but I can?t get any result using this method I did the following: 1- Create geometry.xml using these parameters: nproj = 72 ; first_angle = 0 ; arc = 360 ; sid = 27400 ; sdd = 32900 ; proj_iso_x = 0; proj_iso_y = 0; out_angle = 0 ; in_angle = 0 ; source_x = 0; source_y = 0 ; 2- Create my own mha file (WriteMhaFile.m) from my projection array (36*100*72) using a matlab code with following properties: Voxel size = [0.1 0.1 0.1] Offset = [1 1 1] 3- Then run the: rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 --dimension 500 Could you please tell me if I am setting the geometry correctly? Also, is there any other way to create my own mha file? Thank you in advance and looking forward to hear back from you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 02:23:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 08:23:36 +0200 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Hi, We can try to help but we need to understand your geometry... Where does it come from by the way? If I understand your geometry correctly, I would say : - sid, sdd, nproj, arc are correct, - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 and you have 36x100 pixels, then the pixel size is [200,92,1] (last dimension is not used so anything). For the volume, if your volume is 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and not 0.1. - offset of projections is probably wrong. If you want to have a centered projections, you'll need something like (-3500, -554, 0). You can set is to 0 and put those values in proj_iso_x and proj_iso_y. Regarding mha file, you can write mha files in many ways, using SimpleRTK, matlab or writing an ITK code. Good luck! Simon On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah wrote: > Hi, > > I have a question from you about the CT reconstruction, I would really > appreciate if you can help me with this. > > I have the geometry as described in following and I am trying to run the > rtkfdk code from RTK. > > > % parameters % % % % % % % > > param.nx = 500; % number of voxels > param.ny = 500; > param.nz = 500; > > > param.sx = 5000; % mm (real size) > param.sy = 5000; % mm > param.sz = 5000; % mm > > > %The real detector panel pixel density (number of pixels) > param.nu = 36; % number of pixels > param.nv = 100; > > % Detector setting (real size) > param.su = 7200; % mm (real size) > param.sv = 9200; % mm > > > % X-ray source and detector setting > param.DSD = 32900; % Distance source to detector > param.DSO = 27400; % X-ray source to object axis distance > > > % angle setting > param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) > param.dang = 5; % angular step size (deg) > param.deg = 0:param.dang:360-1; % you can change > param.deg = param.deg*param.dir; > param.nProj = length(param.deg); > > param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than > 360 deg -> param.parker=1 > > param.filter='ram-lak'; % high pass filter > > > param.dx = param.sx/param.nx; % single voxel size > param.dy = param.sy/param.ny; > param.dz = param.sz/param.nz; > param.du = param.su/param.nu; > param.dv = param.sv/param.nv; > param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) > > > % Geometry calculation % % % > param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; > param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; > param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; > param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; > param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; > > > > So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : > 360). > But I got confused how to set the geometry parameters in RTK > I followed the rtkfdk tutorial but I can?t get any result using this method > > I did the following: > > 1- Create geometry.xml using these parameters: > > nproj = 72 ; > first_angle = 0 ; > arc = 360 ; > sid = 27400 ; > sdd = 32900 ; > proj_iso_x = 0; > proj_iso_y = 0; > out_angle = 0 ; > in_angle = 0 ; > source_x = 0; > source_y = 0 ; > > 2- Create my own mha file (WriteMhaFile.m) from my projection array > (36*100*72) using a matlab code with following properties: > Voxel size = [0.1 0.1 0.1] > Offset = [1 1 1] > > > 3- Then run the: > rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 > --dimension 500 > > > Could you please tell me if I am setting the geometry correctly? > Also, is there any other way to create my own mha file? > > Thank you in advance and looking forward to hear back from you. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 12:12:01 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 18:12:01 +0200 Subject: [Rtk-users] RTK training In-Reply-To: <55816290.1010807@uclouvain.be> References: <55816290.1010807@uclouvain.be> Message-ID: Dear RTK users, We have finally set a date for the RTK training, Wednesday, Nov 18 2015 in Lyon (France). The training will be organised by Kitware, go to this page for the registration: http://formations.kitware.fr/browse/116 We will do both user and developer sessions during the training. Since it's the first time that we do the training, we will tailor the balance between the two according to the wishes of registered people. The rest of the information should be available on the website but let us know if you need more information, we are still building the webpage and we'll be happy to improve it. We're looking forward to this new training and we'll do our best to meet your expectations, Simon On Wed, Jun 17, 2015 at 2:05 PM, Cyril Mory wrote: > Dear RTK users, > > The first RTK training is being planned at this very moment. It should > take place in November in Lyon, and be hosted by Kitware. The exact date > has not yet been decided, but will be available soon. > > We need your help to decide what to focus this training on. The choice is > mainly between two options: > - if most trainees want to learn how to use RTK, then we will focus on the > command-line tools and on python + Simple RTK > - if most trainees want to learn how to develop within RTK, modify and > enrich it, then we will focus on software architecture, detailed filter > description, ITK pipeline management, CUDA filters, etc... > > Please let us know which of these choices would best suit your needs. > > Looking forward, > Cyril > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Thu Jul 9 17:59:05 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Thu, 9 Jul 2015 14:59:05 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Simon, Thank you. I think now I understand how the whole geometry is defined in RTK. The projection is based on one experiment I am doing using different simulation techniques. Again thank you for your help. Best, Ali On Wed, Jul 8, 2015 at 11:23 PM, Simon Rit wrote: > Hi, > We can try to help but we need to understand your geometry... Where does > it come from by the way? If I understand your geometry correctly, I would > say : > - sid, sdd, nproj, arc are correct, > - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 > and you have 36x100 pixels, then the pixel size is [200,92,1] (last > dimension is not used so anything). For the volume, if your volume is > 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and > not 0.1. > - offset of projections is probably wrong. If you want to have a centered > projections, you'll need something like (-3500, -554, 0). You can set is to > 0 and put those values in proj_iso_x and proj_iso_y. > Regarding mha file, you can write mha files in many ways, using SimpleRTK, > matlab or writing an ITK code. > Good luck! > Simon > > On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah > wrote: > >> Hi, >> >> I have a question from you about the CT reconstruction, I would really >> appreciate if you can help me with this. >> >> I have the geometry as described in following and I am trying to run the >> rtkfdk code from RTK. >> >> >> % parameters % % % % % % % >> >> param.nx = 500; % number of voxels >> param.ny = 500; >> param.nz = 500; >> >> >> param.sx = 5000; % mm (real size) >> param.sy = 5000; % mm >> param.sz = 5000; % mm >> >> >> %The real detector panel pixel density (number of pixels) >> param.nu = 36; % number of pixels >> param.nv = 100; >> >> % Detector setting (real size) >> param.su = 7200; % mm (real size) >> param.sv = 9200; % mm >> >> >> % X-ray source and detector setting >> param.DSD = 32900; % Distance source to detector >> param.DSO = 27400; % X-ray source to object axis distance >> >> >> % angle setting >> param.dir = +1; % gantry rotating direction (clock wise/ counter >> clockwise) >> param.dang = 5; % angular step size (deg) >> param.deg = 0:param.dang:360-1; % you can change >> param.deg = param.deg*param.dir; >> param.nProj = length(param.deg); >> >> param.parker = 0; % data with 360 deg -> param.parker = 0 , data less >> than >> 360 deg -> param.parker=1 >> >> param.filter='ram-lak'; % high pass filter >> >> >> param.dx = param.sx/param.nx; % single voxel size >> param.dy = param.sy/param.ny; >> param.dz = param.sz/param.nz; >> param.du = param.su/param.nu; >> param.dv = param.sv/param.nv; >> param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) >> >> >> % Geometry calculation % % % >> param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; >> param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; >> param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; >> param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; >> param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; >> >> >> >> So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : >> 360). >> But I got confused how to set the geometry parameters in RTK >> I followed the rtkfdk tutorial but I can?t get any result using this >> method >> >> I did the following: >> >> 1- Create geometry.xml using these parameters: >> >> nproj = 72 ; >> first_angle = 0 ; >> arc = 360 ; >> sid = 27400 ; >> sdd = 32900 ; >> proj_iso_x = 0; >> proj_iso_y = 0; >> out_angle = 0 ; >> in_angle = 0 ; >> source_x = 0; >> source_y = 0 ; >> >> 2- Create my own mha file (WriteMhaFile.m) from my projection array >> (36*100*72) using a matlab code with following properties: >> Voxel size = [0.1 0.1 0.1] >> Offset = [1 1 1] >> >> >> 3- Then run the: >> rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 >> --dimension 500 >> >> >> Could you please tell me if I am setting the geometry correctly? >> Also, is there any other way to create my own mha file? >> >> Thank you in advance and looking forward to hear back from you. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hougeamm at 126.com Thu Jul 9 18:35:09 2015 From: hougeamm at 126.com (=?GBK?B?uu645w==?=) Date: Fri, 10 Jul 2015 06:35:09 +0800 (CST) Subject: [Rtk-users] problems for elekta data Message-ID: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Hello Everyone, Why the Elekta data prompt projection doesn't match when using rtkfdk? e.g., 377 vs 389? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 10 01:43:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Jul 2015 07:43:15 +0200 Subject: [Rtk-users] problems for elekta data In-Reply-To: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> References: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Message-ID: Hi, The message that you have on the command line is the result of the files that have been found in the path (--path option) with the regular expression (--regexp option). If it found more projections than what you have, then you probably need to improve your reg exp, e.g., by a $ after the file extension to specify that the file name must end with it. Simon On Fri, Jul 10, 2015 at 12:35 AM, ?? wrote: > Hello Everyone, > Why the Elekta data prompt projection doesn't match when using > rtkfdk? e.g., 377 vs 389? > Thanks! > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From guangming.zang at kaust.edu.sa Mon Jul 13 02:48:15 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 09:48:15 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset Message-ID: Hi RTK comunity, Besides the prameters like SID and SDD , from the geometry(.xteck) file got from my scanner, i also have object (volume) information like this: VoxelsX=179 VoxelsY=163 VoxelsZ=127 VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 The X,Y and Z axis are identical to RTK's geometry , So i was really wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i can show all other parameters like: rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, but it still a slight different visualization result from what we got from scanner software. So would you help me??? File attached is the geometry file in case. Thanks in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VCC_Dome_0622.xtekct Type: application/octet-stream Size: 1813 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 13 04:38:00 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 11:38:00 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: problem fixed. because the scanned object is symmetric and i did not notice that i should -Z axis in scanner to map Z in RTK thanks. but, i still do not know in RTK how to show the OffsetZ.. :( Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-13 9:48 GMT+03:00 Guangming Zang : > Hi RTK comunity, > Besides the prameters like SID and SDD , from the geometry(.xteck) file > got from my scanner, i also have object (volume) information like this: > VoxelsX=179 VoxelsY=163 VoxelsZ=127 > VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 > OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 > The X,Y and Z axis are identical to RTK's geometry , So i was really > wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i > can show all other parameters like: > > rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing > 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 > --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 > > Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, > but it still a slight different visualization result from what we got from > scanner software. > So would you help me??? > > > File attached is the geometry file in case. Thanks in advance > Regards > Guangming > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Mon Jul 13 13:21:44 2015 From: robert.calliess at gmx.de (=?utf-8?Q?Robert_Callie=C3=9F?=) Date: Mon, 13 Jul 2015 19:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? Message-ID: Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 13 13:42:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 13 Jul 2015 19:42:43 +0200 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: Hi, OffsetZ probably refers to the coordinate of the volume in the room coordinate which we don't use in RTK. Everything is set in the tomography coordinate during reconstruction. You can always change the coordinates of your volume after if you want to put it in some other coordinate system. Simon On Mon, Jul 13, 2015 at 10:38 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > problem fixed. > because the scanned object is symmetric and i did not notice that i > should -Z axis in scanner to map Z in RTK > thanks. > but, i still do not know in RTK how to show the OffsetZ.. :( > > Guangming > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-13 9:48 GMT+03:00 Guangming Zang : > >> Hi RTK comunity, >> Besides the prameters like SID and SDD , from the geometry(.xteck) file >> got from my scanner, i also have object (volume) information like this: >> VoxelsX=179 VoxelsY=163 VoxelsZ=127 >> VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 >> OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 >> The X,Y and Z axis are identical to RTK's geometry , So i was really >> wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i >> can show all other parameters like: >> >> rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing >> 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 >> --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 >> >> Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, >> but it still a slight different visualization result from what we got from >> scanner software. >> So would you help me??? >> >> >> File attached is the geometry file in case. Thanks in advance >> Regards >> Guangming >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Tue Jul 14 03:01:14 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 14 Jul 2015 09:01:14 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 01:32:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 07:32:43 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: > Hell RTK User, > I think there is a mistake in the described approach. > Point a) and f) meight be wrong. As far as I Understand, all Pixels > that are covered by the projected voxel vertices are update > with weight * voxel_value. Where weight is the overlaping area > of the projected voxel vertices polygon on the detector plane and the > underlying detector pixels. > > Any opinions before implementing it ? > > regards, > Robert > > *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr > *Von:* "Robert Callie?" > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what > they called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can > be rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector > cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value > to back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Wed Jul 15 08:07:20 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Wed, 15 Jul 2015 14:07:20 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 08:21:44 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 14:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: > Hello Simon, > thank you for your answer. I guess you linked the wrong article. But I > know what article you are talking about. > It's the articel from 2009 with a piece of code (MapSeq). > > >> I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > detector pixels that are totally covered by the overlap are weight with > "1" and if the overlap is between detector pixels > the pixels are weighted. Do you have a copy of the original article from > the De Man and Basu ? > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > Do you agree with that or did I miss something ? > > best regards, > Robert > > *Gesendet:* Mittwoch, 15. Juli 2015 um 07:32 Uhr > *Von:* "Simon Rit" > *An:* "Robert Callie?" > *Cc:* "rtk-users at public.kitware.com" > *Betreff:* Re: [Rtk-users] distance driven projector, a simplified > approach ? > Hi, > Indeed, I have published an article > on this > projector describing my implementation, you could use it if you want, > there's even a piece of code in it although I'm pretty sure it's not the > best implementation. This implementation dealt with the case where the > rotation axis is parallel to the detector. As far as I can remember, the > original article of De Man and Basu is also quite clear. > I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > Simon > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: >> >> Hell RTK User, >> I think there is a mistake in the described approach. >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> that are covered by the projected voxel vertices are update >> with weight * voxel_value. Where weight is the overlaping area >> of the projected voxel vertices polygon on the detector plane and the >> underlying detector pixels. >> >> Any opinions before implementing it ? >> >> regards, >> Robert >> >> *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr >> *Von:* "Robert Callie?" >> *An:* rtk-users at public.kitware.com >> *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel boundaries >> onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel?s contribution (weight) is the area of this overlapping. I >> read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is what >> they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone beam >> geometry. We can >> >> either rotate the detector and source around the object or the object can >> be rotated >> >> and the detector and source are fixed. I think Simon also wrote a paper >> about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source position, >> object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector >> cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the >> corresponding detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a ? e). Value >> to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I?m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of voxel >> boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 15 15:14:13 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 15 Jul 2015 21:14:13 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hello Simon, thank you for the articles. May I ask you what do you mean by ?voxel correction factor? in the code you provided in your article ? float f) // Voxel correction factor Thank you and best regards, Robert Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit Gesendet: Mittwoch, 15. Juli 2015 14:22 An: Robert Callie? Cc: rtk-users at public.kitware.com Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: Hello Simon, thank you for your answer. I guess you linked the wrong article. But I know what article you are talking about. It's the articel from 2009 with a piece of code (MapSeq). >> I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. You're right. It is that all pixels that are related to the overlap projected voxel overlap have to taken into account. So detector pixels that are totally covered by the overlap are weight with "1" and if the overlap is between detector pixels the pixels are weighted. Do you have a copy of the original article from the De Man and Basu ? I have the opinion that it's not neccessary to project the detector pixel boundaries and voxel boundaries onto a common plane if we use a flat panel detector. Instead we could project the voxel boundaries onto the detector plane directly. Do you agree with that or did I miss something ? best regards, Robert Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr Von: "Simon Rit" An: "Robert Callie?" Cc: "rtk-users at public.kitware.com" Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: Hell RTK User, I think there is a mistake in the described approach. Point a) and f) meight be wrong. As far as I Understand, all Pixels that are covered by the projected voxel vertices are update with weight * voxel_value. Where weight is the overlaping area of the projected voxel vertices polygon on the detector plane and the underlying detector pixels. Any opinions before implementing it ? regards, Robert Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr Von: "Robert Callie?" An: rtk-users at public.kitware.com Betreff: [Rtk-users] distance driven projector, a simplified approach ? Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 15:45:23 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 21:45:23 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. Simon On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie? wrote: > Hello Simon, > > thank you for the articles. May I ask you what do you mean by > > ?voxel correction factor? in the code you provided in your article ? > > float f) // Voxel correction factor > > > > Thank you and best regards, > > Robert > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Mittwoch, 15. Juli 2015 14:22 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified > approach ? > > > > Sorry, this link indeed with the MapSeg function. And yes, I was projecting > it to the detector plane directly. > > Simon > > > > On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" > wrote: > > Hello Simon, > > thank you for your answer. I guess you linked the wrong article. But I know > what article you are talking about. > > It's the articel from 2009 with a piece of code (MapSeq). > > > >>> I don't have time to go into the details of what you have proposed but, >>> from a glance, the first step seems useless. > > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > > detector pixels that are totally covered by the overlap are weight with "1" > and if the overlap is between detector pixels > > the pixels are weighted. Do you have a copy of the original article from the > De Man and Basu ? > > > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > > Do you agree with that or did I miss something ? > > > > best regards, > > Robert > > > > Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr > Von: "Simon Rit" > An: "Robert Callie?" > Cc: "rtk-users at public.kitware.com" > Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? > > Hi, > > Indeed, I have published an article on this projector describing my > implementation, you could use it if you want, there's even a piece of code > in it although I'm pretty sure it's not the best implementation. This > implementation dealt with the case where the rotation axis is parallel to > the detector. As far as I can remember, the original article of De Man and > Basu is also quite clear. > > I don't have time to go into the details of what you have proposed but, from > a glance, the first step seems useless. > > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > > Simon > > > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: > > Hell RTK User, > > I think there is a mistake in the described approach. > > Point a) and f) meight be wrong. As far as I Understand, all Pixels > > that are covered by the projected voxel vertices are update > > with weight * voxel_value. Where weight is the overlaping area > > of the projected voxel vertices polygon on the detector plane and the > > underlying detector pixels. > > > > Any opinions before implementing it ? > > > > regards, > > Robert > > > > Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr > Von: "Robert Callie?" > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what they > called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can be > rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value to > back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From simon.rit at creatis.insa-lyon.fr Fri Jul 17 02:22:16 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 17 Jul 2015 08:22:16 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Please keep on using the mailing list, I don't see a good reason to keep this conversation private. I won't have time to go back into these details. From a quick look, I think this is correct although I would have simply said that D is the center of the detector pixel. Simon On Thu, Jul 16, 2015 at 10:24 PM, Robert Callie? wrote: > Hello, > Sorry that I have to ask again. But I want to clear this before I start. > I want to ask about the cosine weight DeMan mentioned in his article. > He wrote: > > " > (1) The intersection length of the line of interest with the image slab S, the latter being > defined as the slab parallel to the xz plane and containing voxel V. This intersection length > is given by t/(cos ? cos ? ), where t is the isotropic voxel size, and ? and ? are the in- and > out-of-plane angles of the line of interest with the y-axis. > " > > So what he actually does, is that he calculates the intersection length of the slab s (that contains the voxel) with > a ray going from xray source to the middle of two adjacent detector cell boundaries. Let's refare to Figure 5. > So the length to be considered is calculated as the intersection length of slab S with the ray going from > the source ( the black dot in figure 5) to the mid-point of D, that means the center of the two projected adjacent > detector pixel boundaries. > > > Sorry for asking again but I want it to make it clear to me. > > Best regards, > Robert > > > -----Urspr?ngliche Nachricht----- > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit > Gesendet: Mittwoch, 15. Juli 2015 21:45 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? > > "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" > So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. > Simon > > On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie wrote: >> Hello Simon, >> >> thank you for the articles. May I ask you what do you mean by >> >> voxel correction factor in the code you provided in your article ? >> >> float f) // Voxel correction factor >> >> >> >> Thank you and best regards, >> >> Robert >> >> >> >> Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von >> Simon Rit >> Gesendet: Mittwoch, 15. Juli 2015 14:22 >> An: Robert Callie >> Cc: rtk-users at public.kitware.com >> Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified >> approach ? >> >> >> >> Sorry, this link indeed with the MapSeg function. And yes, I was >> projecting it to the detector plane directly. >> >> Simon >> >> >> >> On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie " >> >> wrote: >> >> Hello Simon, >> >> thank you for your answer. I guess you linked the wrong article. But I >> know what article you are talking about. >> >> It's the articel from 2009 with a piece of code (MapSeq). >> >> >> >>>> I don't have time to go into the details of what you have proposed >>>> but, from a glance, the first step seems useless. >> >> You're right. It is that all pixels that are related to the overlap >> projected voxel overlap have to taken into account. So >> >> detector pixels that are totally covered by the overlap are weight with "1" >> and if the overlap is between detector pixels >> >> the pixels are weighted. Do you have a copy of the original article >> from the De Man and Basu ? >> >> >> >> I have the opinion that it's not neccessary to project the detector >> pixel boundaries and voxel boundaries onto a common plane >> >> if we use a flat panel detector. Instead we could project the voxel >> boundaries onto the detector plane directly. >> >> Do you agree with that or did I miss something ? >> >> >> >> best regards, >> >> Robert >> >> >> >> Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr >> Von: "Simon Rit" >> An: "Robert Callie " >> Cc: "rtk-users at public.kitware.com" >> Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hi, >> >> Indeed, I have published an article on this projector describing my >> implementation, you could use it if you want, there's even a piece of >> code in it although I'm pretty sure it's not the best implementation. >> This implementation dealt with the case where the rotation axis is >> parallel to the detector. As far as I can remember, the original >> article of De Man and Basu is also quite clear. >> >> I don't have time to go into the details of what you have proposed >> but, from a glance, the first step seems useless. >> >> Good luck in your implementation and don't hesitate to send it to us >> when you have a working RTK implementation, >> >> Simon >> >> >> >> On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie " >> >> wrote: >> >> Hell RTK User, >> >> I think there is a mistake in the described approach. >> >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> >> that are covered by the projected voxel vertices are update >> >> with weight * voxel_value. Where weight is the overlaping area >> >> of the projected voxel vertices polygon on the detector plane and the >> >> underlying detector pixels. >> >> >> >> Any opinions before implementing it ? >> >> >> >> regards, >> >> Robert >> >> >> >> Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr >> Von: "Robert Callie " >> An: rtk-users at public.kitware.com >> Betreff: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel >> boundaries onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel s contribution (weight) is the area of this >> overlapping. I read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is >> what they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone >> beam geometry. We can >> >> either rotate the detector and source around the object or the object >> can be rotated >> >> and the detector and source are fixed. I think Simon also wrote a >> paper about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source >> position, object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the corresponding >> detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a e). >> Value to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of >> voxel boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > From guangming.zang at kaust.edu.sa Sun Jul 26 18:30:42 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 01:30:42 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed Message-ID: Hi RTK community, i am using SART algorithm to reconstruct an object. But in this new RTK version, the time recording seems a little weird: the total time is 1219.12s , but adding the time cost in different stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward projection part. BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, both multi-threading i think. Can anyone tell me what's going on? Thanks Regards Guangming [image: ???? 1] *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 01:59:11 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 07:59:11 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Guangming, It's not surprising to me that the backprojection is faster than the forward projection, that's what I expect. If the total time is longer, that's probably that some individual steps are not included in the total time. Can you try to add reader->Update(); before the line itk::TimeProbe totalTimeProbe; in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? Simon On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > Hi RTK community, > i am using SART algorithm to reconstruct an object. > But in this new RTK version, the time recording seems a little weird: > the total time is 1219.12s , but adding the time cost in different stages > is not 1291.12 s. especially for "backprojection" part, only 16.6051s to > reconstruct a 128^3 volume ?? even shorter than forward projection part. > BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, > both multi-threading i think. > Can anyone tell me what's going on? > Thanks > Regards > Guangming > > [image: ???? 1] > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 27 04:41:58 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 11:41:58 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, Thanks for your reply. would you pls help and explain why backprojection is expected to take shorter time than forward projection?? because i was thinking if no caching step, the backprojection should take much longer time than sart algorithm. yes, i run rtksart for 2 times once.it took 12xxs, similar to the time consumed of 3 times's sart, which much slower than my own application. BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 shapp-logan projections(512*512 resolution each) rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 and i will try reader->Update() like what you said. Thanks Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 8:59 GMT+03:00 Simon Rit : > Hi Guangming, > It's not surprising to me that the backprojection is faster than the > forward projection, that's what I expect. If the total time is longer, > that's probably that some individual steps are not included in the total > time. Can you try to add > reader->Update(); > before the line > > itk::TimeProbe totalTimeProbe; > > in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? > > Simon > > > > On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi RTK community, >> i am using SART algorithm to reconstruct an object. >> But in this new RTK version, the time recording seems a little weird: >> the total time is 1219.12s , but adding the time cost in different >> stages is not 1291.12 s. especially for "backprojection" part, only >> 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward >> projection part. BTW, the -f and -b are Joseph and >> VoxelBasedBackProjection, respectively, both multi-threading i think. >> Can anyone tell me what's going on? >> Thanks >> Regards >> Guangming >> >> [image: ???? 1] >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 08:28:28 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 14:28:28 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: I can try. Forward and back projection have the same algorithmic complexity but voxel based backprojection benefits from several optimizations in terms of memory management and computations that makes it faster. The best is to look at the code for further details... although both have far from being optimal. And I did not get the sentence "the backprojection should take much longer time than sart algorithm." because SART contains a backprojection and other steps so SART is obviously longer than the bp alone. Your log is strange and I don't see what steps are not timed that would take most of the time. I did the same test on my computer and here is my result: OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha --dimension 512 OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.288571 s Multiplication by zero: 0.131672 s Forward projection: 34.3612 s Subtraction: 0.203409 s Multiplication by lambda: 0.146459 s Ray box intersection: 1.30755 s Division: 0.187294 s Multiplication by the gating weights: 0 s Displaced detector: 0.278408 s Back projection: 11.8456 s Volume update: 0 s It took... 53.2765 s Simon On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang wrote: > Hi Simon, > Thanks for your reply. > would you pls help and explain why backprojection is expected to take > shorter time than forward projection?? because i was thinking if no caching > step, the backprojection should take much longer time than sart algorithm. > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > consumed of 3 times's sart, which much slower than my own application. > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > shapp-logan projections(512*512 resolution each) > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > -64,-64,-64 -l 0.5 -n 3 --time 1 > > and i will try reader->Update() like what you said. > Thanks > Guangming > > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> Hi Guangming, >> It's not surprising to me that the backprojection is faster than the >> forward projection, that's what I expect. If the total time is longer, >> that's probably that some individual steps are not included in the total >> time. Can you try to add >> reader->Update(); >> before the line >> >> itk::TimeProbe totalTimeProbe; >> >> in rtksart.cxx? It may be that all the reading operations are done but not >> timed in the sart->Update(). Why they are so long, I don't know, is your D: >> drive a network drive? Do you observe the same behavior if you do rtksart 2 >> times in a row? >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> wrote: >>> >>> Hi RTK community, >>> i am using SART algorithm to reconstruct an object. >>> But in this new RTK version, the time recording seems a little weird: >>> the total time is 1219.12s , but adding the time cost in different >>> stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s >>> to reconstruct a 128^3 volume ?? even shorter than forward projection part. >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, >>> both multi-threading i think. >>> Can anyone tell me what's going on? >>> Thanks >>> Regards >>> Guangming >>> >>> >>> Guangming Zang (Alex) >>> King Abdullah University of Science and Technology(KAUST) >>> University of Chinese Academy of Sciences(UCAS) >>> >>> >>> >>> >>> ________________________________ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete this >>> message from your computer system. Any unauthorized use or distribution is >>> prohibited. Please consider the environment before printing this email. >> >> > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 08:50:48 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 15:50:48 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, sorry for the mistake, not"the backprojection should take much longer time than sart algorithm" , but "the backprojection should take much longer time than forward projection in sart algorithm". BTW, how many cores does your computer have?? Mine is 24 cores. is it can explain the reason why it takes much longer time on my computer than yours? Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 15:28 GMT+03:00 Simon Rit : > I can try. Forward and back projection have the same algorithmic > complexity but voxel based backprojection benefits from several > optimizations in terms of memory management and computations that > makes it faster. The best is to look at the code for further > details... although both have far from being optimal. And I did not > get the sentence "the backprojection should take much longer time than > sart algorithm." because SART contains a backprojection and other > steps so SART is obviously longer than the bp alone. > Your log is strange and I don't see what steps are not timed that > would take most of the time. I did the same test on my computer and > here is my result: > > OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > --dimension 512 > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.288571 s > Multiplication by zero: 0.131672 s > Forward projection: 34.3612 s > Subtraction: 0.203409 s > Multiplication by lambda: 0.146459 s > Ray box intersection: 1.30755 s > Division: 0.187294 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.278408 s > Back projection: 11.8456 s > Volume update: 0 s > It took... 53.2765 s > > Simon > > On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > wrote: > > Hi Simon, > > Thanks for your reply. > > would you pls help and explain why backprojection is expected to take > > shorter time than forward projection?? because i was thinking if no > caching > > step, the backprojection should take much longer time than sart > algorithm. > > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > > consumed of 3 times's sart, which much slower than my own application. > > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > > shapp-logan projections(512*512 resolution each) > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > > -64,-64,-64 -l 0.5 -n 3 --time 1 > > > > and i will try reader->Update() like what you said. > > Thanks > > Guangming > > > > > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> > >> Hi Guangming, > >> It's not surprising to me that the backprojection is faster than the > >> forward projection, that's what I expect. If the total time is longer, > >> that's probably that some individual steps are not included in the total > >> time. Can you try to add > >> reader->Update(); > >> before the line > >> > >> itk::TimeProbe totalTimeProbe; > >> > >> in rtksart.cxx? It may be that all the reading operations are done but > not > >> timed in the sart->Update(). Why they are so long, I don't know, is > your D: > >> drive a network drive? Do you observe the same behavior if you do > rtksart 2 > >> times in a row? > >> > >> Simon > >> > >> > >> > >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> wrote: > >>> > >>> Hi RTK community, > >>> i am using SART algorithm to reconstruct an object. > >>> But in this new RTK version, the time recording seems a little weird: > >>> the total time is 1219.12s , but adding the time cost in different > >>> stages is not 1291.12 s. especially for "backprojection" part, only > 16.6051s > >>> to reconstruct a 128^3 volume ?? even shorter than forward projection > part. > >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > respectively, > >>> both multi-threading i think. > >>> Can anyone tell me what's going on? > >>> Thanks > >>> Regards > >>> Guangming > >>> > >>> > >>> Guangming Zang (Alex) > >>> King Abdullah University of Science and Technology(KAUST) > >>> University of Chinese Academy of Sciences(UCAS) > >>> > >>> > >>> > >>> > >>> ________________________________ > >>> This message and its contents, including attachments are intended > solely > >>> for the original recipient. If you are not the intended recipient or > have > >>> received this message in error, please notify me immediately and > delete this > >>> message from your computer system. Any unauthorized use or > distribution is > >>> prohibited. Please consider the environment before printing this email. > >> > >> > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 09:02:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 15:02:03 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: No I expect forward projection to be longer than backprojection although with optimal implementations, it should take about the same time since they have the same complexity. I have 4 cores on my laptop. I don't see how it explains it, try to find out where does SART spend the time. Simon On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang wrote: > Hi Simon, > sorry for the mistake, not"the backprojection should take much longer time > than > sart algorithm" , but "the backprojection should take much longer time than > forward projection in sart algorithm". > > BTW, how many cores does your computer have?? Mine is 24 cores. > is it can explain the reason why it takes much longer time on my computer > than yours? > Regards > Guangming > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> I can try. Forward and back projection have the same algorithmic >> complexity but voxel based backprojection benefits from several >> optimizations in terms of memory management and computations that >> makes it faster. The best is to look at the code for further >> details... although both have far from being optimal. And I did not >> get the sentence "the backprojection should take much longer time than >> sart algorithm." because SART contains a backprojection and other >> steps so SART is obviously longer than the bp alone. >> Your log is strange and I don't see what steps are not timed that >> would take most of the time. I did the same test on my computer and >> here is my result: >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> --dimension 512 >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> 1 >> Recording elapsed time... >> SARTConeBeamReconstructionFilter timing: >> Extraction of projection sub-stacks: 0.288571 s >> Multiplication by zero: 0.131672 s >> Forward projection: 34.3612 s >> Subtraction: 0.203409 s >> Multiplication by lambda: 0.146459 s >> Ray box intersection: 1.30755 s >> Division: 0.187294 s >> Multiplication by the gating weights: 0 s >> Displaced detector: 0.278408 s >> Back projection: 11.8456 s >> Volume update: 0 s >> It took... 53.2765 s >> >> Simon >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> wrote: >> > Hi Simon, >> > Thanks for your reply. >> > would you pls help and explain why backprojection is expected to take >> > shorter time than forward projection?? because i was thinking if no >> > caching >> > step, the backprojection should take much longer time than sart >> > algorithm. >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time >> > consumed of 3 times's sart, which much slower than my own application. >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 >> > shapp-logan projections(512*512 resolution each) >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> > >> > and i will try reader->Update() like what you said. >> > Thanks >> > Guangming >> > >> > >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> >> >> Hi Guangming, >> >> It's not surprising to me that the backprojection is faster than the >> >> forward projection, that's what I expect. If the total time is longer, >> >> that's probably that some individual steps are not included in the >> >> total >> >> time. Can you try to add >> >> reader->Update(); >> >> before the line >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done but >> >> not >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> your D: >> >> drive a network drive? Do you observe the same behavior if you do >> >> rtksart 2 >> >> times in a row? >> >> >> >> Simon >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> wrote: >> >>> >> >>> Hi RTK community, >> >>> i am using SART algorithm to reconstruct an object. >> >>> But in this new RTK version, the time recording seems a little weird: >> >>> the total time is 1219.12s , but adding the time cost in different >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >>> 16.6051s >> >>> to reconstruct a 128^3 volume ?? even shorter than forward projection >> >>> part. >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >>> respectively, >> >>> both multi-threading i think. >> >>> Can anyone tell me what's going on? >> >>> Thanks >> >>> Regards >> >>> Guangming >> >>> >> >>> >> >>> Guangming Zang (Alex) >> >>> King Abdullah University of Science and Technology(KAUST) >> >>> University of Chinese Academy of Sciences(UCAS) >> >>> >> >>> >> >>> >> >>> >> >>> ________________________________ >> >>> This message and its contents, including attachments are intended >> >>> solely >> >>> for the original recipient. If you are not the intended recipient or >> >>> have >> >>> received this message in error, please notify me immediately and >> >>> delete this >> >>> message from your computer system. Any unauthorized use or >> >>> distribution is >> >>> prohibited. Please consider the environment before printing this >> >>> email. >> >> >> >> >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended solely >> > for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> > this >> > message from your computer system. Any unauthorized use or distribution >> > is >> > prohibited. Please consider the environment before printing this email. > > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 10:05:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:05:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, it cost 1200s for SART algorithm at first, and the command are: rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 in which, the projections data(360pro_SL_Vol128_512.mha) is not generated from rtkprojectshepploganphantom , but from my application. though it took long time, but i can got a nice result, And i just tried the command you used, i.e. generated the projections data by rtkprojectshepploganphantom : rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 --sid=500.0 rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 yes, it takes about 56s. but the reconstructed result is weird, the voxel values range from [-142186, 208146] and can not see anything when visualizing it. i believe you got the similar results, which maybe explain why it computes much faster. if i wanna use the projections generated by rtkprojectshepploganphantom , can you give me an example to get a nice results? Best regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 16:02 GMT+03:00 Simon Rit : > No I expect forward projection to be longer than backprojection > although with optimal implementations, it should take about the same > time since they have the same complexity. > I have 4 cores on my laptop. I don't see how it explains it, try to > find out where does SART spend the time. > Simon > > On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang > wrote: > > Hi Simon, > > sorry for the mistake, not"the backprojection should take much longer > time > > than > > sart algorithm" , but "the backprojection should take much longer time > than > > forward projection in sart algorithm". > > > > BTW, how many cores does your computer have?? Mine is 24 cores. > > is it can explain the reason why it takes much longer time on my computer > > than yours? > > Regards > > Guangming > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : > >> > >> I can try. Forward and back projection have the same algorithmic > >> complexity but voxel based backprojection benefits from several > >> optimizations in terms of memory management and computations that > >> makes it faster. The best is to look at the code for further > >> details... although both have far from being optimal. And I did not > >> get the sentence "the backprojection should take much longer time than > >> sart algorithm." because SART contains a backprojection and other > >> steps so SART is obviously longer than the bp alone. > >> Your log is strange and I don't see what steps are not timed that > >> would take most of the time. I did the same test on my computer and > >> here is my result: > >> > >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > >> --dimension 512 > >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > >> 1 > >> Recording elapsed time... > >> SARTConeBeamReconstructionFilter timing: > >> Extraction of projection sub-stacks: 0.288571 s > >> Multiplication by zero: 0.131672 s > >> Forward projection: 34.3612 s > >> Subtraction: 0.203409 s > >> Multiplication by lambda: 0.146459 s > >> Ray box intersection: 1.30755 s > >> Division: 0.187294 s > >> Multiplication by the gating weights: 0 s > >> Displaced detector: 0.278408 s > >> Back projection: 11.8456 s > >> Volume update: 0 s > >> It took... 53.2765 s > >> > >> Simon > >> > >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > >> wrote: > >> > Hi Simon, > >> > Thanks for your reply. > >> > would you pls help and explain why backprojection is expected to take > >> > shorter time than forward projection?? because i was thinking if no > >> > caching > >> > step, the backprojection should take much longer time than sart > >> > algorithm. > >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the > time > >> > consumed of 3 times's sart, which much slower than my own application. > >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > >> > shapp-logan projections(512*512 resolution each) > >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > >> > -64,-64,-64 -l 0.5 -n 3 --time 1 > >> > > >> > and i will try reader->Update() like what you said. > >> > Thanks > >> > Guangming > >> > > >> > > >> > > >> > Guangming Zang (Alex) > >> > King Abdullah University of Science and Technology(KAUST) > >> > University of Chinese Academy of Sciences(UCAS) > >> > > >> > > >> > > >> > > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> >> > >> >> Hi Guangming, > >> >> It's not surprising to me that the backprojection is faster than the > >> >> forward projection, that's what I expect. If the total time is > longer, > >> >> that's probably that some individual steps are not included in the > >> >> total > >> >> time. Can you try to add > >> >> reader->Update(); > >> >> before the line > >> >> > >> >> itk::TimeProbe totalTimeProbe; > >> >> > >> >> in rtksart.cxx? It may be that all the reading operations are done > but > >> >> not > >> >> timed in the sart->Update(). Why they are so long, I don't know, is > >> >> your D: > >> >> drive a network drive? Do you observe the same behavior if you do > >> >> rtksart 2 > >> >> times in a row? > >> >> > >> >> Simon > >> >> > >> >> > >> >> > >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> >> wrote: > >> >>> > >> >>> Hi RTK community, > >> >>> i am using SART algorithm to reconstruct an object. > >> >>> But in this new RTK version, the time recording seems a little > weird: > >> >>> the total time is 1219.12s , but adding the time cost in different > >> >>> stages is not 1291.12 s. especially for "backprojection" part, only > >> >>> 16.6051s > >> >>> to reconstruct a 128^3 volume ?? even shorter than forward > projection > >> >>> part. > >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > >> >>> respectively, > >> >>> both multi-threading i think. > >> >>> Can anyone tell me what's going on? > >> >>> Thanks > >> >>> Regards > >> >>> Guangming > >> >>> > >> >>> > >> >>> Guangming Zang (Alex) > >> >>> King Abdullah University of Science and Technology(KAUST) > >> >>> University of Chinese Academy of Sciences(UCAS) > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> ________________________________ > >> >>> This message and its contents, including attachments are intended > >> >>> solely > >> >>> for the original recipient. If you are not the intended recipient or > >> >>> have > >> >>> received this message in error, please notify me immediately and > >> >>> delete this > >> >>> message from your computer system. Any unauthorized use or > >> >>> distribution is > >> >>> prohibited. Please consider the environment before printing this > >> >>> email. > >> >> > >> >> > >> > > >> > > >> > ________________________________ > >> > This message and its contents, including attachments are intended > solely > >> > for > >> > the original recipient. If you are not the intended recipient or have > >> > received this message in error, please notify me immediately and > delete > >> > this > >> > message from your computer system. Any unauthorized use or > distribution > >> > is > >> > prohibited. Please consider the environment before printing this > email. > > > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 10:12:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:12:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: BTW, the projections are 512*512, and the pixel spacing is 0.5 Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:05 GMT+03:00 Guangming Zang : > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 10:20:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 16:20:12 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Obviously I hadn't looked at the result and/or checked the command line options, sorry. This is an example from the same simulated dataset that gives me a good results: OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.567773 s Multiplication by zero: 0.303715 s Forward projection: 142.305 s Subtraction: 0.445842 s Multiplication by lambda: 0.2663 s Ray box intersection: 5.40366 s Division: 0.535618 s Multiplication by the gating weights: 0 s Displaced detector: 0.415431 s Back projection: 21.3689 s Volume update: 0 s It took... 177.059 s but this doesn't change the content of my previous message. What takes time is probably in your own software, be sure that you update SART inputs before timing it. Simon On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang wrote: > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 11:12:16 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 18:12:16 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Thanks Simon, now it work fine when using projections generated by RTK itself (command rtkprojectshepploganphantom ). for 1 iteration of SART to reconstruct 128^3 size volume, it took only 19s, which gives nice results as well. Thanks again. Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:20 GMT+03:00 Simon Rit : > Obviously I hadn't looked at the result and/or checked the command line > options, sorry. This is an example from the same simulated dataset that > gives me a good results: > > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f > Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n > 3 --time 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.567773 s > Multiplication by zero: 0.303715 s > Forward projection: 142.305 s > Subtraction: 0.445842 s > Multiplication by lambda: 0.2663 s > Ray box intersection: 5.40366 s > Division: 0.535618 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.415431 s > Back projection: 21.3689 s > Volume update: 0 s > It took... 177.059 s > > but this doesn't change the content of my previous message. What takes > time is probably in your own software, be sure that you update SART inputs > before timing it. > Simon > > On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon, >> it cost 1200s for SART algorithm at first, and the command are: >> rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd= >> 725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" >> >> rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 >> >> in which, the projections data(360pro_SL_Vol128_512.mha) is not >> generated from rtkprojectshepploganphantom , but from my application. >> though it took long time, but i can got a nice result, >> >> >> And i just tried the command you used, i.e. generated the projections >> data by rtkprojectshepploganphantom : >> >> rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 >> --sid=500.0 >> rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 >> rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b >> VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 >> --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 >> yes, it takes about 56s. >> but the reconstructed result is weird, the voxel values range from >> [-142186, 208146] and can not see anything when visualizing it. >> i believe you got the similar results, which maybe explain why it >> computes much faster. >> >> if i wanna use the projections generated by rtkprojectshepploganphantom >> , can you give me an example to get a nice results? >> >> Best regards >> Guangming >> >> >> >> >> >> >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> 2015-07-27 16:02 GMT+03:00 Simon Rit : >> >>> No I expect forward projection to be longer than backprojection >>> although with optimal implementations, it should take about the same >>> time since they have the same complexity. >>> I have 4 cores on my laptop. I don't see how it explains it, try to >>> find out where does SART spend the time. >>> Simon >>> >>> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >>> wrote: >>> > Hi Simon, >>> > sorry for the mistake, not"the backprojection should take much longer >>> time >>> > than >>> > sart algorithm" , but "the backprojection should take much longer time >>> than >>> > forward projection in sart algorithm". >>> > >>> > BTW, how many cores does your computer have?? Mine is 24 cores. >>> > is it can explain the reason why it takes much longer time on my >>> computer >>> > than yours? >>> > Regards >>> > Guangming >>> > >>> > Guangming Zang (Alex) >>> > King Abdullah University of Science and Technology(KAUST) >>> > University of Chinese Academy of Sciences(UCAS) >>> > >>> > >>> > >>> > >>> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >>> >> >>> >> I can try. Forward and back projection have the same algorithmic >>> >> complexity but voxel based backprojection benefits from several >>> >> optimizations in terms of memory management and computations that >>> >> makes it faster. The best is to look at the code for further >>> >> details... although both have far from being optimal. And I did not >>> >> get the sentence "the backprojection should take much longer time than >>> >> sart algorithm." because SART contains a backprojection and other >>> >> steps so SART is obviously longer than the bp alone. >>> >> Your log is strange and I don't see what steps are not timed that >>> >> would take most of the time. I did the same test on my computer and >>> >> here is my result: >>> >> >>> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >>> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >>> >> --dimension 512 >>> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >>> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >>> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >>> >> 1 >>> >> Recording elapsed time... >>> >> SARTConeBeamReconstructionFilter timing: >>> >> Extraction of projection sub-stacks: 0.288571 s >>> >> Multiplication by zero: 0.131672 s >>> >> Forward projection: 34.3612 s >>> >> Subtraction: 0.203409 s >>> >> Multiplication by lambda: 0.146459 s >>> >> Ray box intersection: 1.30755 s >>> >> Division: 0.187294 s >>> >> Multiplication by the gating weights: 0 s >>> >> Displaced detector: 0.278408 s >>> >> Back projection: 11.8456 s >>> >> Volume update: 0 s >>> >> It took... 53.2765 s >>> >> >>> >> Simon >>> >> >>> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >>> >> wrote: >>> >> > Hi Simon, >>> >> > Thanks for your reply. >>> >> > would you pls help and explain why backprojection is expected to >>> take >>> >> > shorter time than forward projection?? because i was thinking if no >>> >> > caching >>> >> > step, the backprojection should take much longer time than sart >>> >> > algorithm. >>> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >>> time >>> >> > consumed of 3 times's sart, which much slower than my own >>> application. >>> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >>> 360 >>> >> > shapp-logan projections(512*512 resolution each) >>> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >>> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >>> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >>> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >>> >> > >>> >> > and i will try reader->Update() like what you said. >>> >> > Thanks >>> >> > Guangming >>> >> > >>> >> > >>> >> > >>> >> > Guangming Zang (Alex) >>> >> > King Abdullah University of Science and Technology(KAUST) >>> >> > University of Chinese Academy of Sciences(UCAS) >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit >> >: >>> >> >> >>> >> >> Hi Guangming, >>> >> >> It's not surprising to me that the backprojection is faster than >>> the >>> >> >> forward projection, that's what I expect. If the total time is >>> longer, >>> >> >> that's probably that some individual steps are not included in the >>> >> >> total >>> >> >> time. Can you try to add >>> >> >> reader->Update(); >>> >> >> before the line >>> >> >> >>> >> >> itk::TimeProbe totalTimeProbe; >>> >> >> >>> >> >> in rtksart.cxx? It may be that all the reading operations are done >>> but >>> >> >> not >>> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >>> >> >> your D: >>> >> >> drive a network drive? Do you observe the same behavior if you do >>> >> >> rtksart 2 >>> >> >> times in a row? >>> >> >> >>> >> >> Simon >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >>> >> >> wrote: >>> >> >>> >>> >> >>> Hi RTK community, >>> >> >>> i am using SART algorithm to reconstruct an object. >>> >> >>> But in this new RTK version, the time recording seems a little >>> weird: >>> >> >>> the total time is 1219.12s , but adding the time cost in >>> different >>> >> >>> stages is not 1291.12 s. especially for "backprojection" part, >>> only >>> >> >>> 16.6051s >>> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >>> projection >>> >> >>> part. >>> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >>> >> >>> respectively, >>> >> >>> both multi-threading i think. >>> >> >>> Can anyone tell me what's going on? >>> >> >>> Thanks >>> >> >>> Regards >>> >> >>> Guangming >>> >> >>> >>> >> >>> >>> >> >>> Guangming Zang (Alex) >>> >> >>> King Abdullah University of Science and Technology(KAUST) >>> >> >>> University of Chinese Academy of Sciences(UCAS) >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> ________________________________ >>> >> >>> This message and its contents, including attachments are intended >>> >> >>> solely >>> >> >>> for the original recipient. If you are not the intended recipient >>> or >>> >> >>> have >>> >> >>> received this message in error, please notify me immediately and >>> >> >>> delete this >>> >> >>> message from your computer system. Any unauthorized use or >>> >> >>> distribution is >>> >> >>> prohibited. Please consider the environment before printing this >>> >> >>> email. >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > ________________________________ >>> >> > This message and its contents, including attachments are intended >>> solely >>> >> > for >>> >> > the original recipient. If you are not the intended recipient or >>> have >>> >> > received this message in error, please notify me immediately and >>> delete >>> >> > this >>> >> > message from your computer system. Any unauthorized use or >>> distribution >>> >> > is >>> >> > prohibited. Please consider the environment before printing this >>> email. >>> > >>> > >>> > >>> > ________________________________ >>> > This message and its contents, including attachments are intended >>> solely for >>> > the original recipient. If you are not the intended recipient or have >>> > received this message in error, please notify me immediately and >>> delete this >>> > message from your computer system. Any unauthorized use or >>> distribution is >>> > prohibited. Please consider the environment before printing this email. >>> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From infrombox at yandex.ru Tue Jul 28 04:30:22 2015 From: infrombox at yandex.ru (1 1) Date: Tue, 28 Jul 2015 15:30:22 +0700 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: <2213081438072222@web8j.yandex.ru> Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. But program which i use reads meta images with MET_SHORT pixel type only. Is there easy way to setting it and get volume with different from MET_FLOAT pixel type ? If not, could you advice me, what the filter i should to do, for example as post process after reconstruction ala MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward operation of LUTbasedVariableI0RawToAttenuationImageFilter ? Thanks. From simon.rit at creatis.insa-lyon.fr Tue Jul 28 04:56:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 10:56:54 +0200 Subject: [Rtk-users] volume with diffieret pixel type In-Reply-To: <2213081438072222@web8j.yandex.ru> References: <2213081438072222@web8j.yandex.ru> Message-ID: Hi, This is more an ITK question than a RTK question. Yes, we use float by default in our applications. You can cast the image to any type before writing using itk::CastImageFilter but you'll have to modify the applications and, of course, there is a loss of information. If you don't want to program it, you can use any other software, e.g. in vv right clik on your image after opening and use the convert to option. Simon On Tue, Jul 28, 2015 at 10:30 AM, 1 1 wrote: > Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. > But program which i use reads meta images with MET_SHORT pixel type only. > Is there easy way to setting it and get volume with different from > MET_FLOAT pixel type ? If not, could you advice me, what the filter i > should to do, for example as post process after reconstruction ala > MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward > operation of LUTbasedVariableI0RawToAttenuationImageFilter image, float image> ? > Thanks. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pconneely020186 at gmail.com Tue Jul 28 12:05:29 2015 From: pconneely020186 at gmail.com (peter conneely) Date: Tue, 28 Jul 2015 17:05:29 +0100 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: "peter conneely" Date: 24 Jul 2015 11:07 Subject: Issue running FDK reconstruction algorithm To: Cc: Hi, I'm having trouble running the FDK reconstruction alogrithm on Elekta and Varian data sets. The algorithm does work when I try the shepp-logan example. When I initially ran the application I included the (') around .*.his. and got the following lines. [image: Inline image 1] when I try to run with the (') removed it finds the 669 files but then the application stops working. I have tried adding registry edits to run exe and have tried switching of dep. Neither of these work I am not sure what is going wrong and how to fix it. My system properties are as follows. Processor: Intel Pentium CPU P6100 @ 2.00 Ghz RAM: 3.00 GB GPU: Intel HD Graphics Systems type 64 Bit. Thanks and Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Tue Jul 28 12:46:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 18:46:17 +0200 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: Hi, I guess the quotes are OS depedent, maybe you need double quotes on Windows. It's strange that you don't get an error message. Are you sure it crashed? If yes, have you checked the elektaGeometry file? Does it have 669 projection sections as expected? Or maybe it's a memory issue, try the --lowmem option. Simon On Tue, Jul 28, 2015 at 6:05 PM, peter conneely wrote: > ---------- Forwarded message ---------- > From: "peter conneely" > Date: 24 Jul 2015 11:07 > Subject: Issue running FDK reconstruction algorithm > To: > Cc: > > Hi, > > I'm having trouble running the FDK reconstruction alogrithm on Elekta and > Varian data sets. The algorithm does work when I try the shepp-logan > example. > > When I initially ran the application I included the (') around .*.his. and > got the following lines. > [image: Inline image 1] > when I try to run with the (') removed it finds the 669 files but then the > application stops working. I have tried adding registry edits to run exe > and have tried switching of dep. Neither of these work I am not sure what > is going wrong and how to fix it. > > My system properties are as follows. > Processor: Intel Pentium CPU P6100 @ 2.00 Ghz > RAM: 3.00 GB > GPU: Intel HD Graphics > Systems type 64 Bit. > > Thanks and Regards, > Peter > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Tue Jul 28 13:38:45 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Tue, 28 Jul 2015 20:38:45 +0300 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: Hi, in ITK, the default type are described in *Utilities\MetaIO\metaTypes.h* MET_CHAR, MET_UCHAR ?,? ?? MET_SHORT, MET_USHORT, MET_INT,=20 MET_UINT,=20 MET_FLOAT,=20 MET_DOUBLE, ?and for .mha file, the header file includes information like: ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = 0 0 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 1 1 1 DimSize = 128 128 128 ElementType = MET_FLOAT ElementDataFile = LOCAL? ?And recently i just programmed to read and write .mha files. below is the code. u can just replace ElementType from ? MET_FLOAT ? to ? ? MET_SHORT ? in your application. hope this helps: #include "stdafx.h" #include #include #include #include #include #include using namespace std; int _tmain(int argc, _TCHAR* argv[]) { int m_Dims[3]; float spacing[3]; m_Dims[0]=128; m_Dims[1]=128; m_Dims[2]=128; spacing[0]=spacing[1]=spacing[2]=1.0f; ostringstream buffer, buffer1, buffer2, buf3; buffer << spacing[0]; string sp= buffer.str(); buffer1 << spacing[1]; string sp1 = buffer1.str(); buffer2 << spacing[2]; string sp2 = buffer2.str(); string ElementSpacing ="ElementSpacing= "+sp+" "+sp1+" "+sp2+"\n"; // int ss=1000; char temp[64], temp1[64],temp2[64]; string str; sprintf(temp, "%d", m_Dims[0]); sprintf(temp1, "%d", m_Dims[1]); sprintf(temp2, "%d", m_Dims[2]); string s(temp),s1(temp1),s2(temp2); string DimSize="DimSize= "+s+" "+s1+" "+s2+"\n"; string Mywritefile="ObjectType = Image\nNDims = 3\nBinaryData = True\nBinaryDataByteOrderMSB = False \nCompressedData = False \nTransformMatrix = 1 0 0 0 1 0 0 0 1 \n" ; Mywritefile+="Offset = 0 0 0 \nCenterOfRotation = 0 0 0 \nAnatomicalOrientation = RAI \n"; Mywritefile+=ElementSpacing+DimSize+"ElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; // ElementSpacing = 1 1 1 \nDimSize = 128 128 128 \nElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; int leng=Mywritefile.length(); cout< From simon.rit at creatis.insa-lyon.fr Wed Jul 29 08:53:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 29 Jul 2015 14:53:34 +0200 Subject: [Rtk-users] RTK images make the cover of Medical Physics Message-ID: See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Wed Jul 29 09:07:01 2015 From: theday79 at gmail.com (Yang K Park) Date: Wed, 29 Jul 2015 09:07:01 -0400 Subject: [Rtk-users] RTK images make the cover of Medical Physics In-Reply-To: References: Message-ID: <001801d0c9ff$76797860$636c6920$@gmail.com> Hi Simon, Thank you so much for the congrats! This is my great honor and I?d like to thank all the RTK developers and community members for their helps on this achievement! Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: Wednesday, July 29, 2015 8:54 AM To: rtk-users at public.kitware.com Subject: [Rtk-users] RTK images make the cover of Medical Physics See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Thu Jul 30 08:16:38 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Thu, 30 Jul 2015 15:16:38 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK Message-ID: Hi Simon and Chao, i am currently do some comparisons between different reconstruction methods for Shapp-Logan dataset. the commands are: rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=955.4050067 --sid=500.0 rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha --dimension 512,512 when using FDK or SART algorithm from RTK, I can got pretty good results indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 and levels as 1.04 for all results got). When running ADMMTV command below, though the geometry is as same as SART and FDK, the result got from ADMM looks weird.(pls see attached central slice of ground truth and ADMM, same contrast with other algorithm) rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 [image: ???? 1][image: ???? 2] Is it because the CG algorithm used by ADMM, or parameters setting issues here?? if it is parameters setting problem , would you help me and give a nice values for alpha and bate used here? BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already (including default value) Thanks and regards Guangming ?? *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ? -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 31 01:55:32 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 31 Jul 2015 07:55:32 +0200 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi, It looks to me that you haven't converged. I'm not the specialist of this algorithm and the specialist won't be near a computer in the coming weeks but when I try with more iterations in the data attachment term: rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 it's more satisfactory. There are rings at the top and the bottom of the cone-beam which should be reduced with more TV (greater alpha, see doc here ) or with a finer spacing (see this publication ). Simon On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang wrote: > Hi Simon and Chao, > > i am currently do some comparisons between different reconstruction > methods for Shapp-Logan dataset. > > the commands are: > > rtksimulatedgeometry -n 360 --arc -360 -o > geo.xml --sdd=955.4050067 --sid=500.0 > > rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha > --dimension 512,512 > > > > when using FDK or SART algorithm from RTK, I can got pretty good results > indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 > and levels as 1.04 for all results got). When running ADMMTV command below, > though the geometry is as same as SART and FDK, the result got from ADMM > looks weird.(pls see attached central slice of ground truth and ADMM, same > contrast with other algorithm) > > rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o > SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 > --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 > > [image: ???? 1][image: ???? 2] > > Is it because the CG algorithm used by ADMM, or parameters setting issues > here?? if it is parameters setting problem , would you help me and give a > nice values for alpha and bate used here? > > BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already > (including default value) > > Thanks and regards > > Guangming > > > ?? > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > ? > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Fri Jul 31 09:46:41 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 31 Jul 2015 16:46:41 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi simon, i see, thanks for the help and explanation. after following your advice, it works fine now. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-31 8:55 GMT+03:00 Simon Rit : > Hi, > It looks to me that you haven't converged. I'm not the specialist of this > algorithm and the specialist won't be near a computer in the coming weeks > but when I try with more iterations in the data attachment term: > rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml > --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 > it's more satisfactory. There are rings at the top and the bottom of the > cone-beam which should be reduced with more TV (greater alpha, see doc > here > ) > or with a finer spacing (see this publication > ). > Simon > > On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon and Chao, >> >> i am currently do some comparisons between different reconstruction >> methods for Shapp-Logan dataset. >> >> the commands are: >> >> rtksimulatedgeometry -n 360 --arc -360 -o >> geo.xml --sdd=955.4050067 --sid=500.0 >> >> rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha >> --dimension 512,512 >> >> >> >> when using FDK or SART algorithm from RTK, I can got pretty good results >> indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 >> and levels as 1.04 for all results got). When running ADMMTV command below, >> though the geometry is as same as SART and FDK, the result got from ADMM >> looks weird.(pls see attached central slice of ground truth and ADMM, same >> contrast with other algorithm) >> >> rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o >> SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 >> --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 >> >> [image: ???? 1][image: ???? 2] >> >> Is it because the CG algorithm used by ADMM, or parameters setting issues >> here?? if it is parameters setting problem , would you help me and give a >> nice values for alpha and bate used here? >> >> BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already >> (including default value) >> >> Thanks and regards >> >> Guangming >> >> >> ?? >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> ? >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 1 08:45:35 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 1 Jul 2015 14:45:35 +0200 Subject: [Rtk-users] Release of RTK v1.1.0 Message-ID: Dear RTK users, RTK v1.1.0 has been released today, about 14 months after RTK v1.0.0. The main features that have been developed since the previous release are: - SimpleRTK to run RTK filters (even the CUDA ones) from python scripts, C# code, and more - new projection pre-processing options (i0 calculation, scatter correction, water pre-correction) - extraction of the respiratory phase from cone-beam projections - linear programming for field-of-view computation based on a third party software, lp solve 5.5 - management of off-center detector in iterative methods - new iterative 3D and 4D reconstruction methods with Daubechies wavelets regularization - new iterative 4D reconstruction method with motion-aware regularization - reduction of memory footprint, especially GPU memory - many new CUDA filters - more robust (many bugs and memory leaks fixed) - use of MathJax to display formulas in the documentation, e.g., here . Many thanks to the increasing number of contributors, in alphabetical order: Ben Champion, Chao Wu, Cyril Mory, I Putu Susila, Julien Jomier, Marc Vila, Mathieu Dupont, Matt Clarkson, Peter Keuschnigg, S?bastien Brousmiche, Simon Rit, Tristan Coulange, Yang K Park. We don't focus on releases since we have a public github repository that we try to keep stable, I still recommend the use of the master HEAD over releases to enjoy the new RTK developments before their release. We still have a few on-going projects for which we will use and enhance RTK. Simon (for the RTK consortium) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 1 15:39:14 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 1 Jul 2015 21:39:14 +0200 Subject: [Rtk-users] loading projection images for sart Message-ID: Hello, I got compiled the ITK and RTK with help of cmake. I also had a look at the examples coming with RTK. I want to run a simple SART and got projection images in the format PNG and BMP. So I create an instance of the ThreeDcircularProjectionGeometry, SARTConeBeamReconstructionFilter and add the geometric projection data. rtk::ThreeDCircularProjectionGeometry::Pointer geometry; geometry = rtk::ThreeDCircularProjectionGeometry::New(); geometry->AddProjection(??) rtk::SARTConeBeamReconstructionFilter::Pointer sart = rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); How to add a stack of images to the SART reconstruction, i.e. std::vector images ? I got xray projections in png format. There is a method in the SART class called SetInput. But according tot he examples it is used to set a volume. Does anybody alread wrote a small piece of code that loads some images from the disk and put them into the SART reconstruction ? Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 2 12:19:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 2 Jul 2015 18:19:36 +0200 Subject: [Rtk-users] loading projection images for sart In-Reply-To: References: Message-ID: Hi, The stack of 2D images is passed via a 3D image. Look at the rtksart application for example. A way to read this from a set of file names is to use itk::ImageSeriesReader as done in rtk::ProjectionsReader. You should be able to understand how it works by looking at the existing RTK applications in the applications subfolders. Simon On Wed, Jul 1, 2015 at 9:39 PM, Robert Callie? wrote: > Hello, > > I got compiled the ITK and RTK with help of cmake. I also had a look > > at the examples coming with RTK. I want to run a simple SART and > > got projection images in the format PNG and BMP. > > > > So I create an instance of the ThreeDcircularProjectionGeometry, > SARTConeBeamReconstructionFilter > > and add the geometric projection data. > > > > rtk::ThreeDCircularProjectionGeometry::Pointer geometry; > > geometry = rtk::ThreeDCircularProjectionGeometry::New(); > > geometry->AddProjection(??) > > > > rtk::SARTConeBeamReconstructionFilter::Pointer sart = > rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); > > > > How to add a stack of images to the SART reconstruction, i.e. > std::vector images ? > > I got xray projections in png format. > > > > There is a method in the SART class called SetInput. But according tot he > examples it is used to set a volume. > > > > Does anybody alread wrote a small piece of code that loads some images > from the disk and put them into the SART reconstruction ? > > > > Regards, > > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Fri Jul 3 16:28:11 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 3 Jul 2015 23:28:11 +0300 Subject: [Rtk-users] Remote Control Issue in new RTK version Message-ID: Dear RTK community, There is some bug in RTK 1.1 version. That?s : When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 but i did not use Cuda at all.. What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. So i think it is some problem caused by itk ?? can we fix this issue?? Thanks for help in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Sat Jul 4 10:12:03 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Sat, 4 Jul 2015 17:12:03 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. Thanks for the help, Chao. *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ---------- Forwarded message ---------- From: Chao Wu Date: 2015-07-04 0:04 GMT+03:00 Subject: Re: Remote Control Issue To: Guangming Zang Cc: rtk-users-request at public.kitware.com, Simon Rit < simon.rit at creatis.insa-lyon.fr> Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. Regards, Chao Sent from Samsung Galaxy Note 3 2015?7?3? 10:26 PM? "Guangming Zang" ??? > Dear RTK community, > > There is some bug in RTK 1.1 version. That?s : > > When i run commands In 1.1 version with my computer in the lab, RTK works > fine, but when i use my laptop at home to remote control the computer in > the lab, it does not work. i.e., no matter the command are (rtkfdk, > ADMM,SART ?), an error is always shown: > > ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 > @ unknown : Cuda Error #3 > > but i did not use Cuda at all.. > > What?s more, when i run the 1.0 version RTK , it works well and no bug in > remoter control mode. > > So i think it is some problem caused by itk ?? can we fix this issue?? > > Thanks for help in advance > > > Regards > > Guangming > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Sat Jul 4 10:19:32 2015 From: ghostcz at hotmail.com (louie L) Date: Sat, 4 Jul 2015 16:19:32 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: I think because in most cases people use their graphics in TCC mode for scientific computations or don't use gpu at all where the rtk_use_cuda is false. Cheers, Louie Sent from my iOS > On 04 Jul 2015, at 16:12, Guangming Zang wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > > 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> Dear RTK community, >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> >> Regards >> >> Guangming >> >> Guangming Zang (Alex) >> King Abdullah University of Science and Technology(KAUST) >> University of Chinese Academy of Sciences(UCAS) >> >> >> >> >> This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > > > This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Mon Jul 6 05:32:18 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 6 Jul 2015 11:32:18 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Hi Guangming and all, Thanks for reporting this change of behavior. My first answer is that what you find simple is not so simple... but you're right, v1.0.0 allowed to compile RTK with CUDA and to run it without a CUDA device. After a bit of trakcing, I found that the change of behavior has been introduced with this patch so you can blame me. It has now fixed this issue with this patch , which seems to work on my laptop, I hope it does on your computer as well. I can't help you with the fact that you can't run CUDA software with remote control. Simon On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > I think because in most cases people use their graphics in TCC mode for > scientific computations or don't use gpu at all where the rtk_use_cuda is > false. > Cheers, > > Louie > > Sent from my iOS > > On 04 Jul 2015, at 16:12, Guangming Zang > wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes > to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is > defined, then if CUDA device is not available this error will occur. When > using MS remote desktop, graphical card and driver are bypassed unless it > is Tesla cards working in TCC mode. You can either compile exes without > CUDA for remote desktop, or try other graphic-based remote desktop software > like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > 2015?7?3? 10:26 PM? "Guangming Zang" ??? > >> Dear RTK community, >> >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works >> fine, but when i use my laptop at home to remote control the computer in >> the lab, it does not work. i.e., no matter the command are (rtkfdk, >> ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >> @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in >> remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> Regards >> >> Guangming >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 6 06:19:10 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 6 Jul 2015 13:19:10 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Thanks all for your help,Simon. I will try it again when i am at home :) As for using Cuda in remote control, i can handle it:just like what Chao said, change lab computer to TCC. What confused me at the beginning is that a cuda error shown while i did not call cuda at all, and thanks for fixing it. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-06 12:32 GMT+03:00 Simon Rit : > Hi Guangming and all, > Thanks for reporting this change of behavior. My first answer is that what > you find simple is not so simple... but you're right, v1.0.0 allowed to > compile RTK with CUDA and to run it without a CUDA device. After a bit of > trakcing, I found that the change of behavior has been introduced with this > patch > > so you can blame me. It has now fixed this issue with this patch > , > which seems to work on my laptop, I hope it does on your computer as well. > I can't help you with the fact that you can't run CUDA software with > remote control. > Simon > > On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > >> I think because in most cases people use their graphics in TCC mode for >> scientific computations or don't use gpu at all where the rtk_use_cuda is >> false. >> Cheers, >> >> Louie >> >> Sent from my iOS >> >> On 04 Jul 2015, at 16:12, Guangming Zang >> wrote: >> >> Ok, i see. Though i still do not understand why in new version rtk >> changes to call cudaimages, not keeping it simple like before. >> Thanks for the help, Chao. >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ---------- Forwarded message ---------- >> From: Chao Wu >> Date: 2015-07-04 0:04 GMT+03:00 >> Subject: Re: Remote Control Issue >> To: Guangming Zang >> Cc: rtk-users-request at public.kitware.com, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> >> >> Now in many exes cudaimage is the default image type if rtk_use_cuda is >> defined, then if CUDA device is not available this error will occur. When >> using MS remote desktop, graphical card and driver are bypassed unless it >> is Tesla cards working in TCC mode. You can either compile exes without >> CUDA for remote desktop, or try other graphic-based remote desktop software >> like vnc or teamviewer. >> >> Regards, Chao >> Sent from Samsung Galaxy Note 3 >> 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> >>> Dear RTK community, >>> >>> There is some bug in RTK 1.1 version. That?s : >>> >>> When i run commands In 1.1 version with my computer in the lab, RTK >>> works fine, but when i use my laptop at home to remote control the >>> computer in the lab, it does not work. i.e., no matter the command are >>> (rtkfdk, ADMM,SART ?), an error is always shown: >>> >>> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >>> @ unknown : Cuda Error #3 >>> >>> but i did not use Cuda at all.. >>> >>> What?s more, when i run the 1.0 version RTK , it works well and no bug >>> in remoter control mode. >>> >>> So i think it is some problem caused by itk ?? can we fix this issue?? >>> >>> Thanks for help in advance >>> >>> >>> Regards >>> >>> Guangming >>> *Guangming Zang (Alex)* >>> *King Abdullah University of Science and Technology(KAUST)* >>> *University of Chinese Academy of Sciences(UCAS)* >>> >>> >>> >>> >>> ------------------------------ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete >>> this message from your computer system. Any unauthorized use or >>> distribution is prohibited. Please consider the environment before printing >>> this email. >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Wed Jul 8 22:26:29 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Wed, 8 Jul 2015 19:26:29 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question Message-ID: Hi, I have a question from you about the CT reconstruction, I would really appreciate if you can help me with this. I have the geometry as described in following and I am trying to run the rtkfdk code from RTK. % parameters % % % % % % % param.nx = 500; % number of voxels param.ny = 500; param.nz = 500; param.sx = 5000; % mm (real size) param.sy = 5000; % mm param.sz = 5000; % mm %The real detector panel pixel density (number of pixels) param.nu = 36; % number of pixels param.nv = 100; % Detector setting (real size) param.su = 7200; % mm (real size) param.sv = 9200; % mm % X-ray source and detector setting param.DSD = 32900; % Distance source to detector param.DSO = 27400; % X-ray source to object axis distance % angle setting param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) param.dang = 5; % angular step size (deg) param.deg = 0:param.dang:360-1; % you can change param.deg = param.deg*param.dir; param.nProj = length(param.deg); param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than 360 deg -> param.parker=1 param.filter='ram-lak'; % high pass filter param.dx = param.sx/param.nx; % single voxel size param.dy = param.sy/param.ny; param.dz = param.sz/param.nz; param.du = param.su/param.nu; param.dv = param.sv/param.nv; param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) % Geometry calculation % % % param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : 360). But I got confused how to set the geometry parameters in RTK I followed the rtkfdk tutorial but I can?t get any result using this method I did the following: 1- Create geometry.xml using these parameters: nproj = 72 ; first_angle = 0 ; arc = 360 ; sid = 27400 ; sdd = 32900 ; proj_iso_x = 0; proj_iso_y = 0; out_angle = 0 ; in_angle = 0 ; source_x = 0; source_y = 0 ; 2- Create my own mha file (WriteMhaFile.m) from my projection array (36*100*72) using a matlab code with following properties: Voxel size = [0.1 0.1 0.1] Offset = [1 1 1] 3- Then run the: rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 --dimension 500 Could you please tell me if I am setting the geometry correctly? Also, is there any other way to create my own mha file? Thank you in advance and looking forward to hear back from you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 02:23:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 08:23:36 +0200 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Hi, We can try to help but we need to understand your geometry... Where does it come from by the way? If I understand your geometry correctly, I would say : - sid, sdd, nproj, arc are correct, - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 and you have 36x100 pixels, then the pixel size is [200,92,1] (last dimension is not used so anything). For the volume, if your volume is 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and not 0.1. - offset of projections is probably wrong. If you want to have a centered projections, you'll need something like (-3500, -554, 0). You can set is to 0 and put those values in proj_iso_x and proj_iso_y. Regarding mha file, you can write mha files in many ways, using SimpleRTK, matlab or writing an ITK code. Good luck! Simon On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah wrote: > Hi, > > I have a question from you about the CT reconstruction, I would really > appreciate if you can help me with this. > > I have the geometry as described in following and I am trying to run the > rtkfdk code from RTK. > > > % parameters % % % % % % % > > param.nx = 500; % number of voxels > param.ny = 500; > param.nz = 500; > > > param.sx = 5000; % mm (real size) > param.sy = 5000; % mm > param.sz = 5000; % mm > > > %The real detector panel pixel density (number of pixels) > param.nu = 36; % number of pixels > param.nv = 100; > > % Detector setting (real size) > param.su = 7200; % mm (real size) > param.sv = 9200; % mm > > > % X-ray source and detector setting > param.DSD = 32900; % Distance source to detector > param.DSO = 27400; % X-ray source to object axis distance > > > % angle setting > param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) > param.dang = 5; % angular step size (deg) > param.deg = 0:param.dang:360-1; % you can change > param.deg = param.deg*param.dir; > param.nProj = length(param.deg); > > param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than > 360 deg -> param.parker=1 > > param.filter='ram-lak'; % high pass filter > > > param.dx = param.sx/param.nx; % single voxel size > param.dy = param.sy/param.ny; > param.dz = param.sz/param.nz; > param.du = param.su/param.nu; > param.dv = param.sv/param.nv; > param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) > > > % Geometry calculation % % % > param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; > param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; > param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; > param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; > param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; > > > > So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : > 360). > But I got confused how to set the geometry parameters in RTK > I followed the rtkfdk tutorial but I can?t get any result using this method > > I did the following: > > 1- Create geometry.xml using these parameters: > > nproj = 72 ; > first_angle = 0 ; > arc = 360 ; > sid = 27400 ; > sdd = 32900 ; > proj_iso_x = 0; > proj_iso_y = 0; > out_angle = 0 ; > in_angle = 0 ; > source_x = 0; > source_y = 0 ; > > 2- Create my own mha file (WriteMhaFile.m) from my projection array > (36*100*72) using a matlab code with following properties: > Voxel size = [0.1 0.1 0.1] > Offset = [1 1 1] > > > 3- Then run the: > rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 > --dimension 500 > > > Could you please tell me if I am setting the geometry correctly? > Also, is there any other way to create my own mha file? > > Thank you in advance and looking forward to hear back from you. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 12:12:01 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 18:12:01 +0200 Subject: [Rtk-users] RTK training In-Reply-To: <55816290.1010807@uclouvain.be> References: <55816290.1010807@uclouvain.be> Message-ID: Dear RTK users, We have finally set a date for the RTK training, Wednesday, Nov 18 2015 in Lyon (France). The training will be organised by Kitware, go to this page for the registration: http://formations.kitware.fr/browse/116 We will do both user and developer sessions during the training. Since it's the first time that we do the training, we will tailor the balance between the two according to the wishes of registered people. The rest of the information should be available on the website but let us know if you need more information, we are still building the webpage and we'll be happy to improve it. We're looking forward to this new training and we'll do our best to meet your expectations, Simon On Wed, Jun 17, 2015 at 2:05 PM, Cyril Mory wrote: > Dear RTK users, > > The first RTK training is being planned at this very moment. It should > take place in November in Lyon, and be hosted by Kitware. The exact date > has not yet been decided, but will be available soon. > > We need your help to decide what to focus this training on. The choice is > mainly between two options: > - if most trainees want to learn how to use RTK, then we will focus on the > command-line tools and on python + Simple RTK > - if most trainees want to learn how to develop within RTK, modify and > enrich it, then we will focus on software architecture, detailed filter > description, ITK pipeline management, CUDA filters, etc... > > Please let us know which of these choices would best suit your needs. > > Looking forward, > Cyril > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Thu Jul 9 17:59:05 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Thu, 9 Jul 2015 14:59:05 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Simon, Thank you. I think now I understand how the whole geometry is defined in RTK. The projection is based on one experiment I am doing using different simulation techniques. Again thank you for your help. Best, Ali On Wed, Jul 8, 2015 at 11:23 PM, Simon Rit wrote: > Hi, > We can try to help but we need to understand your geometry... Where does > it come from by the way? If I understand your geometry correctly, I would > say : > - sid, sdd, nproj, arc are correct, > - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 > and you have 36x100 pixels, then the pixel size is [200,92,1] (last > dimension is not used so anything). For the volume, if your volume is > 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and > not 0.1. > - offset of projections is probably wrong. If you want to have a centered > projections, you'll need something like (-3500, -554, 0). You can set is to > 0 and put those values in proj_iso_x and proj_iso_y. > Regarding mha file, you can write mha files in many ways, using SimpleRTK, > matlab or writing an ITK code. > Good luck! > Simon > > On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah > wrote: > >> Hi, >> >> I have a question from you about the CT reconstruction, I would really >> appreciate if you can help me with this. >> >> I have the geometry as described in following and I am trying to run the >> rtkfdk code from RTK. >> >> >> % parameters % % % % % % % >> >> param.nx = 500; % number of voxels >> param.ny = 500; >> param.nz = 500; >> >> >> param.sx = 5000; % mm (real size) >> param.sy = 5000; % mm >> param.sz = 5000; % mm >> >> >> %The real detector panel pixel density (number of pixels) >> param.nu = 36; % number of pixels >> param.nv = 100; >> >> % Detector setting (real size) >> param.su = 7200; % mm (real size) >> param.sv = 9200; % mm >> >> >> % X-ray source and detector setting >> param.DSD = 32900; % Distance source to detector >> param.DSO = 27400; % X-ray source to object axis distance >> >> >> % angle setting >> param.dir = +1; % gantry rotating direction (clock wise/ counter >> clockwise) >> param.dang = 5; % angular step size (deg) >> param.deg = 0:param.dang:360-1; % you can change >> param.deg = param.deg*param.dir; >> param.nProj = length(param.deg); >> >> param.parker = 0; % data with 360 deg -> param.parker = 0 , data less >> than >> 360 deg -> param.parker=1 >> >> param.filter='ram-lak'; % high pass filter >> >> >> param.dx = param.sx/param.nx; % single voxel size >> param.dy = param.sy/param.ny; >> param.dz = param.sz/param.nz; >> param.du = param.su/param.nu; >> param.dv = param.sv/param.nv; >> param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) >> >> >> % Geometry calculation % % % >> param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; >> param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; >> param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; >> param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; >> param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; >> >> >> >> So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : >> 360). >> But I got confused how to set the geometry parameters in RTK >> I followed the rtkfdk tutorial but I can?t get any result using this >> method >> >> I did the following: >> >> 1- Create geometry.xml using these parameters: >> >> nproj = 72 ; >> first_angle = 0 ; >> arc = 360 ; >> sid = 27400 ; >> sdd = 32900 ; >> proj_iso_x = 0; >> proj_iso_y = 0; >> out_angle = 0 ; >> in_angle = 0 ; >> source_x = 0; >> source_y = 0 ; >> >> 2- Create my own mha file (WriteMhaFile.m) from my projection array >> (36*100*72) using a matlab code with following properties: >> Voxel size = [0.1 0.1 0.1] >> Offset = [1 1 1] >> >> >> 3- Then run the: >> rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 >> --dimension 500 >> >> >> Could you please tell me if I am setting the geometry correctly? >> Also, is there any other way to create my own mha file? >> >> Thank you in advance and looking forward to hear back from you. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hougeamm at 126.com Thu Jul 9 18:35:09 2015 From: hougeamm at 126.com (=?GBK?B?uu645w==?=) Date: Fri, 10 Jul 2015 06:35:09 +0800 (CST) Subject: [Rtk-users] problems for elekta data Message-ID: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Hello Everyone, Why the Elekta data prompt projection doesn't match when using rtkfdk? e.g., 377 vs 389? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 10 01:43:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Jul 2015 07:43:15 +0200 Subject: [Rtk-users] problems for elekta data In-Reply-To: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> References: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Message-ID: Hi, The message that you have on the command line is the result of the files that have been found in the path (--path option) with the regular expression (--regexp option). If it found more projections than what you have, then you probably need to improve your reg exp, e.g., by a $ after the file extension to specify that the file name must end with it. Simon On Fri, Jul 10, 2015 at 12:35 AM, ?? wrote: > Hello Everyone, > Why the Elekta data prompt projection doesn't match when using > rtkfdk? e.g., 377 vs 389? > Thanks! > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From guangming.zang at kaust.edu.sa Mon Jul 13 02:48:15 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 09:48:15 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset Message-ID: Hi RTK comunity, Besides the prameters like SID and SDD , from the geometry(.xteck) file got from my scanner, i also have object (volume) information like this: VoxelsX=179 VoxelsY=163 VoxelsZ=127 VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 The X,Y and Z axis are identical to RTK's geometry , So i was really wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i can show all other parameters like: rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, but it still a slight different visualization result from what we got from scanner software. So would you help me??? File attached is the geometry file in case. Thanks in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VCC_Dome_0622.xtekct Type: application/octet-stream Size: 1813 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 13 04:38:00 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 11:38:00 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: problem fixed. because the scanned object is symmetric and i did not notice that i should -Z axis in scanner to map Z in RTK thanks. but, i still do not know in RTK how to show the OffsetZ.. :( Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-13 9:48 GMT+03:00 Guangming Zang : > Hi RTK comunity, > Besides the prameters like SID and SDD , from the geometry(.xteck) file > got from my scanner, i also have object (volume) information like this: > VoxelsX=179 VoxelsY=163 VoxelsZ=127 > VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 > OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 > The X,Y and Z axis are identical to RTK's geometry , So i was really > wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i > can show all other parameters like: > > rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing > 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 > --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 > > Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, > but it still a slight different visualization result from what we got from > scanner software. > So would you help me??? > > > File attached is the geometry file in case. Thanks in advance > Regards > Guangming > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Mon Jul 13 13:21:44 2015 From: robert.calliess at gmx.de (=?utf-8?Q?Robert_Callie=C3=9F?=) Date: Mon, 13 Jul 2015 19:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? Message-ID: Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 13 13:42:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 13 Jul 2015 19:42:43 +0200 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: Hi, OffsetZ probably refers to the coordinate of the volume in the room coordinate which we don't use in RTK. Everything is set in the tomography coordinate during reconstruction. You can always change the coordinates of your volume after if you want to put it in some other coordinate system. Simon On Mon, Jul 13, 2015 at 10:38 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > problem fixed. > because the scanned object is symmetric and i did not notice that i > should -Z axis in scanner to map Z in RTK > thanks. > but, i still do not know in RTK how to show the OffsetZ.. :( > > Guangming > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-13 9:48 GMT+03:00 Guangming Zang : > >> Hi RTK comunity, >> Besides the prameters like SID and SDD , from the geometry(.xteck) file >> got from my scanner, i also have object (volume) information like this: >> VoxelsX=179 VoxelsY=163 VoxelsZ=127 >> VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 >> OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 >> The X,Y and Z axis are identical to RTK's geometry , So i was really >> wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i >> can show all other parameters like: >> >> rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing >> 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 >> --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 >> >> Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, >> but it still a slight different visualization result from what we got from >> scanner software. >> So would you help me??? >> >> >> File attached is the geometry file in case. Thanks in advance >> Regards >> Guangming >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Tue Jul 14 03:01:14 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 14 Jul 2015 09:01:14 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 01:32:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 07:32:43 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: > Hell RTK User, > I think there is a mistake in the described approach. > Point a) and f) meight be wrong. As far as I Understand, all Pixels > that are covered by the projected voxel vertices are update > with weight * voxel_value. Where weight is the overlaping area > of the projected voxel vertices polygon on the detector plane and the > underlying detector pixels. > > Any opinions before implementing it ? > > regards, > Robert > > *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr > *Von:* "Robert Callie?" > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what > they called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can > be rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector > cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value > to back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Wed Jul 15 08:07:20 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Wed, 15 Jul 2015 14:07:20 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 08:21:44 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 14:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: > Hello Simon, > thank you for your answer. I guess you linked the wrong article. But I > know what article you are talking about. > It's the articel from 2009 with a piece of code (MapSeq). > > >> I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > detector pixels that are totally covered by the overlap are weight with > "1" and if the overlap is between detector pixels > the pixels are weighted. Do you have a copy of the original article from > the De Man and Basu ? > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > Do you agree with that or did I miss something ? > > best regards, > Robert > > *Gesendet:* Mittwoch, 15. Juli 2015 um 07:32 Uhr > *Von:* "Simon Rit" > *An:* "Robert Callie?" > *Cc:* "rtk-users at public.kitware.com" > *Betreff:* Re: [Rtk-users] distance driven projector, a simplified > approach ? > Hi, > Indeed, I have published an article > on this > projector describing my implementation, you could use it if you want, > there's even a piece of code in it although I'm pretty sure it's not the > best implementation. This implementation dealt with the case where the > rotation axis is parallel to the detector. As far as I can remember, the > original article of De Man and Basu is also quite clear. > I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > Simon > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: >> >> Hell RTK User, >> I think there is a mistake in the described approach. >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> that are covered by the projected voxel vertices are update >> with weight * voxel_value. Where weight is the overlaping area >> of the projected voxel vertices polygon on the detector plane and the >> underlying detector pixels. >> >> Any opinions before implementing it ? >> >> regards, >> Robert >> >> *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr >> *Von:* "Robert Callie?" >> *An:* rtk-users at public.kitware.com >> *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel boundaries >> onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel?s contribution (weight) is the area of this overlapping. I >> read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is what >> they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone beam >> geometry. We can >> >> either rotate the detector and source around the object or the object can >> be rotated >> >> and the detector and source are fixed. I think Simon also wrote a paper >> about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source position, >> object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector >> cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the >> corresponding detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a ? e). Value >> to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I?m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of voxel >> boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 15 15:14:13 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 15 Jul 2015 21:14:13 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hello Simon, thank you for the articles. May I ask you what do you mean by ?voxel correction factor? in the code you provided in your article ? float f) // Voxel correction factor Thank you and best regards, Robert Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit Gesendet: Mittwoch, 15. Juli 2015 14:22 An: Robert Callie? Cc: rtk-users at public.kitware.com Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: Hello Simon, thank you for your answer. I guess you linked the wrong article. But I know what article you are talking about. It's the articel from 2009 with a piece of code (MapSeq). >> I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. You're right. It is that all pixels that are related to the overlap projected voxel overlap have to taken into account. So detector pixels that are totally covered by the overlap are weight with "1" and if the overlap is between detector pixels the pixels are weighted. Do you have a copy of the original article from the De Man and Basu ? I have the opinion that it's not neccessary to project the detector pixel boundaries and voxel boundaries onto a common plane if we use a flat panel detector. Instead we could project the voxel boundaries onto the detector plane directly. Do you agree with that or did I miss something ? best regards, Robert Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr Von: "Simon Rit" An: "Robert Callie?" Cc: "rtk-users at public.kitware.com" Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: Hell RTK User, I think there is a mistake in the described approach. Point a) and f) meight be wrong. As far as I Understand, all Pixels that are covered by the projected voxel vertices are update with weight * voxel_value. Where weight is the overlaping area of the projected voxel vertices polygon on the detector plane and the underlying detector pixels. Any opinions before implementing it ? regards, Robert Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr Von: "Robert Callie?" An: rtk-users at public.kitware.com Betreff: [Rtk-users] distance driven projector, a simplified approach ? Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 15:45:23 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 21:45:23 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. Simon On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie? wrote: > Hello Simon, > > thank you for the articles. May I ask you what do you mean by > > ?voxel correction factor? in the code you provided in your article ? > > float f) // Voxel correction factor > > > > Thank you and best regards, > > Robert > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Mittwoch, 15. Juli 2015 14:22 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified > approach ? > > > > Sorry, this link indeed with the MapSeg function. And yes, I was projecting > it to the detector plane directly. > > Simon > > > > On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" > wrote: > > Hello Simon, > > thank you for your answer. I guess you linked the wrong article. But I know > what article you are talking about. > > It's the articel from 2009 with a piece of code (MapSeq). > > > >>> I don't have time to go into the details of what you have proposed but, >>> from a glance, the first step seems useless. > > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > > detector pixels that are totally covered by the overlap are weight with "1" > and if the overlap is between detector pixels > > the pixels are weighted. Do you have a copy of the original article from the > De Man and Basu ? > > > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > > Do you agree with that or did I miss something ? > > > > best regards, > > Robert > > > > Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr > Von: "Simon Rit" > An: "Robert Callie?" > Cc: "rtk-users at public.kitware.com" > Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? > > Hi, > > Indeed, I have published an article on this projector describing my > implementation, you could use it if you want, there's even a piece of code > in it although I'm pretty sure it's not the best implementation. This > implementation dealt with the case where the rotation axis is parallel to > the detector. As far as I can remember, the original article of De Man and > Basu is also quite clear. > > I don't have time to go into the details of what you have proposed but, from > a glance, the first step seems useless. > > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > > Simon > > > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: > > Hell RTK User, > > I think there is a mistake in the described approach. > > Point a) and f) meight be wrong. As far as I Understand, all Pixels > > that are covered by the projected voxel vertices are update > > with weight * voxel_value. Where weight is the overlaping area > > of the projected voxel vertices polygon on the detector plane and the > > underlying detector pixels. > > > > Any opinions before implementing it ? > > > > regards, > > Robert > > > > Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr > Von: "Robert Callie?" > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what they > called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can be > rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value to > back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From simon.rit at creatis.insa-lyon.fr Fri Jul 17 02:22:16 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 17 Jul 2015 08:22:16 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Please keep on using the mailing list, I don't see a good reason to keep this conversation private. I won't have time to go back into these details. From a quick look, I think this is correct although I would have simply said that D is the center of the detector pixel. Simon On Thu, Jul 16, 2015 at 10:24 PM, Robert Callie? wrote: > Hello, > Sorry that I have to ask again. But I want to clear this before I start. > I want to ask about the cosine weight DeMan mentioned in his article. > He wrote: > > " > (1) The intersection length of the line of interest with the image slab S, the latter being > defined as the slab parallel to the xz plane and containing voxel V. This intersection length > is given by t/(cos ? cos ? ), where t is the isotropic voxel size, and ? and ? are the in- and > out-of-plane angles of the line of interest with the y-axis. > " > > So what he actually does, is that he calculates the intersection length of the slab s (that contains the voxel) with > a ray going from xray source to the middle of two adjacent detector cell boundaries. Let's refare to Figure 5. > So the length to be considered is calculated as the intersection length of slab S with the ray going from > the source ( the black dot in figure 5) to the mid-point of D, that means the center of the two projected adjacent > detector pixel boundaries. > > > Sorry for asking again but I want it to make it clear to me. > > Best regards, > Robert > > > -----Urspr?ngliche Nachricht----- > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit > Gesendet: Mittwoch, 15. Juli 2015 21:45 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? > > "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" > So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. > Simon > > On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie wrote: >> Hello Simon, >> >> thank you for the articles. May I ask you what do you mean by >> >> voxel correction factor in the code you provided in your article ? >> >> float f) // Voxel correction factor >> >> >> >> Thank you and best regards, >> >> Robert >> >> >> >> Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von >> Simon Rit >> Gesendet: Mittwoch, 15. Juli 2015 14:22 >> An: Robert Callie >> Cc: rtk-users at public.kitware.com >> Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified >> approach ? >> >> >> >> Sorry, this link indeed with the MapSeg function. And yes, I was >> projecting it to the detector plane directly. >> >> Simon >> >> >> >> On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie " >> >> wrote: >> >> Hello Simon, >> >> thank you for your answer. I guess you linked the wrong article. But I >> know what article you are talking about. >> >> It's the articel from 2009 with a piece of code (MapSeq). >> >> >> >>>> I don't have time to go into the details of what you have proposed >>>> but, from a glance, the first step seems useless. >> >> You're right. It is that all pixels that are related to the overlap >> projected voxel overlap have to taken into account. So >> >> detector pixels that are totally covered by the overlap are weight with "1" >> and if the overlap is between detector pixels >> >> the pixels are weighted. Do you have a copy of the original article >> from the De Man and Basu ? >> >> >> >> I have the opinion that it's not neccessary to project the detector >> pixel boundaries and voxel boundaries onto a common plane >> >> if we use a flat panel detector. Instead we could project the voxel >> boundaries onto the detector plane directly. >> >> Do you agree with that or did I miss something ? >> >> >> >> best regards, >> >> Robert >> >> >> >> Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr >> Von: "Simon Rit" >> An: "Robert Callie " >> Cc: "rtk-users at public.kitware.com" >> Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hi, >> >> Indeed, I have published an article on this projector describing my >> implementation, you could use it if you want, there's even a piece of >> code in it although I'm pretty sure it's not the best implementation. >> This implementation dealt with the case where the rotation axis is >> parallel to the detector. As far as I can remember, the original >> article of De Man and Basu is also quite clear. >> >> I don't have time to go into the details of what you have proposed >> but, from a glance, the first step seems useless. >> >> Good luck in your implementation and don't hesitate to send it to us >> when you have a working RTK implementation, >> >> Simon >> >> >> >> On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie " >> >> wrote: >> >> Hell RTK User, >> >> I think there is a mistake in the described approach. >> >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> >> that are covered by the projected voxel vertices are update >> >> with weight * voxel_value. Where weight is the overlaping area >> >> of the projected voxel vertices polygon on the detector plane and the >> >> underlying detector pixels. >> >> >> >> Any opinions before implementing it ? >> >> >> >> regards, >> >> Robert >> >> >> >> Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr >> Von: "Robert Callie " >> An: rtk-users at public.kitware.com >> Betreff: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel >> boundaries onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel s contribution (weight) is the area of this >> overlapping. I read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is >> what they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone >> beam geometry. We can >> >> either rotate the detector and source around the object or the object >> can be rotated >> >> and the detector and source are fixed. I think Simon also wrote a >> paper about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source >> position, object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the corresponding >> detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a e). >> Value to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of >> voxel boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > From guangming.zang at kaust.edu.sa Sun Jul 26 18:30:42 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 01:30:42 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed Message-ID: Hi RTK community, i am using SART algorithm to reconstruct an object. But in this new RTK version, the time recording seems a little weird: the total time is 1219.12s , but adding the time cost in different stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward projection part. BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, both multi-threading i think. Can anyone tell me what's going on? Thanks Regards Guangming [image: ???? 1] *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 01:59:11 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 07:59:11 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Guangming, It's not surprising to me that the backprojection is faster than the forward projection, that's what I expect. If the total time is longer, that's probably that some individual steps are not included in the total time. Can you try to add reader->Update(); before the line itk::TimeProbe totalTimeProbe; in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? Simon On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > Hi RTK community, > i am using SART algorithm to reconstruct an object. > But in this new RTK version, the time recording seems a little weird: > the total time is 1219.12s , but adding the time cost in different stages > is not 1291.12 s. especially for "backprojection" part, only 16.6051s to > reconstruct a 128^3 volume ?? even shorter than forward projection part. > BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, > both multi-threading i think. > Can anyone tell me what's going on? > Thanks > Regards > Guangming > > [image: ???? 1] > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 27 04:41:58 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 11:41:58 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, Thanks for your reply. would you pls help and explain why backprojection is expected to take shorter time than forward projection?? because i was thinking if no caching step, the backprojection should take much longer time than sart algorithm. yes, i run rtksart for 2 times once.it took 12xxs, similar to the time consumed of 3 times's sart, which much slower than my own application. BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 shapp-logan projections(512*512 resolution each) rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 and i will try reader->Update() like what you said. Thanks Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 8:59 GMT+03:00 Simon Rit : > Hi Guangming, > It's not surprising to me that the backprojection is faster than the > forward projection, that's what I expect. If the total time is longer, > that's probably that some individual steps are not included in the total > time. Can you try to add > reader->Update(); > before the line > > itk::TimeProbe totalTimeProbe; > > in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? > > Simon > > > > On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi RTK community, >> i am using SART algorithm to reconstruct an object. >> But in this new RTK version, the time recording seems a little weird: >> the total time is 1219.12s , but adding the time cost in different >> stages is not 1291.12 s. especially for "backprojection" part, only >> 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward >> projection part. BTW, the -f and -b are Joseph and >> VoxelBasedBackProjection, respectively, both multi-threading i think. >> Can anyone tell me what's going on? >> Thanks >> Regards >> Guangming >> >> [image: ???? 1] >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 08:28:28 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 14:28:28 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: I can try. Forward and back projection have the same algorithmic complexity but voxel based backprojection benefits from several optimizations in terms of memory management and computations that makes it faster. The best is to look at the code for further details... although both have far from being optimal. And I did not get the sentence "the backprojection should take much longer time than sart algorithm." because SART contains a backprojection and other steps so SART is obviously longer than the bp alone. Your log is strange and I don't see what steps are not timed that would take most of the time. I did the same test on my computer and here is my result: OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha --dimension 512 OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.288571 s Multiplication by zero: 0.131672 s Forward projection: 34.3612 s Subtraction: 0.203409 s Multiplication by lambda: 0.146459 s Ray box intersection: 1.30755 s Division: 0.187294 s Multiplication by the gating weights: 0 s Displaced detector: 0.278408 s Back projection: 11.8456 s Volume update: 0 s It took... 53.2765 s Simon On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang wrote: > Hi Simon, > Thanks for your reply. > would you pls help and explain why backprojection is expected to take > shorter time than forward projection?? because i was thinking if no caching > step, the backprojection should take much longer time than sart algorithm. > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > consumed of 3 times's sart, which much slower than my own application. > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > shapp-logan projections(512*512 resolution each) > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > -64,-64,-64 -l 0.5 -n 3 --time 1 > > and i will try reader->Update() like what you said. > Thanks > Guangming > > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> Hi Guangming, >> It's not surprising to me that the backprojection is faster than the >> forward projection, that's what I expect. If the total time is longer, >> that's probably that some individual steps are not included in the total >> time. Can you try to add >> reader->Update(); >> before the line >> >> itk::TimeProbe totalTimeProbe; >> >> in rtksart.cxx? It may be that all the reading operations are done but not >> timed in the sart->Update(). Why they are so long, I don't know, is your D: >> drive a network drive? Do you observe the same behavior if you do rtksart 2 >> times in a row? >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> wrote: >>> >>> Hi RTK community, >>> i am using SART algorithm to reconstruct an object. >>> But in this new RTK version, the time recording seems a little weird: >>> the total time is 1219.12s , but adding the time cost in different >>> stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s >>> to reconstruct a 128^3 volume ?? even shorter than forward projection part. >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, >>> both multi-threading i think. >>> Can anyone tell me what's going on? >>> Thanks >>> Regards >>> Guangming >>> >>> >>> Guangming Zang (Alex) >>> King Abdullah University of Science and Technology(KAUST) >>> University of Chinese Academy of Sciences(UCAS) >>> >>> >>> >>> >>> ________________________________ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete this >>> message from your computer system. Any unauthorized use or distribution is >>> prohibited. Please consider the environment before printing this email. >> >> > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 08:50:48 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 15:50:48 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, sorry for the mistake, not"the backprojection should take much longer time than sart algorithm" , but "the backprojection should take much longer time than forward projection in sart algorithm". BTW, how many cores does your computer have?? Mine is 24 cores. is it can explain the reason why it takes much longer time on my computer than yours? Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 15:28 GMT+03:00 Simon Rit : > I can try. Forward and back projection have the same algorithmic > complexity but voxel based backprojection benefits from several > optimizations in terms of memory management and computations that > makes it faster. The best is to look at the code for further > details... although both have far from being optimal. And I did not > get the sentence "the backprojection should take much longer time than > sart algorithm." because SART contains a backprojection and other > steps so SART is obviously longer than the bp alone. > Your log is strange and I don't see what steps are not timed that > would take most of the time. I did the same test on my computer and > here is my result: > > OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > --dimension 512 > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.288571 s > Multiplication by zero: 0.131672 s > Forward projection: 34.3612 s > Subtraction: 0.203409 s > Multiplication by lambda: 0.146459 s > Ray box intersection: 1.30755 s > Division: 0.187294 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.278408 s > Back projection: 11.8456 s > Volume update: 0 s > It took... 53.2765 s > > Simon > > On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > wrote: > > Hi Simon, > > Thanks for your reply. > > would you pls help and explain why backprojection is expected to take > > shorter time than forward projection?? because i was thinking if no > caching > > step, the backprojection should take much longer time than sart > algorithm. > > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > > consumed of 3 times's sart, which much slower than my own application. > > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > > shapp-logan projections(512*512 resolution each) > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > > -64,-64,-64 -l 0.5 -n 3 --time 1 > > > > and i will try reader->Update() like what you said. > > Thanks > > Guangming > > > > > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> > >> Hi Guangming, > >> It's not surprising to me that the backprojection is faster than the > >> forward projection, that's what I expect. If the total time is longer, > >> that's probably that some individual steps are not included in the total > >> time. Can you try to add > >> reader->Update(); > >> before the line > >> > >> itk::TimeProbe totalTimeProbe; > >> > >> in rtksart.cxx? It may be that all the reading operations are done but > not > >> timed in the sart->Update(). Why they are so long, I don't know, is > your D: > >> drive a network drive? Do you observe the same behavior if you do > rtksart 2 > >> times in a row? > >> > >> Simon > >> > >> > >> > >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> wrote: > >>> > >>> Hi RTK community, > >>> i am using SART algorithm to reconstruct an object. > >>> But in this new RTK version, the time recording seems a little weird: > >>> the total time is 1219.12s , but adding the time cost in different > >>> stages is not 1291.12 s. especially for "backprojection" part, only > 16.6051s > >>> to reconstruct a 128^3 volume ?? even shorter than forward projection > part. > >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > respectively, > >>> both multi-threading i think. > >>> Can anyone tell me what's going on? > >>> Thanks > >>> Regards > >>> Guangming > >>> > >>> > >>> Guangming Zang (Alex) > >>> King Abdullah University of Science and Technology(KAUST) > >>> University of Chinese Academy of Sciences(UCAS) > >>> > >>> > >>> > >>> > >>> ________________________________ > >>> This message and its contents, including attachments are intended > solely > >>> for the original recipient. If you are not the intended recipient or > have > >>> received this message in error, please notify me immediately and > delete this > >>> message from your computer system. Any unauthorized use or > distribution is > >>> prohibited. Please consider the environment before printing this email. > >> > >> > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 09:02:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 15:02:03 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: No I expect forward projection to be longer than backprojection although with optimal implementations, it should take about the same time since they have the same complexity. I have 4 cores on my laptop. I don't see how it explains it, try to find out where does SART spend the time. Simon On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang wrote: > Hi Simon, > sorry for the mistake, not"the backprojection should take much longer time > than > sart algorithm" , but "the backprojection should take much longer time than > forward projection in sart algorithm". > > BTW, how many cores does your computer have?? Mine is 24 cores. > is it can explain the reason why it takes much longer time on my computer > than yours? > Regards > Guangming > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> I can try. Forward and back projection have the same algorithmic >> complexity but voxel based backprojection benefits from several >> optimizations in terms of memory management and computations that >> makes it faster. The best is to look at the code for further >> details... although both have far from being optimal. And I did not >> get the sentence "the backprojection should take much longer time than >> sart algorithm." because SART contains a backprojection and other >> steps so SART is obviously longer than the bp alone. >> Your log is strange and I don't see what steps are not timed that >> would take most of the time. I did the same test on my computer and >> here is my result: >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> --dimension 512 >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> 1 >> Recording elapsed time... >> SARTConeBeamReconstructionFilter timing: >> Extraction of projection sub-stacks: 0.288571 s >> Multiplication by zero: 0.131672 s >> Forward projection: 34.3612 s >> Subtraction: 0.203409 s >> Multiplication by lambda: 0.146459 s >> Ray box intersection: 1.30755 s >> Division: 0.187294 s >> Multiplication by the gating weights: 0 s >> Displaced detector: 0.278408 s >> Back projection: 11.8456 s >> Volume update: 0 s >> It took... 53.2765 s >> >> Simon >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> wrote: >> > Hi Simon, >> > Thanks for your reply. >> > would you pls help and explain why backprojection is expected to take >> > shorter time than forward projection?? because i was thinking if no >> > caching >> > step, the backprojection should take much longer time than sart >> > algorithm. >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time >> > consumed of 3 times's sart, which much slower than my own application. >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 >> > shapp-logan projections(512*512 resolution each) >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> > >> > and i will try reader->Update() like what you said. >> > Thanks >> > Guangming >> > >> > >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> >> >> Hi Guangming, >> >> It's not surprising to me that the backprojection is faster than the >> >> forward projection, that's what I expect. If the total time is longer, >> >> that's probably that some individual steps are not included in the >> >> total >> >> time. Can you try to add >> >> reader->Update(); >> >> before the line >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done but >> >> not >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> your D: >> >> drive a network drive? Do you observe the same behavior if you do >> >> rtksart 2 >> >> times in a row? >> >> >> >> Simon >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> wrote: >> >>> >> >>> Hi RTK community, >> >>> i am using SART algorithm to reconstruct an object. >> >>> But in this new RTK version, the time recording seems a little weird: >> >>> the total time is 1219.12s , but adding the time cost in different >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >>> 16.6051s >> >>> to reconstruct a 128^3 volume ?? even shorter than forward projection >> >>> part. >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >>> respectively, >> >>> both multi-threading i think. >> >>> Can anyone tell me what's going on? >> >>> Thanks >> >>> Regards >> >>> Guangming >> >>> >> >>> >> >>> Guangming Zang (Alex) >> >>> King Abdullah University of Science and Technology(KAUST) >> >>> University of Chinese Academy of Sciences(UCAS) >> >>> >> >>> >> >>> >> >>> >> >>> ________________________________ >> >>> This message and its contents, including attachments are intended >> >>> solely >> >>> for the original recipient. If you are not the intended recipient or >> >>> have >> >>> received this message in error, please notify me immediately and >> >>> delete this >> >>> message from your computer system. Any unauthorized use or >> >>> distribution is >> >>> prohibited. Please consider the environment before printing this >> >>> email. >> >> >> >> >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended solely >> > for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> > this >> > message from your computer system. Any unauthorized use or distribution >> > is >> > prohibited. Please consider the environment before printing this email. > > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 10:05:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:05:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, it cost 1200s for SART algorithm at first, and the command are: rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 in which, the projections data(360pro_SL_Vol128_512.mha) is not generated from rtkprojectshepploganphantom , but from my application. though it took long time, but i can got a nice result, And i just tried the command you used, i.e. generated the projections data by rtkprojectshepploganphantom : rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 --sid=500.0 rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 yes, it takes about 56s. but the reconstructed result is weird, the voxel values range from [-142186, 208146] and can not see anything when visualizing it. i believe you got the similar results, which maybe explain why it computes much faster. if i wanna use the projections generated by rtkprojectshepploganphantom , can you give me an example to get a nice results? Best regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 16:02 GMT+03:00 Simon Rit : > No I expect forward projection to be longer than backprojection > although with optimal implementations, it should take about the same > time since they have the same complexity. > I have 4 cores on my laptop. I don't see how it explains it, try to > find out where does SART spend the time. > Simon > > On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang > wrote: > > Hi Simon, > > sorry for the mistake, not"the backprojection should take much longer > time > > than > > sart algorithm" , but "the backprojection should take much longer time > than > > forward projection in sart algorithm". > > > > BTW, how many cores does your computer have?? Mine is 24 cores. > > is it can explain the reason why it takes much longer time on my computer > > than yours? > > Regards > > Guangming > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : > >> > >> I can try. Forward and back projection have the same algorithmic > >> complexity but voxel based backprojection benefits from several > >> optimizations in terms of memory management and computations that > >> makes it faster. The best is to look at the code for further > >> details... although both have far from being optimal. And I did not > >> get the sentence "the backprojection should take much longer time than > >> sart algorithm." because SART contains a backprojection and other > >> steps so SART is obviously longer than the bp alone. > >> Your log is strange and I don't see what steps are not timed that > >> would take most of the time. I did the same test on my computer and > >> here is my result: > >> > >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > >> --dimension 512 > >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > >> 1 > >> Recording elapsed time... > >> SARTConeBeamReconstructionFilter timing: > >> Extraction of projection sub-stacks: 0.288571 s > >> Multiplication by zero: 0.131672 s > >> Forward projection: 34.3612 s > >> Subtraction: 0.203409 s > >> Multiplication by lambda: 0.146459 s > >> Ray box intersection: 1.30755 s > >> Division: 0.187294 s > >> Multiplication by the gating weights: 0 s > >> Displaced detector: 0.278408 s > >> Back projection: 11.8456 s > >> Volume update: 0 s > >> It took... 53.2765 s > >> > >> Simon > >> > >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > >> wrote: > >> > Hi Simon, > >> > Thanks for your reply. > >> > would you pls help and explain why backprojection is expected to take > >> > shorter time than forward projection?? because i was thinking if no > >> > caching > >> > step, the backprojection should take much longer time than sart > >> > algorithm. > >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the > time > >> > consumed of 3 times's sart, which much slower than my own application. > >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > >> > shapp-logan projections(512*512 resolution each) > >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > >> > -64,-64,-64 -l 0.5 -n 3 --time 1 > >> > > >> > and i will try reader->Update() like what you said. > >> > Thanks > >> > Guangming > >> > > >> > > >> > > >> > Guangming Zang (Alex) > >> > King Abdullah University of Science and Technology(KAUST) > >> > University of Chinese Academy of Sciences(UCAS) > >> > > >> > > >> > > >> > > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> >> > >> >> Hi Guangming, > >> >> It's not surprising to me that the backprojection is faster than the > >> >> forward projection, that's what I expect. If the total time is > longer, > >> >> that's probably that some individual steps are not included in the > >> >> total > >> >> time. Can you try to add > >> >> reader->Update(); > >> >> before the line > >> >> > >> >> itk::TimeProbe totalTimeProbe; > >> >> > >> >> in rtksart.cxx? It may be that all the reading operations are done > but > >> >> not > >> >> timed in the sart->Update(). Why they are so long, I don't know, is > >> >> your D: > >> >> drive a network drive? Do you observe the same behavior if you do > >> >> rtksart 2 > >> >> times in a row? > >> >> > >> >> Simon > >> >> > >> >> > >> >> > >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> >> wrote: > >> >>> > >> >>> Hi RTK community, > >> >>> i am using SART algorithm to reconstruct an object. > >> >>> But in this new RTK version, the time recording seems a little > weird: > >> >>> the total time is 1219.12s , but adding the time cost in different > >> >>> stages is not 1291.12 s. especially for "backprojection" part, only > >> >>> 16.6051s > >> >>> to reconstruct a 128^3 volume ?? even shorter than forward > projection > >> >>> part. > >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > >> >>> respectively, > >> >>> both multi-threading i think. > >> >>> Can anyone tell me what's going on? > >> >>> Thanks > >> >>> Regards > >> >>> Guangming > >> >>> > >> >>> > >> >>> Guangming Zang (Alex) > >> >>> King Abdullah University of Science and Technology(KAUST) > >> >>> University of Chinese Academy of Sciences(UCAS) > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> ________________________________ > >> >>> This message and its contents, including attachments are intended > >> >>> solely > >> >>> for the original recipient. If you are not the intended recipient or > >> >>> have > >> >>> received this message in error, please notify me immediately and > >> >>> delete this > >> >>> message from your computer system. Any unauthorized use or > >> >>> distribution is > >> >>> prohibited. Please consider the environment before printing this > >> >>> email. > >> >> > >> >> > >> > > >> > > >> > ________________________________ > >> > This message and its contents, including attachments are intended > solely > >> > for > >> > the original recipient. If you are not the intended recipient or have > >> > received this message in error, please notify me immediately and > delete > >> > this > >> > message from your computer system. Any unauthorized use or > distribution > >> > is > >> > prohibited. Please consider the environment before printing this > email. > > > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 10:12:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:12:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: BTW, the projections are 512*512, and the pixel spacing is 0.5 Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:05 GMT+03:00 Guangming Zang : > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 10:20:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 16:20:12 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Obviously I hadn't looked at the result and/or checked the command line options, sorry. This is an example from the same simulated dataset that gives me a good results: OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.567773 s Multiplication by zero: 0.303715 s Forward projection: 142.305 s Subtraction: 0.445842 s Multiplication by lambda: 0.2663 s Ray box intersection: 5.40366 s Division: 0.535618 s Multiplication by the gating weights: 0 s Displaced detector: 0.415431 s Back projection: 21.3689 s Volume update: 0 s It took... 177.059 s but this doesn't change the content of my previous message. What takes time is probably in your own software, be sure that you update SART inputs before timing it. Simon On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang wrote: > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 11:12:16 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 18:12:16 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Thanks Simon, now it work fine when using projections generated by RTK itself (command rtkprojectshepploganphantom ). for 1 iteration of SART to reconstruct 128^3 size volume, it took only 19s, which gives nice results as well. Thanks again. Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:20 GMT+03:00 Simon Rit : > Obviously I hadn't looked at the result and/or checked the command line > options, sorry. This is an example from the same simulated dataset that > gives me a good results: > > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f > Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n > 3 --time 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.567773 s > Multiplication by zero: 0.303715 s > Forward projection: 142.305 s > Subtraction: 0.445842 s > Multiplication by lambda: 0.2663 s > Ray box intersection: 5.40366 s > Division: 0.535618 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.415431 s > Back projection: 21.3689 s > Volume update: 0 s > It took... 177.059 s > > but this doesn't change the content of my previous message. What takes > time is probably in your own software, be sure that you update SART inputs > before timing it. > Simon > > On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon, >> it cost 1200s for SART algorithm at first, and the command are: >> rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd= >> 725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" >> >> rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 >> >> in which, the projections data(360pro_SL_Vol128_512.mha) is not >> generated from rtkprojectshepploganphantom , but from my application. >> though it took long time, but i can got a nice result, >> >> >> And i just tried the command you used, i.e. generated the projections >> data by rtkprojectshepploganphantom : >> >> rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 >> --sid=500.0 >> rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 >> rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b >> VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 >> --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 >> yes, it takes about 56s. >> but the reconstructed result is weird, the voxel values range from >> [-142186, 208146] and can not see anything when visualizing it. >> i believe you got the similar results, which maybe explain why it >> computes much faster. >> >> if i wanna use the projections generated by rtkprojectshepploganphantom >> , can you give me an example to get a nice results? >> >> Best regards >> Guangming >> >> >> >> >> >> >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> 2015-07-27 16:02 GMT+03:00 Simon Rit : >> >>> No I expect forward projection to be longer than backprojection >>> although with optimal implementations, it should take about the same >>> time since they have the same complexity. >>> I have 4 cores on my laptop. I don't see how it explains it, try to >>> find out where does SART spend the time. >>> Simon >>> >>> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >>> wrote: >>> > Hi Simon, >>> > sorry for the mistake, not"the backprojection should take much longer >>> time >>> > than >>> > sart algorithm" , but "the backprojection should take much longer time >>> than >>> > forward projection in sart algorithm". >>> > >>> > BTW, how many cores does your computer have?? Mine is 24 cores. >>> > is it can explain the reason why it takes much longer time on my >>> computer >>> > than yours? >>> > Regards >>> > Guangming >>> > >>> > Guangming Zang (Alex) >>> > King Abdullah University of Science and Technology(KAUST) >>> > University of Chinese Academy of Sciences(UCAS) >>> > >>> > >>> > >>> > >>> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >>> >> >>> >> I can try. Forward and back projection have the same algorithmic >>> >> complexity but voxel based backprojection benefits from several >>> >> optimizations in terms of memory management and computations that >>> >> makes it faster. The best is to look at the code for further >>> >> details... although both have far from being optimal. And I did not >>> >> get the sentence "the backprojection should take much longer time than >>> >> sart algorithm." because SART contains a backprojection and other >>> >> steps so SART is obviously longer than the bp alone. >>> >> Your log is strange and I don't see what steps are not timed that >>> >> would take most of the time. I did the same test on my computer and >>> >> here is my result: >>> >> >>> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >>> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >>> >> --dimension 512 >>> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >>> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >>> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >>> >> 1 >>> >> Recording elapsed time... >>> >> SARTConeBeamReconstructionFilter timing: >>> >> Extraction of projection sub-stacks: 0.288571 s >>> >> Multiplication by zero: 0.131672 s >>> >> Forward projection: 34.3612 s >>> >> Subtraction: 0.203409 s >>> >> Multiplication by lambda: 0.146459 s >>> >> Ray box intersection: 1.30755 s >>> >> Division: 0.187294 s >>> >> Multiplication by the gating weights: 0 s >>> >> Displaced detector: 0.278408 s >>> >> Back projection: 11.8456 s >>> >> Volume update: 0 s >>> >> It took... 53.2765 s >>> >> >>> >> Simon >>> >> >>> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >>> >> wrote: >>> >> > Hi Simon, >>> >> > Thanks for your reply. >>> >> > would you pls help and explain why backprojection is expected to >>> take >>> >> > shorter time than forward projection?? because i was thinking if no >>> >> > caching >>> >> > step, the backprojection should take much longer time than sart >>> >> > algorithm. >>> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >>> time >>> >> > consumed of 3 times's sart, which much slower than my own >>> application. >>> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >>> 360 >>> >> > shapp-logan projections(512*512 resolution each) >>> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >>> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >>> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >>> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >>> >> > >>> >> > and i will try reader->Update() like what you said. >>> >> > Thanks >>> >> > Guangming >>> >> > >>> >> > >>> >> > >>> >> > Guangming Zang (Alex) >>> >> > King Abdullah University of Science and Technology(KAUST) >>> >> > University of Chinese Academy of Sciences(UCAS) >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit >> >: >>> >> >> >>> >> >> Hi Guangming, >>> >> >> It's not surprising to me that the backprojection is faster than >>> the >>> >> >> forward projection, that's what I expect. If the total time is >>> longer, >>> >> >> that's probably that some individual steps are not included in the >>> >> >> total >>> >> >> time. Can you try to add >>> >> >> reader->Update(); >>> >> >> before the line >>> >> >> >>> >> >> itk::TimeProbe totalTimeProbe; >>> >> >> >>> >> >> in rtksart.cxx? It may be that all the reading operations are done >>> but >>> >> >> not >>> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >>> >> >> your D: >>> >> >> drive a network drive? Do you observe the same behavior if you do >>> >> >> rtksart 2 >>> >> >> times in a row? >>> >> >> >>> >> >> Simon >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >>> >> >> wrote: >>> >> >>> >>> >> >>> Hi RTK community, >>> >> >>> i am using SART algorithm to reconstruct an object. >>> >> >>> But in this new RTK version, the time recording seems a little >>> weird: >>> >> >>> the total time is 1219.12s , but adding the time cost in >>> different >>> >> >>> stages is not 1291.12 s. especially for "backprojection" part, >>> only >>> >> >>> 16.6051s >>> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >>> projection >>> >> >>> part. >>> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >>> >> >>> respectively, >>> >> >>> both multi-threading i think. >>> >> >>> Can anyone tell me what's going on? >>> >> >>> Thanks >>> >> >>> Regards >>> >> >>> Guangming >>> >> >>> >>> >> >>> >>> >> >>> Guangming Zang (Alex) >>> >> >>> King Abdullah University of Science and Technology(KAUST) >>> >> >>> University of Chinese Academy of Sciences(UCAS) >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> ________________________________ >>> >> >>> This message and its contents, including attachments are intended >>> >> >>> solely >>> >> >>> for the original recipient. If you are not the intended recipient >>> or >>> >> >>> have >>> >> >>> received this message in error, please notify me immediately and >>> >> >>> delete this >>> >> >>> message from your computer system. Any unauthorized use or >>> >> >>> distribution is >>> >> >>> prohibited. Please consider the environment before printing this >>> >> >>> email. >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > ________________________________ >>> >> > This message and its contents, including attachments are intended >>> solely >>> >> > for >>> >> > the original recipient. If you are not the intended recipient or >>> have >>> >> > received this message in error, please notify me immediately and >>> delete >>> >> > this >>> >> > message from your computer system. Any unauthorized use or >>> distribution >>> >> > is >>> >> > prohibited. Please consider the environment before printing this >>> email. >>> > >>> > >>> > >>> > ________________________________ >>> > This message and its contents, including attachments are intended >>> solely for >>> > the original recipient. If you are not the intended recipient or have >>> > received this message in error, please notify me immediately and >>> delete this >>> > message from your computer system. Any unauthorized use or >>> distribution is >>> > prohibited. Please consider the environment before printing this email. >>> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From infrombox at yandex.ru Tue Jul 28 04:30:22 2015 From: infrombox at yandex.ru (1 1) Date: Tue, 28 Jul 2015 15:30:22 +0700 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: <2213081438072222@web8j.yandex.ru> Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. But program which i use reads meta images with MET_SHORT pixel type only. Is there easy way to setting it and get volume with different from MET_FLOAT pixel type ? If not, could you advice me, what the filter i should to do, for example as post process after reconstruction ala MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward operation of LUTbasedVariableI0RawToAttenuationImageFilter ? Thanks. From simon.rit at creatis.insa-lyon.fr Tue Jul 28 04:56:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 10:56:54 +0200 Subject: [Rtk-users] volume with diffieret pixel type In-Reply-To: <2213081438072222@web8j.yandex.ru> References: <2213081438072222@web8j.yandex.ru> Message-ID: Hi, This is more an ITK question than a RTK question. Yes, we use float by default in our applications. You can cast the image to any type before writing using itk::CastImageFilter but you'll have to modify the applications and, of course, there is a loss of information. If you don't want to program it, you can use any other software, e.g. in vv right clik on your image after opening and use the convert to option. Simon On Tue, Jul 28, 2015 at 10:30 AM, 1 1 wrote: > Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. > But program which i use reads meta images with MET_SHORT pixel type only. > Is there easy way to setting it and get volume with different from > MET_FLOAT pixel type ? If not, could you advice me, what the filter i > should to do, for example as post process after reconstruction ala > MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward > operation of LUTbasedVariableI0RawToAttenuationImageFilter image, float image> ? > Thanks. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pconneely020186 at gmail.com Tue Jul 28 12:05:29 2015 From: pconneely020186 at gmail.com (peter conneely) Date: Tue, 28 Jul 2015 17:05:29 +0100 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: "peter conneely" Date: 24 Jul 2015 11:07 Subject: Issue running FDK reconstruction algorithm To: Cc: Hi, I'm having trouble running the FDK reconstruction alogrithm on Elekta and Varian data sets. The algorithm does work when I try the shepp-logan example. When I initially ran the application I included the (') around .*.his. and got the following lines. [image: Inline image 1] when I try to run with the (') removed it finds the 669 files but then the application stops working. I have tried adding registry edits to run exe and have tried switching of dep. Neither of these work I am not sure what is going wrong and how to fix it. My system properties are as follows. Processor: Intel Pentium CPU P6100 @ 2.00 Ghz RAM: 3.00 GB GPU: Intel HD Graphics Systems type 64 Bit. Thanks and Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Tue Jul 28 12:46:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 18:46:17 +0200 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: Hi, I guess the quotes are OS depedent, maybe you need double quotes on Windows. It's strange that you don't get an error message. Are you sure it crashed? If yes, have you checked the elektaGeometry file? Does it have 669 projection sections as expected? Or maybe it's a memory issue, try the --lowmem option. Simon On Tue, Jul 28, 2015 at 6:05 PM, peter conneely wrote: > ---------- Forwarded message ---------- > From: "peter conneely" > Date: 24 Jul 2015 11:07 > Subject: Issue running FDK reconstruction algorithm > To: > Cc: > > Hi, > > I'm having trouble running the FDK reconstruction alogrithm on Elekta and > Varian data sets. The algorithm does work when I try the shepp-logan > example. > > When I initially ran the application I included the (') around .*.his. and > got the following lines. > [image: Inline image 1] > when I try to run with the (') removed it finds the 669 files but then the > application stops working. I have tried adding registry edits to run exe > and have tried switching of dep. Neither of these work I am not sure what > is going wrong and how to fix it. > > My system properties are as follows. > Processor: Intel Pentium CPU P6100 @ 2.00 Ghz > RAM: 3.00 GB > GPU: Intel HD Graphics > Systems type 64 Bit. > > Thanks and Regards, > Peter > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Tue Jul 28 13:38:45 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Tue, 28 Jul 2015 20:38:45 +0300 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: Hi, in ITK, the default type are described in *Utilities\MetaIO\metaTypes.h* MET_CHAR, MET_UCHAR ?,? ?? MET_SHORT, MET_USHORT, MET_INT,=20 MET_UINT,=20 MET_FLOAT,=20 MET_DOUBLE, ?and for .mha file, the header file includes information like: ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = 0 0 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 1 1 1 DimSize = 128 128 128 ElementType = MET_FLOAT ElementDataFile = LOCAL? ?And recently i just programmed to read and write .mha files. below is the code. u can just replace ElementType from ? MET_FLOAT ? to ? ? MET_SHORT ? in your application. hope this helps: #include "stdafx.h" #include #include #include #include #include #include using namespace std; int _tmain(int argc, _TCHAR* argv[]) { int m_Dims[3]; float spacing[3]; m_Dims[0]=128; m_Dims[1]=128; m_Dims[2]=128; spacing[0]=spacing[1]=spacing[2]=1.0f; ostringstream buffer, buffer1, buffer2, buf3; buffer << spacing[0]; string sp= buffer.str(); buffer1 << spacing[1]; string sp1 = buffer1.str(); buffer2 << spacing[2]; string sp2 = buffer2.str(); string ElementSpacing ="ElementSpacing= "+sp+" "+sp1+" "+sp2+"\n"; // int ss=1000; char temp[64], temp1[64],temp2[64]; string str; sprintf(temp, "%d", m_Dims[0]); sprintf(temp1, "%d", m_Dims[1]); sprintf(temp2, "%d", m_Dims[2]); string s(temp),s1(temp1),s2(temp2); string DimSize="DimSize= "+s+" "+s1+" "+s2+"\n"; string Mywritefile="ObjectType = Image\nNDims = 3\nBinaryData = True\nBinaryDataByteOrderMSB = False \nCompressedData = False \nTransformMatrix = 1 0 0 0 1 0 0 0 1 \n" ; Mywritefile+="Offset = 0 0 0 \nCenterOfRotation = 0 0 0 \nAnatomicalOrientation = RAI \n"; Mywritefile+=ElementSpacing+DimSize+"ElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; // ElementSpacing = 1 1 1 \nDimSize = 128 128 128 \nElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; int leng=Mywritefile.length(); cout< From simon.rit at creatis.insa-lyon.fr Wed Jul 29 08:53:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 29 Jul 2015 14:53:34 +0200 Subject: [Rtk-users] RTK images make the cover of Medical Physics Message-ID: See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Wed Jul 29 09:07:01 2015 From: theday79 at gmail.com (Yang K Park) Date: Wed, 29 Jul 2015 09:07:01 -0400 Subject: [Rtk-users] RTK images make the cover of Medical Physics In-Reply-To: References: Message-ID: <001801d0c9ff$76797860$636c6920$@gmail.com> Hi Simon, Thank you so much for the congrats! This is my great honor and I?d like to thank all the RTK developers and community members for their helps on this achievement! Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: Wednesday, July 29, 2015 8:54 AM To: rtk-users at public.kitware.com Subject: [Rtk-users] RTK images make the cover of Medical Physics See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Thu Jul 30 08:16:38 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Thu, 30 Jul 2015 15:16:38 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK Message-ID: Hi Simon and Chao, i am currently do some comparisons between different reconstruction methods for Shapp-Logan dataset. the commands are: rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=955.4050067 --sid=500.0 rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha --dimension 512,512 when using FDK or SART algorithm from RTK, I can got pretty good results indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 and levels as 1.04 for all results got). When running ADMMTV command below, though the geometry is as same as SART and FDK, the result got from ADMM looks weird.(pls see attached central slice of ground truth and ADMM, same contrast with other algorithm) rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 [image: ???? 1][image: ???? 2] Is it because the CG algorithm used by ADMM, or parameters setting issues here?? if it is parameters setting problem , would you help me and give a nice values for alpha and bate used here? BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already (including default value) Thanks and regards Guangming ?? *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ? -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 31 01:55:32 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 31 Jul 2015 07:55:32 +0200 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi, It looks to me that you haven't converged. I'm not the specialist of this algorithm and the specialist won't be near a computer in the coming weeks but when I try with more iterations in the data attachment term: rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 it's more satisfactory. There are rings at the top and the bottom of the cone-beam which should be reduced with more TV (greater alpha, see doc here ) or with a finer spacing (see this publication ). Simon On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang wrote: > Hi Simon and Chao, > > i am currently do some comparisons between different reconstruction > methods for Shapp-Logan dataset. > > the commands are: > > rtksimulatedgeometry -n 360 --arc -360 -o > geo.xml --sdd=955.4050067 --sid=500.0 > > rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha > --dimension 512,512 > > > > when using FDK or SART algorithm from RTK, I can got pretty good results > indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 > and levels as 1.04 for all results got). When running ADMMTV command below, > though the geometry is as same as SART and FDK, the result got from ADMM > looks weird.(pls see attached central slice of ground truth and ADMM, same > contrast with other algorithm) > > rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o > SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 > --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 > > [image: ???? 1][image: ???? 2] > > Is it because the CG algorithm used by ADMM, or parameters setting issues > here?? if it is parameters setting problem , would you help me and give a > nice values for alpha and bate used here? > > BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already > (including default value) > > Thanks and regards > > Guangming > > > ?? > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > ? > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Fri Jul 31 09:46:41 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 31 Jul 2015 16:46:41 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi simon, i see, thanks for the help and explanation. after following your advice, it works fine now. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-31 8:55 GMT+03:00 Simon Rit : > Hi, > It looks to me that you haven't converged. I'm not the specialist of this > algorithm and the specialist won't be near a computer in the coming weeks > but when I try with more iterations in the data attachment term: > rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml > --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 > it's more satisfactory. There are rings at the top and the bottom of the > cone-beam which should be reduced with more TV (greater alpha, see doc > here > ) > or with a finer spacing (see this publication > ). > Simon > > On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon and Chao, >> >> i am currently do some comparisons between different reconstruction >> methods for Shapp-Logan dataset. >> >> the commands are: >> >> rtksimulatedgeometry -n 360 --arc -360 -o >> geo.xml --sdd=955.4050067 --sid=500.0 >> >> rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha >> --dimension 512,512 >> >> >> >> when using FDK or SART algorithm from RTK, I can got pretty good results >> indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 >> and levels as 1.04 for all results got). When running ADMMTV command below, >> though the geometry is as same as SART and FDK, the result got from ADMM >> looks weird.(pls see attached central slice of ground truth and ADMM, same >> contrast with other algorithm) >> >> rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o >> SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 >> --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 >> >> [image: ???? 1][image: ???? 2] >> >> Is it because the CG algorithm used by ADMM, or parameters setting issues >> here?? if it is parameters setting problem , would you help me and give a >> nice values for alpha and bate used here? >> >> BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already >> (including default value) >> >> Thanks and regards >> >> Guangming >> >> >> ?? >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> ? >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 1 08:45:35 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 1 Jul 2015 14:45:35 +0200 Subject: [Rtk-users] Release of RTK v1.1.0 Message-ID: Dear RTK users, RTK v1.1.0 has been released today, about 14 months after RTK v1.0.0. The main features that have been developed since the previous release are: - SimpleRTK to run RTK filters (even the CUDA ones) from python scripts, C# code, and more - new projection pre-processing options (i0 calculation, scatter correction, water pre-correction) - extraction of the respiratory phase from cone-beam projections - linear programming for field-of-view computation based on a third party software, lp solve 5.5 - management of off-center detector in iterative methods - new iterative 3D and 4D reconstruction methods with Daubechies wavelets regularization - new iterative 4D reconstruction method with motion-aware regularization - reduction of memory footprint, especially GPU memory - many new CUDA filters - more robust (many bugs and memory leaks fixed) - use of MathJax to display formulas in the documentation, e.g., here . Many thanks to the increasing number of contributors, in alphabetical order: Ben Champion, Chao Wu, Cyril Mory, I Putu Susila, Julien Jomier, Marc Vila, Mathieu Dupont, Matt Clarkson, Peter Keuschnigg, S?bastien Brousmiche, Simon Rit, Tristan Coulange, Yang K Park. We don't focus on releases since we have a public github repository that we try to keep stable, I still recommend the use of the master HEAD over releases to enjoy the new RTK developments before their release. We still have a few on-going projects for which we will use and enhance RTK. Simon (for the RTK consortium) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 1 15:39:14 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 1 Jul 2015 21:39:14 +0200 Subject: [Rtk-users] loading projection images for sart Message-ID: Hello, I got compiled the ITK and RTK with help of cmake. I also had a look at the examples coming with RTK. I want to run a simple SART and got projection images in the format PNG and BMP. So I create an instance of the ThreeDcircularProjectionGeometry, SARTConeBeamReconstructionFilter and add the geometric projection data. rtk::ThreeDCircularProjectionGeometry::Pointer geometry; geometry = rtk::ThreeDCircularProjectionGeometry::New(); geometry->AddProjection(??) rtk::SARTConeBeamReconstructionFilter::Pointer sart = rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); How to add a stack of images to the SART reconstruction, i.e. std::vector images ? I got xray projections in png format. There is a method in the SART class called SetInput. But according tot he examples it is used to set a volume. Does anybody alread wrote a small piece of code that loads some images from the disk and put them into the SART reconstruction ? Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 2 12:19:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 2 Jul 2015 18:19:36 +0200 Subject: [Rtk-users] loading projection images for sart In-Reply-To: References: Message-ID: Hi, The stack of 2D images is passed via a 3D image. Look at the rtksart application for example. A way to read this from a set of file names is to use itk::ImageSeriesReader as done in rtk::ProjectionsReader. You should be able to understand how it works by looking at the existing RTK applications in the applications subfolders. Simon On Wed, Jul 1, 2015 at 9:39 PM, Robert Callie? wrote: > Hello, > > I got compiled the ITK and RTK with help of cmake. I also had a look > > at the examples coming with RTK. I want to run a simple SART and > > got projection images in the format PNG and BMP. > > > > So I create an instance of the ThreeDcircularProjectionGeometry, > SARTConeBeamReconstructionFilter > > and add the geometric projection data. > > > > rtk::ThreeDCircularProjectionGeometry::Pointer geometry; > > geometry = rtk::ThreeDCircularProjectionGeometry::New(); > > geometry->AddProjection(??) > > > > rtk::SARTConeBeamReconstructionFilter::Pointer sart = > rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); > > > > How to add a stack of images to the SART reconstruction, i.e. > std::vector images ? > > I got xray projections in png format. > > > > There is a method in the SART class called SetInput. But according tot he > examples it is used to set a volume. > > > > Does anybody alread wrote a small piece of code that loads some images > from the disk and put them into the SART reconstruction ? > > > > Regards, > > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Fri Jul 3 16:28:11 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 3 Jul 2015 23:28:11 +0300 Subject: [Rtk-users] Remote Control Issue in new RTK version Message-ID: Dear RTK community, There is some bug in RTK 1.1 version. That?s : When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 but i did not use Cuda at all.. What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. So i think it is some problem caused by itk ?? can we fix this issue?? Thanks for help in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Sat Jul 4 10:12:03 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Sat, 4 Jul 2015 17:12:03 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. Thanks for the help, Chao. *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ---------- Forwarded message ---------- From: Chao Wu Date: 2015-07-04 0:04 GMT+03:00 Subject: Re: Remote Control Issue To: Guangming Zang Cc: rtk-users-request at public.kitware.com, Simon Rit < simon.rit at creatis.insa-lyon.fr> Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. Regards, Chao Sent from Samsung Galaxy Note 3 2015?7?3? 10:26 PM? "Guangming Zang" ??? > Dear RTK community, > > There is some bug in RTK 1.1 version. That?s : > > When i run commands In 1.1 version with my computer in the lab, RTK works > fine, but when i use my laptop at home to remote control the computer in > the lab, it does not work. i.e., no matter the command are (rtkfdk, > ADMM,SART ?), an error is always shown: > > ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 > @ unknown : Cuda Error #3 > > but i did not use Cuda at all.. > > What?s more, when i run the 1.0 version RTK , it works well and no bug in > remoter control mode. > > So i think it is some problem caused by itk ?? can we fix this issue?? > > Thanks for help in advance > > > Regards > > Guangming > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Sat Jul 4 10:19:32 2015 From: ghostcz at hotmail.com (louie L) Date: Sat, 4 Jul 2015 16:19:32 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: I think because in most cases people use their graphics in TCC mode for scientific computations or don't use gpu at all where the rtk_use_cuda is false. Cheers, Louie Sent from my iOS > On 04 Jul 2015, at 16:12, Guangming Zang wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > > 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> Dear RTK community, >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> >> Regards >> >> Guangming >> >> Guangming Zang (Alex) >> King Abdullah University of Science and Technology(KAUST) >> University of Chinese Academy of Sciences(UCAS) >> >> >> >> >> This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > > > This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Mon Jul 6 05:32:18 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 6 Jul 2015 11:32:18 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Hi Guangming and all, Thanks for reporting this change of behavior. My first answer is that what you find simple is not so simple... but you're right, v1.0.0 allowed to compile RTK with CUDA and to run it without a CUDA device. After a bit of trakcing, I found that the change of behavior has been introduced with this patch so you can blame me. It has now fixed this issue with this patch , which seems to work on my laptop, I hope it does on your computer as well. I can't help you with the fact that you can't run CUDA software with remote control. Simon On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > I think because in most cases people use their graphics in TCC mode for > scientific computations or don't use gpu at all where the rtk_use_cuda is > false. > Cheers, > > Louie > > Sent from my iOS > > On 04 Jul 2015, at 16:12, Guangming Zang > wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes > to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is > defined, then if CUDA device is not available this error will occur. When > using MS remote desktop, graphical card and driver are bypassed unless it > is Tesla cards working in TCC mode. You can either compile exes without > CUDA for remote desktop, or try other graphic-based remote desktop software > like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > 2015?7?3? 10:26 PM? "Guangming Zang" ??? > >> Dear RTK community, >> >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works >> fine, but when i use my laptop at home to remote control the computer in >> the lab, it does not work. i.e., no matter the command are (rtkfdk, >> ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >> @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in >> remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> Regards >> >> Guangming >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 6 06:19:10 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 6 Jul 2015 13:19:10 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Thanks all for your help,Simon. I will try it again when i am at home :) As for using Cuda in remote control, i can handle it:just like what Chao said, change lab computer to TCC. What confused me at the beginning is that a cuda error shown while i did not call cuda at all, and thanks for fixing it. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-06 12:32 GMT+03:00 Simon Rit : > Hi Guangming and all, > Thanks for reporting this change of behavior. My first answer is that what > you find simple is not so simple... but you're right, v1.0.0 allowed to > compile RTK with CUDA and to run it without a CUDA device. After a bit of > trakcing, I found that the change of behavior has been introduced with this > patch > > so you can blame me. It has now fixed this issue with this patch > , > which seems to work on my laptop, I hope it does on your computer as well. > I can't help you with the fact that you can't run CUDA software with > remote control. > Simon > > On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > >> I think because in most cases people use their graphics in TCC mode for >> scientific computations or don't use gpu at all where the rtk_use_cuda is >> false. >> Cheers, >> >> Louie >> >> Sent from my iOS >> >> On 04 Jul 2015, at 16:12, Guangming Zang >> wrote: >> >> Ok, i see. Though i still do not understand why in new version rtk >> changes to call cudaimages, not keeping it simple like before. >> Thanks for the help, Chao. >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ---------- Forwarded message ---------- >> From: Chao Wu >> Date: 2015-07-04 0:04 GMT+03:00 >> Subject: Re: Remote Control Issue >> To: Guangming Zang >> Cc: rtk-users-request at public.kitware.com, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> >> >> Now in many exes cudaimage is the default image type if rtk_use_cuda is >> defined, then if CUDA device is not available this error will occur. When >> using MS remote desktop, graphical card and driver are bypassed unless it >> is Tesla cards working in TCC mode. You can either compile exes without >> CUDA for remote desktop, or try other graphic-based remote desktop software >> like vnc or teamviewer. >> >> Regards, Chao >> Sent from Samsung Galaxy Note 3 >> 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> >>> Dear RTK community, >>> >>> There is some bug in RTK 1.1 version. That?s : >>> >>> When i run commands In 1.1 version with my computer in the lab, RTK >>> works fine, but when i use my laptop at home to remote control the >>> computer in the lab, it does not work. i.e., no matter the command are >>> (rtkfdk, ADMM,SART ?), an error is always shown: >>> >>> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >>> @ unknown : Cuda Error #3 >>> >>> but i did not use Cuda at all.. >>> >>> What?s more, when i run the 1.0 version RTK , it works well and no bug >>> in remoter control mode. >>> >>> So i think it is some problem caused by itk ?? can we fix this issue?? >>> >>> Thanks for help in advance >>> >>> >>> Regards >>> >>> Guangming >>> *Guangming Zang (Alex)* >>> *King Abdullah University of Science and Technology(KAUST)* >>> *University of Chinese Academy of Sciences(UCAS)* >>> >>> >>> >>> >>> ------------------------------ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete >>> this message from your computer system. Any unauthorized use or >>> distribution is prohibited. Please consider the environment before printing >>> this email. >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Wed Jul 8 22:26:29 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Wed, 8 Jul 2015 19:26:29 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question Message-ID: Hi, I have a question from you about the CT reconstruction, I would really appreciate if you can help me with this. I have the geometry as described in following and I am trying to run the rtkfdk code from RTK. % parameters % % % % % % % param.nx = 500; % number of voxels param.ny = 500; param.nz = 500; param.sx = 5000; % mm (real size) param.sy = 5000; % mm param.sz = 5000; % mm %The real detector panel pixel density (number of pixels) param.nu = 36; % number of pixels param.nv = 100; % Detector setting (real size) param.su = 7200; % mm (real size) param.sv = 9200; % mm % X-ray source and detector setting param.DSD = 32900; % Distance source to detector param.DSO = 27400; % X-ray source to object axis distance % angle setting param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) param.dang = 5; % angular step size (deg) param.deg = 0:param.dang:360-1; % you can change param.deg = param.deg*param.dir; param.nProj = length(param.deg); param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than 360 deg -> param.parker=1 param.filter='ram-lak'; % high pass filter param.dx = param.sx/param.nx; % single voxel size param.dy = param.sy/param.ny; param.dz = param.sz/param.nz; param.du = param.su/param.nu; param.dv = param.sv/param.nv; param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) % Geometry calculation % % % param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : 360). But I got confused how to set the geometry parameters in RTK I followed the rtkfdk tutorial but I can?t get any result using this method I did the following: 1- Create geometry.xml using these parameters: nproj = 72 ; first_angle = 0 ; arc = 360 ; sid = 27400 ; sdd = 32900 ; proj_iso_x = 0; proj_iso_y = 0; out_angle = 0 ; in_angle = 0 ; source_x = 0; source_y = 0 ; 2- Create my own mha file (WriteMhaFile.m) from my projection array (36*100*72) using a matlab code with following properties: Voxel size = [0.1 0.1 0.1] Offset = [1 1 1] 3- Then run the: rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 --dimension 500 Could you please tell me if I am setting the geometry correctly? Also, is there any other way to create my own mha file? Thank you in advance and looking forward to hear back from you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 02:23:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 08:23:36 +0200 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Hi, We can try to help but we need to understand your geometry... Where does it come from by the way? If I understand your geometry correctly, I would say : - sid, sdd, nproj, arc are correct, - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 and you have 36x100 pixels, then the pixel size is [200,92,1] (last dimension is not used so anything). For the volume, if your volume is 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and not 0.1. - offset of projections is probably wrong. If you want to have a centered projections, you'll need something like (-3500, -554, 0). You can set is to 0 and put those values in proj_iso_x and proj_iso_y. Regarding mha file, you can write mha files in many ways, using SimpleRTK, matlab or writing an ITK code. Good luck! Simon On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah wrote: > Hi, > > I have a question from you about the CT reconstruction, I would really > appreciate if you can help me with this. > > I have the geometry as described in following and I am trying to run the > rtkfdk code from RTK. > > > % parameters % % % % % % % > > param.nx = 500; % number of voxels > param.ny = 500; > param.nz = 500; > > > param.sx = 5000; % mm (real size) > param.sy = 5000; % mm > param.sz = 5000; % mm > > > %The real detector panel pixel density (number of pixels) > param.nu = 36; % number of pixels > param.nv = 100; > > % Detector setting (real size) > param.su = 7200; % mm (real size) > param.sv = 9200; % mm > > > % X-ray source and detector setting > param.DSD = 32900; % Distance source to detector > param.DSO = 27400; % X-ray source to object axis distance > > > % angle setting > param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) > param.dang = 5; % angular step size (deg) > param.deg = 0:param.dang:360-1; % you can change > param.deg = param.deg*param.dir; > param.nProj = length(param.deg); > > param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than > 360 deg -> param.parker=1 > > param.filter='ram-lak'; % high pass filter > > > param.dx = param.sx/param.nx; % single voxel size > param.dy = param.sy/param.ny; > param.dz = param.sz/param.nz; > param.du = param.su/param.nu; > param.dv = param.sv/param.nv; > param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) > > > % Geometry calculation % % % > param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; > param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; > param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; > param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; > param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; > > > > So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : > 360). > But I got confused how to set the geometry parameters in RTK > I followed the rtkfdk tutorial but I can?t get any result using this method > > I did the following: > > 1- Create geometry.xml using these parameters: > > nproj = 72 ; > first_angle = 0 ; > arc = 360 ; > sid = 27400 ; > sdd = 32900 ; > proj_iso_x = 0; > proj_iso_y = 0; > out_angle = 0 ; > in_angle = 0 ; > source_x = 0; > source_y = 0 ; > > 2- Create my own mha file (WriteMhaFile.m) from my projection array > (36*100*72) using a matlab code with following properties: > Voxel size = [0.1 0.1 0.1] > Offset = [1 1 1] > > > 3- Then run the: > rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 > --dimension 500 > > > Could you please tell me if I am setting the geometry correctly? > Also, is there any other way to create my own mha file? > > Thank you in advance and looking forward to hear back from you. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 12:12:01 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 18:12:01 +0200 Subject: [Rtk-users] RTK training In-Reply-To: <55816290.1010807@uclouvain.be> References: <55816290.1010807@uclouvain.be> Message-ID: Dear RTK users, We have finally set a date for the RTK training, Wednesday, Nov 18 2015 in Lyon (France). The training will be organised by Kitware, go to this page for the registration: http://formations.kitware.fr/browse/116 We will do both user and developer sessions during the training. Since it's the first time that we do the training, we will tailor the balance between the two according to the wishes of registered people. The rest of the information should be available on the website but let us know if you need more information, we are still building the webpage and we'll be happy to improve it. We're looking forward to this new training and we'll do our best to meet your expectations, Simon On Wed, Jun 17, 2015 at 2:05 PM, Cyril Mory wrote: > Dear RTK users, > > The first RTK training is being planned at this very moment. It should > take place in November in Lyon, and be hosted by Kitware. The exact date > has not yet been decided, but will be available soon. > > We need your help to decide what to focus this training on. The choice is > mainly between two options: > - if most trainees want to learn how to use RTK, then we will focus on the > command-line tools and on python + Simple RTK > - if most trainees want to learn how to develop within RTK, modify and > enrich it, then we will focus on software architecture, detailed filter > description, ITK pipeline management, CUDA filters, etc... > > Please let us know which of these choices would best suit your needs. > > Looking forward, > Cyril > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Thu Jul 9 17:59:05 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Thu, 9 Jul 2015 14:59:05 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Simon, Thank you. I think now I understand how the whole geometry is defined in RTK. The projection is based on one experiment I am doing using different simulation techniques. Again thank you for your help. Best, Ali On Wed, Jul 8, 2015 at 11:23 PM, Simon Rit wrote: > Hi, > We can try to help but we need to understand your geometry... Where does > it come from by the way? If I understand your geometry correctly, I would > say : > - sid, sdd, nproj, arc are correct, > - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 > and you have 36x100 pixels, then the pixel size is [200,92,1] (last > dimension is not used so anything). For the volume, if your volume is > 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and > not 0.1. > - offset of projections is probably wrong. If you want to have a centered > projections, you'll need something like (-3500, -554, 0). You can set is to > 0 and put those values in proj_iso_x and proj_iso_y. > Regarding mha file, you can write mha files in many ways, using SimpleRTK, > matlab or writing an ITK code. > Good luck! > Simon > > On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah > wrote: > >> Hi, >> >> I have a question from you about the CT reconstruction, I would really >> appreciate if you can help me with this. >> >> I have the geometry as described in following and I am trying to run the >> rtkfdk code from RTK. >> >> >> % parameters % % % % % % % >> >> param.nx = 500; % number of voxels >> param.ny = 500; >> param.nz = 500; >> >> >> param.sx = 5000; % mm (real size) >> param.sy = 5000; % mm >> param.sz = 5000; % mm >> >> >> %The real detector panel pixel density (number of pixels) >> param.nu = 36; % number of pixels >> param.nv = 100; >> >> % Detector setting (real size) >> param.su = 7200; % mm (real size) >> param.sv = 9200; % mm >> >> >> % X-ray source and detector setting >> param.DSD = 32900; % Distance source to detector >> param.DSO = 27400; % X-ray source to object axis distance >> >> >> % angle setting >> param.dir = +1; % gantry rotating direction (clock wise/ counter >> clockwise) >> param.dang = 5; % angular step size (deg) >> param.deg = 0:param.dang:360-1; % you can change >> param.deg = param.deg*param.dir; >> param.nProj = length(param.deg); >> >> param.parker = 0; % data with 360 deg -> param.parker = 0 , data less >> than >> 360 deg -> param.parker=1 >> >> param.filter='ram-lak'; % high pass filter >> >> >> param.dx = param.sx/param.nx; % single voxel size >> param.dy = param.sy/param.ny; >> param.dz = param.sz/param.nz; >> param.du = param.su/param.nu; >> param.dv = param.sv/param.nv; >> param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) >> >> >> % Geometry calculation % % % >> param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; >> param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; >> param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; >> param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; >> param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; >> >> >> >> So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : >> 360). >> But I got confused how to set the geometry parameters in RTK >> I followed the rtkfdk tutorial but I can?t get any result using this >> method >> >> I did the following: >> >> 1- Create geometry.xml using these parameters: >> >> nproj = 72 ; >> first_angle = 0 ; >> arc = 360 ; >> sid = 27400 ; >> sdd = 32900 ; >> proj_iso_x = 0; >> proj_iso_y = 0; >> out_angle = 0 ; >> in_angle = 0 ; >> source_x = 0; >> source_y = 0 ; >> >> 2- Create my own mha file (WriteMhaFile.m) from my projection array >> (36*100*72) using a matlab code with following properties: >> Voxel size = [0.1 0.1 0.1] >> Offset = [1 1 1] >> >> >> 3- Then run the: >> rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 >> --dimension 500 >> >> >> Could you please tell me if I am setting the geometry correctly? >> Also, is there any other way to create my own mha file? >> >> Thank you in advance and looking forward to hear back from you. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hougeamm at 126.com Thu Jul 9 18:35:09 2015 From: hougeamm at 126.com (=?GBK?B?uu645w==?=) Date: Fri, 10 Jul 2015 06:35:09 +0800 (CST) Subject: [Rtk-users] problems for elekta data Message-ID: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Hello Everyone, Why the Elekta data prompt projection doesn't match when using rtkfdk? e.g., 377 vs 389? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 10 01:43:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Jul 2015 07:43:15 +0200 Subject: [Rtk-users] problems for elekta data In-Reply-To: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> References: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Message-ID: Hi, The message that you have on the command line is the result of the files that have been found in the path (--path option) with the regular expression (--regexp option). If it found more projections than what you have, then you probably need to improve your reg exp, e.g., by a $ after the file extension to specify that the file name must end with it. Simon On Fri, Jul 10, 2015 at 12:35 AM, ?? wrote: > Hello Everyone, > Why the Elekta data prompt projection doesn't match when using > rtkfdk? e.g., 377 vs 389? > Thanks! > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From guangming.zang at kaust.edu.sa Mon Jul 13 02:48:15 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 09:48:15 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset Message-ID: Hi RTK comunity, Besides the prameters like SID and SDD , from the geometry(.xteck) file got from my scanner, i also have object (volume) information like this: VoxelsX=179 VoxelsY=163 VoxelsZ=127 VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 The X,Y and Z axis are identical to RTK's geometry , So i was really wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i can show all other parameters like: rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, but it still a slight different visualization result from what we got from scanner software. So would you help me??? File attached is the geometry file in case. Thanks in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VCC_Dome_0622.xtekct Type: application/octet-stream Size: 1813 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 13 04:38:00 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 11:38:00 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: problem fixed. because the scanned object is symmetric and i did not notice that i should -Z axis in scanner to map Z in RTK thanks. but, i still do not know in RTK how to show the OffsetZ.. :( Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-13 9:48 GMT+03:00 Guangming Zang : > Hi RTK comunity, > Besides the prameters like SID and SDD , from the geometry(.xteck) file > got from my scanner, i also have object (volume) information like this: > VoxelsX=179 VoxelsY=163 VoxelsZ=127 > VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 > OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 > The X,Y and Z axis are identical to RTK's geometry , So i was really > wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i > can show all other parameters like: > > rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing > 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 > --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 > > Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, > but it still a slight different visualization result from what we got from > scanner software. > So would you help me??? > > > File attached is the geometry file in case. Thanks in advance > Regards > Guangming > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Mon Jul 13 13:21:44 2015 From: robert.calliess at gmx.de (=?utf-8?Q?Robert_Callie=C3=9F?=) Date: Mon, 13 Jul 2015 19:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? Message-ID: Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 13 13:42:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 13 Jul 2015 19:42:43 +0200 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: Hi, OffsetZ probably refers to the coordinate of the volume in the room coordinate which we don't use in RTK. Everything is set in the tomography coordinate during reconstruction. You can always change the coordinates of your volume after if you want to put it in some other coordinate system. Simon On Mon, Jul 13, 2015 at 10:38 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > problem fixed. > because the scanned object is symmetric and i did not notice that i > should -Z axis in scanner to map Z in RTK > thanks. > but, i still do not know in RTK how to show the OffsetZ.. :( > > Guangming > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-13 9:48 GMT+03:00 Guangming Zang : > >> Hi RTK comunity, >> Besides the prameters like SID and SDD , from the geometry(.xteck) file >> got from my scanner, i also have object (volume) information like this: >> VoxelsX=179 VoxelsY=163 VoxelsZ=127 >> VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 >> OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 >> The X,Y and Z axis are identical to RTK's geometry , So i was really >> wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i >> can show all other parameters like: >> >> rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing >> 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 >> --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 >> >> Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, >> but it still a slight different visualization result from what we got from >> scanner software. >> So would you help me??? >> >> >> File attached is the geometry file in case. Thanks in advance >> Regards >> Guangming >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Tue Jul 14 03:01:14 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 14 Jul 2015 09:01:14 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 01:32:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 07:32:43 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: > Hell RTK User, > I think there is a mistake in the described approach. > Point a) and f) meight be wrong. As far as I Understand, all Pixels > that are covered by the projected voxel vertices are update > with weight * voxel_value. Where weight is the overlaping area > of the projected voxel vertices polygon on the detector plane and the > underlying detector pixels. > > Any opinions before implementing it ? > > regards, > Robert > > *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr > *Von:* "Robert Callie?" > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what > they called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can > be rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector > cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value > to back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Wed Jul 15 08:07:20 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Wed, 15 Jul 2015 14:07:20 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 08:21:44 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 14:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: > Hello Simon, > thank you for your answer. I guess you linked the wrong article. But I > know what article you are talking about. > It's the articel from 2009 with a piece of code (MapSeq). > > >> I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > detector pixels that are totally covered by the overlap are weight with > "1" and if the overlap is between detector pixels > the pixels are weighted. Do you have a copy of the original article from > the De Man and Basu ? > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > Do you agree with that or did I miss something ? > > best regards, > Robert > > *Gesendet:* Mittwoch, 15. Juli 2015 um 07:32 Uhr > *Von:* "Simon Rit" > *An:* "Robert Callie?" > *Cc:* "rtk-users at public.kitware.com" > *Betreff:* Re: [Rtk-users] distance driven projector, a simplified > approach ? > Hi, > Indeed, I have published an article > on this > projector describing my implementation, you could use it if you want, > there's even a piece of code in it although I'm pretty sure it's not the > best implementation. This implementation dealt with the case where the > rotation axis is parallel to the detector. As far as I can remember, the > original article of De Man and Basu is also quite clear. > I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > Simon > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: >> >> Hell RTK User, >> I think there is a mistake in the described approach. >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> that are covered by the projected voxel vertices are update >> with weight * voxel_value. Where weight is the overlaping area >> of the projected voxel vertices polygon on the detector plane and the >> underlying detector pixels. >> >> Any opinions before implementing it ? >> >> regards, >> Robert >> >> *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr >> *Von:* "Robert Callie?" >> *An:* rtk-users at public.kitware.com >> *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel boundaries >> onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel?s contribution (weight) is the area of this overlapping. I >> read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is what >> they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone beam >> geometry. We can >> >> either rotate the detector and source around the object or the object can >> be rotated >> >> and the detector and source are fixed. I think Simon also wrote a paper >> about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source position, >> object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector >> cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the >> corresponding detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a ? e). Value >> to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I?m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of voxel >> boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 15 15:14:13 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 15 Jul 2015 21:14:13 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hello Simon, thank you for the articles. May I ask you what do you mean by ?voxel correction factor? in the code you provided in your article ? float f) // Voxel correction factor Thank you and best regards, Robert Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit Gesendet: Mittwoch, 15. Juli 2015 14:22 An: Robert Callie? Cc: rtk-users at public.kitware.com Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: Hello Simon, thank you for your answer. I guess you linked the wrong article. But I know what article you are talking about. It's the articel from 2009 with a piece of code (MapSeq). >> I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. You're right. It is that all pixels that are related to the overlap projected voxel overlap have to taken into account. So detector pixels that are totally covered by the overlap are weight with "1" and if the overlap is between detector pixels the pixels are weighted. Do you have a copy of the original article from the De Man and Basu ? I have the opinion that it's not neccessary to project the detector pixel boundaries and voxel boundaries onto a common plane if we use a flat panel detector. Instead we could project the voxel boundaries onto the detector plane directly. Do you agree with that or did I miss something ? best regards, Robert Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr Von: "Simon Rit" An: "Robert Callie?" Cc: "rtk-users at public.kitware.com" Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: Hell RTK User, I think there is a mistake in the described approach. Point a) and f) meight be wrong. As far as I Understand, all Pixels that are covered by the projected voxel vertices are update with weight * voxel_value. Where weight is the overlaping area of the projected voxel vertices polygon on the detector plane and the underlying detector pixels. Any opinions before implementing it ? regards, Robert Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr Von: "Robert Callie?" An: rtk-users at public.kitware.com Betreff: [Rtk-users] distance driven projector, a simplified approach ? Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 15:45:23 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 21:45:23 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. Simon On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie? wrote: > Hello Simon, > > thank you for the articles. May I ask you what do you mean by > > ?voxel correction factor? in the code you provided in your article ? > > float f) // Voxel correction factor > > > > Thank you and best regards, > > Robert > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Mittwoch, 15. Juli 2015 14:22 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified > approach ? > > > > Sorry, this link indeed with the MapSeg function. And yes, I was projecting > it to the detector plane directly. > > Simon > > > > On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" > wrote: > > Hello Simon, > > thank you for your answer. I guess you linked the wrong article. But I know > what article you are talking about. > > It's the articel from 2009 with a piece of code (MapSeq). > > > >>> I don't have time to go into the details of what you have proposed but, >>> from a glance, the first step seems useless. > > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > > detector pixels that are totally covered by the overlap are weight with "1" > and if the overlap is between detector pixels > > the pixels are weighted. Do you have a copy of the original article from the > De Man and Basu ? > > > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > > Do you agree with that or did I miss something ? > > > > best regards, > > Robert > > > > Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr > Von: "Simon Rit" > An: "Robert Callie?" > Cc: "rtk-users at public.kitware.com" > Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? > > Hi, > > Indeed, I have published an article on this projector describing my > implementation, you could use it if you want, there's even a piece of code > in it although I'm pretty sure it's not the best implementation. This > implementation dealt with the case where the rotation axis is parallel to > the detector. As far as I can remember, the original article of De Man and > Basu is also quite clear. > > I don't have time to go into the details of what you have proposed but, from > a glance, the first step seems useless. > > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > > Simon > > > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: > > Hell RTK User, > > I think there is a mistake in the described approach. > > Point a) and f) meight be wrong. As far as I Understand, all Pixels > > that are covered by the projected voxel vertices are update > > with weight * voxel_value. Where weight is the overlaping area > > of the projected voxel vertices polygon on the detector plane and the > > underlying detector pixels. > > > > Any opinions before implementing it ? > > > > regards, > > Robert > > > > Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr > Von: "Robert Callie?" > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what they > called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can be > rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value to > back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From simon.rit at creatis.insa-lyon.fr Fri Jul 17 02:22:16 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 17 Jul 2015 08:22:16 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Please keep on using the mailing list, I don't see a good reason to keep this conversation private. I won't have time to go back into these details. From a quick look, I think this is correct although I would have simply said that D is the center of the detector pixel. Simon On Thu, Jul 16, 2015 at 10:24 PM, Robert Callie? wrote: > Hello, > Sorry that I have to ask again. But I want to clear this before I start. > I want to ask about the cosine weight DeMan mentioned in his article. > He wrote: > > " > (1) The intersection length of the line of interest with the image slab S, the latter being > defined as the slab parallel to the xz plane and containing voxel V. This intersection length > is given by t/(cos ? cos ? ), where t is the isotropic voxel size, and ? and ? are the in- and > out-of-plane angles of the line of interest with the y-axis. > " > > So what he actually does, is that he calculates the intersection length of the slab s (that contains the voxel) with > a ray going from xray source to the middle of two adjacent detector cell boundaries. Let's refare to Figure 5. > So the length to be considered is calculated as the intersection length of slab S with the ray going from > the source ( the black dot in figure 5) to the mid-point of D, that means the center of the two projected adjacent > detector pixel boundaries. > > > Sorry for asking again but I want it to make it clear to me. > > Best regards, > Robert > > > -----Urspr?ngliche Nachricht----- > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit > Gesendet: Mittwoch, 15. Juli 2015 21:45 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? > > "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" > So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. > Simon > > On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie wrote: >> Hello Simon, >> >> thank you for the articles. May I ask you what do you mean by >> >> voxel correction factor in the code you provided in your article ? >> >> float f) // Voxel correction factor >> >> >> >> Thank you and best regards, >> >> Robert >> >> >> >> Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von >> Simon Rit >> Gesendet: Mittwoch, 15. Juli 2015 14:22 >> An: Robert Callie >> Cc: rtk-users at public.kitware.com >> Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified >> approach ? >> >> >> >> Sorry, this link indeed with the MapSeg function. And yes, I was >> projecting it to the detector plane directly. >> >> Simon >> >> >> >> On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie " >> >> wrote: >> >> Hello Simon, >> >> thank you for your answer. I guess you linked the wrong article. But I >> know what article you are talking about. >> >> It's the articel from 2009 with a piece of code (MapSeq). >> >> >> >>>> I don't have time to go into the details of what you have proposed >>>> but, from a glance, the first step seems useless. >> >> You're right. It is that all pixels that are related to the overlap >> projected voxel overlap have to taken into account. So >> >> detector pixels that are totally covered by the overlap are weight with "1" >> and if the overlap is between detector pixels >> >> the pixels are weighted. Do you have a copy of the original article >> from the De Man and Basu ? >> >> >> >> I have the opinion that it's not neccessary to project the detector >> pixel boundaries and voxel boundaries onto a common plane >> >> if we use a flat panel detector. Instead we could project the voxel >> boundaries onto the detector plane directly. >> >> Do you agree with that or did I miss something ? >> >> >> >> best regards, >> >> Robert >> >> >> >> Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr >> Von: "Simon Rit" >> An: "Robert Callie " >> Cc: "rtk-users at public.kitware.com" >> Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hi, >> >> Indeed, I have published an article on this projector describing my >> implementation, you could use it if you want, there's even a piece of >> code in it although I'm pretty sure it's not the best implementation. >> This implementation dealt with the case where the rotation axis is >> parallel to the detector. As far as I can remember, the original >> article of De Man and Basu is also quite clear. >> >> I don't have time to go into the details of what you have proposed >> but, from a glance, the first step seems useless. >> >> Good luck in your implementation and don't hesitate to send it to us >> when you have a working RTK implementation, >> >> Simon >> >> >> >> On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie " >> >> wrote: >> >> Hell RTK User, >> >> I think there is a mistake in the described approach. >> >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> >> that are covered by the projected voxel vertices are update >> >> with weight * voxel_value. Where weight is the overlaping area >> >> of the projected voxel vertices polygon on the detector plane and the >> >> underlying detector pixels. >> >> >> >> Any opinions before implementing it ? >> >> >> >> regards, >> >> Robert >> >> >> >> Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr >> Von: "Robert Callie " >> An: rtk-users at public.kitware.com >> Betreff: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel >> boundaries onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel s contribution (weight) is the area of this >> overlapping. I read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is >> what they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone >> beam geometry. We can >> >> either rotate the detector and source around the object or the object >> can be rotated >> >> and the detector and source are fixed. I think Simon also wrote a >> paper about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source >> position, object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the corresponding >> detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a e). >> Value to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of >> voxel boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > From guangming.zang at kaust.edu.sa Sun Jul 26 18:30:42 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 01:30:42 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed Message-ID: Hi RTK community, i am using SART algorithm to reconstruct an object. But in this new RTK version, the time recording seems a little weird: the total time is 1219.12s , but adding the time cost in different stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward projection part. BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, both multi-threading i think. Can anyone tell me what's going on? Thanks Regards Guangming [image: ???? 1] *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 01:59:11 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 07:59:11 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Guangming, It's not surprising to me that the backprojection is faster than the forward projection, that's what I expect. If the total time is longer, that's probably that some individual steps are not included in the total time. Can you try to add reader->Update(); before the line itk::TimeProbe totalTimeProbe; in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? Simon On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > Hi RTK community, > i am using SART algorithm to reconstruct an object. > But in this new RTK version, the time recording seems a little weird: > the total time is 1219.12s , but adding the time cost in different stages > is not 1291.12 s. especially for "backprojection" part, only 16.6051s to > reconstruct a 128^3 volume ?? even shorter than forward projection part. > BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, > both multi-threading i think. > Can anyone tell me what's going on? > Thanks > Regards > Guangming > > [image: ???? 1] > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 27 04:41:58 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 11:41:58 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, Thanks for your reply. would you pls help and explain why backprojection is expected to take shorter time than forward projection?? because i was thinking if no caching step, the backprojection should take much longer time than sart algorithm. yes, i run rtksart for 2 times once.it took 12xxs, similar to the time consumed of 3 times's sart, which much slower than my own application. BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 shapp-logan projections(512*512 resolution each) rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 and i will try reader->Update() like what you said. Thanks Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 8:59 GMT+03:00 Simon Rit : > Hi Guangming, > It's not surprising to me that the backprojection is faster than the > forward projection, that's what I expect. If the total time is longer, > that's probably that some individual steps are not included in the total > time. Can you try to add > reader->Update(); > before the line > > itk::TimeProbe totalTimeProbe; > > in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? > > Simon > > > > On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi RTK community, >> i am using SART algorithm to reconstruct an object. >> But in this new RTK version, the time recording seems a little weird: >> the total time is 1219.12s , but adding the time cost in different >> stages is not 1291.12 s. especially for "backprojection" part, only >> 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward >> projection part. BTW, the -f and -b are Joseph and >> VoxelBasedBackProjection, respectively, both multi-threading i think. >> Can anyone tell me what's going on? >> Thanks >> Regards >> Guangming >> >> [image: ???? 1] >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 08:28:28 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 14:28:28 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: I can try. Forward and back projection have the same algorithmic complexity but voxel based backprojection benefits from several optimizations in terms of memory management and computations that makes it faster. The best is to look at the code for further details... although both have far from being optimal. And I did not get the sentence "the backprojection should take much longer time than sart algorithm." because SART contains a backprojection and other steps so SART is obviously longer than the bp alone. Your log is strange and I don't see what steps are not timed that would take most of the time. I did the same test on my computer and here is my result: OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha --dimension 512 OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.288571 s Multiplication by zero: 0.131672 s Forward projection: 34.3612 s Subtraction: 0.203409 s Multiplication by lambda: 0.146459 s Ray box intersection: 1.30755 s Division: 0.187294 s Multiplication by the gating weights: 0 s Displaced detector: 0.278408 s Back projection: 11.8456 s Volume update: 0 s It took... 53.2765 s Simon On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang wrote: > Hi Simon, > Thanks for your reply. > would you pls help and explain why backprojection is expected to take > shorter time than forward projection?? because i was thinking if no caching > step, the backprojection should take much longer time than sart algorithm. > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > consumed of 3 times's sart, which much slower than my own application. > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > shapp-logan projections(512*512 resolution each) > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > -64,-64,-64 -l 0.5 -n 3 --time 1 > > and i will try reader->Update() like what you said. > Thanks > Guangming > > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> Hi Guangming, >> It's not surprising to me that the backprojection is faster than the >> forward projection, that's what I expect. If the total time is longer, >> that's probably that some individual steps are not included in the total >> time. Can you try to add >> reader->Update(); >> before the line >> >> itk::TimeProbe totalTimeProbe; >> >> in rtksart.cxx? It may be that all the reading operations are done but not >> timed in the sart->Update(). Why they are so long, I don't know, is your D: >> drive a network drive? Do you observe the same behavior if you do rtksart 2 >> times in a row? >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> wrote: >>> >>> Hi RTK community, >>> i am using SART algorithm to reconstruct an object. >>> But in this new RTK version, the time recording seems a little weird: >>> the total time is 1219.12s , but adding the time cost in different >>> stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s >>> to reconstruct a 128^3 volume ?? even shorter than forward projection part. >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, >>> both multi-threading i think. >>> Can anyone tell me what's going on? >>> Thanks >>> Regards >>> Guangming >>> >>> >>> Guangming Zang (Alex) >>> King Abdullah University of Science and Technology(KAUST) >>> University of Chinese Academy of Sciences(UCAS) >>> >>> >>> >>> >>> ________________________________ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete this >>> message from your computer system. Any unauthorized use or distribution is >>> prohibited. Please consider the environment before printing this email. >> >> > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 08:50:48 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 15:50:48 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, sorry for the mistake, not"the backprojection should take much longer time than sart algorithm" , but "the backprojection should take much longer time than forward projection in sart algorithm". BTW, how many cores does your computer have?? Mine is 24 cores. is it can explain the reason why it takes much longer time on my computer than yours? Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 15:28 GMT+03:00 Simon Rit : > I can try. Forward and back projection have the same algorithmic > complexity but voxel based backprojection benefits from several > optimizations in terms of memory management and computations that > makes it faster. The best is to look at the code for further > details... although both have far from being optimal. And I did not > get the sentence "the backprojection should take much longer time than > sart algorithm." because SART contains a backprojection and other > steps so SART is obviously longer than the bp alone. > Your log is strange and I don't see what steps are not timed that > would take most of the time. I did the same test on my computer and > here is my result: > > OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > --dimension 512 > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.288571 s > Multiplication by zero: 0.131672 s > Forward projection: 34.3612 s > Subtraction: 0.203409 s > Multiplication by lambda: 0.146459 s > Ray box intersection: 1.30755 s > Division: 0.187294 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.278408 s > Back projection: 11.8456 s > Volume update: 0 s > It took... 53.2765 s > > Simon > > On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > wrote: > > Hi Simon, > > Thanks for your reply. > > would you pls help and explain why backprojection is expected to take > > shorter time than forward projection?? because i was thinking if no > caching > > step, the backprojection should take much longer time than sart > algorithm. > > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > > consumed of 3 times's sart, which much slower than my own application. > > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > > shapp-logan projections(512*512 resolution each) > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > > -64,-64,-64 -l 0.5 -n 3 --time 1 > > > > and i will try reader->Update() like what you said. > > Thanks > > Guangming > > > > > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> > >> Hi Guangming, > >> It's not surprising to me that the backprojection is faster than the > >> forward projection, that's what I expect. If the total time is longer, > >> that's probably that some individual steps are not included in the total > >> time. Can you try to add > >> reader->Update(); > >> before the line > >> > >> itk::TimeProbe totalTimeProbe; > >> > >> in rtksart.cxx? It may be that all the reading operations are done but > not > >> timed in the sart->Update(). Why they are so long, I don't know, is > your D: > >> drive a network drive? Do you observe the same behavior if you do > rtksart 2 > >> times in a row? > >> > >> Simon > >> > >> > >> > >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> wrote: > >>> > >>> Hi RTK community, > >>> i am using SART algorithm to reconstruct an object. > >>> But in this new RTK version, the time recording seems a little weird: > >>> the total time is 1219.12s , but adding the time cost in different > >>> stages is not 1291.12 s. especially for "backprojection" part, only > 16.6051s > >>> to reconstruct a 128^3 volume ?? even shorter than forward projection > part. > >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > respectively, > >>> both multi-threading i think. > >>> Can anyone tell me what's going on? > >>> Thanks > >>> Regards > >>> Guangming > >>> > >>> > >>> Guangming Zang (Alex) > >>> King Abdullah University of Science and Technology(KAUST) > >>> University of Chinese Academy of Sciences(UCAS) > >>> > >>> > >>> > >>> > >>> ________________________________ > >>> This message and its contents, including attachments are intended > solely > >>> for the original recipient. If you are not the intended recipient or > have > >>> received this message in error, please notify me immediately and > delete this > >>> message from your computer system. Any unauthorized use or > distribution is > >>> prohibited. Please consider the environment before printing this email. > >> > >> > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 09:02:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 15:02:03 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: No I expect forward projection to be longer than backprojection although with optimal implementations, it should take about the same time since they have the same complexity. I have 4 cores on my laptop. I don't see how it explains it, try to find out where does SART spend the time. Simon On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang wrote: > Hi Simon, > sorry for the mistake, not"the backprojection should take much longer time > than > sart algorithm" , but "the backprojection should take much longer time than > forward projection in sart algorithm". > > BTW, how many cores does your computer have?? Mine is 24 cores. > is it can explain the reason why it takes much longer time on my computer > than yours? > Regards > Guangming > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> I can try. Forward and back projection have the same algorithmic >> complexity but voxel based backprojection benefits from several >> optimizations in terms of memory management and computations that >> makes it faster. The best is to look at the code for further >> details... although both have far from being optimal. And I did not >> get the sentence "the backprojection should take much longer time than >> sart algorithm." because SART contains a backprojection and other >> steps so SART is obviously longer than the bp alone. >> Your log is strange and I don't see what steps are not timed that >> would take most of the time. I did the same test on my computer and >> here is my result: >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> --dimension 512 >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> 1 >> Recording elapsed time... >> SARTConeBeamReconstructionFilter timing: >> Extraction of projection sub-stacks: 0.288571 s >> Multiplication by zero: 0.131672 s >> Forward projection: 34.3612 s >> Subtraction: 0.203409 s >> Multiplication by lambda: 0.146459 s >> Ray box intersection: 1.30755 s >> Division: 0.187294 s >> Multiplication by the gating weights: 0 s >> Displaced detector: 0.278408 s >> Back projection: 11.8456 s >> Volume update: 0 s >> It took... 53.2765 s >> >> Simon >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> wrote: >> > Hi Simon, >> > Thanks for your reply. >> > would you pls help and explain why backprojection is expected to take >> > shorter time than forward projection?? because i was thinking if no >> > caching >> > step, the backprojection should take much longer time than sart >> > algorithm. >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time >> > consumed of 3 times's sart, which much slower than my own application. >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 >> > shapp-logan projections(512*512 resolution each) >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> > >> > and i will try reader->Update() like what you said. >> > Thanks >> > Guangming >> > >> > >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> >> >> Hi Guangming, >> >> It's not surprising to me that the backprojection is faster than the >> >> forward projection, that's what I expect. If the total time is longer, >> >> that's probably that some individual steps are not included in the >> >> total >> >> time. Can you try to add >> >> reader->Update(); >> >> before the line >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done but >> >> not >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> your D: >> >> drive a network drive? Do you observe the same behavior if you do >> >> rtksart 2 >> >> times in a row? >> >> >> >> Simon >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> wrote: >> >>> >> >>> Hi RTK community, >> >>> i am using SART algorithm to reconstruct an object. >> >>> But in this new RTK version, the time recording seems a little weird: >> >>> the total time is 1219.12s , but adding the time cost in different >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >>> 16.6051s >> >>> to reconstruct a 128^3 volume ?? even shorter than forward projection >> >>> part. >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >>> respectively, >> >>> both multi-threading i think. >> >>> Can anyone tell me what's going on? >> >>> Thanks >> >>> Regards >> >>> Guangming >> >>> >> >>> >> >>> Guangming Zang (Alex) >> >>> King Abdullah University of Science and Technology(KAUST) >> >>> University of Chinese Academy of Sciences(UCAS) >> >>> >> >>> >> >>> >> >>> >> >>> ________________________________ >> >>> This message and its contents, including attachments are intended >> >>> solely >> >>> for the original recipient. If you are not the intended recipient or >> >>> have >> >>> received this message in error, please notify me immediately and >> >>> delete this >> >>> message from your computer system. Any unauthorized use or >> >>> distribution is >> >>> prohibited. Please consider the environment before printing this >> >>> email. >> >> >> >> >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended solely >> > for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> > this >> > message from your computer system. Any unauthorized use or distribution >> > is >> > prohibited. Please consider the environment before printing this email. > > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 10:05:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:05:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, it cost 1200s for SART algorithm at first, and the command are: rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 in which, the projections data(360pro_SL_Vol128_512.mha) is not generated from rtkprojectshepploganphantom , but from my application. though it took long time, but i can got a nice result, And i just tried the command you used, i.e. generated the projections data by rtkprojectshepploganphantom : rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 --sid=500.0 rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 yes, it takes about 56s. but the reconstructed result is weird, the voxel values range from [-142186, 208146] and can not see anything when visualizing it. i believe you got the similar results, which maybe explain why it computes much faster. if i wanna use the projections generated by rtkprojectshepploganphantom , can you give me an example to get a nice results? Best regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 16:02 GMT+03:00 Simon Rit : > No I expect forward projection to be longer than backprojection > although with optimal implementations, it should take about the same > time since they have the same complexity. > I have 4 cores on my laptop. I don't see how it explains it, try to > find out where does SART spend the time. > Simon > > On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang > wrote: > > Hi Simon, > > sorry for the mistake, not"the backprojection should take much longer > time > > than > > sart algorithm" , but "the backprojection should take much longer time > than > > forward projection in sart algorithm". > > > > BTW, how many cores does your computer have?? Mine is 24 cores. > > is it can explain the reason why it takes much longer time on my computer > > than yours? > > Regards > > Guangming > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : > >> > >> I can try. Forward and back projection have the same algorithmic > >> complexity but voxel based backprojection benefits from several > >> optimizations in terms of memory management and computations that > >> makes it faster. The best is to look at the code for further > >> details... although both have far from being optimal. And I did not > >> get the sentence "the backprojection should take much longer time than > >> sart algorithm." because SART contains a backprojection and other > >> steps so SART is obviously longer than the bp alone. > >> Your log is strange and I don't see what steps are not timed that > >> would take most of the time. I did the same test on my computer and > >> here is my result: > >> > >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > >> --dimension 512 > >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > >> 1 > >> Recording elapsed time... > >> SARTConeBeamReconstructionFilter timing: > >> Extraction of projection sub-stacks: 0.288571 s > >> Multiplication by zero: 0.131672 s > >> Forward projection: 34.3612 s > >> Subtraction: 0.203409 s > >> Multiplication by lambda: 0.146459 s > >> Ray box intersection: 1.30755 s > >> Division: 0.187294 s > >> Multiplication by the gating weights: 0 s > >> Displaced detector: 0.278408 s > >> Back projection: 11.8456 s > >> Volume update: 0 s > >> It took... 53.2765 s > >> > >> Simon > >> > >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > >> wrote: > >> > Hi Simon, > >> > Thanks for your reply. > >> > would you pls help and explain why backprojection is expected to take > >> > shorter time than forward projection?? because i was thinking if no > >> > caching > >> > step, the backprojection should take much longer time than sart > >> > algorithm. > >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the > time > >> > consumed of 3 times's sart, which much slower than my own application. > >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > >> > shapp-logan projections(512*512 resolution each) > >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > >> > -64,-64,-64 -l 0.5 -n 3 --time 1 > >> > > >> > and i will try reader->Update() like what you said. > >> > Thanks > >> > Guangming > >> > > >> > > >> > > >> > Guangming Zang (Alex) > >> > King Abdullah University of Science and Technology(KAUST) > >> > University of Chinese Academy of Sciences(UCAS) > >> > > >> > > >> > > >> > > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> >> > >> >> Hi Guangming, > >> >> It's not surprising to me that the backprojection is faster than the > >> >> forward projection, that's what I expect. If the total time is > longer, > >> >> that's probably that some individual steps are not included in the > >> >> total > >> >> time. Can you try to add > >> >> reader->Update(); > >> >> before the line > >> >> > >> >> itk::TimeProbe totalTimeProbe; > >> >> > >> >> in rtksart.cxx? It may be that all the reading operations are done > but > >> >> not > >> >> timed in the sart->Update(). Why they are so long, I don't know, is > >> >> your D: > >> >> drive a network drive? Do you observe the same behavior if you do > >> >> rtksart 2 > >> >> times in a row? > >> >> > >> >> Simon > >> >> > >> >> > >> >> > >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> >> wrote: > >> >>> > >> >>> Hi RTK community, > >> >>> i am using SART algorithm to reconstruct an object. > >> >>> But in this new RTK version, the time recording seems a little > weird: > >> >>> the total time is 1219.12s , but adding the time cost in different > >> >>> stages is not 1291.12 s. especially for "backprojection" part, only > >> >>> 16.6051s > >> >>> to reconstruct a 128^3 volume ?? even shorter than forward > projection > >> >>> part. > >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > >> >>> respectively, > >> >>> both multi-threading i think. > >> >>> Can anyone tell me what's going on? > >> >>> Thanks > >> >>> Regards > >> >>> Guangming > >> >>> > >> >>> > >> >>> Guangming Zang (Alex) > >> >>> King Abdullah University of Science and Technology(KAUST) > >> >>> University of Chinese Academy of Sciences(UCAS) > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> ________________________________ > >> >>> This message and its contents, including attachments are intended > >> >>> solely > >> >>> for the original recipient. If you are not the intended recipient or > >> >>> have > >> >>> received this message in error, please notify me immediately and > >> >>> delete this > >> >>> message from your computer system. Any unauthorized use or > >> >>> distribution is > >> >>> prohibited. Please consider the environment before printing this > >> >>> email. > >> >> > >> >> > >> > > >> > > >> > ________________________________ > >> > This message and its contents, including attachments are intended > solely > >> > for > >> > the original recipient. If you are not the intended recipient or have > >> > received this message in error, please notify me immediately and > delete > >> > this > >> > message from your computer system. Any unauthorized use or > distribution > >> > is > >> > prohibited. Please consider the environment before printing this > email. > > > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 10:12:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:12:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: BTW, the projections are 512*512, and the pixel spacing is 0.5 Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:05 GMT+03:00 Guangming Zang : > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 10:20:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 16:20:12 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Obviously I hadn't looked at the result and/or checked the command line options, sorry. This is an example from the same simulated dataset that gives me a good results: OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.567773 s Multiplication by zero: 0.303715 s Forward projection: 142.305 s Subtraction: 0.445842 s Multiplication by lambda: 0.2663 s Ray box intersection: 5.40366 s Division: 0.535618 s Multiplication by the gating weights: 0 s Displaced detector: 0.415431 s Back projection: 21.3689 s Volume update: 0 s It took... 177.059 s but this doesn't change the content of my previous message. What takes time is probably in your own software, be sure that you update SART inputs before timing it. Simon On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang wrote: > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 11:12:16 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 18:12:16 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Thanks Simon, now it work fine when using projections generated by RTK itself (command rtkprojectshepploganphantom ). for 1 iteration of SART to reconstruct 128^3 size volume, it took only 19s, which gives nice results as well. Thanks again. Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:20 GMT+03:00 Simon Rit : > Obviously I hadn't looked at the result and/or checked the command line > options, sorry. This is an example from the same simulated dataset that > gives me a good results: > > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f > Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n > 3 --time 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.567773 s > Multiplication by zero: 0.303715 s > Forward projection: 142.305 s > Subtraction: 0.445842 s > Multiplication by lambda: 0.2663 s > Ray box intersection: 5.40366 s > Division: 0.535618 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.415431 s > Back projection: 21.3689 s > Volume update: 0 s > It took... 177.059 s > > but this doesn't change the content of my previous message. What takes > time is probably in your own software, be sure that you update SART inputs > before timing it. > Simon > > On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon, >> it cost 1200s for SART algorithm at first, and the command are: >> rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd= >> 725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" >> >> rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 >> >> in which, the projections data(360pro_SL_Vol128_512.mha) is not >> generated from rtkprojectshepploganphantom , but from my application. >> though it took long time, but i can got a nice result, >> >> >> And i just tried the command you used, i.e. generated the projections >> data by rtkprojectshepploganphantom : >> >> rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 >> --sid=500.0 >> rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 >> rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b >> VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 >> --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 >> yes, it takes about 56s. >> but the reconstructed result is weird, the voxel values range from >> [-142186, 208146] and can not see anything when visualizing it. >> i believe you got the similar results, which maybe explain why it >> computes much faster. >> >> if i wanna use the projections generated by rtkprojectshepploganphantom >> , can you give me an example to get a nice results? >> >> Best regards >> Guangming >> >> >> >> >> >> >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> 2015-07-27 16:02 GMT+03:00 Simon Rit : >> >>> No I expect forward projection to be longer than backprojection >>> although with optimal implementations, it should take about the same >>> time since they have the same complexity. >>> I have 4 cores on my laptop. I don't see how it explains it, try to >>> find out where does SART spend the time. >>> Simon >>> >>> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >>> wrote: >>> > Hi Simon, >>> > sorry for the mistake, not"the backprojection should take much longer >>> time >>> > than >>> > sart algorithm" , but "the backprojection should take much longer time >>> than >>> > forward projection in sart algorithm". >>> > >>> > BTW, how many cores does your computer have?? Mine is 24 cores. >>> > is it can explain the reason why it takes much longer time on my >>> computer >>> > than yours? >>> > Regards >>> > Guangming >>> > >>> > Guangming Zang (Alex) >>> > King Abdullah University of Science and Technology(KAUST) >>> > University of Chinese Academy of Sciences(UCAS) >>> > >>> > >>> > >>> > >>> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >>> >> >>> >> I can try. Forward and back projection have the same algorithmic >>> >> complexity but voxel based backprojection benefits from several >>> >> optimizations in terms of memory management and computations that >>> >> makes it faster. The best is to look at the code for further >>> >> details... although both have far from being optimal. And I did not >>> >> get the sentence "the backprojection should take much longer time than >>> >> sart algorithm." because SART contains a backprojection and other >>> >> steps so SART is obviously longer than the bp alone. >>> >> Your log is strange and I don't see what steps are not timed that >>> >> would take most of the time. I did the same test on my computer and >>> >> here is my result: >>> >> >>> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >>> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >>> >> --dimension 512 >>> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >>> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >>> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >>> >> 1 >>> >> Recording elapsed time... >>> >> SARTConeBeamReconstructionFilter timing: >>> >> Extraction of projection sub-stacks: 0.288571 s >>> >> Multiplication by zero: 0.131672 s >>> >> Forward projection: 34.3612 s >>> >> Subtraction: 0.203409 s >>> >> Multiplication by lambda: 0.146459 s >>> >> Ray box intersection: 1.30755 s >>> >> Division: 0.187294 s >>> >> Multiplication by the gating weights: 0 s >>> >> Displaced detector: 0.278408 s >>> >> Back projection: 11.8456 s >>> >> Volume update: 0 s >>> >> It took... 53.2765 s >>> >> >>> >> Simon >>> >> >>> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >>> >> wrote: >>> >> > Hi Simon, >>> >> > Thanks for your reply. >>> >> > would you pls help and explain why backprojection is expected to >>> take >>> >> > shorter time than forward projection?? because i was thinking if no >>> >> > caching >>> >> > step, the backprojection should take much longer time than sart >>> >> > algorithm. >>> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >>> time >>> >> > consumed of 3 times's sart, which much slower than my own >>> application. >>> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >>> 360 >>> >> > shapp-logan projections(512*512 resolution each) >>> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >>> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >>> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >>> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >>> >> > >>> >> > and i will try reader->Update() like what you said. >>> >> > Thanks >>> >> > Guangming >>> >> > >>> >> > >>> >> > >>> >> > Guangming Zang (Alex) >>> >> > King Abdullah University of Science and Technology(KAUST) >>> >> > University of Chinese Academy of Sciences(UCAS) >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit >> >: >>> >> >> >>> >> >> Hi Guangming, >>> >> >> It's not surprising to me that the backprojection is faster than >>> the >>> >> >> forward projection, that's what I expect. If the total time is >>> longer, >>> >> >> that's probably that some individual steps are not included in the >>> >> >> total >>> >> >> time. Can you try to add >>> >> >> reader->Update(); >>> >> >> before the line >>> >> >> >>> >> >> itk::TimeProbe totalTimeProbe; >>> >> >> >>> >> >> in rtksart.cxx? It may be that all the reading operations are done >>> but >>> >> >> not >>> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >>> >> >> your D: >>> >> >> drive a network drive? Do you observe the same behavior if you do >>> >> >> rtksart 2 >>> >> >> times in a row? >>> >> >> >>> >> >> Simon >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >>> >> >> wrote: >>> >> >>> >>> >> >>> Hi RTK community, >>> >> >>> i am using SART algorithm to reconstruct an object. >>> >> >>> But in this new RTK version, the time recording seems a little >>> weird: >>> >> >>> the total time is 1219.12s , but adding the time cost in >>> different >>> >> >>> stages is not 1291.12 s. especially for "backprojection" part, >>> only >>> >> >>> 16.6051s >>> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >>> projection >>> >> >>> part. >>> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >>> >> >>> respectively, >>> >> >>> both multi-threading i think. >>> >> >>> Can anyone tell me what's going on? >>> >> >>> Thanks >>> >> >>> Regards >>> >> >>> Guangming >>> >> >>> >>> >> >>> >>> >> >>> Guangming Zang (Alex) >>> >> >>> King Abdullah University of Science and Technology(KAUST) >>> >> >>> University of Chinese Academy of Sciences(UCAS) >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> ________________________________ >>> >> >>> This message and its contents, including attachments are intended >>> >> >>> solely >>> >> >>> for the original recipient. If you are not the intended recipient >>> or >>> >> >>> have >>> >> >>> received this message in error, please notify me immediately and >>> >> >>> delete this >>> >> >>> message from your computer system. Any unauthorized use or >>> >> >>> distribution is >>> >> >>> prohibited. Please consider the environment before printing this >>> >> >>> email. >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > ________________________________ >>> >> > This message and its contents, including attachments are intended >>> solely >>> >> > for >>> >> > the original recipient. If you are not the intended recipient or >>> have >>> >> > received this message in error, please notify me immediately and >>> delete >>> >> > this >>> >> > message from your computer system. Any unauthorized use or >>> distribution >>> >> > is >>> >> > prohibited. Please consider the environment before printing this >>> email. >>> > >>> > >>> > >>> > ________________________________ >>> > This message and its contents, including attachments are intended >>> solely for >>> > the original recipient. If you are not the intended recipient or have >>> > received this message in error, please notify me immediately and >>> delete this >>> > message from your computer system. Any unauthorized use or >>> distribution is >>> > prohibited. Please consider the environment before printing this email. >>> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From infrombox at yandex.ru Tue Jul 28 04:30:22 2015 From: infrombox at yandex.ru (1 1) Date: Tue, 28 Jul 2015 15:30:22 +0700 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: <2213081438072222@web8j.yandex.ru> Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. But program which i use reads meta images with MET_SHORT pixel type only. Is there easy way to setting it and get volume with different from MET_FLOAT pixel type ? If not, could you advice me, what the filter i should to do, for example as post process after reconstruction ala MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward operation of LUTbasedVariableI0RawToAttenuationImageFilter ? Thanks. From simon.rit at creatis.insa-lyon.fr Tue Jul 28 04:56:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 10:56:54 +0200 Subject: [Rtk-users] volume with diffieret pixel type In-Reply-To: <2213081438072222@web8j.yandex.ru> References: <2213081438072222@web8j.yandex.ru> Message-ID: Hi, This is more an ITK question than a RTK question. Yes, we use float by default in our applications. You can cast the image to any type before writing using itk::CastImageFilter but you'll have to modify the applications and, of course, there is a loss of information. If you don't want to program it, you can use any other software, e.g. in vv right clik on your image after opening and use the convert to option. Simon On Tue, Jul 28, 2015 at 10:30 AM, 1 1 wrote: > Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. > But program which i use reads meta images with MET_SHORT pixel type only. > Is there easy way to setting it and get volume with different from > MET_FLOAT pixel type ? If not, could you advice me, what the filter i > should to do, for example as post process after reconstruction ala > MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward > operation of LUTbasedVariableI0RawToAttenuationImageFilter image, float image> ? > Thanks. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pconneely020186 at gmail.com Tue Jul 28 12:05:29 2015 From: pconneely020186 at gmail.com (peter conneely) Date: Tue, 28 Jul 2015 17:05:29 +0100 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: "peter conneely" Date: 24 Jul 2015 11:07 Subject: Issue running FDK reconstruction algorithm To: Cc: Hi, I'm having trouble running the FDK reconstruction alogrithm on Elekta and Varian data sets. The algorithm does work when I try the shepp-logan example. When I initially ran the application I included the (') around .*.his. and got the following lines. [image: Inline image 1] when I try to run with the (') removed it finds the 669 files but then the application stops working. I have tried adding registry edits to run exe and have tried switching of dep. Neither of these work I am not sure what is going wrong and how to fix it. My system properties are as follows. Processor: Intel Pentium CPU P6100 @ 2.00 Ghz RAM: 3.00 GB GPU: Intel HD Graphics Systems type 64 Bit. Thanks and Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Tue Jul 28 12:46:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 18:46:17 +0200 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: Hi, I guess the quotes are OS depedent, maybe you need double quotes on Windows. It's strange that you don't get an error message. Are you sure it crashed? If yes, have you checked the elektaGeometry file? Does it have 669 projection sections as expected? Or maybe it's a memory issue, try the --lowmem option. Simon On Tue, Jul 28, 2015 at 6:05 PM, peter conneely wrote: > ---------- Forwarded message ---------- > From: "peter conneely" > Date: 24 Jul 2015 11:07 > Subject: Issue running FDK reconstruction algorithm > To: > Cc: > > Hi, > > I'm having trouble running the FDK reconstruction alogrithm on Elekta and > Varian data sets. The algorithm does work when I try the shepp-logan > example. > > When I initially ran the application I included the (') around .*.his. and > got the following lines. > [image: Inline image 1] > when I try to run with the (') removed it finds the 669 files but then the > application stops working. I have tried adding registry edits to run exe > and have tried switching of dep. Neither of these work I am not sure what > is going wrong and how to fix it. > > My system properties are as follows. > Processor: Intel Pentium CPU P6100 @ 2.00 Ghz > RAM: 3.00 GB > GPU: Intel HD Graphics > Systems type 64 Bit. > > Thanks and Regards, > Peter > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Tue Jul 28 13:38:45 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Tue, 28 Jul 2015 20:38:45 +0300 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: Hi, in ITK, the default type are described in *Utilities\MetaIO\metaTypes.h* MET_CHAR, MET_UCHAR ?,? ?? MET_SHORT, MET_USHORT, MET_INT,=20 MET_UINT,=20 MET_FLOAT,=20 MET_DOUBLE, ?and for .mha file, the header file includes information like: ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = 0 0 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 1 1 1 DimSize = 128 128 128 ElementType = MET_FLOAT ElementDataFile = LOCAL? ?And recently i just programmed to read and write .mha files. below is the code. u can just replace ElementType from ? MET_FLOAT ? to ? ? MET_SHORT ? in your application. hope this helps: #include "stdafx.h" #include #include #include #include #include #include using namespace std; int _tmain(int argc, _TCHAR* argv[]) { int m_Dims[3]; float spacing[3]; m_Dims[0]=128; m_Dims[1]=128; m_Dims[2]=128; spacing[0]=spacing[1]=spacing[2]=1.0f; ostringstream buffer, buffer1, buffer2, buf3; buffer << spacing[0]; string sp= buffer.str(); buffer1 << spacing[1]; string sp1 = buffer1.str(); buffer2 << spacing[2]; string sp2 = buffer2.str(); string ElementSpacing ="ElementSpacing= "+sp+" "+sp1+" "+sp2+"\n"; // int ss=1000; char temp[64], temp1[64],temp2[64]; string str; sprintf(temp, "%d", m_Dims[0]); sprintf(temp1, "%d", m_Dims[1]); sprintf(temp2, "%d", m_Dims[2]); string s(temp),s1(temp1),s2(temp2); string DimSize="DimSize= "+s+" "+s1+" "+s2+"\n"; string Mywritefile="ObjectType = Image\nNDims = 3\nBinaryData = True\nBinaryDataByteOrderMSB = False \nCompressedData = False \nTransformMatrix = 1 0 0 0 1 0 0 0 1 \n" ; Mywritefile+="Offset = 0 0 0 \nCenterOfRotation = 0 0 0 \nAnatomicalOrientation = RAI \n"; Mywritefile+=ElementSpacing+DimSize+"ElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; // ElementSpacing = 1 1 1 \nDimSize = 128 128 128 \nElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; int leng=Mywritefile.length(); cout< From simon.rit at creatis.insa-lyon.fr Wed Jul 29 08:53:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 29 Jul 2015 14:53:34 +0200 Subject: [Rtk-users] RTK images make the cover of Medical Physics Message-ID: See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Wed Jul 29 09:07:01 2015 From: theday79 at gmail.com (Yang K Park) Date: Wed, 29 Jul 2015 09:07:01 -0400 Subject: [Rtk-users] RTK images make the cover of Medical Physics In-Reply-To: References: Message-ID: <001801d0c9ff$76797860$636c6920$@gmail.com> Hi Simon, Thank you so much for the congrats! This is my great honor and I?d like to thank all the RTK developers and community members for their helps on this achievement! Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: Wednesday, July 29, 2015 8:54 AM To: rtk-users at public.kitware.com Subject: [Rtk-users] RTK images make the cover of Medical Physics See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Thu Jul 30 08:16:38 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Thu, 30 Jul 2015 15:16:38 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK Message-ID: Hi Simon and Chao, i am currently do some comparisons between different reconstruction methods for Shapp-Logan dataset. the commands are: rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=955.4050067 --sid=500.0 rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha --dimension 512,512 when using FDK or SART algorithm from RTK, I can got pretty good results indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 and levels as 1.04 for all results got). When running ADMMTV command below, though the geometry is as same as SART and FDK, the result got from ADMM looks weird.(pls see attached central slice of ground truth and ADMM, same contrast with other algorithm) rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 [image: ???? 1][image: ???? 2] Is it because the CG algorithm used by ADMM, or parameters setting issues here?? if it is parameters setting problem , would you help me and give a nice values for alpha and bate used here? BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already (including default value) Thanks and regards Guangming ?? *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ? -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 31 01:55:32 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 31 Jul 2015 07:55:32 +0200 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi, It looks to me that you haven't converged. I'm not the specialist of this algorithm and the specialist won't be near a computer in the coming weeks but when I try with more iterations in the data attachment term: rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 it's more satisfactory. There are rings at the top and the bottom of the cone-beam which should be reduced with more TV (greater alpha, see doc here ) or with a finer spacing (see this publication ). Simon On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang wrote: > Hi Simon and Chao, > > i am currently do some comparisons between different reconstruction > methods for Shapp-Logan dataset. > > the commands are: > > rtksimulatedgeometry -n 360 --arc -360 -o > geo.xml --sdd=955.4050067 --sid=500.0 > > rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha > --dimension 512,512 > > > > when using FDK or SART algorithm from RTK, I can got pretty good results > indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 > and levels as 1.04 for all results got). When running ADMMTV command below, > though the geometry is as same as SART and FDK, the result got from ADMM > looks weird.(pls see attached central slice of ground truth and ADMM, same > contrast with other algorithm) > > rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o > SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 > --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 > > [image: ???? 1][image: ???? 2] > > Is it because the CG algorithm used by ADMM, or parameters setting issues > here?? if it is parameters setting problem , would you help me and give a > nice values for alpha and bate used here? > > BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already > (including default value) > > Thanks and regards > > Guangming > > > ?? > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > ? > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Fri Jul 31 09:46:41 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 31 Jul 2015 16:46:41 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi simon, i see, thanks for the help and explanation. after following your advice, it works fine now. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-31 8:55 GMT+03:00 Simon Rit : > Hi, > It looks to me that you haven't converged. I'm not the specialist of this > algorithm and the specialist won't be near a computer in the coming weeks > but when I try with more iterations in the data attachment term: > rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml > --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 > it's more satisfactory. There are rings at the top and the bottom of the > cone-beam which should be reduced with more TV (greater alpha, see doc > here > ) > or with a finer spacing (see this publication > ). > Simon > > On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon and Chao, >> >> i am currently do some comparisons between different reconstruction >> methods for Shapp-Logan dataset. >> >> the commands are: >> >> rtksimulatedgeometry -n 360 --arc -360 -o >> geo.xml --sdd=955.4050067 --sid=500.0 >> >> rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha >> --dimension 512,512 >> >> >> >> when using FDK or SART algorithm from RTK, I can got pretty good results >> indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 >> and levels as 1.04 for all results got). When running ADMMTV command below, >> though the geometry is as same as SART and FDK, the result got from ADMM >> looks weird.(pls see attached central slice of ground truth and ADMM, same >> contrast with other algorithm) >> >> rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o >> SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 >> --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 >> >> [image: ???? 1][image: ???? 2] >> >> Is it because the CG algorithm used by ADMM, or parameters setting issues >> here?? if it is parameters setting problem , would you help me and give a >> nice values for alpha and bate used here? >> >> BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already >> (including default value) >> >> Thanks and regards >> >> Guangming >> >> >> ?? >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> ? >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 1 08:45:35 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 1 Jul 2015 14:45:35 +0200 Subject: [Rtk-users] Release of RTK v1.1.0 Message-ID: Dear RTK users, RTK v1.1.0 has been released today, about 14 months after RTK v1.0.0. The main features that have been developed since the previous release are: - SimpleRTK to run RTK filters (even the CUDA ones) from python scripts, C# code, and more - new projection pre-processing options (i0 calculation, scatter correction, water pre-correction) - extraction of the respiratory phase from cone-beam projections - linear programming for field-of-view computation based on a third party software, lp solve 5.5 - management of off-center detector in iterative methods - new iterative 3D and 4D reconstruction methods with Daubechies wavelets regularization - new iterative 4D reconstruction method with motion-aware regularization - reduction of memory footprint, especially GPU memory - many new CUDA filters - more robust (many bugs and memory leaks fixed) - use of MathJax to display formulas in the documentation, e.g., here . Many thanks to the increasing number of contributors, in alphabetical order: Ben Champion, Chao Wu, Cyril Mory, I Putu Susila, Julien Jomier, Marc Vila, Mathieu Dupont, Matt Clarkson, Peter Keuschnigg, S?bastien Brousmiche, Simon Rit, Tristan Coulange, Yang K Park. We don't focus on releases since we have a public github repository that we try to keep stable, I still recommend the use of the master HEAD over releases to enjoy the new RTK developments before their release. We still have a few on-going projects for which we will use and enhance RTK. Simon (for the RTK consortium) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 1 15:39:14 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 1 Jul 2015 21:39:14 +0200 Subject: [Rtk-users] loading projection images for sart Message-ID: Hello, I got compiled the ITK and RTK with help of cmake. I also had a look at the examples coming with RTK. I want to run a simple SART and got projection images in the format PNG and BMP. So I create an instance of the ThreeDcircularProjectionGeometry, SARTConeBeamReconstructionFilter and add the geometric projection data. rtk::ThreeDCircularProjectionGeometry::Pointer geometry; geometry = rtk::ThreeDCircularProjectionGeometry::New(); geometry->AddProjection(??) rtk::SARTConeBeamReconstructionFilter::Pointer sart = rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); How to add a stack of images to the SART reconstruction, i.e. std::vector images ? I got xray projections in png format. There is a method in the SART class called SetInput. But according tot he examples it is used to set a volume. Does anybody alread wrote a small piece of code that loads some images from the disk and put them into the SART reconstruction ? Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 2 12:19:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 2 Jul 2015 18:19:36 +0200 Subject: [Rtk-users] loading projection images for sart In-Reply-To: References: Message-ID: Hi, The stack of 2D images is passed via a 3D image. Look at the rtksart application for example. A way to read this from a set of file names is to use itk::ImageSeriesReader as done in rtk::ProjectionsReader. You should be able to understand how it works by looking at the existing RTK applications in the applications subfolders. Simon On Wed, Jul 1, 2015 at 9:39 PM, Robert Callie? wrote: > Hello, > > I got compiled the ITK and RTK with help of cmake. I also had a look > > at the examples coming with RTK. I want to run a simple SART and > > got projection images in the format PNG and BMP. > > > > So I create an instance of the ThreeDcircularProjectionGeometry, > SARTConeBeamReconstructionFilter > > and add the geometric projection data. > > > > rtk::ThreeDCircularProjectionGeometry::Pointer geometry; > > geometry = rtk::ThreeDCircularProjectionGeometry::New(); > > geometry->AddProjection(??) > > > > rtk::SARTConeBeamReconstructionFilter::Pointer sart = > rtk::SARTConeBeamReconstructionFilter< OutputImageType >::New(); > > > > How to add a stack of images to the SART reconstruction, i.e. > std::vector images ? > > I got xray projections in png format. > > > > There is a method in the SART class called SetInput. But according tot he > examples it is used to set a volume. > > > > Does anybody alread wrote a small piece of code that loads some images > from the disk and put them into the SART reconstruction ? > > > > Regards, > > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Fri Jul 3 16:28:11 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 3 Jul 2015 23:28:11 +0300 Subject: [Rtk-users] Remote Control Issue in new RTK version Message-ID: Dear RTK community, There is some bug in RTK 1.1 version. That?s : When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 but i did not use Cuda at all.. What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. So i think it is some problem caused by itk ?? can we fix this issue?? Thanks for help in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Sat Jul 4 10:12:03 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Sat, 4 Jul 2015 17:12:03 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. Thanks for the help, Chao. *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ---------- Forwarded message ---------- From: Chao Wu Date: 2015-07-04 0:04 GMT+03:00 Subject: Re: Remote Control Issue To: Guangming Zang Cc: rtk-users-request at public.kitware.com, Simon Rit < simon.rit at creatis.insa-lyon.fr> Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. Regards, Chao Sent from Samsung Galaxy Note 3 2015?7?3? 10:26 PM? "Guangming Zang" ??? > Dear RTK community, > > There is some bug in RTK 1.1 version. That?s : > > When i run commands In 1.1 version with my computer in the lab, RTK works > fine, but when i use my laptop at home to remote control the computer in > the lab, it does not work. i.e., no matter the command are (rtkfdk, > ADMM,SART ?), an error is always shown: > > ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 > @ unknown : Cuda Error #3 > > but i did not use Cuda at all.. > > What?s more, when i run the 1.0 version RTK , it works well and no bug in > remoter control mode. > > So i think it is some problem caused by itk ?? can we fix this issue?? > > Thanks for help in advance > > > Regards > > Guangming > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Sat Jul 4 10:19:32 2015 From: ghostcz at hotmail.com (louie L) Date: Sat, 4 Jul 2015 16:19:32 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: I think because in most cases people use their graphics in TCC mode for scientific computations or don't use gpu at all where the rtk_use_cuda is false. Cheers, Louie Sent from my iOS > On 04 Jul 2015, at 16:12, Guangming Zang wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is defined, then if CUDA device is not available this error will occur. When using MS remote desktop, graphical card and driver are bypassed unless it is Tesla cards working in TCC mode. You can either compile exes without CUDA for remote desktop, or try other graphic-based remote desktop software like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > > 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> Dear RTK community, >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works fine, but when i use my laptop at home to remote control the computer in the lab, it does not work. i.e., no matter the command are (rtkfdk, ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> >> Regards >> >> Guangming >> >> Guangming Zang (Alex) >> King Abdullah University of Science and Technology(KAUST) >> University of Chinese Academy of Sciences(UCAS) >> >> >> >> >> This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > > > This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Mon Jul 6 05:32:18 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 6 Jul 2015 11:32:18 +0200 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Hi Guangming and all, Thanks for reporting this change of behavior. My first answer is that what you find simple is not so simple... but you're right, v1.0.0 allowed to compile RTK with CUDA and to run it without a CUDA device. After a bit of trakcing, I found that the change of behavior has been introduced with this patch so you can blame me. It has now fixed this issue with this patch , which seems to work on my laptop, I hope it does on your computer as well. I can't help you with the fact that you can't run CUDA software with remote control. Simon On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > I think because in most cases people use their graphics in TCC mode for > scientific computations or don't use gpu at all where the rtk_use_cuda is > false. > Cheers, > > Louie > > Sent from my iOS > > On 04 Jul 2015, at 16:12, Guangming Zang > wrote: > > Ok, i see. Though i still do not understand why in new version rtk changes > to call cudaimages, not keeping it simple like before. > Thanks for the help, Chao. > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ---------- Forwarded message ---------- > From: Chao Wu > Date: 2015-07-04 0:04 GMT+03:00 > Subject: Re: Remote Control Issue > To: Guangming Zang > Cc: rtk-users-request at public.kitware.com, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > > Now in many exes cudaimage is the default image type if rtk_use_cuda is > defined, then if CUDA device is not available this error will occur. When > using MS remote desktop, graphical card and driver are bypassed unless it > is Tesla cards working in TCC mode. You can either compile exes without > CUDA for remote desktop, or try other graphic-based remote desktop software > like vnc or teamviewer. > > Regards, Chao > Sent from Samsung Galaxy Note 3 > 2015?7?3? 10:26 PM? "Guangming Zang" ??? > >> Dear RTK community, >> >> There is some bug in RTK 1.1 version. That?s : >> >> When i run commands In 1.1 version with my computer in the lab, RTK works >> fine, but when i use my laptop at home to remote control the computer in >> the lab, it does not work. i.e., no matter the command are (rtkfdk, >> ADMM,SART ?), an error is always shown: >> >> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >> @ unknown : Cuda Error #3 >> >> but i did not use Cuda at all.. >> >> What?s more, when i run the 1.0 version RTK , it works well and no bug in >> remoter control mode. >> >> So i think it is some problem caused by itk ?? can we fix this issue?? >> >> Thanks for help in advance >> >> >> Regards >> >> Guangming >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 6 06:19:10 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 6 Jul 2015 13:19:10 +0300 Subject: [Rtk-users] Fwd: Remote Control Issue In-Reply-To: References: Message-ID: Thanks all for your help,Simon. I will try it again when i am at home :) As for using Cuda in remote control, i can handle it:just like what Chao said, change lab computer to TCC. What confused me at the beginning is that a cuda error shown while i did not call cuda at all, and thanks for fixing it. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-06 12:32 GMT+03:00 Simon Rit : > Hi Guangming and all, > Thanks for reporting this change of behavior. My first answer is that what > you find simple is not so simple... but you're right, v1.0.0 allowed to > compile RTK with CUDA and to run it without a CUDA device. After a bit of > trakcing, I found that the change of behavior has been introduced with this > patch > > so you can blame me. It has now fixed this issue with this patch > , > which seems to work on my laptop, I hope it does on your computer as well. > I can't help you with the fact that you can't run CUDA software with > remote control. > Simon > > On Sat, Jul 4, 2015 at 4:19 PM, louie L wrote: > >> I think because in most cases people use their graphics in TCC mode for >> scientific computations or don't use gpu at all where the rtk_use_cuda is >> false. >> Cheers, >> >> Louie >> >> Sent from my iOS >> >> On 04 Jul 2015, at 16:12, Guangming Zang >> wrote: >> >> Ok, i see. Though i still do not understand why in new version rtk >> changes to call cudaimages, not keeping it simple like before. >> Thanks for the help, Chao. >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ---------- Forwarded message ---------- >> From: Chao Wu >> Date: 2015-07-04 0:04 GMT+03:00 >> Subject: Re: Remote Control Issue >> To: Guangming Zang >> Cc: rtk-users-request at public.kitware.com, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> >> >> Now in many exes cudaimage is the default image type if rtk_use_cuda is >> defined, then if CUDA device is not available this error will occur. When >> using MS remote desktop, graphical card and driver are bypassed unless it >> is Tesla cards working in TCC mode. You can either compile exes without >> CUDA for remote desktop, or try other graphic-based remote desktop software >> like vnc or teamviewer. >> >> Regards, Chao >> Sent from Samsung Galaxy Note 3 >> 2015?7?3? 10:26 PM? "Guangming Zang" ??? >> >>> Dear RTK community, >>> >>> There is some bug in RTK 1.1 version. That?s : >>> >>> When i run commands In 1.1 version with my computer in the lab, RTK >>> works fine, but when i use my laptop at home to remote control the >>> computer in the lab, it does not work. i.e., no matter the command are >>> (rtkfdk, ADMM,SART ?), an error is always shown: >>> >>> ..\..\..\..\RTK-master\utilities\ITKCudaCommon\src\itkCudaDataManager.cxx:28 >>> @ unknown : Cuda Error #3 >>> >>> but i did not use Cuda at all.. >>> >>> What?s more, when i run the 1.0 version RTK , it works well and no bug >>> in remoter control mode. >>> >>> So i think it is some problem caused by itk ?? can we fix this issue?? >>> >>> Thanks for help in advance >>> >>> >>> Regards >>> >>> Guangming >>> *Guangming Zang (Alex)* >>> *King Abdullah University of Science and Technology(KAUST)* >>> *University of Chinese Academy of Sciences(UCAS)* >>> >>> >>> >>> >>> ------------------------------ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete >>> this message from your computer system. Any unauthorized use or >>> distribution is prohibited. Please consider the environment before printing >>> this email. >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Wed Jul 8 22:26:29 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Wed, 8 Jul 2015 19:26:29 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question Message-ID: Hi, I have a question from you about the CT reconstruction, I would really appreciate if you can help me with this. I have the geometry as described in following and I am trying to run the rtkfdk code from RTK. % parameters % % % % % % % param.nx = 500; % number of voxels param.ny = 500; param.nz = 500; param.sx = 5000; % mm (real size) param.sy = 5000; % mm param.sz = 5000; % mm %The real detector panel pixel density (number of pixels) param.nu = 36; % number of pixels param.nv = 100; % Detector setting (real size) param.su = 7200; % mm (real size) param.sv = 9200; % mm % X-ray source and detector setting param.DSD = 32900; % Distance source to detector param.DSO = 27400; % X-ray source to object axis distance % angle setting param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) param.dang = 5; % angular step size (deg) param.deg = 0:param.dang:360-1; % you can change param.deg = param.deg*param.dir; param.nProj = length(param.deg); param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than 360 deg -> param.parker=1 param.filter='ram-lak'; % high pass filter param.dx = param.sx/param.nx; % single voxel size param.dy = param.sy/param.ny; param.dz = param.sz/param.nz; param.du = param.su/param.nu; param.dv = param.sv/param.nv; param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) % Geometry calculation % % % param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : 360). But I got confused how to set the geometry parameters in RTK I followed the rtkfdk tutorial but I can?t get any result using this method I did the following: 1- Create geometry.xml using these parameters: nproj = 72 ; first_angle = 0 ; arc = 360 ; sid = 27400 ; sdd = 32900 ; proj_iso_x = 0; proj_iso_y = 0; out_angle = 0 ; in_angle = 0 ; source_x = 0; source_y = 0 ; 2- Create my own mha file (WriteMhaFile.m) from my projection array (36*100*72) using a matlab code with following properties: Voxel size = [0.1 0.1 0.1] Offset = [1 1 1] 3- Then run the: rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 --dimension 500 Could you please tell me if I am setting the geometry correctly? Also, is there any other way to create my own mha file? Thank you in advance and looking forward to hear back from you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 02:23:36 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 08:23:36 +0200 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Hi, We can try to help but we need to understand your geometry... Where does it come from by the way? If I understand your geometry correctly, I would say : - sid, sdd, nproj, arc are correct, - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 and you have 36x100 pixels, then the pixel size is [200,92,1] (last dimension is not used so anything). For the volume, if your volume is 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and not 0.1. - offset of projections is probably wrong. If you want to have a centered projections, you'll need something like (-3500, -554, 0). You can set is to 0 and put those values in proj_iso_x and proj_iso_y. Regarding mha file, you can write mha files in many ways, using SimpleRTK, matlab or writing an ITK code. Good luck! Simon On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah wrote: > Hi, > > I have a question from you about the CT reconstruction, I would really > appreciate if you can help me with this. > > I have the geometry as described in following and I am trying to run the > rtkfdk code from RTK. > > > % parameters % % % % % % % > > param.nx = 500; % number of voxels > param.ny = 500; > param.nz = 500; > > > param.sx = 5000; % mm (real size) > param.sy = 5000; % mm > param.sz = 5000; % mm > > > %The real detector panel pixel density (number of pixels) > param.nu = 36; % number of pixels > param.nv = 100; > > % Detector setting (real size) > param.su = 7200; % mm (real size) > param.sv = 9200; % mm > > > % X-ray source and detector setting > param.DSD = 32900; % Distance source to detector > param.DSO = 27400; % X-ray source to object axis distance > > > % angle setting > param.dir = +1; % gantry rotating direction (clock wise/ counter clockwise) > param.dang = 5; % angular step size (deg) > param.deg = 0:param.dang:360-1; % you can change > param.deg = param.deg*param.dir; > param.nProj = length(param.deg); > > param.parker = 0; % data with 360 deg -> param.parker = 0 , data less than > 360 deg -> param.parker=1 > > param.filter='ram-lak'; % high pass filter > > > param.dx = param.sx/param.nx; % single voxel size > param.dy = param.sy/param.ny; > param.dz = param.sz/param.nz; > param.du = param.su/param.nu; > param.dv = param.sv/param.nv; > param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) > > > % Geometry calculation % % % > param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; > param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; > param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; > param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; > param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; > > > > So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : > 360). > But I got confused how to set the geometry parameters in RTK > I followed the rtkfdk tutorial but I can?t get any result using this method > > I did the following: > > 1- Create geometry.xml using these parameters: > > nproj = 72 ; > first_angle = 0 ; > arc = 360 ; > sid = 27400 ; > sdd = 32900 ; > proj_iso_x = 0; > proj_iso_y = 0; > out_angle = 0 ; > in_angle = 0 ; > source_x = 0; > source_y = 0 ; > > 2- Create my own mha file (WriteMhaFile.m) from my projection array > (36*100*72) using a matlab code with following properties: > Voxel size = [0.1 0.1 0.1] > Offset = [1 1 1] > > > 3- Then run the: > rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 > --dimension 500 > > > Could you please tell me if I am setting the geometry correctly? > Also, is there any other way to create my own mha file? > > Thank you in advance and looking forward to hear back from you. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jul 9 12:12:01 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Jul 2015 18:12:01 +0200 Subject: [Rtk-users] RTK training In-Reply-To: <55816290.1010807@uclouvain.be> References: <55816290.1010807@uclouvain.be> Message-ID: Dear RTK users, We have finally set a date for the RTK training, Wednesday, Nov 18 2015 in Lyon (France). The training will be organised by Kitware, go to this page for the registration: http://formations.kitware.fr/browse/116 We will do both user and developer sessions during the training. Since it's the first time that we do the training, we will tailor the balance between the two according to the wishes of registered people. The rest of the information should be available on the website but let us know if you need more information, we are still building the webpage and we'll be happy to improve it. We're looking forward to this new training and we'll do our best to meet your expectations, Simon On Wed, Jun 17, 2015 at 2:05 PM, Cyril Mory wrote: > Dear RTK users, > > The first RTK training is being planned at this very moment. It should > take place in November in Lyon, and be hosted by Kitware. The exact date > has not yet been decided, but will be available soon. > > We need your help to decide what to focus this training on. The choice is > mainly between two options: > - if most trainees want to learn how to use RTK, then we will focus on the > command-line tools and on python + Simple RTK > - if most trainees want to learn how to develop within RTK, modify and > enrich it, then we will focus on software architecture, detailed filter > description, ITK pipeline management, CUDA filters, etc... > > Please let us know which of these choices would best suit your needs. > > Looking forward, > Cyril > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.yazdanpanah at gmail.com Thu Jul 9 17:59:05 2015 From: ali.yazdanpanah at gmail.com (Ali Yazdanpanah) Date: Thu, 9 Jul 2015 14:59:05 -0700 Subject: [Rtk-users] Rtkfdk Geometry Question In-Reply-To: References: Message-ID: Simon, Thank you. I think now I understand how the whole geometry is defined in RTK. The projection is based on one experiment I am doing using different simulation techniques. Again thank you for your help. Best, Ali On Wed, Jul 8, 2015 at 11:23 PM, Simon Rit wrote: > Hi, > We can try to help but we need to understand your geometry... Where does > it come from by the way? If I understand your geometry correctly, I would > say : > - sid, sdd, nproj, arc are correct, > - voxel size is wrong. For the detector, if your detector is 7200x9200 mm2 > and you have 36x100 pixels, then the pixel size is [200,92,1] (last > dimension is not used so anything). For the volume, if your volume is > 5000^3 mm^3 and you have 500^3 voxels, then pixel size is [10,10,10] and > not 0.1. > - offset of projections is probably wrong. If you want to have a centered > projections, you'll need something like (-3500, -554, 0). You can set is to > 0 and put those values in proj_iso_x and proj_iso_y. > Regarding mha file, you can write mha files in many ways, using SimpleRTK, > matlab or writing an ITK code. > Good luck! > Simon > > On Thu, Jul 9, 2015 at 4:26 AM, Ali Yazdanpanah > wrote: > >> Hi, >> >> I have a question from you about the CT reconstruction, I would really >> appreciate if you can help me with this. >> >> I have the geometry as described in following and I am trying to run the >> rtkfdk code from RTK. >> >> >> % parameters % % % % % % % >> >> param.nx = 500; % number of voxels >> param.ny = 500; >> param.nz = 500; >> >> >> param.sx = 5000; % mm (real size) >> param.sy = 5000; % mm >> param.sz = 5000; % mm >> >> >> %The real detector panel pixel density (number of pixels) >> param.nu = 36; % number of pixels >> param.nv = 100; >> >> % Detector setting (real size) >> param.su = 7200; % mm (real size) >> param.sv = 9200; % mm >> >> >> % X-ray source and detector setting >> param.DSD = 32900; % Distance source to detector >> param.DSO = 27400; % X-ray source to object axis distance >> >> >> % angle setting >> param.dir = +1; % gantry rotating direction (clock wise/ counter >> clockwise) >> param.dang = 5; % angular step size (deg) >> param.deg = 0:param.dang:360-1; % you can change >> param.deg = param.deg*param.dir; >> param.nProj = length(param.deg); >> >> param.parker = 0; % data with 360 deg -> param.parker = 0 , data less >> than >> 360 deg -> param.parker=1 >> >> param.filter='ram-lak'; % high pass filter >> >> >> param.dx = param.sx/param.nx; % single voxel size >> param.dy = param.sy/param.ny; >> param.dz = param.sz/param.nz; >> param.du = param.su/param.nu; >> param.dv = param.sv/param.nv; >> param.off_u = 0; param.off_v = 0; % detector rotation shift (real size) >> >> >> % Geometry calculation % % % >> param.xs = [-(param.nx-1)/2:1:(param.nx-1)/2]*param.dx; >> param.ys = [-(param.ny-1)/2:1:(param.ny-1)/2]*param.dy; >> param.zs = [-(param.nz-1)/2:1:(param.nz-1)/2]*param.dz; >> param.us = (-(param.nu-1)/2:1:(param.nu-1)/2)*param.du + param.off_u; >> param.vs = (-(param.nv-1)/2:1:(param.nv-1)/2)*param.dv + param.off_v; >> >> >> >> So basically my final projection array has 36 * 100 * 72(=angles: 0 : 5 : >> 360). >> But I got confused how to set the geometry parameters in RTK >> I followed the rtkfdk tutorial but I can?t get any result using this >> method >> >> I did the following: >> >> 1- Create geometry.xml using these parameters: >> >> nproj = 72 ; >> first_angle = 0 ; >> arc = 360 ; >> sid = 27400 ; >> sdd = 32900 ; >> proj_iso_x = 0; >> proj_iso_y = 0; >> out_angle = 0 ; >> in_angle = 0 ; >> source_x = 0; >> source_y = 0 ; >> >> 2- Create my own mha file (WriteMhaFile.m) from my projection array >> (36*100*72) using a matlab code with following properties: >> Voxel size = [0.1 0.1 0.1] >> Offset = [1 1 1] >> >> >> 3- Then run the: >> rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 0.1 >> --dimension 500 >> >> >> Could you please tell me if I am setting the geometry correctly? >> Also, is there any other way to create my own mha file? >> >> Thank you in advance and looking forward to hear back from you. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hougeamm at 126.com Thu Jul 9 18:35:09 2015 From: hougeamm at 126.com (=?GBK?B?uu645w==?=) Date: Fri, 10 Jul 2015 06:35:09 +0800 (CST) Subject: [Rtk-users] problems for elekta data Message-ID: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Hello Everyone, Why the Elekta data prompt projection doesn't match when using rtkfdk? e.g., 377 vs 389? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 10 01:43:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Jul 2015 07:43:15 +0200 Subject: [Rtk-users] problems for elekta data In-Reply-To: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> References: <70a1ba84.122c9.14e74f54bbb.Coremail.hougeamm@126.com> Message-ID: Hi, The message that you have on the command line is the result of the files that have been found in the path (--path option) with the regular expression (--regexp option). If it found more projections than what you have, then you probably need to improve your reg exp, e.g., by a $ after the file extension to specify that the file name must end with it. Simon On Fri, Jul 10, 2015 at 12:35 AM, ?? wrote: > Hello Everyone, > Why the Elekta data prompt projection doesn't match when using > rtkfdk? e.g., 377 vs 389? > Thanks! > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From guangming.zang at kaust.edu.sa Mon Jul 13 02:48:15 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 09:48:15 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset Message-ID: Hi RTK comunity, Besides the prameters like SID and SDD , from the geometry(.xteck) file got from my scanner, i also have object (volume) information like this: VoxelsX=179 VoxelsY=163 VoxelsZ=127 VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 The X,Y and Z axis are identical to RTK's geometry , So i was really wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i can show all other parameters like: rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, but it still a slight different visualization result from what we got from scanner software. So would you help me??? File attached is the geometry file in case. Thanks in advance Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VCC_Dome_0622.xtekct Type: application/octet-stream Size: 1813 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 13 04:38:00 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 13 Jul 2015 11:38:00 +0300 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: problem fixed. because the scanned object is symmetric and i did not notice that i should -Z axis in scanner to map Z in RTK thanks. but, i still do not know in RTK how to show the OffsetZ.. :( Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-13 9:48 GMT+03:00 Guangming Zang : > Hi RTK comunity, > Besides the prameters like SID and SDD , from the geometry(.xteck) file > got from my scanner, i also have object (volume) information like this: > VoxelsX=179 VoxelsY=163 VoxelsZ=127 > VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 > OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 > The X,Y and Z axis are identical to RTK's geometry , So i was really > wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i > can show all other parameters like: > > rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing > 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 > --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 > > Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, > but it still a slight different visualization result from what we got from > scanner software. > So would you help me??? > > > File attached is the geometry file in case. Thanks in advance > Regards > Guangming > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Mon Jul 13 13:21:44 2015 From: robert.calliess at gmx.de (=?utf-8?Q?Robert_Callie=C3=9F?=) Date: Mon, 13 Jul 2015 19:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? Message-ID: Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 13 13:42:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 13 Jul 2015 19:42:43 +0200 Subject: [Rtk-users] Parameters to show Volume 's Z offset In-Reply-To: References: Message-ID: Hi, OffsetZ probably refers to the coordinate of the volume in the room coordinate which we don't use in RTK. Everything is set in the tomography coordinate during reconstruction. You can always change the coordinates of your volume after if you want to put it in some other coordinate system. Simon On Mon, Jul 13, 2015 at 10:38 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > problem fixed. > because the scanned object is symmetric and i did not notice that i > should -Z axis in scanner to map Z in RTK > thanks. > but, i still do not know in RTK how to show the OffsetZ.. :( > > Guangming > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-13 9:48 GMT+03:00 Guangming Zang : > >> Hi RTK comunity, >> Besides the prameters like SID and SDD , from the geometry(.xteck) file >> got from my scanner, i also have object (volume) information like this: >> VoxelsX=179 VoxelsY=163 VoxelsZ=127 >> VoxelSizeX=0.3751 VoxelSizeY=0.3751 VoxelSizeZ=0.3751 >> OffsetX=-0.5386 OffsetY=-2.9935 OffsetZ=-1.0744 >> The X,Y and Z axis are identical to RTK's geometry , So i was really >> wondering how to show the offsetZ in our RTK setting?? besides OffsetZ, i >> can show all other parameters like: >> >> rtkfdk -p . -r sub_proj.mhd -o fdk.mha -g sub_geo.xml --newspacing >> 0.127(detector spacing or pixel spaing) --neworigin -0.5386,-2.9935 >> --spacing 0.3751,0.3751,0.3751 --dimension 179,163,127 >> >> Also, i tried to change the SID,i.e., SID=SID-1.0744 or SID=SID+1.0744, >> but it still a slight different visualization result from what we got from >> scanner software. >> So would you help me??? >> >> >> File attached is the geometry file in case. Thanks in advance >> Regards >> Guangming >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Tue Jul 14 03:01:14 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 14 Jul 2015 09:01:14 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 01:32:43 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 07:32:43 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: > Hell RTK User, > I think there is a mistake in the described approach. > Point a) and f) meight be wrong. As far as I Understand, all Pixels > that are covered by the projected voxel vertices are update > with weight * voxel_value. Where weight is the overlaping area > of the projected voxel vertices polygon on the detector plane and the > underlying detector pixels. > > Any opinions before implementing it ? > > regards, > Robert > > *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr > *Von:* "Robert Callie?" > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what > they called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can > be rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector > cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value > to back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Calliess at gmx.de Wed Jul 15 08:07:20 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Wed, 15 Jul 2015 14:07:20 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 08:21:44 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 14:21:44 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: > Hello Simon, > thank you for your answer. I guess you linked the wrong article. But I > know what article you are talking about. > It's the articel from 2009 with a piece of code (MapSeq). > > >> I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > detector pixels that are totally covered by the overlap are weight with > "1" and if the overlap is between detector pixels > the pixels are weighted. Do you have a copy of the original article from > the De Man and Basu ? > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > Do you agree with that or did I miss something ? > > best regards, > Robert > > *Gesendet:* Mittwoch, 15. Juli 2015 um 07:32 Uhr > *Von:* "Simon Rit" > *An:* "Robert Callie?" > *Cc:* "rtk-users at public.kitware.com" > *Betreff:* Re: [Rtk-users] distance driven projector, a simplified > approach ? > Hi, > Indeed, I have published an article > on this > projector describing my implementation, you could use it if you want, > there's even a piece of code in it although I'm pretty sure it's not the > best implementation. This implementation dealt with the case where the > rotation axis is parallel to the detector. As far as I can remember, the > original article of De Man and Basu is also quite clear. > I don't have time to go into the details of what you have proposed but, > from a glance, the first step seems useless. > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > Simon > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: >> >> Hell RTK User, >> I think there is a mistake in the described approach. >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> that are covered by the projected voxel vertices are update >> with weight * voxel_value. Where weight is the overlaping area >> of the projected voxel vertices polygon on the detector plane and the >> underlying detector pixels. >> >> Any opinions before implementing it ? >> >> regards, >> Robert >> >> *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr >> *Von:* "Robert Callie?" >> *An:* rtk-users at public.kitware.com >> *Betreff:* [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel boundaries >> onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel?s contribution (weight) is the area of this overlapping. I >> read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is what >> they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone beam >> geometry. We can >> >> either rotate the detector and source around the object or the object can >> be rotated >> >> and the detector and source are fixed. I think Simon also wrote a paper >> about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source position, >> object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector >> cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the >> corresponding detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a ? e). Value >> to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I?m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of voxel >> boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Wed Jul 15 15:14:13 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Wed, 15 Jul 2015 21:14:13 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Hello Simon, thank you for the articles. May I ask you what do you mean by ?voxel correction factor? in the code you provided in your article ? float f) // Voxel correction factor Thank you and best regards, Robert Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit Gesendet: Mittwoch, 15. Juli 2015 14:22 An: Robert Callie? Cc: rtk-users at public.kitware.com Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? Sorry, this link indeed with the MapSeg function. And yes, I was projecting it to the detector plane directly. Simon On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" wrote: Hello Simon, thank you for your answer. I guess you linked the wrong article. But I know what article you are talking about. It's the articel from 2009 with a piece of code (MapSeq). >> I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. You're right. It is that all pixels that are related to the overlap projected voxel overlap have to taken into account. So detector pixels that are totally covered by the overlap are weight with "1" and if the overlap is between detector pixels the pixels are weighted. Do you have a copy of the original article from the De Man and Basu ? I have the opinion that it's not neccessary to project the detector pixel boundaries and voxel boundaries onto a common plane if we use a flat panel detector. Instead we could project the voxel boundaries onto the detector plane directly. Do you agree with that or did I miss something ? best regards, Robert Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr Von: "Simon Rit" An: "Robert Callie?" Cc: "rtk-users at public.kitware.com" Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? Hi, Indeed, I have published an article on this projector describing my implementation, you could use it if you want, there's even a piece of code in it although I'm pretty sure it's not the best implementation. This implementation dealt with the case where the rotation axis is parallel to the detector. As far as I can remember, the original article of De Man and Basu is also quite clear. I don't have time to go into the details of what you have proposed but, from a glance, the first step seems useless. Good luck in your implementation and don't hesitate to send it to us when you have a working RTK implementation, Simon On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" wrote: Hell RTK User, I think there is a mistake in the described approach. Point a) and f) meight be wrong. As far as I Understand, all Pixels that are covered by the projected voxel vertices are update with weight * voxel_value. Where weight is the overlaping area of the projected voxel vertices polygon on the detector plane and the underlying detector pixels. Any opinions before implementing it ? regards, Robert Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr Von: "Robert Callie?" An: rtk-users at public.kitware.com Betreff: [Rtk-users] distance driven projector, a simplified approach ? Hello RTK users, I guess you know about the distance-driven projector. The main idea, as far as I understand, of this algorithm is to project voxel boundaries onto a common plane and the detector cell boundaries also on this common plane. Then the voxel?s contribution (weight) is the area of this overlapping. I read that the projection of the voxel and detector cell boundaries on a common plane can be simplified if the detector is a flat panel detector (guess this is what they called fixed detector geometry). Even if they mean by fixed-detector geometry that the detector is not moving, we could use this simplification in a circular cone beam geometry. We can either rotate the detector and source around the object or the object can be rotated and the detector and source are fixed. I think Simon also wrote a paper about the distance driven projector (?). So my simplified approach would be (fixed detector and source position, object is rotating): a) project voxel center on detector plane to determine the corresponding detector cell b) project voxel vertices on detector plane (dertemine area of this projected polygon) c) for each projected voxel vertex dertermine the neares detector cell o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) d) dertermine the area of the polygon described by the corresponding detector cells (c) e) weight = area_from_b / area_from_d f) add voxel_value * weight in detector cell determined in a For the back projector the steps would be always the same (a ? e). Value to back project Is taken from the correction image at position determined in step a. For step b and d we could determine the minimum bounding rect and use this as the polygons areas. So the weights should always be between 0 and 1 ( Wether the MEB lies exactly on the detector cells or in between) I?m new to this topic. I want to hear your opinion. Is this a possible interpretation of the distance-driven projector, since the main idea is to calculate the overlapping of voxel boundaries with detector cell bounderies. Best Regards, Robert _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Jul 15 15:45:23 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Jul 2015 21:45:23 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. Simon On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie? wrote: > Hello Simon, > > thank you for the articles. May I ask you what do you mean by > > ?voxel correction factor? in the code you provided in your article ? > > float f) // Voxel correction factor > > > > Thank you and best regards, > > Robert > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Mittwoch, 15. Juli 2015 14:22 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified > approach ? > > > > Sorry, this link indeed with the MapSeg function. And yes, I was projecting > it to the detector plane directly. > > Simon > > > > On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie?" > wrote: > > Hello Simon, > > thank you for your answer. I guess you linked the wrong article. But I know > what article you are talking about. > > It's the articel from 2009 with a piece of code (MapSeq). > > > >>> I don't have time to go into the details of what you have proposed but, >>> from a glance, the first step seems useless. > > You're right. It is that all pixels that are related to the overlap > projected voxel overlap have to taken into account. So > > detector pixels that are totally covered by the overlap are weight with "1" > and if the overlap is between detector pixels > > the pixels are weighted. Do you have a copy of the original article from the > De Man and Basu ? > > > > I have the opinion that it's not neccessary to project the detector pixel > boundaries and voxel boundaries onto a common plane > > if we use a flat panel detector. Instead we could project the voxel > boundaries onto the detector plane directly. > > Do you agree with that or did I miss something ? > > > > best regards, > > Robert > > > > Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr > Von: "Simon Rit" > An: "Robert Callie?" > Cc: "rtk-users at public.kitware.com" > Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? > > Hi, > > Indeed, I have published an article on this projector describing my > implementation, you could use it if you want, there's even a piece of code > in it although I'm pretty sure it's not the best implementation. This > implementation dealt with the case where the rotation axis is parallel to > the detector. As far as I can remember, the original article of De Man and > Basu is also quite clear. > > I don't have time to go into the details of what you have proposed but, from > a glance, the first step seems useless. > > Good luck in your implementation and don't hesitate to send it to us when > you have a working RTK implementation, > > Simon > > > > On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie?" > wrote: > > Hell RTK User, > > I think there is a mistake in the described approach. > > Point a) and f) meight be wrong. As far as I Understand, all Pixels > > that are covered by the projected voxel vertices are update > > with weight * voxel_value. Where weight is the overlaping area > > of the projected voxel vertices polygon on the detector plane and the > > underlying detector pixels. > > > > Any opinions before implementing it ? > > > > regards, > > Robert > > > > Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr > Von: "Robert Callie?" > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] distance driven projector, a simplified approach ? > > Hello RTK users, > > I guess you know about the distance-driven projector. The main idea, > > as far as I understand, of this algorithm is to project voxel boundaries > onto > > a common plane and the detector cell boundaries also on this common plane. > > Then the voxel?s contribution (weight) is the area of this overlapping. I > read that the > > projection of the voxel and detector cell boundaries on a common plane can > be > > simplified if the detector is a flat panel detector (guess this is what they > called fixed > > detector geometry). Even if they mean by fixed-detector geometry that the > detector > > is not moving, we could use this simplification in a circular cone beam > geometry. We can > > either rotate the detector and source around the object or the object can be > rotated > > and the detector and source are fixed. I think Simon also wrote a paper > about the > > distance driven projector (?). > > > > > > So my simplified approach would be (fixed detector and source position, > object is rotating): > > > > a) project voxel center on detector plane to determine the > corresponding detector cell > > b) project voxel vertices on detector plane (dertemine area of this > projected polygon) > > c) for each projected voxel vertex dertermine the neares detector cell > > o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) > > d) dertermine the area of the polygon described by the corresponding > detector cells (c) > > e) weight = area_from_b / area_from_d > > f) add voxel_value * weight in detector cell determined in a > > > > For the back projector the steps would be always the same (a ? e). Value to > back project > > Is taken from the correction image at position determined in step a. > > For step b and d we could determine the minimum bounding rect and use this > as the polygons areas. > > So the weights should always be between 0 and 1 ( Wether the MEB lies > exactly on the detector cells > > or in between) > > > > I?m new to this topic. I want to hear your opinion. Is this a possible > interpretation of the distance-driven > > projector, since the main idea is to calculate the overlapping of voxel > boundaries with detector cell bounderies. > > > > > > Best Regards, > > Robert > > > > _______________________________________________ Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From simon.rit at creatis.insa-lyon.fr Fri Jul 17 02:22:16 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 17 Jul 2015 08:22:16 +0200 Subject: [Rtk-users] distance driven projector, a simplified approach ? In-Reply-To: References: Message-ID: Please keep on using the mailing list, I don't see a good reason to keep this conversation private. I won't have time to go back into these details. From a quick look, I think this is correct although I would have simply said that D is the center of the detector pixel. Simon On Thu, Jul 16, 2015 at 10:24 PM, Robert Callie? wrote: > Hello, > Sorry that I have to ask again. But I want to clear this before I start. > I want to ask about the cosine weight DeMan mentioned in his article. > He wrote: > > " > (1) The intersection length of the line of interest with the image slab S, the latter being > defined as the slab parallel to the xz plane and containing voxel V. This intersection length > is given by t/(cos ? cos ? ), where t is the isotropic voxel size, and ? and ? are the in- and > out-of-plane angles of the line of interest with the y-axis. > " > > So what he actually does, is that he calculates the intersection length of the slab s (that contains the voxel) with > a ray going from xray source to the middle of two adjacent detector cell boundaries. Let's refare to Figure 5. > So the length to be considered is calculated as the intersection length of slab S with the ray going from > the source ( the black dot in figure 5) to the mid-point of D, that means the center of the two projected adjacent > detector pixel boundaries. > > > Sorry for asking again but I want it to make it clear to me. > > Best regards, > Robert > > > -----Urspr?ngliche Nachricht----- > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit > Gesendet: Mittwoch, 15. Juli 2015 21:45 > An: Robert Callie? > Cc: rtk-users at public.kitware.com > Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ? > > "f is set to the fraction along v multiplied by the length of the intersection between the ray and the segment" > So MapSeg handles one side of the rectangle intersections and f contains the length of the other side and the step length, i.e., the distance between the intersection points of the ray and two consecutive planes in the main direction. > Simon > > On Wed, Jul 15, 2015 at 9:14 PM, Robert Callie wrote: >> Hello Simon, >> >> thank you for the articles. May I ask you what do you mean by >> >> voxel correction factor in the code you provided in your article ? >> >> float f) // Voxel correction factor >> >> >> >> Thank you and best regards, >> >> Robert >> >> >> >> Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von >> Simon Rit >> Gesendet: Mittwoch, 15. Juli 2015 14:22 >> An: Robert Callie >> Cc: rtk-users at public.kitware.com >> Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified >> approach ? >> >> >> >> Sorry, this link indeed with the MapSeg function. And yes, I was >> projecting it to the detector plane directly. >> >> Simon >> >> >> >> On Wed, Jul 15, 2015 at 2:07 PM, "Robert Callie " >> >> wrote: >> >> Hello Simon, >> >> thank you for your answer. I guess you linked the wrong article. But I >> know what article you are talking about. >> >> It's the articel from 2009 with a piece of code (MapSeq). >> >> >> >>>> I don't have time to go into the details of what you have proposed >>>> but, from a glance, the first step seems useless. >> >> You're right. It is that all pixels that are related to the overlap >> projected voxel overlap have to taken into account. So >> >> detector pixels that are totally covered by the overlap are weight with "1" >> and if the overlap is between detector pixels >> >> the pixels are weighted. Do you have a copy of the original article >> from the De Man and Basu ? >> >> >> >> I have the opinion that it's not neccessary to project the detector >> pixel boundaries and voxel boundaries onto a common plane >> >> if we use a flat panel detector. Instead we could project the voxel >> boundaries onto the detector plane directly. >> >> Do you agree with that or did I miss something ? >> >> >> >> best regards, >> >> Robert >> >> >> >> Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr >> Von: "Simon Rit" >> An: "Robert Callie " >> Cc: "rtk-users at public.kitware.com" >> Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hi, >> >> Indeed, I have published an article on this projector describing my >> implementation, you could use it if you want, there's even a piece of >> code in it although I'm pretty sure it's not the best implementation. >> This implementation dealt with the case where the rotation axis is >> parallel to the detector. As far as I can remember, the original >> article of De Man and Basu is also quite clear. >> >> I don't have time to go into the details of what you have proposed >> but, from a glance, the first step seems useless. >> >> Good luck in your implementation and don't hesitate to send it to us >> when you have a working RTK implementation, >> >> Simon >> >> >> >> On Tue, Jul 14, 2015 at 9:01 AM, "Robert Callie " >> >> wrote: >> >> Hell RTK User, >> >> I think there is a mistake in the described approach. >> >> Point a) and f) meight be wrong. As far as I Understand, all Pixels >> >> that are covered by the projected voxel vertices are update >> >> with weight * voxel_value. Where weight is the overlaping area >> >> of the projected voxel vertices polygon on the detector plane and the >> >> underlying detector pixels. >> >> >> >> Any opinions before implementing it ? >> >> >> >> regards, >> >> Robert >> >> >> >> Gesendet: Montag, 13. Juli 2015 um 19:21 Uhr >> Von: "Robert Callie " >> An: rtk-users at public.kitware.com >> Betreff: [Rtk-users] distance driven projector, a simplified approach ? >> >> Hello RTK users, >> >> I guess you know about the distance-driven projector. The main idea, >> >> as far as I understand, of this algorithm is to project voxel >> boundaries onto >> >> a common plane and the detector cell boundaries also on this common plane. >> >> Then the voxel s contribution (weight) is the area of this >> overlapping. I read that the >> >> projection of the voxel and detector cell boundaries on a common plane >> can be >> >> simplified if the detector is a flat panel detector (guess this is >> what they called fixed >> >> detector geometry). Even if they mean by fixed-detector geometry that >> the detector >> >> is not moving, we could use this simplification in a circular cone >> beam geometry. We can >> >> either rotate the detector and source around the object or the object >> can be rotated >> >> and the detector and source are fixed. I think Simon also wrote a >> paper about the >> >> distance driven projector (?). >> >> >> >> >> >> So my simplified approach would be (fixed detector and source >> position, object is rotating): >> >> >> >> a) project voxel center on detector plane to determine the >> corresponding detector cell >> >> b) project voxel vertices on detector plane (dertemine area of this >> projected polygon) >> >> c) for each projected voxel vertex dertermine the neares detector cell >> >> o i.e. vertex(20.3, 10.1) => DetectorCell(20, 10) >> >> d) dertermine the area of the polygon described by the corresponding >> detector cells (c) >> >> e) weight = area_from_b / area_from_d >> >> f) add voxel_value * weight in detector cell determined in a >> >> >> >> For the back projector the steps would be always the same (a e). >> Value to back project >> >> Is taken from the correction image at position determined in step a. >> >> For step b and d we could determine the minimum bounding rect and use >> this as the polygons areas. >> >> So the weights should always be between 0 and 1 ( Wether the MEB lies >> exactly on the detector cells >> >> or in between) >> >> >> >> I m new to this topic. I want to hear your opinion. Is this a possible >> interpretation of the distance-driven >> >> projector, since the main idea is to calculate the overlapping of >> voxel boundaries with detector cell bounderies. >> >> >> >> >> >> Best Regards, >> >> Robert >> >> >> >> _______________________________________________ Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > From guangming.zang at kaust.edu.sa Sun Jul 26 18:30:42 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 01:30:42 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed Message-ID: Hi RTK community, i am using SART algorithm to reconstruct an object. But in this new RTK version, the time recording seems a little weird: the total time is 1219.12s , but adding the time cost in different stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward projection part. BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, both multi-threading i think. Can anyone tell me what's going on? Thanks Regards Guangming [image: ???? 1] *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 01:59:11 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 07:59:11 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Guangming, It's not surprising to me that the backprojection is faster than the forward projection, that's what I expect. If the total time is longer, that's probably that some individual steps are not included in the total time. Can you try to add reader->Update(); before the line itk::TimeProbe totalTimeProbe; in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? Simon On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < guangming.zang at kaust.edu.sa> wrote: > Hi RTK community, > i am using SART algorithm to reconstruct an object. > But in this new RTK version, the time recording seems a little weird: > the total time is 1219.12s , but adding the time cost in different stages > is not 1291.12 s. especially for "backprojection" part, only 16.6051s to > reconstruct a 128^3 volume ?? even shorter than forward projection part. > BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, > both multi-threading i think. > Can anyone tell me what's going on? > Thanks > Regards > Guangming > > [image: ???? 1] > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Mon Jul 27 04:41:58 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 11:41:58 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, Thanks for your reply. would you pls help and explain why backprojection is expected to take shorter time than forward projection?? because i was thinking if no caching step, the backprojection should take much longer time than sart algorithm. yes, i run rtksart for 2 times once.it took 12xxs, similar to the time consumed of 3 times's sart, which much slower than my own application. BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 shapp-logan projections(512*512 resolution each) rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 and i will try reader->Update() like what you said. Thanks Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 8:59 GMT+03:00 Simon Rit : > Hi Guangming, > It's not surprising to me that the backprojection is faster than the > forward projection, that's what I expect. If the total time is longer, > that's probably that some individual steps are not included in the total > time. Can you try to add > reader->Update(); > before the line > > itk::TimeProbe totalTimeProbe; > > in rtksart.cxx? It may be that all the reading operations are done but not timed in the sart->Update(). Why they are so long, I don't know, is your D: drive a network drive? Do you observe the same behavior if you do rtksart 2 times in a row? > > Simon > > > > On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi RTK community, >> i am using SART algorithm to reconstruct an object. >> But in this new RTK version, the time recording seems a little weird: >> the total time is 1219.12s , but adding the time cost in different >> stages is not 1291.12 s. especially for "backprojection" part, only >> 16.6051s to reconstruct a 128^3 volume ?? even shorter than forward >> projection part. BTW, the -f and -b are Joseph and >> VoxelBasedBackProjection, respectively, both multi-threading i think. >> Can anyone tell me what's going on? >> Thanks >> Regards >> Guangming >> >> [image: ???? 1] >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SART.png Type: image/png Size: 20825 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 08:28:28 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 14:28:28 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: I can try. Forward and back projection have the same algorithmic complexity but voxel based backprojection benefits from several optimizations in terms of memory management and computations that makes it faster. The best is to look at the code for further details... although both have far from being optimal. And I did not get the sentence "the backprojection should take much longer time than sart algorithm." because SART contains a backprojection and other steps so SART is obviously longer than the bp alone. Your log is strange and I don't see what steps are not timed that would take most of the time. I did the same test on my computer and here is my result: OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha --dimension 512 OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.288571 s Multiplication by zero: 0.131672 s Forward projection: 34.3612 s Subtraction: 0.203409 s Multiplication by lambda: 0.146459 s Ray box intersection: 1.30755 s Division: 0.187294 s Multiplication by the gating weights: 0 s Displaced detector: 0.278408 s Back projection: 11.8456 s Volume update: 0 s It took... 53.2765 s Simon On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang wrote: > Hi Simon, > Thanks for your reply. > would you pls help and explain why backprojection is expected to take > shorter time than forward projection?? because i was thinking if no caching > step, the backprojection should take much longer time than sart algorithm. > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > consumed of 3 times's sart, which much slower than my own application. > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > shapp-logan projections(512*512 resolution each) > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > -64,-64,-64 -l 0.5 -n 3 --time 1 > > and i will try reader->Update() like what you said. > Thanks > Guangming > > > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> Hi Guangming, >> It's not surprising to me that the backprojection is faster than the >> forward projection, that's what I expect. If the total time is longer, >> that's probably that some individual steps are not included in the total >> time. Can you try to add >> reader->Update(); >> before the line >> >> itk::TimeProbe totalTimeProbe; >> >> in rtksart.cxx? It may be that all the reading operations are done but not >> timed in the sart->Update(). Why they are so long, I don't know, is your D: >> drive a network drive? Do you observe the same behavior if you do rtksart 2 >> times in a row? >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> wrote: >>> >>> Hi RTK community, >>> i am using SART algorithm to reconstruct an object. >>> But in this new RTK version, the time recording seems a little weird: >>> the total time is 1219.12s , but adding the time cost in different >>> stages is not 1291.12 s. especially for "backprojection" part, only 16.6051s >>> to reconstruct a 128^3 volume ?? even shorter than forward projection part. >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, respectively, >>> both multi-threading i think. >>> Can anyone tell me what's going on? >>> Thanks >>> Regards >>> Guangming >>> >>> >>> Guangming Zang (Alex) >>> King Abdullah University of Science and Technology(KAUST) >>> University of Chinese Academy of Sciences(UCAS) >>> >>> >>> >>> >>> ________________________________ >>> This message and its contents, including attachments are intended solely >>> for the original recipient. If you are not the intended recipient or have >>> received this message in error, please notify me immediately and delete this >>> message from your computer system. Any unauthorized use or distribution is >>> prohibited. Please consider the environment before printing this email. >> >> > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 08:50:48 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 15:50:48 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, sorry for the mistake, not"the backprojection should take much longer time than sart algorithm" , but "the backprojection should take much longer time than forward projection in sart algorithm". BTW, how many cores does your computer have?? Mine is 24 cores. is it can explain the reason why it takes much longer time on my computer than yours? Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 15:28 GMT+03:00 Simon Rit : > I can try. Forward and back projection have the same algorithmic > complexity but voxel based backprojection benefits from several > optimizations in terms of memory management and computations that > makes it faster. The best is to look at the code for further > details... although both have far from being optimal. And I did not > get the sentence "the backprojection should take much longer time than > sart algorithm." because SART contains a backprojection and other > steps so SART is obviously longer than the bp alone. > Your log is strange and I don't see what steps are not timed that > would take most of the time. I did the same test on my computer and > here is my result: > > OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > --dimension 512 > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.288571 s > Multiplication by zero: 0.131672 s > Forward projection: 34.3612 s > Subtraction: 0.203409 s > Multiplication by lambda: 0.146459 s > Ray box intersection: 1.30755 s > Division: 0.187294 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.278408 s > Back projection: 11.8456 s > Volume update: 0 s > It took... 53.2765 s > > Simon > > On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > wrote: > > Hi Simon, > > Thanks for your reply. > > would you pls help and explain why backprojection is expected to take > > shorter time than forward projection?? because i was thinking if no > caching > > step, the backprojection should take much longer time than sart > algorithm. > > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time > > consumed of 3 times's sart, which much slower than my own application. > > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > > shapp-logan projections(512*512 resolution each) > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > > -64,-64,-64 -l 0.5 -n 3 --time 1 > > > > and i will try reader->Update() like what you said. > > Thanks > > Guangming > > > > > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> > >> Hi Guangming, > >> It's not surprising to me that the backprojection is faster than the > >> forward projection, that's what I expect. If the total time is longer, > >> that's probably that some individual steps are not included in the total > >> time. Can you try to add > >> reader->Update(); > >> before the line > >> > >> itk::TimeProbe totalTimeProbe; > >> > >> in rtksart.cxx? It may be that all the reading operations are done but > not > >> timed in the sart->Update(). Why they are so long, I don't know, is > your D: > >> drive a network drive? Do you observe the same behavior if you do > rtksart 2 > >> times in a row? > >> > >> Simon > >> > >> > >> > >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> wrote: > >>> > >>> Hi RTK community, > >>> i am using SART algorithm to reconstruct an object. > >>> But in this new RTK version, the time recording seems a little weird: > >>> the total time is 1219.12s , but adding the time cost in different > >>> stages is not 1291.12 s. especially for "backprojection" part, only > 16.6051s > >>> to reconstruct a 128^3 volume ?? even shorter than forward projection > part. > >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > respectively, > >>> both multi-threading i think. > >>> Can anyone tell me what's going on? > >>> Thanks > >>> Regards > >>> Guangming > >>> > >>> > >>> Guangming Zang (Alex) > >>> King Abdullah University of Science and Technology(KAUST) > >>> University of Chinese Academy of Sciences(UCAS) > >>> > >>> > >>> > >>> > >>> ________________________________ > >>> This message and its contents, including attachments are intended > solely > >>> for the original recipient. If you are not the intended recipient or > have > >>> received this message in error, please notify me immediately and > delete this > >>> message from your computer system. Any unauthorized use or > distribution is > >>> prohibited. Please consider the environment before printing this email. > >> > >> > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 09:02:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 15:02:03 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: No I expect forward projection to be longer than backprojection although with optimal implementations, it should take about the same time since they have the same complexity. I have 4 cores on my laptop. I don't see how it explains it, try to find out where does SART spend the time. Simon On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang wrote: > Hi Simon, > sorry for the mistake, not"the backprojection should take much longer time > than > sart algorithm" , but "the backprojection should take much longer time than > forward projection in sart algorithm". > > BTW, how many cores does your computer have?? Mine is 24 cores. > is it can explain the reason why it takes much longer time on my computer > than yours? > Regards > Guangming > > Guangming Zang (Alex) > King Abdullah University of Science and Technology(KAUST) > University of Chinese Academy of Sciences(UCAS) > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> I can try. Forward and back projection have the same algorithmic >> complexity but voxel based backprojection benefits from several >> optimizations in terms of memory management and computations that >> makes it faster. The best is to look at the code for further >> details... although both have far from being optimal. And I did not >> get the sentence "the backprojection should take much longer time than >> sart algorithm." because SART contains a backprojection and other >> steps so SART is obviously longer than the bp alone. >> Your log is strange and I don't see what steps are not timed that >> would take most of the time. I did the same test on my computer and >> here is my result: >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> --dimension 512 >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> 1 >> Recording elapsed time... >> SARTConeBeamReconstructionFilter timing: >> Extraction of projection sub-stacks: 0.288571 s >> Multiplication by zero: 0.131672 s >> Forward projection: 34.3612 s >> Subtraction: 0.203409 s >> Multiplication by lambda: 0.146459 s >> Ray box intersection: 1.30755 s >> Division: 0.187294 s >> Multiplication by the gating weights: 0 s >> Displaced detector: 0.278408 s >> Back projection: 11.8456 s >> Volume update: 0 s >> It took... 53.2765 s >> >> Simon >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> wrote: >> > Hi Simon, >> > Thanks for your reply. >> > would you pls help and explain why backprojection is expected to take >> > shorter time than forward projection?? because i was thinking if no >> > caching >> > step, the backprojection should take much longer time than sart >> > algorithm. >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time >> > consumed of 3 times's sart, which much slower than my own application. >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 >> > shapp-logan projections(512*512 resolution each) >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> > >> > and i will try reader->Update() like what you said. >> > Thanks >> > Guangming >> > >> > >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : >> >> >> >> Hi Guangming, >> >> It's not surprising to me that the backprojection is faster than the >> >> forward projection, that's what I expect. If the total time is longer, >> >> that's probably that some individual steps are not included in the >> >> total >> >> time. Can you try to add >> >> reader->Update(); >> >> before the line >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done but >> >> not >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> your D: >> >> drive a network drive? Do you observe the same behavior if you do >> >> rtksart 2 >> >> times in a row? >> >> >> >> Simon >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> wrote: >> >>> >> >>> Hi RTK community, >> >>> i am using SART algorithm to reconstruct an object. >> >>> But in this new RTK version, the time recording seems a little weird: >> >>> the total time is 1219.12s , but adding the time cost in different >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >>> 16.6051s >> >>> to reconstruct a 128^3 volume ?? even shorter than forward projection >> >>> part. >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >>> respectively, >> >>> both multi-threading i think. >> >>> Can anyone tell me what's going on? >> >>> Thanks >> >>> Regards >> >>> Guangming >> >>> >> >>> >> >>> Guangming Zang (Alex) >> >>> King Abdullah University of Science and Technology(KAUST) >> >>> University of Chinese Academy of Sciences(UCAS) >> >>> >> >>> >> >>> >> >>> >> >>> ________________________________ >> >>> This message and its contents, including attachments are intended >> >>> solely >> >>> for the original recipient. If you are not the intended recipient or >> >>> have >> >>> received this message in error, please notify me immediately and >> >>> delete this >> >>> message from your computer system. Any unauthorized use or >> >>> distribution is >> >>> prohibited. Please consider the environment before printing this >> >>> email. >> >> >> >> >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended solely >> > for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> > this >> > message from your computer system. Any unauthorized use or distribution >> > is >> > prohibited. Please consider the environment before printing this email. > > > > ________________________________ > This message and its contents, including attachments are intended solely for > the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete this > message from your computer system. Any unauthorized use or distribution is > prohibited. Please consider the environment before printing this email. From guangming.zang at kaust.edu.sa Mon Jul 27 10:05:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:05:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Hi Simon, it cost 1200s for SART algorithm at first, and the command are: rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 in which, the projections data(360pro_SL_Vol128_512.mha) is not generated from rtkprojectshepploganphantom , but from my application. though it took long time, but i can got a nice result, And i just tried the command you used, i.e. generated the projections data by rtkprojectshepploganphantom : rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 --sid=500.0 rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 yes, it takes about 56s. but the reconstructed result is weird, the voxel values range from [-142186, 208146] and can not see anything when visualizing it. i believe you got the similar results, which maybe explain why it computes much faster. if i wanna use the projections generated by rtkprojectshepploganphantom , can you give me an example to get a nice results? Best regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 16:02 GMT+03:00 Simon Rit : > No I expect forward projection to be longer than backprojection > although with optimal implementations, it should take about the same > time since they have the same complexity. > I have 4 cores on my laptop. I don't see how it explains it, try to > find out where does SART spend the time. > Simon > > On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang > wrote: > > Hi Simon, > > sorry for the mistake, not"the backprojection should take much longer > time > > than > > sart algorithm" , but "the backprojection should take much longer time > than > > forward projection in sart algorithm". > > > > BTW, how many cores does your computer have?? Mine is 24 cores. > > is it can explain the reason why it takes much longer time on my computer > > than yours? > > Regards > > Guangming > > > > Guangming Zang (Alex) > > King Abdullah University of Science and Technology(KAUST) > > University of Chinese Academy of Sciences(UCAS) > > > > > > > > > > 2015-07-27 15:28 GMT+03:00 Simon Rit : > >> > >> I can try. Forward and back projection have the same algorithmic > >> complexity but voxel based backprojection benefits from several > >> optimizations in terms of memory management and computations that > >> makes it faster. The best is to look at the code for further > >> details... although both have far from being optimal. And I did not > >> get the sentence "the backprojection should take much longer time than > >> sart algorithm." because SART contains a backprojection and other > >> steps so SART is obviously longer than the bp alone. > >> Your log is strange and I don't see what steps are not timed that > >> would take most of the time. I did the same test on my computer and > >> here is my result: > >> > >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo > >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha > >> --dimension 512 > >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha > >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time > >> 1 > >> Recording elapsed time... > >> SARTConeBeamReconstructionFilter timing: > >> Extraction of projection sub-stacks: 0.288571 s > >> Multiplication by zero: 0.131672 s > >> Forward projection: 34.3612 s > >> Subtraction: 0.203409 s > >> Multiplication by lambda: 0.146459 s > >> Ray box intersection: 1.30755 s > >> Division: 0.187294 s > >> Multiplication by the gating weights: 0 s > >> Displaced detector: 0.278408 s > >> Back projection: 11.8456 s > >> Volume update: 0 s > >> It took... 53.2765 s > >> > >> Simon > >> > >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang > >> wrote: > >> > Hi Simon, > >> > Thanks for your reply. > >> > would you pls help and explain why backprojection is expected to take > >> > shorter time than forward projection?? because i was thinking if no > >> > caching > >> > step, the backprojection should take much longer time than sart > >> > algorithm. > >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the > time > >> > consumed of 3 times's sart, which much slower than my own application. > >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360 > >> > shapp-logan projections(512*512 resolution each) > >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o > >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection > >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin > >> > -64,-64,-64 -l 0.5 -n 3 --time 1 > >> > > >> > and i will try reader->Update() like what you said. > >> > Thanks > >> > Guangming > >> > > >> > > >> > > >> > Guangming Zang (Alex) > >> > King Abdullah University of Science and Technology(KAUST) > >> > University of Chinese Academy of Sciences(UCAS) > >> > > >> > > >> > > >> > > >> > 2015-07-27 8:59 GMT+03:00 Simon Rit : > >> >> > >> >> Hi Guangming, > >> >> It's not surprising to me that the backprojection is faster than the > >> >> forward projection, that's what I expect. If the total time is > longer, > >> >> that's probably that some individual steps are not included in the > >> >> total > >> >> time. Can you try to add > >> >> reader->Update(); > >> >> before the line > >> >> > >> >> itk::TimeProbe totalTimeProbe; > >> >> > >> >> in rtksart.cxx? It may be that all the reading operations are done > but > >> >> not > >> >> timed in the sart->Update(). Why they are so long, I don't know, is > >> >> your D: > >> >> drive a network drive? Do you observe the same behavior if you do > >> >> rtksart 2 > >> >> times in a row? > >> >> > >> >> Simon > >> >> > >> >> > >> >> > >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang > >> >> wrote: > >> >>> > >> >>> Hi RTK community, > >> >>> i am using SART algorithm to reconstruct an object. > >> >>> But in this new RTK version, the time recording seems a little > weird: > >> >>> the total time is 1219.12s , but adding the time cost in different > >> >>> stages is not 1291.12 s. especially for "backprojection" part, only > >> >>> 16.6051s > >> >>> to reconstruct a 128^3 volume ?? even shorter than forward > projection > >> >>> part. > >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, > >> >>> respectively, > >> >>> both multi-threading i think. > >> >>> Can anyone tell me what's going on? > >> >>> Thanks > >> >>> Regards > >> >>> Guangming > >> >>> > >> >>> > >> >>> Guangming Zang (Alex) > >> >>> King Abdullah University of Science and Technology(KAUST) > >> >>> University of Chinese Academy of Sciences(UCAS) > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> ________________________________ > >> >>> This message and its contents, including attachments are intended > >> >>> solely > >> >>> for the original recipient. If you are not the intended recipient or > >> >>> have > >> >>> received this message in error, please notify me immediately and > >> >>> delete this > >> >>> message from your computer system. Any unauthorized use or > >> >>> distribution is > >> >>> prohibited. Please consider the environment before printing this > >> >>> email. > >> >> > >> >> > >> > > >> > > >> > ________________________________ > >> > This message and its contents, including attachments are intended > solely > >> > for > >> > the original recipient. If you are not the intended recipient or have > >> > received this message in error, please notify me immediately and > delete > >> > this > >> > message from your computer system. Any unauthorized use or > distribution > >> > is > >> > prohibited. Please consider the environment before printing this > email. > > > > > > > > ________________________________ > > This message and its contents, including attachments are intended solely > for > > the original recipient. If you are not the intended recipient or have > > received this message in error, please notify me immediately and delete > this > > message from your computer system. Any unauthorized use or distribution > is > > prohibited. Please consider the environment before printing this email. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 10:12:04 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 17:12:04 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: BTW, the projections are 512*512, and the pixel spacing is 0.5 Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:05 GMT+03:00 Guangming Zang : > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jul 27 10:20:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Jul 2015 16:20:12 +0200 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Obviously I hadn't looked at the result and/or checked the command line options, sorry. This is an example from the same simulated dataset that gives me a good results: OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n 3 --time 1 Recording elapsed time... SARTConeBeamReconstructionFilter timing: Extraction of projection sub-stacks: 0.567773 s Multiplication by zero: 0.303715 s Forward projection: 142.305 s Subtraction: 0.445842 s Multiplication by lambda: 0.2663 s Ray box intersection: 5.40366 s Division: 0.535618 s Multiplication by the gating weights: 0 s Displaced detector: 0.415431 s Back projection: 21.3689 s Volume update: 0 s It took... 177.059 s but this doesn't change the content of my previous message. What takes time is probably in your own software, be sure that you update SART inputs before timing it. Simon On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang wrote: > Hi Simon, > it cost 1200s for SART algorithm at first, and the command are: > rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd=725.9240729 > --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" > > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha > -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension > 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 > > in which, the projections data(360pro_SL_Vol128_512.mha) is not generated > from rtkprojectshepploganphantom , but from my application. though it took > long time, but i can got a nice result, > > > And i just tried the command you used, i.e. generated the projections > data by rtkprojectshepploganphantom : > > rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 > --sid=500.0 > rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 > rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b > VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 > --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 > yes, it takes about 56s. > but the reconstructed result is weird, the voxel values range from > [-142186, 208146] and can not see anything when visualizing it. > i believe you got the similar results, which maybe explain why it > computes much faster. > > if i wanna use the projections generated by rtkprojectshepploganphantom , > can you give me an example to get a nice results? > > Best regards > Guangming > > > > > > > > > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > > > > 2015-07-27 16:02 GMT+03:00 Simon Rit : > >> No I expect forward projection to be longer than backprojection >> although with optimal implementations, it should take about the same >> time since they have the same complexity. >> I have 4 cores on my laptop. I don't see how it explains it, try to >> find out where does SART spend the time. >> Simon >> >> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >> wrote: >> > Hi Simon, >> > sorry for the mistake, not"the backprojection should take much longer >> time >> > than >> > sart algorithm" , but "the backprojection should take much longer time >> than >> > forward projection in sart algorithm". >> > >> > BTW, how many cores does your computer have?? Mine is 24 cores. >> > is it can explain the reason why it takes much longer time on my >> computer >> > than yours? >> > Regards >> > Guangming >> > >> > Guangming Zang (Alex) >> > King Abdullah University of Science and Technology(KAUST) >> > University of Chinese Academy of Sciences(UCAS) >> > >> > >> > >> > >> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >> >> >> >> I can try. Forward and back projection have the same algorithmic >> >> complexity but voxel based backprojection benefits from several >> >> optimizations in terms of memory management and computations that >> >> makes it faster. The best is to look at the code for further >> >> details... although both have far from being optimal. And I did not >> >> get the sentence "the backprojection should take much longer time than >> >> sart algorithm." because SART contains a backprojection and other >> >> steps so SART is obviously longer than the bp alone. >> >> Your log is strange and I don't see what steps are not timed that >> >> would take most of the time. I did the same test on my computer and >> >> here is my result: >> >> >> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >> >> --dimension 512 >> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >> >> 1 >> >> Recording elapsed time... >> >> SARTConeBeamReconstructionFilter timing: >> >> Extraction of projection sub-stacks: 0.288571 s >> >> Multiplication by zero: 0.131672 s >> >> Forward projection: 34.3612 s >> >> Subtraction: 0.203409 s >> >> Multiplication by lambda: 0.146459 s >> >> Ray box intersection: 1.30755 s >> >> Division: 0.187294 s >> >> Multiplication by the gating weights: 0 s >> >> Displaced detector: 0.278408 s >> >> Back projection: 11.8456 s >> >> Volume update: 0 s >> >> It took... 53.2765 s >> >> >> >> Simon >> >> >> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >> >> wrote: >> >> > Hi Simon, >> >> > Thanks for your reply. >> >> > would you pls help and explain why backprojection is expected to take >> >> > shorter time than forward projection?? because i was thinking if no >> >> > caching >> >> > step, the backprojection should take much longer time than sart >> >> > algorithm. >> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >> time >> >> > consumed of 3 times's sart, which much slower than my own >> application. >> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >> 360 >> >> > shapp-logan projections(512*512 resolution each) >> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >> >> > >> >> > and i will try reader->Update() like what you said. >> >> > Thanks >> >> > Guangming >> >> > >> >> > >> >> > >> >> > Guangming Zang (Alex) >> >> > King Abdullah University of Science and Technology(KAUST) >> >> > University of Chinese Academy of Sciences(UCAS) >> >> > >> >> > >> >> > >> >> > >> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit > >: >> >> >> >> >> >> Hi Guangming, >> >> >> It's not surprising to me that the backprojection is faster than the >> >> >> forward projection, that's what I expect. If the total time is >> longer, >> >> >> that's probably that some individual steps are not included in the >> >> >> total >> >> >> time. Can you try to add >> >> >> reader->Update(); >> >> >> before the line >> >> >> >> >> >> itk::TimeProbe totalTimeProbe; >> >> >> >> >> >> in rtksart.cxx? It may be that all the reading operations are done >> but >> >> >> not >> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >> >> >> your D: >> >> >> drive a network drive? Do you observe the same behavior if you do >> >> >> rtksart 2 >> >> >> times in a row? >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >> >> >> wrote: >> >> >>> >> >> >>> Hi RTK community, >> >> >>> i am using SART algorithm to reconstruct an object. >> >> >>> But in this new RTK version, the time recording seems a little >> weird: >> >> >>> the total time is 1219.12s , but adding the time cost in different >> >> >>> stages is not 1291.12 s. especially for "backprojection" part, only >> >> >>> 16.6051s >> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >> projection >> >> >>> part. >> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >> >> >>> respectively, >> >> >>> both multi-threading i think. >> >> >>> Can anyone tell me what's going on? >> >> >>> Thanks >> >> >>> Regards >> >> >>> Guangming >> >> >>> >> >> >>> >> >> >>> Guangming Zang (Alex) >> >> >>> King Abdullah University of Science and Technology(KAUST) >> >> >>> University of Chinese Academy of Sciences(UCAS) >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> This message and its contents, including attachments are intended >> >> >>> solely >> >> >>> for the original recipient. If you are not the intended recipient >> or >> >> >>> have >> >> >>> received this message in error, please notify me immediately and >> >> >>> delete this >> >> >>> message from your computer system. Any unauthorized use or >> >> >>> distribution is >> >> >>> prohibited. Please consider the environment before printing this >> >> >>> email. >> >> >> >> >> >> >> >> > >> >> > >> >> > ________________________________ >> >> > This message and its contents, including attachments are intended >> solely >> >> > for >> >> > the original recipient. If you are not the intended recipient or have >> >> > received this message in error, please notify me immediately and >> delete >> >> > this >> >> > message from your computer system. Any unauthorized use or >> distribution >> >> > is >> >> > prohibited. Please consider the environment before printing this >> email. >> > >> > >> > >> > ________________________________ >> > This message and its contents, including attachments are intended >> solely for >> > the original recipient. If you are not the intended recipient or have >> > received this message in error, please notify me immediately and delete >> this >> > message from your computer system. Any unauthorized use or distribution >> is >> > prohibited. Please consider the environment before printing this email. >> > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Mon Jul 27 11:12:16 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Mon, 27 Jul 2015 18:12:16 +0300 Subject: [Rtk-users] Issue report regarding the recorder of Time elapsed In-Reply-To: References: Message-ID: Thanks Simon, now it work fine when using projections generated by RTK itself (command rtkprojectshepploganphantom ). for 1 iteration of SART to reconstruct 128^3 size volume, it took only 19s, which gives nice results as well. Thanks again. Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-27 17:20 GMT+03:00 Simon Rit : > Obviously I hadn't looked at the result and/or checked the command line > options, sorry. This is an example from the same simulated dataset that > gives me a good results: > > OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha -f > Joseph -b VoxelBasedBackProjection --dimension 128 --spacing 2 -l 0.3 -n > 3 --time 1 > Recording elapsed time... > SARTConeBeamReconstructionFilter timing: > Extraction of projection sub-stacks: 0.567773 s > Multiplication by zero: 0.303715 s > Forward projection: 142.305 s > Subtraction: 0.445842 s > Multiplication by lambda: 0.2663 s > Ray box intersection: 5.40366 s > Division: 0.535618 s > Multiplication by the gating weights: 0 s > Displaced detector: 0.415431 s > Back projection: 21.3689 s > Volume update: 0 s > It took... 177.059 s > > but this doesn't change the content of my previous message. What takes > time is probably in your own software, be sure that you update SART inputs > before timing it. > Simon > > On Mon, Jul 27, 2015 at 4:05 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon, >> it cost 1200s for SART algorithm at first, and the command are: >> rtksimulatedgeometry -n 360 --arc -360 -o geometry.xml --sdd= >> 725.9240729 --sid=500.0 --proj_iso_x="-128" --proj_iso_y="-128" >> >> rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o SART_SL.mha >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 1 --time 1 >> >> in which, the projections data(360pro_SL_Vol128_512.mha) is not >> generated from rtkprojectshepploganphantom , but from my application. >> though it took long time, but i can got a nice result, >> >> >> And i just tried the command you used, i.e. generated the projections >> data by rtkprojectshepploganphantom : >> >> rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=725.9240729 >> --sid=500.0 >> rtkprojectshepploganphantom -g geo.xml -o proj.mha --dimension 512 >> rtksart -p . -r proj.mha -g geo.xml -o SART_SLnew.mha -f Joseph -b >> VoxelBasedBackProjection --newspacing 0.5 --dimension 128,128,128 >> --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time 1 >> yes, it takes about 56s. >> but the reconstructed result is weird, the voxel values range from >> [-142186, 208146] and can not see anything when visualizing it. >> i believe you got the similar results, which maybe explain why it >> computes much faster. >> >> if i wanna use the projections generated by rtkprojectshepploganphantom >> , can you give me an example to get a nice results? >> >> Best regards >> Guangming >> >> >> >> >> >> >> >> >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> >> >> >> 2015-07-27 16:02 GMT+03:00 Simon Rit : >> >>> No I expect forward projection to be longer than backprojection >>> although with optimal implementations, it should take about the same >>> time since they have the same complexity. >>> I have 4 cores on my laptop. I don't see how it explains it, try to >>> find out where does SART spend the time. >>> Simon >>> >>> On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang >>> wrote: >>> > Hi Simon, >>> > sorry for the mistake, not"the backprojection should take much longer >>> time >>> > than >>> > sart algorithm" , but "the backprojection should take much longer time >>> than >>> > forward projection in sart algorithm". >>> > >>> > BTW, how many cores does your computer have?? Mine is 24 cores. >>> > is it can explain the reason why it takes much longer time on my >>> computer >>> > than yours? >>> > Regards >>> > Guangming >>> > >>> > Guangming Zang (Alex) >>> > King Abdullah University of Science and Technology(KAUST) >>> > University of Chinese Academy of Sciences(UCAS) >>> > >>> > >>> > >>> > >>> > 2015-07-27 15:28 GMT+03:00 Simon Rit : >>> >> >>> >> I can try. Forward and back projection have the same algorithmic >>> >> complexity but voxel based backprojection benefits from several >>> >> optimizations in terms of memory management and computations that >>> >> makes it faster. The best is to look at the code for further >>> >> details... although both have far from being optimal. And I did not >>> >> get the sentence "the backprojection should take much longer time than >>> >> sart algorithm." because SART contains a backprojection and other >>> >> steps so SART is obviously longer than the bp alone. >>> >> Your log is strange and I don't see what steps are not timed that >>> >> would take most of the time. I did the same test on my computer and >>> >> here is my result: >>> >> >>> >> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo >>> >> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha >>> >> --dimension 512 >>> >> OS-SR-466:tmp srit$ rtksart -p . -r proj.mha -g geo -o SART_SL3.mha >>> >> -f Joseph -b VoxelBasedBackProjection --newspacing 0.5 --dimension >>> >> 128,128,128 --spacing 1,1,1 --origin -64,-64,-64 -l 0.5 -n 3 --time >>> >> 1 >>> >> Recording elapsed time... >>> >> SARTConeBeamReconstructionFilter timing: >>> >> Extraction of projection sub-stacks: 0.288571 s >>> >> Multiplication by zero: 0.131672 s >>> >> Forward projection: 34.3612 s >>> >> Subtraction: 0.203409 s >>> >> Multiplication by lambda: 0.146459 s >>> >> Ray box intersection: 1.30755 s >>> >> Division: 0.187294 s >>> >> Multiplication by the gating weights: 0 s >>> >> Displaced detector: 0.278408 s >>> >> Back projection: 11.8456 s >>> >> Volume update: 0 s >>> >> It took... 53.2765 s >>> >> >>> >> Simon >>> >> >>> >> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang >>> >> wrote: >>> >> > Hi Simon, >>> >> > Thanks for your reply. >>> >> > would you pls help and explain why backprojection is expected to >>> take >>> >> > shorter time than forward projection?? because i was thinking if no >>> >> > caching >>> >> > step, the backprojection should take much longer time than sart >>> >> > algorithm. >>> >> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the >>> time >>> >> > consumed of 3 times's sart, which much slower than my own >>> application. >>> >> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are >>> 360 >>> >> > shapp-logan projections(512*512 resolution each) >>> >> > rtksart -p . -r 360pro_SL_Vol128_512.mha -g geometry.xml -o >>> >> > ../Result_SL512/SART_SL3.mha -f Joseph -b VoxelBasedBackProjection >>> >> > --newspacing 0.5 --dimension 128,128,128 --spacing 1,1,1 --origin >>> >> > -64,-64,-64 -l 0.5 -n 3 --time 1 >>> >> > >>> >> > and i will try reader->Update() like what you said. >>> >> > Thanks >>> >> > Guangming >>> >> > >>> >> > >>> >> > >>> >> > Guangming Zang (Alex) >>> >> > King Abdullah University of Science and Technology(KAUST) >>> >> > University of Chinese Academy of Sciences(UCAS) >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > 2015-07-27 8:59 GMT+03:00 Simon Rit >> >: >>> >> >> >>> >> >> Hi Guangming, >>> >> >> It's not surprising to me that the backprojection is faster than >>> the >>> >> >> forward projection, that's what I expect. If the total time is >>> longer, >>> >> >> that's probably that some individual steps are not included in the >>> >> >> total >>> >> >> time. Can you try to add >>> >> >> reader->Update(); >>> >> >> before the line >>> >> >> >>> >> >> itk::TimeProbe totalTimeProbe; >>> >> >> >>> >> >> in rtksart.cxx? It may be that all the reading operations are done >>> but >>> >> >> not >>> >> >> timed in the sart->Update(). Why they are so long, I don't know, is >>> >> >> your D: >>> >> >> drive a network drive? Do you observe the same behavior if you do >>> >> >> rtksart 2 >>> >> >> times in a row? >>> >> >> >>> >> >> Simon >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang >>> >> >> wrote: >>> >> >>> >>> >> >>> Hi RTK community, >>> >> >>> i am using SART algorithm to reconstruct an object. >>> >> >>> But in this new RTK version, the time recording seems a little >>> weird: >>> >> >>> the total time is 1219.12s , but adding the time cost in >>> different >>> >> >>> stages is not 1291.12 s. especially for "backprojection" part, >>> only >>> >> >>> 16.6051s >>> >> >>> to reconstruct a 128^3 volume ?? even shorter than forward >>> projection >>> >> >>> part. >>> >> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection, >>> >> >>> respectively, >>> >> >>> both multi-threading i think. >>> >> >>> Can anyone tell me what's going on? >>> >> >>> Thanks >>> >> >>> Regards >>> >> >>> Guangming >>> >> >>> >>> >> >>> >>> >> >>> Guangming Zang (Alex) >>> >> >>> King Abdullah University of Science and Technology(KAUST) >>> >> >>> University of Chinese Academy of Sciences(UCAS) >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> ________________________________ >>> >> >>> This message and its contents, including attachments are intended >>> >> >>> solely >>> >> >>> for the original recipient. If you are not the intended recipient >>> or >>> >> >>> have >>> >> >>> received this message in error, please notify me immediately and >>> >> >>> delete this >>> >> >>> message from your computer system. Any unauthorized use or >>> >> >>> distribution is >>> >> >>> prohibited. Please consider the environment before printing this >>> >> >>> email. >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > ________________________________ >>> >> > This message and its contents, including attachments are intended >>> solely >>> >> > for >>> >> > the original recipient. If you are not the intended recipient or >>> have >>> >> > received this message in error, please notify me immediately and >>> delete >>> >> > this >>> >> > message from your computer system. Any unauthorized use or >>> distribution >>> >> > is >>> >> > prohibited. Please consider the environment before printing this >>> email. >>> > >>> > >>> > >>> > ________________________________ >>> > This message and its contents, including attachments are intended >>> solely for >>> > the original recipient. If you are not the intended recipient or have >>> > received this message in error, please notify me immediately and >>> delete this >>> > message from your computer system. Any unauthorized use or >>> distribution is >>> > prohibited. Please consider the environment before printing this email. >>> >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. >> > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From infrombox at yandex.ru Tue Jul 28 04:30:22 2015 From: infrombox at yandex.ru (1 1) Date: Tue, 28 Jul 2015 15:30:22 +0700 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: <2213081438072222@web8j.yandex.ru> Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. But program which i use reads meta images with MET_SHORT pixel type only. Is there easy way to setting it and get volume with different from MET_FLOAT pixel type ? If not, could you advice me, what the filter i should to do, for example as post process after reconstruction ala MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward operation of LUTbasedVariableI0RawToAttenuationImageFilter ? Thanks. From simon.rit at creatis.insa-lyon.fr Tue Jul 28 04:56:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 10:56:54 +0200 Subject: [Rtk-users] volume with diffieret pixel type In-Reply-To: <2213081438072222@web8j.yandex.ru> References: <2213081438072222@web8j.yandex.ru> Message-ID: Hi, This is more an ITK question than a RTK question. Yes, we use float by default in our applications. You can cast the image to any type before writing using itk::CastImageFilter but you'll have to modify the applications and, of course, there is a loss of information. If you don't want to program it, you can use any other software, e.g. in vv right clik on your image after opening and use the convert to option. Simon On Tue, Jul 28, 2015 at 10:30 AM, 1 1 wrote: > Hello RTK-users. By default in RTK volume saves with MET_FLOAT pixel type. > But program which i use reads meta images with MET_SHORT pixel type only. > Is there easy way to setting it and get volume with different from > MET_FLOAT pixel type ? If not, could you advice me, what the filter i > should to do, for example as post process after reconstruction ala > MET_FLOAT -> MET_SHORT conversion of obtained volume, may be some backward > operation of LUTbasedVariableI0RawToAttenuationImageFilter image, float image> ? > Thanks. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pconneely020186 at gmail.com Tue Jul 28 12:05:29 2015 From: pconneely020186 at gmail.com (peter conneely) Date: Tue, 28 Jul 2015 17:05:29 +0100 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: "peter conneely" Date: 24 Jul 2015 11:07 Subject: Issue running FDK reconstruction algorithm To: Cc: Hi, I'm having trouble running the FDK reconstruction alogrithm on Elekta and Varian data sets. The algorithm does work when I try the shepp-logan example. When I initially ran the application I included the (') around .*.his. and got the following lines. [image: Inline image 1] when I try to run with the (') removed it finds the 669 files but then the application stops working. I have tried adding registry edits to run exe and have tried switching of dep. Neither of these work I am not sure what is going wrong and how to fix it. My system properties are as follows. Processor: Intel Pentium CPU P6100 @ 2.00 Ghz RAM: 3.00 GB GPU: Intel HD Graphics Systems type 64 Bit. Thanks and Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Tue Jul 28 12:46:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 28 Jul 2015 18:46:17 +0200 Subject: [Rtk-users] Fwd: Issue running FDK reconstruction algorithm In-Reply-To: References: Message-ID: Hi, I guess the quotes are OS depedent, maybe you need double quotes on Windows. It's strange that you don't get an error message. Are you sure it crashed? If yes, have you checked the elektaGeometry file? Does it have 669 projection sections as expected? Or maybe it's a memory issue, try the --lowmem option. Simon On Tue, Jul 28, 2015 at 6:05 PM, peter conneely wrote: > ---------- Forwarded message ---------- > From: "peter conneely" > Date: 24 Jul 2015 11:07 > Subject: Issue running FDK reconstruction algorithm > To: > Cc: > > Hi, > > I'm having trouble running the FDK reconstruction alogrithm on Elekta and > Varian data sets. The algorithm does work when I try the shepp-logan > example. > > When I initially ran the application I included the (') around .*.his. and > got the following lines. > [image: Inline image 1] > when I try to run with the (') removed it finds the 669 files but then the > application stops working. I have tried adding registry edits to run exe > and have tried switching of dep. Neither of these work I am not sure what > is going wrong and how to fix it. > > My system properties are as follows. > Processor: Intel Pentium CPU P6100 @ 2.00 Ghz > RAM: 3.00 GB > GPU: Intel HD Graphics > Systems type 64 Bit. > > Thanks and Regards, > Peter > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 59284 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Tue Jul 28 13:38:45 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Tue, 28 Jul 2015 20:38:45 +0300 Subject: [Rtk-users] volume with diffieret pixel type Message-ID: Hi, in ITK, the default type are described in *Utilities\MetaIO\metaTypes.h* MET_CHAR, MET_UCHAR ?,? ?? MET_SHORT, MET_USHORT, MET_INT,=20 MET_UINT,=20 MET_FLOAT,=20 MET_DOUBLE, ?and for .mha file, the header file includes information like: ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = 0 0 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 1 1 1 DimSize = 128 128 128 ElementType = MET_FLOAT ElementDataFile = LOCAL? ?And recently i just programmed to read and write .mha files. below is the code. u can just replace ElementType from ? MET_FLOAT ? to ? ? MET_SHORT ? in your application. hope this helps: #include "stdafx.h" #include #include #include #include #include #include using namespace std; int _tmain(int argc, _TCHAR* argv[]) { int m_Dims[3]; float spacing[3]; m_Dims[0]=128; m_Dims[1]=128; m_Dims[2]=128; spacing[0]=spacing[1]=spacing[2]=1.0f; ostringstream buffer, buffer1, buffer2, buf3; buffer << spacing[0]; string sp= buffer.str(); buffer1 << spacing[1]; string sp1 = buffer1.str(); buffer2 << spacing[2]; string sp2 = buffer2.str(); string ElementSpacing ="ElementSpacing= "+sp+" "+sp1+" "+sp2+"\n"; // int ss=1000; char temp[64], temp1[64],temp2[64]; string str; sprintf(temp, "%d", m_Dims[0]); sprintf(temp1, "%d", m_Dims[1]); sprintf(temp2, "%d", m_Dims[2]); string s(temp),s1(temp1),s2(temp2); string DimSize="DimSize= "+s+" "+s1+" "+s2+"\n"; string Mywritefile="ObjectType = Image\nNDims = 3\nBinaryData = True\nBinaryDataByteOrderMSB = False \nCompressedData = False \nTransformMatrix = 1 0 0 0 1 0 0 0 1 \n" ; Mywritefile+="Offset = 0 0 0 \nCenterOfRotation = 0 0 0 \nAnatomicalOrientation = RAI \n"; Mywritefile+=ElementSpacing+DimSize+"ElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; // ElementSpacing = 1 1 1 \nDimSize = 128 128 128 \nElementType = MET_FLOAT \nElementDataFile = LOCAL \n"; int leng=Mywritefile.length(); cout< From simon.rit at creatis.insa-lyon.fr Wed Jul 29 08:53:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 29 Jul 2015 14:53:34 +0200 Subject: [Rtk-users] RTK images make the cover of Medical Physics Message-ID: See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Wed Jul 29 09:07:01 2015 From: theday79 at gmail.com (Yang K Park) Date: Wed, 29 Jul 2015 09:07:01 -0400 Subject: [Rtk-users] RTK images make the cover of Medical Physics In-Reply-To: References: Message-ID: <001801d0c9ff$76797860$636c6920$@gmail.com> Hi Simon, Thank you so much for the congrats! This is my great honor and I?d like to thank all the RTK developers and community members for their helps on this achievement! Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: Wednesday, July 29, 2015 8:54 AM To: rtk-users at public.kitware.com Subject: [Rtk-users] RTK images make the cover of Medical Physics See the news on RTK website: http://www.openrtk.org/RTK/news/201507_press.php Congratulations Yang! -------------- next part -------------- An HTML attachment was scrubbed... URL: From guangming.zang at kaust.edu.sa Thu Jul 30 08:16:38 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Thu, 30 Jul 2015 15:16:38 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK Message-ID: Hi Simon and Chao, i am currently do some comparisons between different reconstruction methods for Shapp-Logan dataset. the commands are: rtksimulatedgeometry -n 360 --arc -360 -o geo.xml --sdd=955.4050067 --sid=500.0 rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha --dimension 512,512 when using FDK or SART algorithm from RTK, I can got pretty good results indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 and levels as 1.04 for all results got). When running ADMMTV command below, though the geometry is as same as SART and FDK, the result got from ADMM looks weird.(pls see attached central slice of ground truth and ADMM, same contrast with other algorithm) rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 [image: ???? 1][image: ???? 2] Is it because the CG algorithm used by ADMM, or parameters setting issues here?? if it is parameters setting problem , would you help me and give a nice values for alpha and bate used here? BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already (including default value) Thanks and regards Guangming ?? *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* ? -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Jul 31 01:55:32 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 31 Jul 2015 07:55:32 +0200 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi, It looks to me that you haven't converged. I'm not the specialist of this algorithm and the specialist won't be near a computer in the coming weeks but when I try with more iterations in the data attachment term: rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 it's more satisfactory. There are rings at the top and the bottom of the cone-beam which should be reduced with more TV (greater alpha, see doc here ) or with a finer spacing (see this publication ). Simon On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang wrote: > Hi Simon and Chao, > > i am currently do some comparisons between different reconstruction > methods for Shapp-Logan dataset. > > the commands are: > > rtksimulatedgeometry -n 360 --arc -360 -o > geo.xml --sdd=955.4050067 --sid=500.0 > > rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha > --dimension 512,512 > > > > when using FDK or SART algorithm from RTK, I can got pretty good results > indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 > and levels as 1.04 for all results got). When running ADMMTV command below, > though the geometry is as same as SART and FDK, the result got from ADMM > looks weird.(pls see attached central slice of ground truth and ADMM, same > contrast with other algorithm) > > rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o > SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 > --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 > > [image: ???? 1][image: ???? 2] > > Is it because the CG algorithm used by ADMM, or parameters setting issues > here?? if it is parameters setting problem , would you help me and give a > nice values for alpha and bate used here? > > BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already > (including default value) > > Thanks and regards > > Guangming > > > ?? > *Guangming Zang (Alex)* > *King Abdullah University of Science and Technology(KAUST)* > *University of Chinese Academy of Sciences(UCAS)* > > ? > > > ------------------------------ > This message and its contents, including attachments are intended solely > for the original recipient. If you are not the intended recipient or have > received this message in error, please notify me immediately and delete > this message from your computer system. Any unauthorized use or > distribution is prohibited. Please consider the environment before printing > this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: From guangming.zang at kaust.edu.sa Fri Jul 31 09:46:41 2015 From: guangming.zang at kaust.edu.sa (Guangming Zang) Date: Fri, 31 Jul 2015 16:46:41 +0300 Subject: [Rtk-users] The result got from ADMMTV from shapp-logan generated from RTK In-Reply-To: References: Message-ID: Hi simon, i see, thanks for the help and explanation. after following your advice, it works fine now. Regards Guangming *Guangming Zang (Alex)* *King Abdullah University of Science and Technology(KAUST)* *University of Chinese Academy of Sciences(UCAS)* 2015-07-31 8:55 GMT+03:00 Simon Rit : > Hi, > It looks to me that you haven't converged. I'm not the specialist of this > algorithm and the specialist won't be near a computer in the coming weeks > but when I try with more iterations in the data attachment term: > rtkadmmtotalvariation -p . -r proj.mha -o admmtv.mha -g geo.xml > --spacing 1 --dimension 128 --alpha 1 --beta 1000 -n 10 > it's more satisfactory. There are rings at the top and the bottom of the > cone-beam which should be reduced with more TV (greater alpha, see doc > here > ) > or with a finer spacing (see this publication > ). > Simon > > On Thu, Jul 30, 2015 at 2:16 PM, Guangming Zang < > guangming.zang at kaust.edu.sa> wrote: > >> Hi Simon and Chao, >> >> i am currently do some comparisons between different reconstruction >> methods for Shapp-Logan dataset. >> >> the commands are: >> >> rtksimulatedgeometry -n 360 --arc -360 -o >> geo.xml --sdd=955.4050067 --sid=500.0 >> >> rtkprojectshepploganphantom -g geo.xml --phantomscale 64 -o proj.mha >> --dimension 512,512 >> >> >> >> when using FDK or SART algorithm from RTK, I can got pretty good results >> indeed(to see clearly, set contrast as [0.95,1.13], i.e., windows as 0.09 >> and levels as 1.04 for all results got). When running ADMMTV command below, >> though the geometry is as same as SART and FDK, the result got from ADMM >> looks weird.(pls see attached central slice of ground truth and ADMM, same >> contrast with other algorithm) >> >> rtkadmmtotalvariation -p . -r proj.mha -g geo.xml -o >> SL_ADMM_0.001_0.01.mha --dimension 128,128,128 --spacing 1,1,1 -n 2 >> --CGiter 3 --origin -64,-64,-64 --alpha 0.001 --beta 0.01 --time 1 >> >> [image: ???? 1][image: ???? 2] >> >> Is it because the CG algorithm used by ADMM, or parameters setting issues >> here?? if it is parameters setting problem , would you help me and give a >> nice values for alpha and bate used here? >> >> BTW, I had tried the ?alpha from [0.001,1] and ?bate[0.01,10] already >> (including default value) >> >> Thanks and regards >> >> Guangming >> >> >> ?? >> *Guangming Zang (Alex)* >> *King Abdullah University of Science and Technology(KAUST)* >> *University of Chinese Academy of Sciences(UCAS)* >> >> ? >> >> >> ------------------------------ >> This message and its contents, including attachments are intended solely >> for the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete >> this message from your computer system. Any unauthorized use or >> distribution is prohibited. Please consider the environment before printing >> this email. > > > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT.jpg Type: image/jpeg Size: 55956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admm.jpg Type: image/jpeg Size: 47494 bytes Desc: not available URL: