From James.Korte at petermac.org Fri Oct 11 02:52:36 2019 From: James.Korte at petermac.org (Korte James) Date: Fri, 11 Oct 2019 06:52:36 +0000 Subject: [Rtk-users] Offset detector with ADMM - hole in centre Message-ID: <5422EC0047E2FA49B1B02A7AA280DDE109DAEDE4@PAPR-EXMBX1.petermac.org.au> Hi, I am having issues with an artifact (black hole in the centre) in my ADMM reconstructions when using an offset detector. I have tested the same projection set and geometry file with the FDK algorithm and the reconstruction is fine. I've previously been using the same workflow with a centred detector, with no issues, for both the FDK and ADMM reconstruction methods. Are there any known issues/common pitfalls with the ADMM implementation and detector offsets? Cheers, James Disclaimer: This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gabriele.belotti.bergamo at gmail.com Fri Oct 11 03:58:22 2019 From: gabriele.belotti.bergamo at gmail.com (gabriele.belotti.bergamo at gmail.com) Date: Fri, 11 Oct 2019 09:58:22 +0200 Subject: [Rtk-users] Half Fan dataset Message-ID: <000801d58009$a7828ef0$f687acd0$@gmail.com> Dear RTK users and developers, I'm currently experimenting with FDK reconstruction and I'm struggling to find a Half-Fan projection dataset to fiddle around.. Do you know where I can find one? I've taken into consideration generating a set of DRRs from an existing phantom. Any help or advice you can give me would be greatly appreciated, thanks! Gabriele Belotti -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 11 06:21:40 2019 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 11 Oct 2019 12:21:40 +0200 Subject: [Rtk-users] Offset detector with ADMM - hole in centre In-Reply-To: <5422EC0047E2FA49B1B02A7AA280DDE109DAEDE4@PAPR-EXMBX1.petermac.org.au> References: <5422EC0047E2FA49B1B02A7AA280DDE109DAEDE4@PAPR-EXMBX1.petermac.org.au> Message-ID: Hi, I don't have much experience with ADMM. However, in my experience with the conjugate gradient algorithm, it's worth weighting the least squares cost function with the redundancies at the center. This has been documented by others, see e.g. https://doi.org/10.1088/0031-9155/58/2/205 This seems to be implemented in ADMM as well, have you tried to set DisableDisplacedDetectorFilter to true? Simon On Fri, Oct 11, 2019 at 9:00 AM Korte James wrote: > Hi, > > > > I am having issues with an artifact (black hole in the centre) in my ADMM > reconstructions when using an offset detector. I have tested the same > projection set and geometry file with the FDK algorithm and the > reconstruction is fine. > > > > I?ve previously been using the same workflow with a centred detector, with > no issues, for both the FDK and ADMM reconstruction methods. > > > > Are there any known issues/common pitfalls with the ADMM implementation > and detector offsets? > > > > Cheers, > > James > > *Disclaimer:* This email (including any attachments or links) may contain > confidential and/or legally privileged information and is intended only to > be read or used by the addressee. If you are not the intended addressee, > any use, distribution, disclosure or copying of this email is strictly > prohibited. Confidentiality and legal privilege attached to this email > (including any attachments) are not waived or lost by reason of its > mistaken delivery to you. If you have received this email in error, please > delete it and notify us immediately by telephone or email. Peter MacCallum > Cancer Centre provides no guarantee that this transmission is free of virus > or that it has not been intercepted or altered and will not be liable for > any delay in its receipt. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 11 07:09:43 2019 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 11 Oct 2019 13:09:43 +0200 Subject: [Rtk-users] Half Fan dataset In-Reply-To: <000801d58009$a7828ef0$f687acd0$@gmail.com> References: <000801d58009$a7828ef0$f687acd0$@gmail.com> Message-ID: Hi, It's easy to generate, you need to offset your detector, either via the RTK geometry or by setting the first coordinate of the origin of your projection to something which makes the projection uncentered. For example, in the geometry : rtksimulatedgeometry -n 180 --proj_iso_x 100 -o g rtkprojectshepploganphantom -g g -o proj.mha rtkfdk -p . -g g -r proj.mha -o fdk.mha You can simulate from a CT image by following this example . Simon On Fri, Oct 11, 2019 at 9:58 AM wrote: > Dear RTK users and developers, > > I?m currently experimenting with FDK reconstruction and I?m struggling to > find a Half-Fan projection dataset to fiddle around.. Do you know where I > can find one? I?ve taken into consideration generating a set of DRRs from > an existing phantom. Any help or advice you can give me would be greatly > appreciated, thanks! > > Gabriele Belotti > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gabriele.belotti.bergamo at gmail.com Fri Oct 11 08:03:33 2019 From: gabriele.belotti.bergamo at gmail.com (gabriele.belotti.bergamo at gmail.com) Date: Fri, 11 Oct 2019 14:03:33 +0200 Subject: [Rtk-users] R: Half Fan dataset In-Reply-To: References: <000801d58009$a7828ef0$f687acd0$@gmail.com> Message-ID: <001e01d5802b$e7cd2cf0$b76786d0$@gmail.com> Thank you Simon this is very practical! Da: Simon Rit Inviato: venerd? 11 ottobre 2019 13.10 A: gabriele.belotti.bergamo at gmail.com Cc: rtk-users Oggetto: Re: [Rtk-users] Half Fan dataset Hi, It's easy to generate, you need to offset your detector, either via the RTK geometry or by setting the first coordinate of the origin of your projection to something which makes the projection uncentered. For example, in the geometry : rtksimulatedgeometry -n 180 --proj_iso_x 100 -o g rtkprojectshepploganphantom -g g -o proj.mha rtkfdk -p . -g g -r proj.mha -o fdk.mha You can simulate from a CT image by following this example . Simon On Fri, Oct 11, 2019 at 9:58 AM > wrote: Dear RTK users and developers, I?m currently experimenting with FDK reconstruction and I?m struggling to find a Half-Fan projection dataset to fiddle around.. Do you know where I can find one? I?ve taken into consideration generating a set of DRRs from an existing phantom. Any help or advice you can give me would be greatly appreciated, thanks! Gabriele Belotti _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com https://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From vl at xris.eu Tue Oct 15 11:35:36 2019 From: vl at xris.eu (vincent) Date: Tue, 15 Oct 2019 17:35:36 +0200 Subject: [Rtk-users] Multi GPU capabilities Message-ID: Hello everyone, I was wondering if RTK automagically spread the workload over several GPU's when available on a machine ?? I tried to find the answer by myself, but up to now, the only information I could get were that: - cuda provides with a unified memory framework supposed to simplify memory management, - class itkCudaUtil has members that identify all the GPU's present on the computer. I had a look on the other itkCuda*** classes but found nothing that could help me understand if multiple GPU's are managed by RTK. Would someone would be so kind as to help me find an answer ? I thank you very much in advance, best regards, Vincent From simon.rit at creatis.insa-lyon.fr Tue Oct 15 11:53:46 2019 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 15 Oct 2019 17:53:46 +0200 Subject: [Rtk-users] Multi GPU capabilities In-Reply-To: References: Message-ID: Hi, No. This is quite a challenge to implement this and we have no resources on this topic. My first attempt to do this would be to use ASTRA from RTK. RTK only automagically select the "best" GPU, see here . For FDK, I think it would be easy to split the volume and ask each GPU to reconstruct a specific part of the volume (but I never did it and RTK would need to allow parameterization of the device which it currently doesn't). Note that we don't use the unified memory framework. Simon On Tue, Oct 15, 2019 at 5:43 PM vincent wrote: > Hello everyone, > > I was wondering if RTK automagically spread the workload over several > GPU's when available on a machine ? I tried to find the answer by > myself, but up to now, the only information I could get were that: > > - cuda provides with a unified memory framework supposed to simplify > memory management, > > - class itkCudaUtil has members that identify all the GPU's present on > the computer. > > I had a look on the other itkCuda*** classes but found nothing that > could help me understand if multiple GPU's are managed by RTK. > > Would someone would be so kind as to help me find an answer ? > > I thank you very much in advance, > > best regards, > > Vincent > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vl at xris.eu Tue Oct 15 11:54:35 2019 From: vl at xris.eu (vincent) Date: Tue, 15 Oct 2019 17:54:35 +0200 Subject: [Rtk-users] Multi GPU capabilities In-Reply-To: References: Message-ID: Hi Simon, thank you for the quick reply.? I'll try the splitting strategy. Best regards, Vincent On 15.10.19 17:53, Simon Rit wrote: > Hi, > No. This is quite a challenge to implement this and we have no > resources on this topic. My first attempt to do this would be to use > ASTRA from RTK. RTK only automagically > select the "best" GPU, see here > . > For FDK, I think it would be easy to split the volume and ask each GPU > to reconstruct a specific part of the volume (but I never did it and > RTK would need to allow parameterization of the device which it > currently doesn't). > Note that we don't use the unified memory framework. > Simon > > On Tue, Oct 15, 2019 at 5:43 PM vincent > wrote: > > Hello everyone, > > I was wondering if RTK automagically spread the workload over several > GPU's when available on a machine ?? I tried to find the answer by > myself, but up to now, the only information I could get were that: > > - cuda provides with a unified memory framework supposed to simplify > memory management, > > - class itkCudaUtil has members that identify all the GPU's > present on > the computer. > > I had a look on the other itkCuda*** classes but found nothing that > could help me understand if multiple GPU's are managed by RTK. > > Would someone would be so kind as to help me find an answer ? > > I thank you very much in advance, > > best regards, > > Vincent > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vl at xris.eu Wed Oct 23 06:37:28 2019 From: vl at xris.eu (vincent) Date: Wed, 23 Oct 2019 12:37:28 +0200 Subject: [Rtk-users] Reconstruction artefact with SART Message-ID: Hi everyone, I am trying to reconstruct a volume representing an aluminum casted part and investigate the differences between FDK and SART. Here are the parameters involved: the images are 700*820 pixels and I have 900 projections.? The physical pixel size is 0.28 mm and the sdd and sid are 558.3 mm and 461.3 mm respectively, which gives me a magnification factor of 1.2 roughly.? I performed one iteration of SART with CudaRayCast as forward and backward projectors and I wanted to reconstruct a 700*700*700 volume with a 0.23 mm (= 0.28/1.2) voxel size.? The result is shown on the two pictures attached: https://ibb.co/8sLdJxw https://ibb.co/N3NLg2D The result is getting worse as I increase the number of iterations I have a hard time understanding where the stripes come from.? A reconstruction with the standard 256*256*256 volume and 1mm spacing gives a "smoother" result, closer to what FDK gives.? I thought it might be related to the linear system resolution, but unless I am mistaken, I am trying to solve a system with 700*700*700 unknown with 700*820*900 equations, which should be ok. Furthermore, the reconstruction with FDK at the same "full" resolution gives satisfactory results. Any help/explanation will be greatly appreciated ! I thank you very much in advance, Vincent From simon.rit at creatis.insa-lyon.fr Wed Oct 23 16:30:14 2019 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 23 Oct 2019 22:30:14 +0200 Subject: [Rtk-users] Reconstruction artefact with SART In-Reply-To: References: Message-ID: Hi Vincent, There is a problem indeed! It's hard to guess what's the problem from the images you sent. I would check the projections to see what could be wrong. The first thing I would check for example is whether air is really at 0 (as it should be). You can also look at the difference between the forward projections of this first iterate and the measured projections. It's known that SART should be stopped at a few iterations but 1 should not give such a result. You can always check if the conjugate gradient provides a better result, you can add some regularization in it. Good luck solving this! Simon On Wed, Oct 23, 2019 at 3:03 PM vincent wrote: > Hi everyone, > > I am trying to reconstruct a volume representing an aluminum casted part > and investigate the differences between FDK and SART. > > Here are the parameters involved: the images are 700*820 pixels and I > have 900 projections. The physical pixel size is 0.28 mm and the sdd > and sid are 558.3 mm and 461.3 mm respectively, which gives me a > magnification factor of 1.2 roughly. I performed one iteration of SART > with CudaRayCast as forward and backward projectors and I wanted to > reconstruct a 700*700*700 volume with a 0.23 mm (= 0.28/1.2) voxel > size. The result is shown on the two pictures attached: > > https://ibb.co/8sLdJxw > https://ibb.co/N3NLg2D > > The result is getting worse as I increase the number of iterations > > I have a hard time understanding where the stripes come from. A > reconstruction with the standard 256*256*256 volume and 1mm spacing > gives a "smoother" result, closer to what FDK gives. I thought it might > be related to the linear system resolution, but unless I am mistaken, I > am trying to solve a system with 700*700*700 unknown with 700*820*900 > equations, which should be ok. > > Furthermore, the reconstruction with FDK at the same "full" resolution > gives satisfactory results. > > Any help/explanation will be greatly appreciated ! > > I thank you very much in advance, > > Vincent > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vl at xris.eu Fri Oct 25 05:17:39 2019 From: vl at xris.eu (vincent) Date: Fri, 25 Oct 2019 11:17:39 +0200 Subject: [Rtk-users] Reconstruction artefact with SART In-Reply-To: References: Message-ID: <677f012a-8b94-cf8e-333f-ff38fbf489d8@xris.eu> Hi Simon, thank you very much for the suggestions.? I think I have a lead and I was wondering if you could give me your opinion before I roll up my sleeves and dive into the code. Since the issue is number-of-voxels-dependent, and because I use CudaRayCast both for forward and backward projections, my guess was that it has to do with? the forward projection operator, and more specifically with the step size along the ray;? while it is an option in rtkforwardprojections, it is not customizable in rtksart.? To investigate further, I reprojected the reconstructed FDK volume (700x700x700 voxels, voxel size = 0.23 mm) 3 times, once with Joseph, once with CudaRayCast and the default step (1) and one with a custom step (0.1).? The vertical streaks appear as I expected in the second case but not in the others: https://ibb.co/ZX57FPM https://ibb.co/MnMk5Ny https://ibb.co/gzfPQG1 So I think that adding the step size option in rtksart should get rid of my problem, but I would like your feedback before, as I trust your experience more than my intuition :) ! Thanks again, Vincent On 23.10.19 22:30, Simon Rit wrote: > Hi Vincent, > There is a problem indeed! It's hard to guess what's the problem from > the images you sent. I would check the projections to see what could > be wrong. The first thing I would check for example is whether air is > really at 0 (as it should be). You can also look at the difference > between the forward projections of this first iterate and the measured > projections. It's known that SART should be stopped at a few > iterations but 1 should not give such a result. You can always check > if the conjugate gradient provides a better result, you can add some > regularization in it. > Good luck solving this! > Simon > > > On Wed, Oct 23, 2019 at 3:03 PM vincent > wrote: > > Hi everyone, > > I am trying to reconstruct a volume representing an aluminum > casted part > and investigate the differences between FDK and SART. > > Here are the parameters involved: the images are 700*820 pixels and I > have 900 projections.? The physical pixel size is 0.28 mm and the sdd > and sid are 558.3 mm and 461.3 mm respectively, which gives me a > magnification factor of 1.2 roughly.? I performed one iteration of > SART > with CudaRayCast as forward and backward projectors and I wanted to > reconstruct a 700*700*700 volume with a 0.23 mm (= 0.28/1.2) voxel > size.? The result is shown on the two pictures attached: > > https://ibb.co/8sLdJxw > https://ibb.co/N3NLg2D > > The result is getting worse as I increase the number of iterations > > I have a hard time understanding where the stripes come from. A > reconstruction with the standard 256*256*256 volume and 1mm spacing > gives a "smoother" result, closer to what FDK gives.? I thought it > might > be related to the linear system resolution, but unless I am > mistaken, I > am trying to solve a system with 700*700*700 unknown with 700*820*900 > equations, which should be ok. > > Furthermore, the reconstruction with FDK at the same "full" > resolution > gives satisfactory results. > > Any help/explanation will be greatly appreciated ! > > I thank you very much in advance, > > Vincent > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Sun Oct 27 16:42:53 2019 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 27 Oct 2019 21:42:53 +0100 Subject: [Rtk-users] Reconstruction artefact with SART In-Reply-To: <677f012a-8b94-cf8e-333f-ff38fbf489d8@xris.eu> References: <677f012a-8b94-cf8e-333f-ff38fbf489d8@xris.eu> Message-ID: Hi Vincent, I'm not sure why the step size would make such a large difference but that's an interesting lead indeed. Feel free to add the step size as an option, I hope this will indeed solve your problem! Best regards, Simon On Fri, Oct 25, 2019 at 11:55 AM vincent wrote: > Hi Simon, > > thank you very much for the suggestions. I think I have a lead and I was > wondering if you could give me your opinion before I roll up my sleeves and > dive into the code. > > Since the issue is number-of-voxels-dependent, and because I use > CudaRayCast both for forward and backward projections, my guess was that it > has to do with the forward projection operator, and more specifically with > the step size along the ray; while it is an option in > rtkforwardprojections, it is not customizable in rtksart. To investigate > further, I reprojected the reconstructed FDK volume (700x700x700 voxels, > voxel size = 0.23 mm) 3 times, once with Joseph, once with CudaRayCast and > the default step (1) and one with a custom step (0.1). The vertical > streaks appear as I expected in the second case but not in the others: > > https://ibb.co/ZX57FPM > https://ibb.co/MnMk5Ny > https://ibb.co/gzfPQG1 > > So I think that adding the step size option in rtksart should get rid of > my problem, but I would like your feedback before, as I trust your > experience more than my intuition :) ! > > Thanks again, > > Vincent > On 23.10.19 22:30, Simon Rit wrote: > > Hi Vincent, > There is a problem indeed! It's hard to guess what's the problem from the > images you sent. I would check the projections to see what could be wrong. > The first thing I would check for example is whether air is really at 0 (as > it should be). You can also look at the difference between the forward > projections of this first iterate and the measured projections. It's known > that SART should be stopped at a few iterations but 1 should not give such > a result. You can always check if the conjugate gradient provides a better > result, you can add some regularization in it. > Good luck solving this! > Simon > > > On Wed, Oct 23, 2019 at 3:03 PM vincent wrote: > >> Hi everyone, >> >> I am trying to reconstruct a volume representing an aluminum casted part >> and investigate the differences between FDK and SART. >> >> Here are the parameters involved: the images are 700*820 pixels and I >> have 900 projections. The physical pixel size is 0.28 mm and the sdd >> and sid are 558.3 mm and 461.3 mm respectively, which gives me a >> magnification factor of 1.2 roughly. I performed one iteration of SART >> with CudaRayCast as forward and backward projectors and I wanted to >> reconstruct a 700*700*700 volume with a 0.23 mm (= 0.28/1.2) voxel >> size. The result is shown on the two pictures attached: >> >> https://ibb.co/8sLdJxw >> https://ibb.co/N3NLg2D >> >> The result is getting worse as I increase the number of iterations >> >> I have a hard time understanding where the stripes come from. A >> reconstruction with the standard 256*256*256 volume and 1mm spacing >> gives a "smoother" result, closer to what FDK gives. I thought it might >> be related to the linear system resolution, but unless I am mistaken, I >> am trying to solve a system with 700*700*700 unknown with 700*820*900 >> equations, which should be ok. >> >> Furthermore, the reconstruction with FDK at the same "full" resolution >> gives satisfactory results. >> >> Any help/explanation will be greatly appreciated ! >> >> I thank you very much in advance, >> >> Vincent >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> https://public.kitware.com/mailman/listinfo/rtk-users >> >> _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gabriele.belotti.bergamo at gmail.com Tue Oct 29 11:10:14 2019 From: gabriele.belotti.bergamo at gmail.com (gabriele.belotti.bergamo at gmail.com) Date: Tue, 29 Oct 2019 16:10:14 +0100 Subject: [Rtk-users] R: Half Fan dataset In-Reply-To: References: <000801d58009$a7828ef0$f687acd0$@gmail.com> Message-ID: <008501d58e6a$f7aa7a40$e6ff6ec0$@gmail.com> Dear Simon and RTK users, I?ve been experimenting on the generation of Half Fan CBCT images successfully from reprojections of CTs starting from Simon?s suggestions. So far I was able to reconstruct images by displacing the detector in the X direction (+ or -) and completing a single rotation. Results were good and the FOV was of course larger than the one obtained from using the same virtual detector without displacement. I?ve taken the simulation a step further and I?m currently creating a geometry which is similar to the combination of ?rtksimulatedgeometry -n 180 --proj_iso_x -o g_1? and ?rtksimulatedgeometry -n 180 --proj_iso_x <(-1)*displacement> -o g_2 -f 180? (I?m rotating first between 0? and 180? while displacing by half detector size on +X and then 180? and 360? while displacing by half detector size on -X). With this single .xml I?m reprojecting a CT into a single .mha using rtkforwardprojections and then I?m using the output as input for rtkfdk. My results however suffer from a centered artifact, of semi-cylindrical shape, in my opinion caused by the superimposition of rays from the two beams around the isocenter. This is further supported by the fact that the more I displace the detector the smaller the artefact becomes (of course I can?t displace more than 50% of detector size). I guess a possible solution would be to have a perfect half-cone x-ray beam by shaping it using a collimator, but I?m not sure how to proceed on this in the simulated environment. Have you got any suggestions or observation on how to achieve a reconstruction based on this? (two rotations/acquistion given two opposite detector displacements) Thanks in advance, Gabriele Da: Simon Rit Inviato: venerd? 11 ottobre 2019 13.10 A: gabriele.belotti.bergamo at gmail.com Cc: rtk-users Oggetto: Re: [Rtk-users] Half Fan dataset Hi, It's easy to generate, you need to offset your detector, either via the RTK geometry or by setting the first coordinate of the origin of your projection to something which makes the projection uncentered. For example, in the geometry : rtksimulatedgeometry -n 180 --proj_iso_x 100 -o g rtkprojectshepploganphantom -g g -o proj.mha rtkfdk -p . -g g -r proj.mha -o fdk.mha You can simulate from a CT image by following this example. Simon On Fri, Oct 11, 2019 at 9:58 AM < gabriele.belotti.bergamo at gmail.com> wrote: Dear RTK users and developers, I?m currently experimenting with FDK reconstruction and I?m struggling to find a Half-Fan projection dataset to fiddle around.. Do you know where I can find one? I?ve taken into consideration generating a set of DRRs from an existing phantom. Any help or advice you can give me would be greatly appreciated, thanks! Gabriele Belotti _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com https://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From vl at xris.eu Tue Oct 29 13:00:20 2019 From: vl at xris.eu (vincent) Date: Tue, 29 Oct 2019 18:00:20 +0100 Subject: [Rtk-users] Reconstruction artefact with SART In-Reply-To: References: <677f012a-8b94-cf8e-333f-ff38fbf489d8@xris.eu> Message-ID: <6575d06d-ff61-86f0-55fc-de5d5d0fb0ae@xris.eu> Hi Simon, well the step size marginally improved the result.? But using CudaVoxelBased as the BP rather than CudaRayCast completely solved it ! Thank you for your time and advice, best regards, Vincent On 27.10.19 21:42, Simon Rit wrote: > Hi Vincent, > I'm not sure why the step size would make such a large difference but > that's an interesting lead indeed. Feel free to add the step size as > an option, I hope this will indeed solve your problem! > Best regards, > Simon > > On Fri, Oct 25, 2019 at 11:55 AM vincent > wrote: > > Hi Simon, > > thank you very much for the suggestions.? I think I have a lead > and I was wondering if you could give me your opinion before I > roll up my sleeves and dive into the code. > > Since the issue is number-of-voxels-dependent, and because I use > CudaRayCast both for forward and backward projections, my guess > was that it has to do with? the forward projection operator, and > more specifically with the step size along the ray;? while it is > an option in rtkforwardprojections, it is not customizable in > rtksart. To investigate further, I reprojected the reconstructed > FDK volume (700x700x700 voxels, voxel size = 0.23 mm) 3 times, > once with Joseph, once with CudaRayCast and the default step (1) > and one with a custom step (0.1).? The vertical streaks appear as > I expected in the second case but not in the others: > > https://ibb.co/ZX57FPM > https://ibb.co/MnMk5Ny > https://ibb.co/gzfPQG1 > > So I think that adding the step size option in rtksart should get > rid of my problem, but I would like your feedback before, as I > trust your experience more than my intuition :) ! > > Thanks again, > > Vincent > > On 23.10.19 22:30, Simon Rit wrote: >> Hi Vincent, >> There is a problem indeed! It's hard to guess what's the problem >> from the images you sent. I would check the projections to see >> what could be wrong. The first thing I would check for example is >> whether air is really at 0 (as it should be). You can also look >> at the difference between the forward projections of this first >> iterate and the measured projections. It's known that SART should >> be stopped at a few iterations but 1 should not give such a >> result. You can always check if the conjugate gradient provides a >> better result, you can add some regularization in it. >> Good luck solving this! >> Simon >> >> >> On Wed, Oct 23, 2019 at 3:03 PM vincent > > wrote: >> >> Hi everyone, >> >> I am trying to reconstruct a volume representing an aluminum >> casted part >> and investigate the differences between FDK and SART. >> >> Here are the parameters involved: the images are 700*820 >> pixels and I >> have 900 projections.? The physical pixel size is 0.28 mm and >> the sdd >> and sid are 558.3 mm and 461.3 mm respectively, which gives me a >> magnification factor of 1.2 roughly.? I performed one >> iteration of SART >> with CudaRayCast as forward and backward projectors and I >> wanted to >> reconstruct a 700*700*700 volume with a 0.23 mm (= 0.28/1.2) >> voxel >> size.? The result is shown on the two pictures attached: >> >> https://ibb.co/8sLdJxw >> https://ibb.co/N3NLg2D >> >> The result is getting worse as I increase the number of >> iterations >> >> I have a hard time understanding where the stripes come from.? A >> reconstruction with the standard 256*256*256 volume and 1mm >> spacing >> gives a "smoother" result, closer to what FDK gives. I >> thought it might >> be related to the linear system resolution, but unless I am >> mistaken, I >> am trying to solve a system with 700*700*700 unknown with >> 700*820*900 >> equations, which should be ok. >> >> Furthermore, the reconstruction with FDK at the same "full" >> resolution >> gives satisfactory results. >> >> Any help/explanation will be greatly appreciated ! >> >> I thank you very much in advance, >> >> Vincent >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> >> https://public.kitware.com/mailman/listinfo/rtk-users >> > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 29 13:21:26 2019 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 29 Oct 2019 18:21:26 +0100 Subject: [Rtk-users] Half Fan dataset In-Reply-To: <008501d58e6a$f7aa7a40$e6ff6ec0$@gmail.com> References: <000801d58009$a7828ef0$f687acd0$@gmail.com> <008501d58e6a$f7aa7a40$e6ff6ec0$@gmail.com> Message-ID: Hi Gabriele, Great that you moved forward. It's quite sure that the current implementation does not handle this new exotic geometry. So my suggestion would be to implement your own weights (e.g., using the python package). It's not clear to me what you're trying to achieve here but it seems to me that only the central part seen by all source positions has enough data (point of space which see at least 180? of source positions) to be reconstructible. Maybe you should draw your two cones at 90? and -90? to be sure of what you're doing? Don't hesitate to share such a drawing on which we could comment. Best regards, Simon On Tue, Oct 29, 2019 at 4:10 PM wrote: > Dear Simon and RTK users, > > I?ve been experimenting on the generation of Half Fan CBCT images > successfully from reprojections of CTs starting from Simon?s suggestions. > So far I was able to reconstruct images by displacing the detector in the > X direction (+ or -) and completing a single rotation. Results were good > and the FOV was of course larger than the one obtained from using the same > virtual detector without displacement. > > I?ve taken the simulation a step further and I?m currently creating a > geometry which is similar to the combination of ?rtksimulatedgeometry -n > 180 --proj_iso_x -o g_1? and ?rtksimulatedgeometry -n 180 > --proj_iso_x <(-1)*displacement> -o g_2 -f 180? (I?m rotating first between > 0? and 180? while displacing by half detector size on +X and then 180? and > 360? while displacing by half detector size on -X). > With this single .xml I?m reprojecting a CT into a single .mha using > rtkforwardprojections and then I?m using the output as input for rtkfdk. > > My results however suffer from a centered artifact, of semi-cylindrical > shape, in my opinion caused by the superimposition of rays from the two > beams around the isocenter. > This is further supported by the fact that the more I displace the > detector the smaller the artefact becomes (of course I can?t displace more > than 50% of detector size). > I guess a possible solution would be to have a perfect half-cone x-ray > beam by shaping it using a collimator, but I?m not sure how to proceed on > this in the simulated environment. > Have you got any suggestions or observation on how to achieve a > reconstruction based on this? (two rotations/acquistion given two opposite > detector displacements) > > Thanks in advance, > Gabriele > > > > > > > > *Da:* Simon Rit > *Inviato:* venerd? 11 ottobre 2019 13.10 > *A:* gabriele.belotti.bergamo at gmail.com > *Cc:* rtk-users > *Oggetto:* Re: [Rtk-users] Half Fan dataset > > > > Hi, > > It's easy to generate, you need to offset your detector, either via the > RTK geometry or by setting the first coordinate of the origin of your > projection to something which makes the projection uncentered. For example, > in the geometry : > > rtksimulatedgeometry -n 180 --proj_iso_x 100 -o g > > rtkprojectshepploganphantom -g g -o proj.mha > > rtkfdk -p . -g g -r proj.mha -o fdk.mha > > You can simulate from a CT image by following this example > . > > Simon > > > > On Fri, Oct 11, 2019 at 9:58 AM > wrote: > > Dear RTK users and developers, > > I?m currently experimenting with FDK reconstruction and I?m struggling to > find a Half-Fan projection dataset to fiddle around.. Do you know where I > can find one? I?ve taken into consideration generating a set of DRRs from > an existing phantom. Any help or advice you can give me would be greatly > appreciated, thanks! > > Gabriele Belotti > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 29 13:24:01 2019 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 29 Oct 2019 18:24:01 +0100 Subject: [Rtk-users] Reconstruction artefact with SART In-Reply-To: <6575d06d-ff61-86f0-55fc-de5d5d0fb0ae@xris.eu> References: <677f012a-8b94-cf8e-333f-ff38fbf489d8@xris.eu> <6575d06d-ff61-86f0-55fc-de5d5d0fb0ae@xris.eu> Message-ID: Thanks for sharing the result. We should definitely try to work on a more efficient and matched projector / backprojection pair. In the meantime, my feeling is that you could also use some spatial regularization to reduce the effect of unmatched projectors. Best regards, Simon On Tue, Oct 29, 2019 at 6:19 PM vincent wrote: > Hi Simon, > > well the step size marginally improved the result. But using > CudaVoxelBased as the BP rather than CudaRayCast completely solved it ! > > Thank you for your time and advice, > > best regards, > > Vincent > On 27.10.19 21:42, Simon Rit wrote: > > Hi Vincent, > I'm not sure why the step size would make such a large difference but > that's an interesting lead indeed. Feel free to add the step size as an > option, I hope this will indeed solve your problem! > Best regards, > Simon > > On Fri, Oct 25, 2019 at 11:55 AM vincent wrote: > >> Hi Simon, >> >> thank you very much for the suggestions. I think I have a lead and I was >> wondering if you could give me your opinion before I roll up my sleeves and >> dive into the code. >> >> Since the issue is number-of-voxels-dependent, and because I use >> CudaRayCast both for forward and backward projections, my guess was that it >> has to do with the forward projection operator, and more specifically with >> the step size along the ray; while it is an option in >> rtkforwardprojections, it is not customizable in rtksart. To investigate >> further, I reprojected the reconstructed FDK volume (700x700x700 voxels, >> voxel size = 0.23 mm) 3 times, once with Joseph, once with CudaRayCast and >> the default step (1) and one with a custom step (0.1). The vertical >> streaks appear as I expected in the second case but not in the others: >> >> https://ibb.co/ZX57FPM >> https://ibb.co/MnMk5Ny >> https://ibb.co/gzfPQG1 >> >> So I think that adding the step size option in rtksart should get rid of >> my problem, but I would like your feedback before, as I trust your >> experience more than my intuition :) ! >> >> Thanks again, >> >> Vincent >> On 23.10.19 22:30, Simon Rit wrote: >> >> Hi Vincent, >> There is a problem indeed! It's hard to guess what's the problem from the >> images you sent. I would check the projections to see what could be wrong. >> The first thing I would check for example is whether air is really at 0 (as >> it should be). You can also look at the difference between the forward >> projections of this first iterate and the measured projections. It's known >> that SART should be stopped at a few iterations but 1 should not give such >> a result. You can always check if the conjugate gradient provides a better >> result, you can add some regularization in it. >> Good luck solving this! >> Simon >> >> >> On Wed, Oct 23, 2019 at 3:03 PM vincent wrote: >> >>> Hi everyone, >>> >>> I am trying to reconstruct a volume representing an aluminum casted part >>> and investigate the differences between FDK and SART. >>> >>> Here are the parameters involved: the images are 700*820 pixels and I >>> have 900 projections. The physical pixel size is 0.28 mm and the sdd >>> and sid are 558.3 mm and 461.3 mm respectively, which gives me a >>> magnification factor of 1.2 roughly. I performed one iteration of SART >>> with CudaRayCast as forward and backward projectors and I wanted to >>> reconstruct a 700*700*700 volume with a 0.23 mm (= 0.28/1.2) voxel >>> size. The result is shown on the two pictures attached: >>> >>> https://ibb.co/8sLdJxw >>> https://ibb.co/N3NLg2D >>> >>> The result is getting worse as I increase the number of iterations >>> >>> I have a hard time understanding where the stripes come from. A >>> reconstruction with the standard 256*256*256 volume and 1mm spacing >>> gives a "smoother" result, closer to what FDK gives. I thought it might >>> be related to the linear system resolution, but unless I am mistaken, I >>> am trying to solve a system with 700*700*700 unknown with 700*820*900 >>> equations, which should be ok. >>> >>> Furthermore, the reconstruction with FDK at the same "full" resolution >>> gives satisfactory results. >>> >>> Any help/explanation will be greatly appreciated ! >>> >>> I thank you very much in advance, >>> >>> Vincent >>> >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> https://public.kitware.com/mailman/listinfo/rtk-users >>> >>> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> https://public.kitware.com/mailman/listinfo/rtk-users >> > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Oct 30 19:22:14 2019 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 31 Oct 2019 00:22:14 +0100 Subject: [Rtk-users] Half Fan dataset In-Reply-To: <001201d58f43$866a9390$933fbab0$@gmail.com> References: <000801d58009$a7828ef0$f687acd0$@gmail.com> <008501d58e6a$f7aa7a40$e6ff6ec0$@gmail.com> <001201d58f43$866a9390$933fbab0$@gmail.com> Message-ID: Hi, with --proj_iso_x, you only move the detector, not the source. If you also want to move the source, --source_x needs to be used. Hopefully the drawing on the doc page helps to understand this. So since you don't have any source offset in your geometry file, you are in the first line and last line situation of your drawing image. Now, on the last line, what you're actually doing is imaging with the same source arc but actually shifting the detector. This is equivalent to a 180? source rotation with a larger rotation. You only need a weighting function to account for the redundancy but this is not going to be the same one as the one implemented because it needs to be on different side of the detector/projections (as on the first line of your projections). In any case, 180? is not enough, you need at least 180+fan angle and to combine this with a short scan Parker weighting. Simon On Wed, Oct 30, 2019 at 6:00 PM wrote: > Hi Simon, > > Sorry for the late reply. > I drew a sketch in two part to explain my doubts. > First I drew 3 configurations for the geometry, representing my doubt > towards what exactly is achieved by Isocenter Projection translation in the > RTK geometry; i.e. does it result in a source translation or in a cone beam > rotation (in XZ plane) to accommodate for the panel displacement? (I?m > expecting the latter but I couldn?t properly check). > > The last two sketches represent the same concept with two of the possible > geometries(of course I?d prefer the latter): > The idea is to first rotate with the detector displaced on one side by > 180? and then displace in the opposite direction and rotate of additional > 180? (always clockwise rotation). > Any comment or suggestion would be highly appreciated and eventually I > will try to impose weights according to improve the reconstruction. > > PS: zoom in on the sketch, the resolution should be sufficient to read > PPS: I?m also attaching a screenshot of a reconstruction achieved with the > exotic geometry :^] and the xml I generated for it (beware that my detector > is 298 mm wide and the displacement is of +/-120 mm) > > Best regards, > Gabriele > > > > *Da:* Simon Rit > *Inviato:* marted? 29 ottobre 2019 18.21 > *A:* gabriele.belotti.bergamo at gmail.com > *Cc:* rtk-users > *Oggetto:* Re: [Rtk-users] Half Fan dataset > > > > Hi Gabriele, > > Great that you moved forward. > > It's quite sure that the current implementation does not handle this new > exotic geometry. So my suggestion would be to implement your own weights > (e.g., using the python package). > > It's not clear to me what you're trying to achieve here but it seems to me > that only the central part seen by all source positions has enough data > (point of space which see at least 180? of source positions) to be > reconstructible. Maybe you should draw your two cones at 90? and -90? to be > sure of what you're doing? Don't hesitate to share such a drawing on which > we could comment. > > Best regards, > > Simon > > > > On Tue, Oct 29, 2019 at 4:10 PM > wrote: > > Dear Simon and RTK users, > > I?ve been experimenting on the generation of Half Fan CBCT images > successfully from reprojections of CTs starting from Simon?s suggestions. > So far I was able to reconstruct images by displacing the detector in the > X direction (+ or -) and completing a single rotation. Results were good > and the FOV was of course larger than the one obtained from using the same > virtual detector without displacement. > > I?ve taken the simulation a step further and I?m currently creating a > geometry which is similar to the combination of ?rtksimulatedgeometry -n > 180 --proj_iso_x -o g_1? and ?rtksimulatedgeometry -n 180 > --proj_iso_x <(-1)*displacement> -o g_2 -f 180? (I?m rotating first between > 0? and 180? while displacing by half detector size on +X and then 180? and > 360? while displacing by half detector size on -X). > With this single .xml I?m reprojecting a CT into a single .mha using > rtkforwardprojections and then I?m using the output as input for rtkfdk. > > My results however suffer from a centered artifact, of semi-cylindrical > shape, in my opinion caused by the superimposition of rays from the two > beams around the isocenter. > This is further supported by the fact that the more I displace the > detector the smaller the artefact becomes (of course I can?t displace more > than 50% of detector size). > I guess a possible solution would be to have a perfect half-cone x-ray > beam by shaping it using a collimator, but I?m not sure how to proceed on > this in the simulated environment. > Have you got any suggestions or observation on how to achieve a > reconstruction based on this? (two rotations/acquistion given two opposite > detector displacements) > > Thanks in advance, > Gabriele > > > > > > > > *Da:* Simon Rit > *Inviato:* venerd? 11 ottobre 2019 13.10 > *A:* gabriele.belotti.bergamo at gmail.com > *Cc:* rtk-users > *Oggetto:* Re: [Rtk-users] Half Fan dataset > > > > Hi, > > It's easy to generate, you need to offset your detector, either via the > RTK geometry or by setting the first coordinate of the origin of your > projection to something which makes the projection uncentered. For example, > in the geometry : > > rtksimulatedgeometry -n 180 --proj_iso_x 100 -o g > > rtkprojectshepploganphantom -g g -o proj.mha > > rtkfdk -p . -g g -r proj.mha -o fdk.mha > > You can simulate from a CT image by following this example > . > > Simon > > > > On Fri, Oct 11, 2019 at 9:58 AM > wrote: > > Dear RTK users and developers, > > I?m currently experimenting with FDK reconstruction and I?m struggling to > find a Half-Fan projection dataset to fiddle around.. Do you know where I > can find one? I?ve taken into consideration generating a set of DRRs from > an existing phantom. Any help or advice you can give me would be greatly > appreciated, thanks! > > Gabriele Belotti > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: