From saimahesh.m at panaceamedical.com Mon Oct 9 04:23:02 2017 From: saimahesh.m at panaceamedical.com (M B Sai Mahesh) Date: Mon, 09 Oct 2017 08:23:02 +0000 Subject: [Rtk-users] Hounsfield Calibration for CBCT . Message-ID: <20171009082302.0fcdf45f@PMT-SRV-MS.panaceamedical.local> Dear all, We are using rtk for CBCT reconstruction (cuda FDK cone beam reconstruction filter ). I am mapping the voxels to attenuation value linearly.The slope and intercept for that mapping are calculated from the known phantom and known KV . But linear mapping does not work for all the materials in the phantom. I have read some journals and most seem to suggest that attenuation and the reconstructed voxels are related linearly. Can anyone suggest other ways. Any pointers to references are appreciated. with regards, M.B.SaiMahesh. *********************************************************************************** PANACEA MEDICAL TECHNOLOGIES PVT. LTD. Head Office: Plot #116, 4th Floor, Shailendra Techno Park, Road No 3, EPIP Area Phase 1, Whitefield, Bangalore - 560 066, Karnataka, INDIA Manufacturing Unit: Plot #87 A, Phase -II, Malur KIADB Industrial Area, Malur - 563130. Kolar District. INDIA. Tel : +91 80 4242 8700 / 2845 4785 Fax : + 91 80 42428710 Url : http://www.panaceamedical.com ____________________________________________________________________________ PMT EMAIL DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. From simon.rit at creatis.insa-lyon.fr Mon Oct 9 04:44:43 2017 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Oct 2017 10:44:43 +0200 Subject: [Rtk-users] Hounsfield Calibration for CBCT . In-Reply-To: <20171009082302.0fcdf45f@PMT-SRV-MS.panaceamedical.local> References: <20171009082302.0fcdf45f@PMT-SRV-MS.panaceamedical.local> Message-ID: Hi, I am not sure I understand your question but it seems to me that your problem is beam hardening. It is a known limitation of polychromatic x-ray imaging and there is a wealth of literature on the subject. Best regards, Simon On Mon, Oct 9, 2017 at 10:23 AM, M B Sai Mahesh < saimahesh.m at panaceamedical.com> wrote: > Dear all, > We are using rtk for CBCT reconstruction (cuda FDK cone beam > reconstruction > filter ). I am mapping the voxels to attenuation value linearly.The > slope and intercept for that mapping are calculated from > the known phantom and known KV . But linear mapping does not work for all > the materials > in the phantom. I have read some journals and most seem to suggest that > attenuation and the reconstructed voxels are related linearly. > Can anyone suggest other ways. Any pointers to references are appreciated. > > with regards, > M.B.SaiMahesh. > > > ************************************************************ > *********************** > PANACEA MEDICAL TECHNOLOGIES PVT. LTD. > Head Office: Plot #116, 4th Floor, Shailendra Techno Park, Road No 3, EPIP > Area Phase 1, Whitefield, Bangalore - 560 066, Karnataka, INDIA > Manufacturing Unit: Plot #87 A, Phase -II, Malur KIADB Industrial Area, > Malur - 563130. Kolar District. INDIA. > > Tel : +91 80 4242 8700 / 2845 4785 > Fax : + 91 80 42428710 > Url : http://www.panaceamedical.com > ____________________________________________________________ > ________________ > PMT EMAIL DISCLAIMER: > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > Please note that any views or opinions presented in this email are solely > those of the author and do not necessarily represent those of the company. > Finally, the recipient should check this email and any attachments for the > presence of viruses. The company accepts no liability for any damage > caused by any virus transmitted by 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 didomenico at fe.infn.it Mon Oct 9 13:20:30 2017 From: didomenico at fe.infn.it (Giovanni Di Domenico) Date: Mon, 9 Oct 2017 19:20:30 +0200 Subject: [Rtk-users] RTK compilation error Message-ID: <826835feeb505a9f07d28fef8474ce03.squirrel@webmail.fe.infn.it> HI, I have tried to compile RTK, but the following error raise usr/bin/ld: /home/gdidomenico/Reconstruction/openRTK/ITK/ITK-build/lib/libITKCommon-4.13.a(itkSimpleFastMutexLock.cxx.o): undefined reference to symbol 'pthread_mutexattr_settype@@GLIBC_2.2.5' /usr/lib64/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Please could you help me? Best Regards Giovanni Giovanni Di Domenico, Ph.D. Dipartimento di Fisica e Scienze della Terra Universita' degli Studi di Ferrara Polo Scientifico Tecnologico via Saragat 1 44122 Ferrara - ITALY e-mail: didomenico at fe.infn.it Phone: +39-0532-974223 FAX: +39-0532-974210 From simon.rit at creatis.insa-lyon.fr Tue Oct 10 02:10:41 2017 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 10 Oct 2017 08:10:41 +0200 Subject: [Rtk-users] RTK compilation error In-Reply-To: <826835feeb505a9f07d28fef8474ce03.squirrel@webmail.fe.infn.it> References: <826835feeb505a9f07d28fef8474ce03.squirrel@webmail.fe.infn.it> Message-ID: Hi, I don't know and I don't think it's an RTK problem. I would try adding -lpthread to the CMAKE_EXE_LINKER_FLAGS in ccmake. Best regards, Simon On Mon, Oct 9, 2017 at 7:20 PM, Giovanni Di Domenico wrote: > HI, > > I have tried to compile RTK, but the following error raise > > usr/bin/ld: > /home/gdidomenico/Reconstruction/openRTK/ITK/ITK-build/lib/libITKCommon-4. > 13.a(itkSimpleFastMutexLock.cxx.o): > undefined reference to symbol 'pthread_mutexattr_settype@@GLIBC_2.2.5' > /usr/lib64/libpthread.so.0: error adding symbols: DSO missing from command > line > collect2: error: ld returned 1 exit status > > Please could you help me? > > Best Regards > > Giovanni > > Giovanni Di Domenico, Ph.D. > Dipartimento di Fisica e Scienze della Terra > Universita' degli Studi di Ferrara > Polo Scientifico Tecnologico > via Saragat 1 > 44122 Ferrara - ITALY > e-mail: didomenico at fe.infn.it > Phone: +39-0532-974223 > FAX: +39-0532-974210 > > _______________________________________________ > 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 Oct 10 09:02:24 2017 From: robert.calliess at gmx.de (Robert Calliess) Date: Tue, 10 Oct 2017 15:02:24 +0200 Subject: [Rtk-users] FDK for planar ct Message-ID: <002101d341c8$04b34b00$0e19e100$@gmx.de> Hello rtk users, I have question to the RTK FDK Filter. As far as I understand from to the fourier slice theorem the object to be reconstructed needs a circular trajectory and needs to rotate its own centre. Please have a look at the attached sketch. With this planar trajectory (Object, a PCB, is moved on a circle trajectpry "in-plane", PCB itself is not rotating) do I need a special filtering if I want to use FDK for planar CT with respect to the sketched trajectory ? I tried a circular in-plane trajectory where the PCB is centred and rotates around its centre point. And with 100 projections I get good results. But with the trajectory I described (sketch, attached image) the results are not so good. Because of the row-wise ramp filter It looks like there is a directional dependency. My assumption is, and with respect to fourier slice theorem, that the missing object rotation (rotation around itself) causes there directional effects. So my questions to the experts are. Do I need to apply a special filtering before backprojecting with FDK or is it just the wrong algorithm for this kind of trajectory ? kind regards, Robert C. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pct.png Type: image/png Size: 13256 bytes Desc: not available URL: From cyril.mory at creatis.insa-lyon.fr Tue Oct 10 09:31:15 2017 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Tue, 10 Oct 2017 15:31:15 +0200 Subject: [Rtk-users] FDK for planar ct In-Reply-To: <002101d341c8$04b34b00$0e19e100$@gmx.de> References: <002101d341c8$04b34b00$0e19e100$@gmx.de> Message-ID: <52555187-df4b-6432-20c6-638aa0f25988@creatis.insa-lyon.fr> Dear Robert, Your description of the trajectory is very obscure to me. Maybe you have a very unusual X-ray system. Could you make the following points clear : - what is a PCB ? - what is fixed/moving in your system (we need this information for the object, the source and the detector), and what kind of trajectories have the moving parts ? - can you re-draw your sketch with just 2 or 3 positions (ideally, on similar but separate drawings), each one with the object, the source and the detector ? If you do that, we should have a clear understanding of how your acquisition goes, and be able to give you appropriate advice. Best regards, Cyril On 10/10/2017 15:02, Robert Calliess wrote: > > Hello rtk users, > > I have question to the RTK FDK Filter. As far as I understand from to > the fourier slice theorem the object to be reconstructed needs a > circular trajectory and needs to rotate its own centre. > > Please have a look at the attached sketch. With this planar trajectory > (Object, a PCB, is moved on a circle trajectpry ??in-plane?, PCB > itself is not rotating) do I need > > a special filtering if I want to use FDK for planar CT with respect to > the sketched trajectory ? I tried a circular in-plane trajectory where > the PCB is centred and rotates > > around its centre point. And with 100 projections I get good results. > But with the trajectory I described (sketch, attached image) the > results are not so good. > > Because of the row-wise ramp filter It looks like there is a > directional dependency. My assumption is, and with respect to fourier > slice theorem, that the missing object > > rotation (rotation around itself) causes there directional effects. > > So my questions to the experts are. Do I need to apply a special > filtering before backprojecting with FDK or is it just the wrong > > algorithm for this kind of trajectory ? > > kind regards, > > Robert C. > > > > _______________________________________________ > 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 Oct 10 11:43:23 2017 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 10 Oct 2017 17:43:23 +0200 Subject: [Rtk-users] FDK for planar ct In-Reply-To: <52555187-df4b-6432-20c6-638aa0f25988@creatis.insa-lyon.fr> References: <002101d341c8$04b34b00$0e19e100$@gmx.de> <52555187-df4b-6432-20c6-638aa0f25988@creatis.insa-lyon.fr> Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: trajectory_1.jpg Type: image/jpeg Size: 25530 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: trajectory_2.png Type: image/png Size: 19773 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 10 13:06:24 2017 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 10 Oct 2017 19:06:24 +0200 Subject: [Rtk-users] FDK for planar ct In-Reply-To: References: <002101d341c8$04b34b00$0e19e100$@gmx.de> <52555187-df4b-6432-20c6-638aa0f25988@creatis.insa-lyon.fr> Message-ID: Hi, It's still not clear to me but what is helpful is to think in terms of source trajectory wrt the object. Trajectory 1: if I understand, you move the source on two circles plus one point. I don't know of a FBP algorithm to reconstruct this, but there might be one. I would consider iterative reconstruction first. Trajectory 2: your trajectory is a point, the source does not move with respect ot the object since it lies on the rotation axis. So each projection contains exactly the same information up to a simple 2D projection deformation. So it's hopeless to reconstruct from one projection only. To create the correct geometry, I would suggest using the function AddProjection for which you provide the source and detector positions plus the 3D coordinates of the two axes of the coordinate system of the projection. I hope this helps Simon On Tue, Oct 10, 2017 at 5:43 PM, "Robert Callie?" wrote: > Hello, > thank you for the fast reply. > To answer your questions first. > In this case the abbrevation pcb stands for printed circuit board. > Next point is the trajectory we are currently handling with. > Please see the attached image "trajectory.png". There are two schematics > showing the side view and top view for trajectory type 1 > and a side-view for trajectory type 2. > > For type 1: > The xray source is fixed. The pcb is clamped within a transport, so the > pcb and the detector are moveable with in the xy plane. > As you can see at the image, the pcb moves along a circular path but the > pcb itself is not rotating. And let's assume that the iso ray > always passes through the centre of the pcb and the centre of the detector. > > For type 2: > The xray source is fixed and the detector is tilted. The pcb lies centred > in the middle of a table. So that the pcb rotates around its centre > around the z-axis. > > > I hope this makes clear what trajectory i'm dealing with. Thank you. > > Kind regards, > Robert C. > > > > > > > *Gesendet:* Dienstag, 10. Oktober 2017 um 15:31 Uhr > *Von:* "Cyril Mory" > *An:* "Robert Calliess" , > rtk-users at public.kitware.com > *Betreff:* Re: [Rtk-users] FDK for planar ct > > Dear Robert, > > Your description of the trajectory is very obscure to me. Maybe you have a > very unusual X-ray system. Could you make the following points clear : > > - what is a PCB ? > > - what is fixed/moving in your system (we need this information for the > object, the source and the detector), and what kind of trajectories have > the moving parts ? > > - can you re-draw your sketch with just 2 or 3 positions (ideally, on > similar but separate drawings), each one with the object, the source and > the detector ? > > If you do that, we should have a clear understanding of how your > acquisition goes, and be able to give you appropriate advice. > > Best regards, > > Cyril > > On 10/10/2017 15:02, Robert Calliess wrote: > > Hello rtk users, > > I have question to the RTK FDK Filter. As far as I understand from to the > fourier slice theorem the object to be reconstructed needs a circular > trajectory and needs to rotate its own centre. > > Please have a look at the attached sketch. With this planar trajectory > (Object, a PCB, is moved on a circle trajectpry ?in-plane?, PCB itself is > not rotating) do I need > > a special filtering if I want to use FDK for planar CT with respect to the > sketched trajectory ? I tried a circular in-plane trajectory where the PCB > is centred and rotates > > around its centre point. And with 100 projections I get good results. But > with the trajectory I described (sketch, attached image) the results are > not so good. > > Because of the row-wise ramp filter It looks like there is a directional > dependency. My assumption is, and with respect to fourier slice theorem, > that the missing object > > rotation (rotation around itself) causes there directional effects. > > > > So my questions to the experts are. Do I need to apply a special filtering > before backprojecting with FDK or is it just the wrong > > algorithm for this kind of trajectory ? > > > > kind regards, > > Robert C. > > > _______________________________________________ > Rtk-users mailing listRtk-users at public.kitware.comhttp://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 Tue Oct 10 14:07:28 2017 From: robert.calliess at gmx.de (Robert Calliess) Date: Tue, 10 Oct 2017 20:07:28 +0200 Subject: [Rtk-users] FDK for planar ct In-Reply-To: References: <002101d341c8$04b34b00$0e19e100$@gmx.de> <52555187-df4b-6432-20c6-638aa0f25988@creatis.insa-lyon.fr> Message-ID: <004001d341f2$a2ce0c60$e86a2520$@gmx.de> Hello, I try to clarify the both trajectories. Trajectory 1: No, i dont move the source on two circles. The xray source is fixed. Only the object and the detector moves. Both move on a circular path so that the iso-ray always passes through the pcb centre and the detector centre. There is one orthogonal view and the others are the ones moving on the circular path. (Object is not rotating around its own axis). Trajectory 2: Yes, the xray source lies in the rotation axis and only the object rotates around its z-axis. Detector and xray source are fixed and the detector is tilted. It?s almost like this trajectory here https://www.ikeda-shoponline.com/engctsoft/wp-content/uploads/2016/06/Oblique-View-CT1.jpg except that the xray source lies on the rotation axis. I hope this helps to understand the trajectories I have to deal with. Kind regards, Robert Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit Gesendet: Dienstag, 10. Oktober 2017 19:06 An: Robert Callie? Cc: Cyril Mory; rtk-users at public.kitware.com Betreff: Re: [Rtk-users] FDK for planar ct Hi, It's still not clear to me but what is helpful is to think in terms of source trajectory wrt the object. Trajectory 1: if I understand, you move the source on two circles plus one point. I don't know of a FBP algorithm to reconstruct this, but there might be one. I would consider iterative reconstruction first. Trajectory 2: your trajectory is a point, the source does not move with respect ot the object since it lies on the rotation axis. So each projection contains exactly the same information up to a simple 2D projection deformation. So it's hopeless to reconstruct from one projection only. To create the correct geometry, I would suggest using the function AddProjection for which you provide the source and detector positions plus the 3D coordinates of the two axes of the coordinate system of the projection. I hope this helps Simon On Tue, Oct 10, 2017 at 5:43 PM, "Robert Callie?" wrote: Hello, thank you for the fast reply. To answer your questions first. In this case the abbrevation pcb stands for printed circuit board. Next point is the trajectory we are currently handling with. Please see the attached image "trajectory.png". There are two schematics showing the side view and top view for trajectory type 1 and a side-view for trajectory type 2. For type 1: The xray source is fixed. The pcb is clamped within a transport, so the pcb and the detector are moveable with in the xy plane. As you can see at the image, the pcb moves along a circular path but the pcb itself is not rotating. And let's assume that the iso ray always passes through the centre of the pcb and the centre of the detector. For type 2: The xray source is fixed and the detector is tilted. The pcb lies centred in the middle of a table. So that the pcb rotates around its centre around the z-axis. I hope this makes clear what trajectory i'm dealing with. Thank you. Kind regards, Robert C. Gesendet: Dienstag, 10. Oktober 2017 um 15:31 Uhr Von: "Cyril Mory" An: "Robert Calliess" , rtk-users at public.kitware.com Betreff: Re: [Rtk-users] FDK for planar ct Dear Robert, Your description of the trajectory is very obscure to me. Maybe you have a very unusual X-ray system. Could you make the following points clear : - what is a PCB ? - what is fixed/moving in your system (we need this information for the object, the source and the detector), and what kind of trajectories have the moving parts ? - can you re-draw your sketch with just 2 or 3 positions (ideally, on similar but separate drawings), each one with the object, the source and the detector ? If you do that, we should have a clear understanding of how your acquisition goes, and be able to give you appropriate advice. Best regards, Cyril On 10/10/2017 15:02, Robert Calliess wrote: Hello rtk users, I have question to the RTK FDK Filter. As far as I understand from to the fourier slice theorem the object to be reconstructed needs a circular trajectory and needs to rotate its own centre. Please have a look at the attached sketch. With this planar trajectory (Object, a PCB, is moved on a circle trajectpry ?in-plane?, PCB itself is not rotating) do I need a special filtering if I want to use FDK for planar CT with respect to the sketched trajectory ? I tried a circular in-plane trajectory where the PCB is centred and rotates around its centre point. And with 100 projections I get good results. But with the trajectory I described (sketch, attached image) the results are not so good. Because of the row-wise ramp filter It looks like there is a directional dependency. My assumption is, and with respect to fourier slice theorem, that the missing object rotation (rotation around itself) causes there directional effects. So my questions to the experts are. Do I need to apply a special filtering before backprojecting with FDK or is it just the wrong algorithm for this kind of trajectory ? kind regards, Robert C. _______________________________________________ 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 Tue Oct 10 14:29:00 2017 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 10 Oct 2017 20:29:00 +0200 Subject: [Rtk-users] FDK for planar ct In-Reply-To: <004001d341f2$a2ce0c60$e86a2520$@gmx.de> References: <002101d341c8$04b34b00$0e19e100$@gmx.de> <52555187-df4b-6432-20c6-638aa0f25988@creatis.insa-lyon.fr> <004001d341f2$a2ce0c60$e86a2520$@gmx.de> Message-ID: Hi, Let me try to clarify what I mean by "source trajectory wrt the object." In tomography, you need to determine the source trajectory in the object coordinate system, we don't really care about the source trajectory in the room coordinate system. For example, rotating the source on a circular trajectory or rotating the object makes no difference for the reconstruction algorithm. That's why we call diagnostic scanners "helical scanners". So for trajectory 1, it seems that the source trajectory (again, wrt to the object) is a circle but the object is offset. This is somewhat similar to https://doi.org/10.1109/TNS.2006.880977 except that the detector is not tilted so FDK would be the only FBP algorithm I could think of. But the situation is really not good, data are missing and iterative reconstruction should give better results. Trajectory 2: what I said in my previous email is true, it's useless I believe, all projections are similar up to a 2D transform of the projection. Simon On Tue, Oct 10, 2017 at 8:07 PM, Robert Calliess wrote: > Hello, > > I try to clarify the both trajectories. > > > > Trajectory 1: > > No, i dont move the source on two circles. The xray source is fixed. Only > the object and the detector moves. Both move on a circular path so that the > iso-ray > > always passes through the pcb centre and the detector centre. There is one > orthogonal view and the others are the ones moving on the circular path. > > (Object is not rotating around its own axis). > > > > Trajectory 2: > > Yes, the xray source lies in the rotation axis and only the object rotates > around its z-axis. Detector and xray source are fixed and the detector is > tilted. > > It?s almost like this trajectory here https://www.ikeda-shoponline. > com/engctsoft/wp-content/uploads/2016/06/Oblique-View-CT1.jpg > > except that the xray source lies on the rotation axis. > > > > I hope this helps to understand the trajectories I have to deal with. > > > > Kind regards, > > Robert > > > > > > *Von:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *Im Auftrag von *Simon > Rit > *Gese**ndet:* Dienstag, 10. Oktober 2017 19:06 > *An:* Robert Callie? > *Cc:* Cyril Mory; rtk-users at public.kitware.com > > *Betreff:* Re: [Rtk-users] FDK for planar ct > > > > Hi, > > It's still not clear to me but what is helpful is to think in terms of > source trajectory wrt the object. > > Trajectory 1: if I understand, you move the source on two circles plus one > point. I don't know of a FBP algorithm to reconstruct this, but there might > be one. I would consider iterative reconstruction first. > > Trajectory 2: your trajectory is a point, the source does not move with > respect ot the object since it lies on the rotation axis. So each > projection contains exactly the same information up to a simple 2D > projection deformation. So it's hopeless to reconstruct from one projection > only. > > To create the correct geometry, I would suggest using the function > AddProjection > > for which you provide the source and detector positions plus the 3D > coordinates of the two axes of the coordinate system of the projection. > > I hope this helps > > Simon > > > > On Tue, Oct 10, 2017 at 5:43 PM, "Robert Callie?" > wrote: > > Hello, > > thank you for the fast reply. > > To answer your questions first. > > In this case the abbrevation pcb stands for printed circuit board. > > Next point is the trajectory we are currently handling with. > > Please see the attached image "trajectory.png". There are two schematics > showing the side view and top view for trajectory type 1 > > and a side-view for trajectory type 2. > > > > For type 1: > > The xray source is fixed. The pcb is clamped within a transport, so the > pcb and the detector are moveable with in the xy plane. > > As you can see at the image, the pcb moves along a circular path but the > pcb itself is not rotating. And let's assume that the iso ray > > always passes through the centre of the pcb and the centre of the detector. > > > > For type 2: > > The xray source is fixed and the detector is tilted. The pcb lies centred > in the middle of a table. So that the pcb rotates around its centre > > around the z-axis. > > > > > > I hope this makes clear what trajectory i'm dealing with. Thank you. > > > > Kind regards, > > Robert C. > > > > > > > > > > > > > > *Gesendet:* Dienstag, 10. Oktober 2017 um 15:31 Uhr > *Von:* "Cyril Mory" > *An:* "Robert Calliess" , > rtk-users at public.kitware.com > *Betreff:* Re: [Rtk-users] FDK for planar ct > > Dear Robert, > > Your description of the trajectory is very obscure to me. Maybe you have a > very unusual X-ray system. Could you make the following points clear : > > - what is a PCB ? > > - what is fixed/moving in your system (we need this information for the > object, the source and the detector), and what kind of trajectories have > the moving parts ? > > - can you re-draw your sketch with just 2 or 3 positions (ideally, on > similar but separate drawings), each one with the object, the source and > the detector ? > > If you do that, we should have a clear understanding of how your > acquisition goes, and be able to give you appropriate advice. > > Best regards, > > Cyril > > > > On 10/10/2017 15:02, Robert Calliess wrote: > > Hello rtk users, > > I have question to the RTK FDK Filter. As far as I understand from to the > fourier slice theorem the object to be reconstructed needs a circular > trajectory and needs to rotate its own centre. > > Please have a look at the attached sketch. With this planar trajectory > (Object, a PCB, is moved on a circle trajectpry ?in-plane?, PCB itself is > not rotating) do I need > > a special filtering if I want to use FDK for planar CT with respect to the > sketched trajectory ? I tried a circular in-plane trajectory where the PCB > is centred and rotates > > around its centre point. And with 100 projections I get good results. But > with the trajectory I described (sketch, attached image) the results are > not so good. > > Because of the row-wise ramp filter It looks like there is a directional > dependency. My assumption is, and with respect to fourier slice theorem, > that the missing object > > rotation (rotation around itself) causes there directional effects. > > > > So my questions to the experts are. Do I need to apply a special filtering > before backprojecting with FDK or is it just the wrong > > algorithm for this kind of trajectory ? > > > > kind regards, > > Robert C. > > > > _______________________________________________ > > 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 Oct 11 14:58:21 2017 From: robert.calliess at gmx.de (Robert Calliess) Date: Wed, 11 Oct 2017 20:58:21 +0200 Subject: [Rtk-users] FDK for planar ct In-Reply-To: References: <002101d341c8$04b34b00$0e19e100$@gmx.de> <52555187-df4b-6432-20c6-638aa0f25988@creatis.insa-lyon.fr> <004001d341f2$a2ce0c60$e86a2520$@gmx.de> Message-ID: <004501d342c2$e8bebfa0$ba3c3ee0$@gmx.de> Hello, thanks for the link to the paper but I dont have access to it. Aside from how the trajectory is interpreted within in RTK. My actual question was if any of those two trajectories would need another reconstruction filter than the FDK Filter. From my point of understanding a specific rotation around the object is necessary for fbp/fdk (like c-arm bow, standard circular cone-beam trajectory). That?s why I asked If the first trajectory needs some other reconstruction filter because the object itself doesn?t rotate around itself. It actually gets translated on a circular path. So I was more expecting a ?yes? or ?no? to the fdk filter or a hint to another filter (except iterative reconstructions) I should use for these trajectories. To trajectory 2: I think the projections are different. The object rotates and each projection shows a different view. Kind regards, Robert C. Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit Gesendet: Dienstag, 10. Oktober 2017 20:29 An: Robert Calliess Cc: Cyril Mory; rtk-users at public.kitware.com Betreff: Re: [Rtk-users] FDK for planar ct Hi, Let me try to clarify what I mean by "source trajectory wrt the object." In tomography, you need to determine the source trajectory in the object coordinate system, we don't really care about the source trajectory in the room coordinate system. For example, rotating the source on a circular trajectory or rotating the object makes no difference for the reconstruction algorithm. That's why we call diagnostic scanners "helical scanners". So for trajectory 1, it seems that the source trajectory (again, wrt to the object) is a circle but the object is offset. This is somewhat similar to https://doi.org/10.1109/TNS.2006.880977 except that the detector is not tilted so FDK would be the only FBP algorithm I could think of. But the situation is really not good, data are missing and iterative reconstruction should give better results. Trajectory 2: what I said in my previous email is true, it's useless I believe, all projections are similar up to a 2D transform of the projection. Simon On Tue, Oct 10, 2017 at 8:07 PM, Robert Calliess wrote: Hello, I try to clarify the both trajectories. Trajectory 1: No, i dont move the source on two circles. The xray source is fixed. Only the object and the detector moves. Both move on a circular path so that the iso-ray always passes through the pcb centre and the detector centre. There is one orthogonal view and the others are the ones moving on the circular path. (Object is not rotating around its own axis). Trajectory 2: Yes, the xray source lies in the rotation axis and only the object rotates around its z-axis. Detector and xray source are fixed and the detector is tilted. It?s almost like this trajectory here https://www.ikeda-shoponline.com/engctsoft/wp-content/uploads/2016/06/Oblique-View-CT1.jpg except that the xray source lies on the rotation axis. I hope this helps to understand the trajectories I have to deal with. Kind regards, Robert Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit Gesendet: Dienstag, 10. Oktober 2017 19:06 An: Robert Callie? Cc: Cyril Mory; rtk-users at public.kitware.com Betreff: Re: [Rtk-users] FDK for planar ct Hi, It's still not clear to me but what is helpful is to think in terms of source trajectory wrt the object. Trajectory 1: if I understand, you move the source on two circles plus one point. I don't know of a FBP algorithm to reconstruct this, but there might be one. I would consider iterative reconstruction first. Trajectory 2: your trajectory is a point, the source does not move with respect ot the object since it lies on the rotation axis. So each projection contains exactly the same information up to a simple 2D projection deformation. So it's hopeless to reconstruct from one projection only. To create the correct geometry, I would suggest using the function AddProjection for which you provide the source and detector positions plus the 3D coordinates of the two axes of the coordinate system of the projection. I hope this helps Simon On Tue, Oct 10, 2017 at 5:43 PM, "Robert Callie?" wrote: Hello, thank you for the fast reply. To answer your questions first. In this case the abbrevation pcb stands for printed circuit board. Next point is the trajectory we are currently handling with. Please see the attached image "trajectory.png". There are two schematics showing the side view and top view for trajectory type 1 and a side-view for trajectory type 2. For type 1: The xray source is fixed. The pcb is clamped within a transport, so the pcb and the detector are moveable with in the xy plane. As you can see at the image, the pcb moves along a circular path but the pcb itself is not rotating. And let's assume that the iso ray always passes through the centre of the pcb and the centre of the detector. For type 2: The xray source is fixed and the detector is tilted. The pcb lies centred in the middle of a table. So that the pcb rotates around its centre around the z-axis. I hope this makes clear what trajectory i'm dealing with. Thank you. Kind regards, Robert C. Gesendet: Dienstag, 10. Oktober 2017 um 15:31 Uhr Von: "Cyril Mory" An: "Robert Calliess" , rtk-users at public.kitware.com Betreff: Re: [Rtk-users] FDK for planar ct Dear Robert, Your description of the trajectory is very obscure to me. Maybe you have a very unusual X-ray system. Could you make the following points clear : - what is a PCB ? - what is fixed/moving in your system (we need this information for the object, the source and the detector), and what kind of trajectories have the moving parts ? - can you re-draw your sketch with just 2 or 3 positions (ideally, on similar but separate drawings), each one with the object, the source and the detector ? If you do that, we should have a clear understanding of how your acquisition goes, and be able to give you appropriate advice. Best regards, Cyril On 10/10/2017 15:02, Robert Calliess wrote: Hello rtk users, I have question to the RTK FDK Filter. As far as I understand from to the fourier slice theorem the object to be reconstructed needs a circular trajectory and needs to rotate its own centre. Please have a look at the attached sketch. With this planar trajectory (Object, a PCB, is moved on a circle trajectpry ?in-plane?, PCB itself is not rotating) do I need a special filtering if I want to use FDK for planar CT with respect to the sketched trajectory ? I tried a circular in-plane trajectory where the PCB is centred and rotates around its centre point. And with 100 projections I get good results. But with the trajectory I described (sketch, attached image) the results are not so good. Because of the row-wise ramp filter It looks like there is a directional dependency. My assumption is, and with respect to fourier slice theorem, that the missing object rotation (rotation around itself) causes there directional effects. So my questions to the experts are. Do I need to apply a special filtering before backprojecting with FDK or is it just the wrong algorithm for this kind of trajectory ? kind regards, Robert C. _______________________________________________ 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 Thu Oct 12 01:14:26 2017 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Oct 2017 07:14:26 +0200 Subject: [Rtk-users] FDK for planar ct In-Reply-To: <004501d342c2$e8bebfa0$ba3c3ee0$@gmx.de> References: <002101d341c8$04b34b00$0e19e100$@gmx.de> <52555187-df4b-6432-20c6-638aa0f25988@creatis.insa-lyon.fr> <004001d341f2$a2ce0c60$e86a2520$@gmx.de> <004501d342c2$e8bebfa0$ba3c3ee0$@gmx.de> Message-ID: Hello, No. The filter should be orthogonal to the rotation axis. The RTK ramp filter is along the u axis of the projection. Trajectory 2: if you take photos by rotating the cameras, they are photographies of the same point-of-view. This is what I meant. Cheers, Simon On Wed, Oct 11, 2017 at 8:58 PM, Robert Calliess wrote: > Hello, > > thanks for the link to the paper but I dont have access to it. Aside from > how the trajectory is interpreted within in RTK. My actual question was > > if any of those two trajectories would need another reconstruction filter > than the FDK Filter. From my point of understanding a specific rotation > around > > the object is necessary for fbp/fdk (like c-arm bow, standard circular > cone-beam trajectory). That?s why I asked If the first trajectory needs > some other reconstruction > > filter because the object itself doesn?t rotate around itself. It actually > gets translated on a circular path. So I was more expecting a ?yes? or ?no? > to the fdk filter > > or a hint to another filter (except iterative reconstructions) I should > use for these trajectories. > > > > To trajectory 2: I think the projections are different. The object rotates > and each projection shows a different view. > > > > > > Kind regards, > > Robert C. > > > > *Von:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *Im Auftrag von *Simon > Rit > *Gesendet:* Dienstag, 10. Oktober 2017 20:29 > *An:* Robert Calliess > > *Cc:* Cyril Mory; rtk-users at public.kitware.com > *Betreff:* Re: [Rtk-users] FDK for planar ct > > > > Hi, > > Let me try to clarify what I mean by "source trajectory wrt the object." > In tomography, you need to determine the source trajectory in the object > coordinate system, we don't really care about the source trajectory in the > room coordinate system. For example, rotating the source on a circular > trajectory or rotating the object makes no difference for the > reconstruction algorithm. That's why we call diagnostic scanners "helical > scanners". > > So for trajectory 1, it seems that the source trajectory (again, wrt to > the object) is a circle but the object is offset. This is somewhat similar > to https://doi.org/10.1109/TNS.2006.880977 except that the detector is > not tilted so FDK would be the only FBP algorithm I could think of. But the > situation is really not good, data are missing and iterative reconstruction > should give better results. > > Trajectory 2: what I said in my previous email is true, it's useless I > believe, all projections are similar up to a 2D transform of the projection. > > Simon > > > > On Tue, Oct 10, 2017 at 8:07 PM, Robert Calliess > wrote: > > Hello, > > I try to clarify the both trajectories. > > > > Trajectory 1: > > No, i dont move the source on two circles. The xray source is fixed. Only > the object and the detector moves. Both move on a circular path so that the > iso-ray > > always passes through the pcb centre and the detector centre. There is one > orthogonal view and the others are the ones moving on the circular path. > > (Object is not rotating around its own axis). > > > > Trajectory 2: > > Yes, the xray source lies in the rotation axis and only the object rotates > around its z-axis. Detector and xray source are fixed and the detector is > tilted. > > It?s almost like this trajectory here https://www.ikeda-shoponline. > com/engctsoft/wp-content/uploads/2016/06/Oblique-View-CT1.jpg > > except that the xray source lies on the rotation axis. > > > > I hope this helps to understand the trajectories I have to deal with. > > > > Kind regards, > > Robert > > > > > > *Von:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *Im Auftrag von *Simon > Rit > *Gese**ndet:* Dienstag, 10. Oktober 2017 19:06 > *An:* Robert Callie? > *Cc:* Cyril Mory; rtk-users at public.kitware.com > > > *Betreff:* Re: [Rtk-users] FDK for planar ct > > > > Hi, > > It's still not clear to me but what is helpful is to think in terms of > source trajectory wrt the object. > > Trajectory 1: if I understand, you move the source on two circles plus one > point. I don't know of a FBP algorithm to reconstruct this, but there might > be one. I would consider iterative reconstruction first. > > Trajectory 2: your trajectory is a point, the source does not move with > respect ot the object since it lies on the rotation axis. So each > projection contains exactly the same information up to a simple 2D > projection deformation. So it's hopeless to reconstruct from one projection > only. > > To create the correct geometry, I would suggest using the function > AddProjection > > for which you provide the source and detector positions plus the 3D > coordinates of the two axes of the coordinate system of the projection. > > I hope this helps > > Simon > > > > On Tue, Oct 10, 2017 at 5:43 PM, "Robert Callie?" > wrote: > > Hello, > > thank you for the fast reply. > > To answer your questions first. > > In this case the abbrevation pcb stands for printed circuit board. > > Next point is the trajectory we are currently handling with. > > Please see the attached image "trajectory.png". There are two schematics > showing the side view and top view for trajectory type 1 > > and a side-view for trajectory type 2. > > > > For type 1: > > The xray source is fixed. The pcb is clamped within a transport, so the > pcb and the detector are moveable with in the xy plane. > > As you can see at the image, the pcb moves along a circular path but the > pcb itself is not rotating. And let's assume that the iso ray > > always passes through the centre of the pcb and the centre of the detector. > > > > For type 2: > > The xray source is fixed and the detector is tilted. The pcb lies centred > in the middle of a table. So that the pcb rotates around its centre > > around the z-axis. > > > > > > I hope this makes clear what trajectory i'm dealing with. Thank you. > > > > Kind regards, > > Robert C. > > > > > > > > > > > > > > *Gesendet:* Dienstag, 10. Oktober 2017 um 15:31 Uhr > *Von:* "Cyril Mory" > *An:* "Robert Calliess" , > rtk-users at public.kitware.com > *Betreff:* Re: [Rtk-users] FDK for planar ct > > Dear Robert, > > Your description of the trajectory is very obscure to me. Maybe you have a > very unusual X-ray system. Could you make the following points clear : > > - what is a PCB ? > > - what is fixed/moving in your system (we need this information for the > object, the source and the detector), and what kind of trajectories have > the moving parts ? > > - can you re-draw your sketch with just 2 or 3 positions (ideally, on > similar but separate drawings), each one with the object, the source and > the detector ? > > If you do that, we should have a clear understanding of how your > acquisition goes, and be able to give you appropriate advice. > > Best regards, > > Cyril > > > > On 10/10/2017 15:02, Robert Calliess wrote: > > Hello rtk users, > > I have question to the RTK FDK Filter. As far as I understand from to the > fourier slice theorem the object to be reconstructed needs a circular > trajectory and needs to rotate its own centre. > > Please have a look at the attached sketch. With this planar trajectory > (Object, a PCB, is moved on a circle trajectpry ?in-plane?, PCB itself is > not rotating) do I need > > a special filtering if I want to use FDK for planar CT with respect to the > sketched trajectory ? I tried a circular in-plane trajectory where the PCB > is centred and rotates > > around its centre point. And with 100 projections I get good results. But > with the trajectory I described (sketch, attached image) the results are > not so good. > > Because of the row-wise ramp filter It looks like there is a directional > dependency. My assumption is, and with respect to fourier slice theorem, > that the missing object > > rotation (rotation around itself) causes there directional effects. > > > > So my questions to the experts are. Do I need to apply a special filtering > before backprojecting with FDK or is it just the wrong > > algorithm for this kind of trajectory ? > > > > kind regards, > > Robert C. > > > > _______________________________________________ > > 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 Oct 18 10:41:58 2017 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 18 Oct 2017 16:41:58 +0200 Subject: [Rtk-users] RTK training - Monday November 27 Message-ID: Dear RTK users, We will organize a new training session on November 27 2017 at the Centre L?on B?rard in Lyon, from 9:30 am to 5:30 pm. We organize it ourselves so it's free and you can just send me an email if you want to participate. The training is for both users and developers. We are happy to answer any question that you might have. I'm looking forward to meeting you at the training, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathis.hoffmann at fau.de Mon Oct 23 06:55:57 2017 From: mathis.hoffmann at fau.de (mathis.hoffmann at fau.de) Date: Mon, 23 Oct 2017 12:55:57 +0200 Subject: [Rtk-users] Issue with projection matrices Message-ID: <85a00588d96a883b4b700dad4bfc9047@fau.de> Hello, I'm using the Python3 interface of RTK (current RTK master, built from source) and try to set up a simple reconstrucion pipeline. Unfortunately I fail in adding projection matrices to ThreeDCircularProjectionGeometry. Here is a simple example that demonstrates the problem: import numpy as np import SimpleRTK as rtk geom = rtk.ThreeDCircularProjectionGeometry() m = np.array( [[ -3.40666667e-01, 2.00000000e+00, 0.00000000e+00, 2.55500000e+02], [ -3.40666667e-01, 0.00000000e+00, 2.00000000e+00, 2.55500000e+02], [ -1.33333330e-03, 0.00000000e+00, 0.00000000e+00, 1.00000000e+00]] ) geom.AddProjection( m.flatten() ) I get "Failed to AddProjection" from RTK with no further information. To make sure that the projection matrix is correctly passed to RTK, I printed pMat in code/ThreeDCircularProjectionGeometry::AddProjection to the command line. This is passed correctly. I don't know what is wrong with my projection matrix (and also tried another one from a different dataset). Does anyone have an idea? Thanks in advance for any hints! Mathis Hoffmann From Robert.Calliess at gmx.de Tue Oct 24 09:58:30 2017 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 24 Oct 2017 15:58:30 +0200 Subject: [Rtk-users] FDK for planar ct In-Reply-To: References: <002101d341c8$04b34b00$0e19e100$@gmx.de> <52555187-df4b-6432-20c6-638aa0f25988@creatis.insa-lyon.fr> <004001d341f2$a2ce0c60$e86a2520$@gmx.de> <004501d342c2$e8bebfa0$ba3c3ee0$@gmx.de> Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: planar_ct_1.png Type: image/png Size: 31371 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 24 10:47:40 2017 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 24 Oct 2017 16:47:40 +0200 Subject: [Rtk-users] FDK for planar ct In-Reply-To: References: <002101d341c8$04b34b00$0e19e100$@gmx.de> <52555187-df4b-6432-20c6-638aa0f25988@creatis.insa-lyon.fr> <004001d341f2$a2ce0c60$e86a2520$@gmx.de> <004501d342c2$e8bebfa0$ba3c3ee0$@gmx.de> Message-ID: Hi, I see one drawing only, not two. And the object does not seem to be moving on your drawing, is it? If not and the source is also static (as it seem), this is equivalent to one large projection. Simon On Tue, Oct 24, 2017 at 3:58 PM, "Robert Callie?" wrote: > Hello, > I suppose there are still misunderstandings with respect to the trajectory. > Attached you can find the two difference trajectories. I also had a closer > look to > the off centered fdk ( the paper you suggested). But I don't think it is > in my case. > The iso ray passes object center and detector center at each view. Off > centered fdk > has a different preweighting scheme. > > You said that the RTK ramp filter is along the u axis (orthogonal to > rotaion axis). For planar_ct_1 trajectory that > should fit. As you can see at the picture, the object is moving on a > circular path but not rotating around the > center point (red cross in the image). > > > Kind regards, > Robert C. > > *Gesendet:* Donnerstag, 12. Oktober 2017 um 07:14 Uhr > *Von:* "Simon Rit" > *An:* "Robert Calliess" > *Cc:* "rtk-users at public.kitware.com" > > *Betreff:* Re: [Rtk-users] FDK for planar ct > Hello, > No. The filter should be orthogonal to the rotation axis. The RTK ramp > filter is along the u axis of the projection. > Trajectory 2: if you take photos by rotating the cameras, they are > photographies of the same point-of-view. This is what I meant. > Cheers, > Simon > > On Wed, Oct 11, 2017 at 8:58 PM, Robert Calliess > wrote: >> >> Hello, >> >> thanks for the link to the paper but I dont have access to it. Aside from >> how the trajectory is interpreted within in RTK. My actual question was >> >> if any of those two trajectories would need another reconstruction filter >> than the FDK Filter. From my point of understanding a specific rotation >> around >> >> the object is necessary for fbp/fdk (like c-arm bow, standard circular >> cone-beam trajectory). That?s why I asked If the first trajectory needs >> some other reconstruction >> >> filter because the object itself doesn?t rotate around itself. It >> actually gets translated on a circular path. So I was more expecting a >> ?yes? or ?no? to the fdk filter >> >> or a hint to another filter (except iterative reconstructions) I should >> use for these trajectories. >> >> >> >> To trajectory 2: I think the projections are different. The object >> rotates and each projection shows a different view. >> >> >> >> >> >> Kind regards, >> >> Robert C. >> >> >> >> *Von:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *Im Auftrag von *Simon >> Rit >> *Gesendet:* Dienstag, 10. Oktober 2017 20:29 >> *An:* Robert Calliess >> >> *Cc:* Cyril Mory; rtk-users at public.kitware.com >> *Betreff:* Re: [Rtk-users] FDK for planar ct >> >> >> >> >> >> Hi, >> >> Let me try to clarify what I mean by "source trajectory wrt the object." >> In tomography, you need to determine the source trajectory in the object >> coordinate system, we don't really care about the source trajectory in the >> room coordinate system. For example, rotating the source on a circular >> trajectory or rotating the object makes no difference for the >> reconstruction algorithm. That's why we call diagnostic scanners "helical >> scanners". >> >> So for trajectory 1, it seems that the source trajectory (again, wrt to >> the object) is a circle but the object is offset. This is somewhat similar >> to https://doi.org/10.1109/TNS.2006.880977 except that the detector is >> not tilted so FDK would be the only FBP algorithm I could think of. But the >> situation is really not good, data are missing and iterative reconstruction >> should give better results. >> >> Trajectory 2: what I said in my previous email is true, it's useless I >> believe, all projections are similar up to a 2D transform of the projection. >> >> Simon >> >> >> >> On Tue, Oct 10, 2017 at 8:07 PM, Robert Calliess >> wrote: >> >> Hello, >> >> I try to clarify the both trajectories. >> >> >> >> Trajectory 1: >> >> No, i dont move the source on two circles. The xray source is fixed. Only >> the object and the detector moves. Both move on a circular path so that the >> iso-ray >> >> always passes through the pcb centre and the detector centre. There is >> one orthogonal view and the others are the ones moving on the circular >> path. >> >> (Object is not rotating around its own axis). >> >> >> >> Trajectory 2: >> >> Yes, the xray source lies in the rotation axis and only the object >> rotates around its z-axis. Detector and xray source are fixed and the >> detector is tilted. >> >> It?s almost like this trajectory here https://www.ikeda-shoponline. >> com/engctsoft/wp-content/uploads/2016/06/Oblique-View-CT1.jpg >> >> except that the xray source lies on the rotation axis. >> >> >> >> I hope this helps to understand the trajectories I have to deal with. >> >> >> >> Kind regards, >> >> Robert >> >> >> >> >> >> *Von:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *Im Auftrag von *Simon >> Rit >> *Gese**ndet:* Dienstag, 10. Oktober 2017 19:06 >> *An:* Robert Callie? >> *Cc:* Cyril Mory; rtk-users at public.kitware.com >> >> >> *Betreff:* Re: [Rtk-users] FDK for planar ct >> >> >> >> Hi, >> >> It's still not clear to me but what is helpful is to think in terms of >> source trajectory wrt the object. >> >> Trajectory 1: if I understand, you move the source on two circles plus >> one point. I don't know of a FBP algorithm to reconstruct this, but there >> might be one. I would consider iterative reconstruction first. >> >> Trajectory 2: your trajectory is a point, the source does not move with >> respect ot the object since it lies on the rotation axis. So each >> projection contains exactly the same information up to a simple 2D >> projection deformation. So it's hopeless to reconstruct from one projection >> only. >> >> To create the correct geometry, I would suggest using the function >> AddProjection >> >> for which you provide the source and detector positions plus the 3D >> coordinates of the two axes of the coordinate system of the projection. >> >> I hope this helps >> >> Simon >> >> >> >> On Tue, Oct 10, 2017 at 5:43 PM, "Robert Callie?" >> wrote: >> >> Hello, >> >> thank you for the fast reply. >> >> To answer your questions first. >> >> In this case the abbrevation pcb stands for printed circuit board. >> >> Next point is the trajectory we are currently handling with. >> >> Please see the attached image "trajectory.png". There are two schematics >> showing the side view and top view for trajectory type 1 >> >> and a side-view for trajectory type 2. >> >> >> >> For type 1: >> >> The xray source is fixed. The pcb is clamped within a transport, so the >> pcb and the detector are moveable with in the xy plane. >> >> As you can see at the image, the pcb moves along a circular path but the >> pcb itself is not rotating. And let's assume that the iso ray >> >> always passes through the centre of the pcb and the centre of the >> detector. >> >> >> >> For type 2: >> >> The xray source is fixed and the detector is tilted. The pcb lies centred >> in the middle of a table. So that the pcb rotates around its centre >> >> around the z-axis. >> >> >> >> >> >> I hope this makes clear what trajectory i'm dealing with. Thank you. >> >> >> >> Kind regards, >> >> Robert C. >> >> >> >> >> >> >> >> >> >> >> >> >> >> *Gesendet:* Dienstag, 10. Oktober 2017 um 15:31 Uhr >> *Von:* "Cyril Mory" >> *An:* "Robert Calliess" , >> rtk-users at public.kitware.com >> *Betreff:* Re: [Rtk-users] FDK for planar ct >> >> Dear Robert, >> >> Your description of the trajectory is very obscure to me. Maybe you have >> a very unusual X-ray system. Could you make the following points clear : >> >> - what is a PCB ? >> >> - what is fixed/moving in your system (we need this information for the >> object, the source and the detector), and what kind of trajectories have >> the moving parts ? >> >> - can you re-draw your sketch with just 2 or 3 positions (ideally, on >> similar but separate drawings), each one with the object, the source and >> the detector ? >> >> If you do that, we should have a clear understanding of how your >> acquisition goes, and be able to give you appropriate advice. >> >> Best regards, >> >> Cyril >> >> >> >> On 10/10/2017 15:02, Robert Calliess wrote: >> >> Hello rtk users, >> >> I have question to the RTK FDK Filter. As far as I understand from to the >> fourier slice theorem the object to be reconstructed needs a circular >> trajectory and needs to rotate its own centre. >> >> Please have a look at the attached sketch. With this planar trajectory >> (Object, a PCB, is moved on a circle trajectpry ?in-plane?, PCB itself is >> not rotating) do I need >> >> a special filtering if I want to use FDK for planar CT with respect to >> the sketched trajectory ? I tried a circular in-plane trajectory where the >> PCB is centred and rotates >> >> around its centre point. And with 100 projections I get good results. But >> with the trajectory I described (sketch, attached image) the results are >> not so good. >> >> Because of the row-wise ramp filter It looks like there is a directional >> dependency. My assumption is, and with respect to fourier slice theorem, >> that the missing object >> >> rotation (rotation around itself) causes there directional effects. >> >> >> >> So my questions to the experts are. Do I need to apply a special >> filtering before backprojecting with FDK or is it just the wrong >> >> algorithm for this kind of trajectory ? >> >> >> >> kind regards, >> >> Robert C. >> >> >> >> _______________________________________________ >> >> 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 Oct 25 03:03:29 2017 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Wed, 25 Oct 2017 09:03:29 +0200 Subject: [Rtk-users] FDK for planar ct In-Reply-To: References: <002101d341c8$04b34b00$0e19e100$@gmx.de> <52555187-df4b-6432-20c6-638aa0f25988@creatis.insa-lyon.fr> <004001d341f2$a2ce0c60$e86a2520$@gmx.de> <004501d342c2$e8bebfa0$ba3c3ee0$@gmx.de> Message-ID: An HTML attachment was scrubbed... URL: From cyril.mory at creatis.insa-lyon.fr Wed Oct 25 03:34:04 2017 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Wed, 25 Oct 2017 09:34:04 +0200 Subject: [Rtk-users] FDK for planar ct In-Reply-To: References: <002101d341c8$04b34b00$0e19e100$@gmx.de> <52555187-df4b-6432-20c6-638aa0f25988@creatis.insa-lyon.fr> <004001d341f2$a2ce0c60$e86a2520$@gmx.de> <004501d342c2$e8bebfa0$ba3c3ee0$@gmx.de> Message-ID: Dear Robert, Could you send two datasets of projections, one for each case ? We would have a look at them and it would help us understand your trajectories. The drawings you sent do not seem to be sufficient to remove all ambiguities. Best regards, Cyril On 25/10/2017 09:03, "Robert Callie?" wrote: > Hello, > the object is moving on a circular path. There are arrows between the > different detector positions showing the > moving direction. The source is static. > Kind regards, > Robert > *Gesendet:*?Dienstag, 24. Oktober 2017 um 16:47 Uhr > *Von:*?"Simon Rit" > *An:*?"Robert Callie?" > *Cc:*?"rtk-users at public.kitware.com" > *Betreff:*?Re: Re: [Rtk-users] FDK for planar ct > Hi, > I see one drawing only, not two. And the object does not seem to be > moving on your drawing, is it? If not and the source is also static > (as it seem), this is equivalent to one large projection. > Simon > On Tue, Oct 24, 2017 at 3:58 PM, "Robert Callie?" > > wrote: > > Hello, > I suppose there are still misunderstandings with respect to the > trajectory. > Attached you can find the two difference trajectories. I also had > a closer look to > the off centered fdk ( the paper you suggested). But I don't think > it is in my case. > The iso ray passes object center and detector center at each view. > Off centered fdk > has a different preweighting scheme. > You said that the RTK ramp filter is along the u axis (orthogonal > to rotaion axis). For planar_ct_1 trajectory that > should fit. As you can see at the picture, the object is moving on > a circular path but not rotating around the > center point (red cross in the image). > Kind regards, > Robert C. > *Gesendet:*?Donnerstag, 12. Oktober 2017 um 07:14 Uhr > *Von:*?"Simon Rit" > > *An:*?"Robert Calliess" > > *Cc:*?"rtk-users at public.kitware.com > " > > > > *Betreff:*?Re: [Rtk-users] FDK for planar ct > Hello, > No. The filter should be orthogonal to the rotation axis.? The RTK > ramp filter is along the u axis of the projection. > Trajectory 2: if you take photos by rotating the cameras, they are > photographies of the same point-of-view. This is what I meant. > Cheers, > Simon > On Wed, Oct 11, 2017 at 8:58 PM, Robert Calliess > > wrote: > > Hello, > > thanks for the link to the paper but I dont have access to it. > Aside from how the trajectory is interpreted within in RTK. My > actual question was > > if any of those two trajectories would need another > reconstruction filter than the FDK Filter. From my point of > understanding a specific rotation around > > the object is necessary for fbp/fdk (like c-arm bow, standard > circular cone-beam trajectory).? That?s why I asked If the > first trajectory needs some other reconstruction > > filter because the object itself doesn?t rotate around itself. > It actually gets translated on a circular path. So I was more > expecting a ?yes? or ?no? to the fdk filter > > or a hint to another filter (except iterative reconstructions) > I should use for these trajectories. > > To trajectory 2: I think the projections are different. The > object rotates and each projection shows a different view. > > Kind regards, > > Robert C. > > *Von:*simon.rit at gmail.com > [mailto:simon.rit at gmail.com ] *Im > Auftrag von *Simon Rit > *Gesendet:* Dienstag, 10. Oktober 2017 20:29 > *An:* Robert Calliess > > > *Cc:* Cyril Mory; rtk-users at public.kitware.com > > *Betreff:* Re: [Rtk-users] FDK for planar ct > > Hi, > > Let me try to clarify what I mean by "source trajectory wrt > the object." In tomography, you need to determine the source > trajectory in the object coordinate system, we don't really > care about the source trajectory in the room coordinate > system. For example, rotating the source on a circular > trajectory or rotating the object makes no difference for the > reconstruction algorithm. That's why we call diagnostic > scanners "helical scanners". > > So for trajectory 1, it seems that the source trajectory > (again, wrt to the object) is a circle but the object is > offset. This is somewhat similar to > https://doi.org/10.1109/TNS.2006.880977 except that the > detector is not tilted so FDK would be the only FBP algorithm > I could think of. But the situation is really not good, data > are missing and iterative reconstruction should give better > results. > > Trajectory 2: what I said in my previous email is true, it's > useless I believe, all projections are similar up to a 2D > transform of the projection. > > Simon > > On Tue, Oct 10, 2017 at 8:07 PM, Robert Calliess > > wrote: > > Hello, > > I try to clarify the both trajectories. > > Trajectory 1: > > No, i dont move the source on two circles. The xray source is > fixed. Only the object and the detector moves. Both move on a > circular path so that the iso-ray > > always passes through the pcb centre and the detector centre. > There is one orthogonal view and the others are the ones > moving on the circular path. > > (Object is not rotating around its own axis). > > Trajectory 2: > > Yes, the xray source lies in the rotation axis and only the > object rotates around its z-axis. Detector and xray source are > fixed and the detector is tilted. > > It?s almost like this trajectory here > https://www.ikeda-shoponline.com/engctsoft/wp-content/uploads/2016/06/Oblique-View-CT1.jpg > > except that the xray source lies on the rotation axis. > > I hope this helps to understand the trajectories I have to > deal with. > > Kind regards, > > Robert > > *Von:*simon.rit at gmail.com > [mailto:simon.rit at gmail.com ] *Im > Auftrag von *Simon Rit > *Gese**ndet:*Dienstag, 10. Oktober 2017 19:06 > *An:* Robert Callie? > *Cc:* Cyril Mory; rtk-users at public.kitware.com > > > > *Betreff:* Re: [Rtk-users] FDK for planar ct > > Hi, > > It's still not clear to me but what is helpful is to think in > terms of source trajectory wrt the object. > > Trajectory 1: if I understand, you move the source on two > circles plus one point. I don't know of a FBP algorithm to > reconstruct this, but there might be one. I would consider > iterative reconstruction first. > > Trajectory 2: your trajectory is a point, the source does not > move with respect ot the object since it lies on the rotation > axis. So each projection contains exactly the same information > up to a simple 2D projection deformation. So it's hopeless to > reconstruct from one projection only. > > To create the correct geometry, I would suggest using the > function AddProjection > > for which you provide the source and detector positions plus > the 3D coordinates of the two axes of the coordinate system of > the projection. > > I hope this helps > > Simon > > On Tue, Oct 10, 2017 at 5:43 PM, "Robert Callie?" > > wrote: > > Hello, > > thank you for the fast reply. > > To answer your questions first. > > In this case the abbrevation pcb stands for printed circuit board. > > Next point is the trajectory we are currently handling with. > > Please see the attached image "trajectory.png". There are two > schematics showing the side view and top view for trajectory > type 1 > > and a side-view for trajectory type 2. > > For type 1: > > The xray source is fixed. The pcb is clamped within a > transport, so the pcb and the detector are moveable with in > the xy plane. > > As you can see at the image, the pcb moves?along a?circular > path but the pcb itself is not rotating. And let's assume that > the iso ray > > always passes through the centre of the pcb and the centre of > the detector. > > For type 2: > > The xray source is fixed and the detector is tilted. The pcb > lies centred in the middle of a table. So that the pcb rotates > around its centre > > around the z-axis. > > I hope this makes clear what trajectory i'm dealing with. > Thank you. > > Kind regards, > > Robert C. > > *Gesendet:*?Dienstag, 10. Oktober 2017 um 15:31 Uhr > *Von:*?"Cyril Mory" > > *An:*?"Robert Calliess" >, rtk-users at public.kitware.com > > *Betreff:*?Re: [Rtk-users] FDK for planar ct > > Dear Robert, > > Your description of the trajectory is very obscure to me. > Maybe you have a very unusual X-ray system. Could you make the > following points clear : > > - what is a PCB ? > > - what is fixed/moving in your system (we need this > information for the object, the source and the detector), and > what kind of trajectories have the moving parts ? > > - can you re-draw your sketch with just 2 or 3 positions > (ideally, on similar but separate drawings), each one with the > object, the source and the detector ? > > If you do that, we should have a clear understanding of how > your acquisition goes, and be able to give you appropriate advice. > > Best regards, > > Cyril > > On 10/10/2017 15:02, Robert Calliess wrote: > > Hello rtk users, > > I have question to the RTK FDK Filter. As far as I > understand from to the fourier slice theorem the object to > be reconstructed needs a circular trajectory and needs to > rotate its own centre. > > Please have a look at the attached sketch. With this > planar trajectory (Object, a PCB, is moved on a circle > trajectpry ??in-plane?, PCB itself is not rotating) do I need > > a special filtering if I want to use FDK for planar CT > with respect to the sketched trajectory ? I tried a > circular in-plane trajectory where the PCB is centred and > rotates > > around its centre point. And with 100 projections I get > good results. But with the trajectory I described (sketch, > attached image) the results are not so good. > > Because of the row-wise ramp filter It looks like there is > a directional dependency. My assumption is, and with > respect to fourier slice theorem, that the missing object > > rotation (rotation around itself) causes there directional > effects. > > So my questions to the experts are. Do I need to apply a > special filtering before backprojecting with FDK or is it > just the wrong > > algorithm for this kind of trajectory ? > > kind regards, > > Robert C. > > _______________________________________________ > > 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 > > > > _______________________________________________ > 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 fredrik.hellman at gmail.com Wed Oct 25 08:15:33 2017 From: fredrik.hellman at gmail.com (Fredrik Hellman) Date: Wed, 25 Oct 2017 14:15:33 +0200 Subject: [Rtk-users] rtkThreeDCircularProjectionGeometry cannot be cloned Message-ID: Hi, I would like to clone a geometry object, but it does not seem to be possible. Is this the expected behaviour or a bug? The code below prints 1 0 i.e. the two geometry objects (seemingly clones) have different number of projections. Code: #include #include int main(int argc, char *argv[]) { rtk::ThreeDCircularProjectionGeometry::Pointer geometry = rtk::ThreeDCircularProjectionGeometry::New(); double sourceToIsocenterDistance = 1; double sourceToDetectorDistance = 1; double gantryAngleInDegrees = 0; geometry->AddProjection(sourceToIsocenterDistance, sourceToDetectorDistance, gantryAngleInDegrees); rtk::ThreeDCircularProjectionGeometry::Pointer geometryClone = geometry->Clone(); std::cout << geometry->GetGantryAngles().size() << std::endl; std::cout << geometryClone->GetGantryAngles().size() << std::endl; return 0; } Best regards, Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Oct 25 12:03:15 2017 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 25 Oct 2017 18:03:15 +0200 Subject: [Rtk-users] rtkThreeDCircularProjectionGeometry cannot be cloned In-Reply-To: References: Message-ID: Dear Fredrik, Thanks for the report. I actually never use this function. I checked and I have a similar behavior with itk::Image: #include "itkImage.h" int main(int argc, char *argv[]) { typedef float PixelType; const unsigned int Dimension = 3; typedef itk::Image< PixelType, Dimension > ImageType; ImageType::Pointer img = ImageType::New(); ImageType::RegionType reg; reg.SetSize(0,128); reg.SetSize(1,128); reg.SetSize(2,128); img->SetRegions(reg); img->Allocate(); img->Print(std::cout); ImageType::Pointer imgClone = img->Clone(); imgClone->Print(std::cout); return 0; } The standard output shows that the two images are of the same type but don't contain the same members, e.g., not the same region. It seems that copying an image is done using the Copy function in ImageAlgorithms. If we want to change the behavior for the geometry object, we need to re-implement InternalClone() . Are you used to use the Clone function in ITK? BTW, I wonder why would one want to do a clone of a geometry but we can probably implement it if it is useful for you. Best regards, Simon On Wed, Oct 25, 2017 at 2:15 PM, Fredrik Hellman wrote: > Hi, > > I would like to clone a geometry object, but it does not seem to be > possible. Is this the expected behaviour or a bug? > > The code below prints > > 1 > 0 > > i.e. the two geometry objects (seemingly clones) have different number of > projections. > > Code: > > #include > #include > > int main(int argc, char *argv[]) > { > rtk::ThreeDCircularProjectionGeometry::Pointer geometry = rtk:: > ThreeDCircularProjectionGeometry::New(); > > double sourceToIsocenterDistance = 1; > double sourceToDetectorDistance = 1; > double gantryAngleInDegrees = 0; > geometry->AddProjection(sourceToIsocenterDistance, > sourceToDetectorDistance, > gantryAngleInDegrees); > > rtk::ThreeDCircularProjectionGeometry::Pointer geometryClone = > geometry->Clone(); > > std::cout << geometry->GetGantryAngles().size() << std::endl; > std::cout << geometryClone->GetGantryAngles().size() << std::endl; > > return 0; > } > > Best regards, > Fredrik > > _______________________________________________ > 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 fredrik.hellman at gmail.com Thu Oct 26 05:14:53 2017 From: fredrik.hellman at gmail.com (Fredrik Hellman) Date: Thu, 26 Oct 2017 11:14:53 +0200 Subject: [Rtk-users] rtkThreeDCircularProjectionGeometry cannot be cloned In-Reply-To: References: Message-ID: Dear Simon, No, I can't say I have used the Clone function before. I am writing a geometry converter class that takes ThreeDCircularProjectionGeometry through a setter-function. The converter is supposed to give detector positions etc. on demand in a different coordinate system. I need to determine what behavior I want of this converter: 1. Either the converter tracks the ThreeDCircularProjectionGeometry object with a smart pointer. All changes in the geometry by the caller so the setter is reflected in the converter. 2. Or the object is cloned and the converter will reflect the object as it was when it was set, regardless of any changes done to it by the caller. Actually, I think I can do with behavior 1. However, as it is now, I don't think I have possibility to implement behavior 2 at all. Best regards, Fredrik 2017-10-25 18:03 GMT+02:00 Simon Rit : > Dear Fredrik, > Thanks for the report. I actually never use this function. I checked and I > have a similar behavior with itk::Image: > > #include "itkImage.h" > > int main(int argc, char *argv[]) > { > typedef float PixelType; > const unsigned int Dimension = 3; > typedef itk::Image< PixelType, Dimension > ImageType; > > ImageType::Pointer img = ImageType::New(); > ImageType::RegionType reg; > reg.SetSize(0,128); > reg.SetSize(1,128); > reg.SetSize(2,128); > img->SetRegions(reg); > img->Allocate(); > img->Print(std::cout); > ImageType::Pointer imgClone = img->Clone(); > imgClone->Print(std::cout); > return 0; > } > > The standard output shows that the two images are of the same type but > don't contain the same members, e.g., not the same region. It seems that > copying an image is done using the Copy function in ImageAlgorithms. > If we want to change the behavior for the geometry object, we need to > re-implement InternalClone() > . > Are you used to use the Clone function in ITK? > BTW, I wonder why would one want to do a clone of a geometry but we can > probably implement it if it is useful for you. > Best regards, > Simon > > On Wed, Oct 25, 2017 at 2:15 PM, Fredrik Hellman < > fredrik.hellman at gmail.com> wrote: > >> Hi, >> >> I would like to clone a geometry object, but it does not seem to be >> possible. Is this the expected behaviour or a bug? >> >> The code below prints >> >> 1 >> 0 >> >> i.e. the two geometry objects (seemingly clones) have different number of >> projections. >> >> Code: >> >> #include >> #include >> >> int main(int argc, char *argv[]) >> { >> rtk::ThreeDCircularProjectionGeometry::Pointer geometry = >> rtk::ThreeDCircularProjectionGeometry::New(); >> >> double sourceToIsocenterDistance = 1; >> double sourceToDetectorDistance = 1; >> double gantryAngleInDegrees = 0; >> geometry->AddProjection(sourceToIsocenterDistance, >> sourceToDetectorDistance, >> gantryAngleInDegrees); >> >> rtk::ThreeDCircularProjectionGeometry::Pointer geometryClone = >> geometry->Clone(); >> >> std::cout << geometry->GetGantryAngles().size() << std::endl; >> std::cout << geometryClone->GetGantryAngles().size() << std::endl; >> >> return 0; >> } >> >> Best regards, >> Fredrik >> >> _______________________________________________ >> 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 mathis.hoffmann at fau.de Thu Oct 26 06:24:48 2017 From: mathis.hoffmann at fau.de (mathis.hoffmann at fau.de) Date: Thu, 26 Oct 2017 12:24:48 +0200 Subject: [Rtk-users] Simple FDK reconstruction using SimpleRTK does not work Message-ID: <133ba66caeffc08c10d420878880d25a@fau.de> Hello, we currently try to set up a simple FDK reconstruction pipeline using SimpleRTK for research purposes. We have projections from a simulated Forbild phantom and the corresponding projection matrices. We can reconstruct the same data trouble-free using our internal tools. However, we fail to do so using SimpleRTK. We provide the data including a minimal example that demonstrates the problem here: https://www.dropbox.com/sh/8fqhyvcnzb5u8zd/AAAYLQ50_3GIoTSMli5nmtYca?dl=0 Could someone please have a look on the problem? We have tried for a long time now. The relevant geometry parameters (which are also set in the script) are: Detector offset in u/v direction: 255.5/255.5 Pixel sizes u/v: 0.8/0.8 Size of projections: 512x512 Size of volume: 512x512x512 Voxel sizes x/y/z: 0.5/0.5/0.5 Midpoint of volume: 0/0/0 Thank you in advance for any help! Mathis Hoffmann From simon.rit at creatis.insa-lyon.fr Thu Oct 26 11:23:17 2017 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Oct 2017 17:23:17 +0200 Subject: [Rtk-users] Simple FDK reconstruction using SimpleRTK does not work In-Reply-To: <133ba66caeffc08c10d420878880d25a@fau.de> References: <133ba66caeffc08c10d420878880d25a@fau.de> Message-ID: Dear Mathis, Sorry to hear about your difficulties. You use AddProjection with a matrix which, internally, converts your projection matrix to parameters that are used in the FDK reconstruction. After writing down the produced geometry, it turns out that you rotate around Z where RTK works in FDK if you rotate around Y (see geometry.pdf) . Two solutions: - start with an iterative algorithm (conjugate gradient) for which there is no geometry constraint, - change the projection matrix to rotate around Y. I have done the second thing and reconstructed one slice only (on my laptop). I noticed that there is a projection offset in the geometry, so it seems that your projection matrix assumes that the coordinate (0,0) is at the corner of the projection. You don't need to set the origin then. Your reconstructed volume was also off-centered. Maybe you need to check the ITK software guide to understand the origin concept. I obtained a more decent results with the enclosed scripts but I let you do some checks on a large volume. In particular, if the object size is not right, it might be because your projection matrix converts 3D positions in mm to 2D positions in pixel instead of mm. In this case, you need to multiply the projection matrix m by a 3x3 scaling matrix s (m=s*m) to convert pixel coordinates to mm coordinates. I hope this helps, Simon PS: if you want to make FDK work with any circular trajectory, I'm interested but this is a lot more work. On Thu, Oct 26, 2017 at 12:24 PM, wrote: > Hello, > > we currently try to set up a simple FDK reconstruction pipeline using > SimpleRTK for research purposes. We have projections from a simulated > Forbild phantom and the corresponding projection matrices. We can > reconstruct the same data trouble-free using our internal tools. However, > we fail to do so using SimpleRTK. We provide the data including a minimal > example that demonstrates the problem here: https://www.dropbox.com/sh/8fq > hyvcnzb5u8zd/AAAYLQ50_3GIoTSMli5nmtYca?dl=0 > > Could someone please have a look on the problem? We have tried for a long > time now. The relevant geometry parameters (which are also set in the > script) are: > Detector offset in u/v direction: 255.5/255.5 > Pixel sizes u/v: 0.8/0.8 > Size of projections: 512x512 > Size of volume: 512x512x512 > Voxel sizes x/y/z: 0.5/0.5/0.5 > Midpoint of volume: 0/0/0 > > Thank you in advance for any help! > > Mathis Hoffmann > _______________________________________________ > 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: minimal.py Type: text/x-python-script Size: 1207 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Oct 26 16:11:10 2017 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Oct 2017 22:11:10 +0200 Subject: [Rtk-users] rtkThreeDCircularProjectionGeometry cannot be cloned In-Reply-To: References: Message-ID: Hi, I have pushed a fix to a new branch: https://github.com/SimonRit/RTK/commit/f5249c900a8776dfb3a8a6243a41a2396eb5c134 I'll merge it to master tomorrow if all test pass. Best regards, Simon On Thu, Oct 26, 2017 at 11:14 AM, Fredrik Hellman wrote: > Dear Simon, > > No, I can't say I have used the Clone function before. I am writing a > geometry converter class that takes ThreeDCircularProjectionGeometry > through a setter-function. The converter is supposed to give detector > positions etc. on demand in a different coordinate system. > > I need to determine what behavior I want of this converter: > > 1. Either the converter tracks the ThreeDCircularProjectionGeometry > object with a smart pointer. All changes in the geometry by the caller so > the setter is reflected in the converter. > 2. Or the object is cloned and the converter will reflect the object as it > was when it was set, regardless of any changes done to it by the caller. > > Actually, I think I can do with behavior 1. However, as it is now, I don't > think I have possibility to implement behavior 2 at all. > > Best regards, > Fredrik > > 2017-10-25 18:03 GMT+02:00 Simon Rit : > >> Dear Fredrik, >> Thanks for the report. I actually never use this function. I checked and >> I have a similar behavior with itk::Image: >> >> #include "itkImage.h" >> >> int main(int argc, char *argv[]) >> { >> typedef float PixelType; >> const unsigned int Dimension = 3; >> typedef itk::Image< PixelType, Dimension > ImageType; >> >> ImageType::Pointer img = ImageType::New(); >> ImageType::RegionType reg; >> reg.SetSize(0,128); >> reg.SetSize(1,128); >> reg.SetSize(2,128); >> img->SetRegions(reg); >> img->Allocate(); >> img->Print(std::cout); >> ImageType::Pointer imgClone = img->Clone(); >> imgClone->Print(std::cout); >> return 0; >> } >> >> The standard output shows that the two images are of the same type but >> don't contain the same members, e.g., not the same region. It seems that >> copying an image is done using the Copy function in ImageAlgorithms. >> If we want to change the behavior for the geometry object, we need to >> re-implement InternalClone() >> . >> Are you used to use the Clone function in ITK? >> BTW, I wonder why would one want to do a clone of a geometry but we can >> probably implement it if it is useful for you. >> Best regards, >> Simon >> >> On Wed, Oct 25, 2017 at 2:15 PM, Fredrik Hellman < >> fredrik.hellman at gmail.com> wrote: >> >>> Hi, >>> >>> I would like to clone a geometry object, but it does not seem to be >>> possible. Is this the expected behaviour or a bug? >>> >>> The code below prints >>> >>> 1 >>> 0 >>> >>> i.e. the two geometry objects (seemingly clones) have different number >>> of projections. >>> >>> Code: >>> >>> #include >>> #include >>> >>> int main(int argc, char *argv[]) >>> { >>> rtk::ThreeDCircularProjectionGeometry::Pointer geometry = >>> rtk::ThreeDCircularProjectionGeometry::New(); >>> >>> double sourceToIsocenterDistance = 1; >>> double sourceToDetectorDistance = 1; >>> double gantryAngleInDegrees = 0; >>> geometry->AddProjection(sourceToIsocenterDistance, >>> sourceToDetectorDistance, >>> gantryAngleInDegrees); >>> >>> rtk::ThreeDCircularProjectionGeometry::Pointer geometryClone = >>> geometry->Clone(); >>> >>> std::cout << geometry->GetGantryAngles().size() << std::endl; >>> std::cout << geometryClone->GetGantryAngles().size() << std::endl; >>> >>> return 0; >>> } >>> >>> Best regards, >>> Fredrik >>> >>> _______________________________________________ >>> 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: