From robert.calliess at gmx.de Wed Nov 1 05:22:58 2017 From: robert.calliess at gmx.de (Robert Calliess) Date: Wed, 1 Nov 2017 10:22:58 +0100 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: <001501d352f3$0215a5a0$0640f0e0$@gmx.de> Hello, i?ve uploaded the projection images for the first trajectory. https://www.dropbox.com/s/rpcyemuvfngd4rw/QFN1.7z?dl=0 Inside the folder you can find the projection images. Furthermore you will find two textfiles, positions.txt and calibration.txt. The positions.txt contains the physical position of the detector center. Position id 35 is the orthogonal view. All other projection ids are positions on a circular path around the center position 35. The calibration.txt contains the fod, odd and the physical detector size. All units given are in micrometers. Kind regards, Robert Von: Cyril Mory [mailto:cyril.mory at creatis.insa-lyon.fr] Gesendet: Mittwoch, 25. Oktober 2017 09:34 An: Robert Callie? Cc: rtk-users at public.kitware.com Betreff: Re: [Rtk-users] FDK for planar ct 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 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 _______________________________________________ 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 Nov 8 02:27:50 2017 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 8 Nov 2017 08:27:50 +0100 Subject: [Rtk-users] Error Issues about Building RTK In-Reply-To: References: Message-ID: Dear Daniel, Please send your questions to the mailing list. Regarding FFTW: yes, RTK works without FFTW. It then uses the (slow) implementation of the FFT in ITK. I know that some vendors use RTK without FFTW but with CUDA to enable fast reconstruction. There is one piece of software that won't work though (rtkHilbertImageFilter.hxx), which is used for respiratory signal extraction (for 4D CBCT). Regarding your build error: I think you should post the full log. If it cannot find rtkcuda.lib, it's probably because it did not manage to compile it? Best regards, Simon On Wed, Nov 8, 2017 at 5:42 AM, Daniel lee wrote: > Dear Simon, > > I`m just looking for the person who can give me advise about RTK. > > Could I ask you tiny things about RTK? or could I have to find another one? > > - I`d like to avoid GPL License. So is there any way to use RTK > without FFTW (for ITK)? > - When I build RTK itself there are build error ("LNK1104 '..\..\bin\Debug\rtkcuda.lib' > cannot open file"). Could you give me some tip for it? > > Sincerely > > K. Y. Daniel Lee > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From albert.murienne at thalesgroup.com Thu Nov 9 07:11:04 2017 From: albert.murienne at thalesgroup.com (MURIENNE Albert) Date: Thu, 9 Nov 2017 13:11:04 +0100 Subject: [Rtk-users] Reconstruction filter progress observer Message-ID: <3528F1E81E278E41BAD4B13A9B7A63610112F5541712@THSONEA01CMS02P.one.grp> Hello, Is there a simple code example available to illustrate the registration of an observer to be notified with the progression of rtk's reconstruction filters? Thanks in advance for your help, Regards -- Albert Murienne -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.mory at creatis.insa-lyon.fr Thu Nov 9 07:24:35 2017 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Thu, 9 Nov 2017 13:24:35 +0100 Subject: [Rtk-users] Reconstruction filter progress observer In-Reply-To: <3528F1E81E278E41BAD4B13A9B7A63610112F5541712@THSONEA01CMS02P.one.grp> References: <3528F1E81E278E41BAD4B13A9B7A63610112F5541712@THSONEA01CMS02P.one.grp> Message-ID: <5464a053-3ef9-1e50-0299-41a0dc220883@creatis.insa-lyon.fr> Hello, I am not sure I understand. Are you trying to know, during runtime, which filter is currently being updated ? Otherwise, can you reformulate your question (possibly with more context) ? Best, Cyril On 09/11/2017 13:11, MURIENNE Albert wrote: > > Hello, > > Is there a simple code example available to illustrate the > registration of an observer to be notified with the progression of > rtk?s reconstruction filters? > > Thanks in advance for your help, > > Regards > > -- > > Albert Murienne > > > > _______________________________________________ > 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 albert.murienne at thalesgroup.com Thu Nov 9 07:27:26 2017 From: albert.murienne at thalesgroup.com (MURIENNE Albert) Date: Thu, 9 Nov 2017 13:27:26 +0100 Subject: [Rtk-users] Reconstruction filter progress observer In-Reply-To: <5464a053-3ef9-1e50-0299-41a0dc220883@creatis.insa-lyon.fr> References: <3528F1E81E278E41BAD4B13A9B7A63610112F5541712@THSONEA01CMS02P.one.grp> <5464a053-3ef9-1e50-0299-41a0dc220883@creatis.insa-lyon.fr> Message-ID: <3528F1E81E278E41BAD4B13A9B7A63610112F554175D@THSONEA01CMS02P.one.grp> Cyril, to be more precise : if I run a long time reconstruction, I want to be available to track progression of the computation (ie 0 to 1 floating index), to have an idea of how fast it is running, if we are close to the end and so on... Albert De : Cyril Mory [mailto:cyril.mory at creatis.insa-lyon.fr] Envoy? : jeudi 9 novembre 2017 13:25 ? : MURIENNE Albert; rtk-users at public.kitware.com Objet : Re: [Rtk-users] Reconstruction filter progress observer Hello, I am not sure I understand. Are you trying to know, during runtime, which filter is currently being updated ? Otherwise, can you reformulate your question (possibly with more context) ? Best, Cyril On 09/11/2017 13:11, MURIENNE Albert wrote: Hello, Is there a simple code example available to illustrate the registration of an observer to be notified with the progression of rtk's reconstruction filters? Thanks in advance for your help, Regards -- Albert Murienne _______________________________________________ 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 Nov 9 08:29:04 2017 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Nov 2017 14:29:04 +0100 Subject: [Rtk-users] Reconstruction filter progress observer In-Reply-To: <3528F1E81E278E41BAD4B13A9B7A63610112F554175D@THSONEA01CMS02P.one.grp> References: <3528F1E81E278E41BAD4B13A9B7A63610112F5541712@THSONEA01CMS02P.one.grp> <5464a053-3ef9-1e50-0299-41a0dc220883@creatis.insa-lyon.fr> <3528F1E81E278E41BAD4B13A9B7A63610112F554175D@THSONEA01CMS02P.one.grp> Message-ID: Dear Albert, We have not implemented anything in this direction so far. But it would be useful to have it and I know there is a mechanism to do that in ITK Have you ever used it on your side? I think the idea is: - in the reconstruction filter, to create and regularly call a ProgressReporter , - where you want to observe the progress, you add an observer. There are many examples in ITK. If you want to do it, feel free to give it a try. If you need help, I'm happy to support your. I have created an issue in github to keep it in mind. Simon On Thu, Nov 9, 2017 at 1:27 PM, MURIENNE Albert < albert.murienne at thalesgroup.com> wrote: > Cyril, to be more precise : if I run a long time reconstruction, I want to > be available to track progression of the computation (ie 0 to 1 floating > index), to have an idea of how fast it is running, if we are close to the > end and so on? > > > > Albert > > > > *De :* Cyril Mory [mailto:cyril.mory at creatis.insa-lyon.fr] > *Envoy? :* jeudi 9 novembre 2017 13:25 > *? :* MURIENNE Albert; rtk-users at public.kitware.com > *Objet :* Re: [Rtk-users] Reconstruction filter progress observer > > > > Hello, > > I am not sure I understand. Are you trying to know, during runtime, which > filter is currently being updated ? > > Otherwise, can you reformulate your question (possibly with more context) > ? > > Best, > Cyril > > On 09/11/2017 13:11, MURIENNE Albert wrote: > > Hello, > > > > Is there a simple code example available to illustrate the registration of > an observer to be notified with the progression of rtk?s reconstruction > filters? > > > > Thanks in advance for your help, > > > > Regards > > > > -- > > > > Albert Murienne > > > > > _______________________________________________ > > 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 cyril.mory at creatis.insa-lyon.fr Thu Nov 9 08:34:26 2017 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Thu, 9 Nov 2017 14:34:26 +0100 Subject: [Rtk-users] Reconstruction filter progress observer In-Reply-To: References: <3528F1E81E278E41BAD4B13A9B7A63610112F5541712@THSONEA01CMS02P.one.grp> <5464a053-3ef9-1e50-0299-41a0dc220883@creatis.insa-lyon.fr> <3528F1E81E278E41BAD4B13A9B7A63610112F554175D@THSONEA01CMS02P.one.grp> Message-ID: <28b2a58e-13f2-2ab5-4edc-e59bc8d4607d@creatis.insa-lyon.fr> A few more sentences on this point: - Indeed, very few RTK filters currently perform progress reporting - For pipelines (instead of individual filters), you want to use that class: https://itk.org/Doxygen/html/classitk_1_1ProgressAccumulator.html. - Despite its name, "progress.CompletedPixel()" can be called after any meaningful step, not just the update of a pixel. On iterative filters, for example, http://www.cs.cmu.edu/~galeotti/methods_course/ITK_Filters2.pdf suggest thatProgressReporter can be initialized with the maximum number of iterations instead of with the total number of pixels to update, and progress.CompletedPixel() can be called at each iteration. So if you are reconstructing with an iterative reconstruction filter, you could start by trying to add a ProgressReporter to that class, and count its iterations. That's for the modifications to perform in the RTK code, it is probably just a few lines for the first test. Now, your question was about the existence of some code to observe the progress of a filter, assuming that filter does call the progress.CompletedPixel() adequately. You may want to check this ITK example: https://itk.org/Doxygen/html/SphinxExamples_2src_2Core_2Common_2ObserveAnEvent_2Code_8cxx-example.html I hope it helps, Cyril On 09/11/2017 14:29, Simon Rit wrote: > Dear Albert, > We have not implemented anything in this direction so far. But it > would be useful to have it and I know there is a mechanism to do that > in ITK Have you ever used it on your side? > I think the idea is: > - in the reconstruction filter, to create and regularly call a > ProgressReporter > , > - where you want to observe the progress, you add an observer. > There are many examples in ITK. If you want to do it, feel free to > give it a try. If you need help, I'm happy to support your. I have > created an issue in > github to keep it in mind. > Simon > > On Thu, Nov 9, 2017 at 1:27 PM, MURIENNE Albert > > wrote: > > Cyril, to be more precise?: if I run a long time reconstruction, I > want to be available to track progression of the computation (ie 0 > to 1 floating index), to have an idea of how fast it is running, > if we are close to the end and so on? > > Albert > > *De?:*Cyril Mory [mailto:cyril.mory at creatis.insa-lyon.fr > ] > *Envoy??:* jeudi 9 novembre 2017 13:25 > *??:* MURIENNE Albert; rtk-users at public.kitware.com > > *Objet?:* Re: [Rtk-users] Reconstruction filter progress observer > > Hello, > > I am not sure I understand. Are you trying to know, during > runtime, which filter is currently being updated ? > > Otherwise, can you reformulate your question (possibly with more > context) ? > > Best, > Cyril > > On 09/11/2017 13:11, MURIENNE Albert wrote: > > Hello, > > Is there a simple code example available to illustrate the > registration of an observer to be notified with the > progression of rtk?s reconstruction filters? > > Thanks in advance for your help, > > Regards > > -- > > Albert Murienne > > > > > _______________________________________________ > > 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 albert.murienne at thalesgroup.com Fri Nov 10 09:41:53 2017 From: albert.murienne at thalesgroup.com (MURIENNE Albert) Date: Fri, 10 Nov 2017 15:41:53 +0100 Subject: [Rtk-users] Reconstruction filter progress observer In-Reply-To: <28b2a58e-13f2-2ab5-4edc-e59bc8d4607d@creatis.insa-lyon.fr> References: <3528F1E81E278E41BAD4B13A9B7A63610112F5541712@THSONEA01CMS02P.one.grp> <5464a053-3ef9-1e50-0299-41a0dc220883@creatis.insa-lyon.fr> <3528F1E81E278E41BAD4B13A9B7A63610112F554175D@THSONEA01CMS02P.one.grp> <28b2a58e-13f2-2ab5-4edc-e59bc8d4607d@creatis.insa-lyon.fr> Message-ID: <3528F1E81E278E41BAD4B13A9B7A63610112F558C871@THSONEA01CMS02P.one.grp> Cyril, Simon, Thanks for your detailed answers. I?ll try to give a go with the FDK filter first, and I?ll keep you updated. Regards, Albert De : Cyril Mory [mailto:cyril.mory at creatis.insa-lyon.fr] Envoy? : jeudi 9 novembre 2017 14:34 ? : MURIENNE Albert Cc : rtk-users at public.kitware.com Objet : Re: [Rtk-users] Reconstruction filter progress observer A few more sentences on this point: - Indeed, very few RTK filters currently perform progress reporting - For pipelines (instead of individual filters), you want to use that class: https://itk.org/Doxygen/html/classitk_1_1ProgressAccumulator.html. - Despite its name, "progress.CompletedPixel()" can be called after any meaningful step, not just the update of a pixel. On iterative filters, for example, http://www.cs.cmu.edu/~galeotti/methods_course/ITK_Filters2.pdf suggest that ProgressReporter can be initialized with the maximum number of iterations instead of with the total number of pixels to update, and progress.CompletedPixel() can be called at each iteration. So if you are reconstructing with an iterative reconstruction filter, you could start by trying to add a ProgressReporter to that class, and count its iterations. That's for the modifications to perform in the RTK code, it is probably just a few lines for the first test. Now, your question was about the existence of some code to observe the progress of a filter, assuming that filter does call the progress.CompletedPixel() adequately. You may want to check this ITK example: https://itk.org/Doxygen/html/SphinxExamples_2src_2Core_2Common_2ObserveAnEvent_2Code_8cxx-example.html I hope it helps, Cyril On 09/11/2017 14:29, Simon Rit wrote: Dear Albert, We have not implemented anything in this direction so far. But it would be useful to have it and I know there is a mechanism to do that in ITK Have you ever used it on your side? I think the idea is: - in the reconstruction filter, to create and regularly call a ProgressReporter, - where you want to observe the progress, you add an observer. There are many examples in ITK. If you want to do it, feel free to give it a try. If you need help, I'm happy to support your. I have created an issue in github to keep it in mind. Simon On Thu, Nov 9, 2017 at 1:27 PM, MURIENNE Albert > wrote: Cyril, to be more precise : if I run a long time reconstruction, I want to be available to track progression of the computation (ie 0 to 1 floating index), to have an idea of how fast it is running, if we are close to the end and so on? Albert De : Cyril Mory [mailto:cyril.mory at creatis.insa-lyon.fr] Envoy? : jeudi 9 novembre 2017 13:25 ? : MURIENNE Albert; rtk-users at public.kitware.com Objet : Re: [Rtk-users] Reconstruction filter progress observer Hello, I am not sure I understand. Are you trying to know, during runtime, which filter is currently being updated ? Otherwise, can you reformulate your question (possibly with more context) ? Best, Cyril On 09/11/2017 13:11, MURIENNE Albert wrote: Hello, Is there a simple code example available to illustrate the registration of an observer to be notified with the progression of rtk?s reconstruction filters? Thanks in advance for your help, Regards -- Albert Murienne _______________________________________________ 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 makun93 at outlook.com Sun Nov 12 21:22:57 2017 From: makun93 at outlook.com (M. K.) Date: Mon, 13 Nov 2017 02:22:57 +0000 Subject: [Rtk-users] =?gb2312?b?QWJvdXQgZ2VvbWV0cmljIGNvcnJlY3Rpb26joQ==?= Message-ID: Hi?all Recently on the reconstruction of CBCT, I did not to do geometric correction, so ,cannot get the correction geometric information, such as SDD(distance from source to detector) SAD?distance from source to axes?,etc. Who have CBCT RTK-based geometric correction code, hope you can give me a hand , could you share a copy to me ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Nov 13 05:50:36 2017 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 13 Nov 2017 11:50:36 +0100 Subject: [Rtk-users] =?utf-8?q?About_geometric_correction=EF=BC=81?= In-Reply-To: References: Message-ID: Dear M.K., This is difficult. We have made some works in this direction http://www.creatis.insa-lyon.fr/~srit/biblio/lesaint2017.pdf but the (Python) code cannot be easily shared. If you can, I would suggest to redo the acquisition if possible... Best regards, Simon On Mon, Nov 13, 2017 at 3:22 AM, M. K. wrote: > Hi?all > > Recently on the reconstruction of CBCT, I did not to do geometric > correction, so ,cannot get the correction geometric information, such as > SDD(distance from source to detector) SAD?distance from source to axes? > ,etc. > > Who have CBCT RTK-based geometric correction code, hope you can give me a > hand , could you share a copy to me ? > > _______________________________________________ > 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 brent.vanderheyden at maastro.nl Tue Nov 14 04:40:08 2017 From: brent.vanderheyden at maastro.nl (Brent van der Heyden) Date: Tue, 14 Nov 2017 09:40:08 +0000 Subject: [Rtk-users] arc detector reconstruction. ThreeDCircularProjectionGeometry->SetRadiusCylindricalDetector(x) Message-ID: Good morning I want to reconstruct a simulated fan-beam sinogram with (S)RTK. The original simulation code used an arc-detector, not a plane detector which is implemented in RTK. After changing the simulation code I was able to obtain a nice reconstruction with the plane detector, but I still want to compare it with the arc detector. The rtk:: ThreeDCircularProjectionGeometry class has a function to set the cylindrical detector radius (SetRadiusCylindricalDetector), unfortunately this method is not completely implemented yet. Did anyone already tried to implement this method? Or can someone give me (theoretical) advise on how to implement it? Thank you for the help! Kind regards Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From brent.vanderheyden at maastro.nl Tue Nov 14 04:42:08 2017 From: brent.vanderheyden at maastro.nl (Brent van der Heyden) Date: Tue, 14 Nov 2017 09:42:08 +0000 Subject: [Rtk-users] arc detector reconstruction. ThreeDCircularProjectionGeometry Message-ID: Good morning I want to reconstruct a simulated fan-beam sinogram with (S)RTK. The original simulation code used an arc-detector, not a plane detector which is implemented in RTK. After changing the simulation code I was able to obtain a nice reconstruction with the plane detector, but I still want to compare it with the arc detector. The rtk:: ThreeDCircularProjectionGeometry class has a function to set the cylindrical detector radius (SetRadiusCylindricalDetector), unfortunately this method is not completely implemented yet. Did anyone already tried to implement this method? Or can someone give me (theoretical) advise on how to implement it? Thank you for the help! Kind regards Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Nov 15 11:29:21 2017 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 15 Nov 2017 17:29:21 +0100 Subject: [Rtk-users] FDK for planar ct In-Reply-To: <001501d352f3$0215a5a0$0640f0e0$@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>

<001501d352f3$0215a5a0$0640f0e0$@gmx.de> Message-ID: Hi, FYI, I have opened the images. As far as I can guess from the sequence, the circular trajectory of the source is very small wrt to the object size. I don't know what I would do from such a trajectory. I would start by checking the work in tomosynthesis to find some inspiration. Good luck! Simon On Wed, Nov 1, 2017 at 10:22 AM, Robert Calliess wrote: > Hello, > > i?ve uploaded the projection images for the first trajectory. > > https://www.dropbox.com/s/rpcyemuvfngd4rw/QFN1.7z?dl=0 > > > > Inside the folder you can find the projection images. Furthermore you will > find > > two textfiles, positions.txt and calibration.txt. The positions.txt > contains the physical > > position of the detector center. Position id 35 is the orthogonal view. > All other projection ids > > are positions on a circular path around the center position 35. > > The calibration.txt contains the fod, odd and the physical detector size. > > All units given are in micrometers. > > > > Kind regards, > > Robert > > > > > > *Von:* Cyril Mory [mailto:cyril.mory at creatis.insa-lyon.fr] > *Gesendet:* Mittwoch, 25. Oktober 2017 09:34 > *An:* Robert Callie? > *Cc:* rtk-users at public.kitware.com > > *Betreff:* Re: [Rtk-users] FDK for planar ct > > > > 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 > *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 > > > > > > > > > _______________________________________________ > > 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 Nov 15 14:26:11 2017 From: robert.calliess at gmx.de (Robert Calliess) Date: Wed, 15 Nov 2017 20:26:11 +0100 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>

<001501d352f3$0215a5a0$0640f0e0$@gmx.de> Message-ID: <012f01d35e47$98f35850$cada08f0$@gmx.de> Hello, Indeed the trajectory is very small. Thank you very much for your help so far. Kind regards, Robert Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit Gesendet: Mittwoch, 15. November 2017 17:29 An: Robert Calliess Cc: Cyril Mory; rtk-users at public.kitware.com Betreff: Re: [Rtk-users] FDK for planar ct Hi, FYI, I have opened the images. As far as I can guess from the sequence, the circular trajectory of the source is very small wrt to the object size. I don't know what I would do from such a trajectory. I would start by checking the work in tomosynthesis to find some inspiration. Good luck! Simon On Wed, Nov 1, 2017 at 10:22 AM, Robert Calliess wrote: Hello, i?ve uploaded the projection images for the first trajectory. https://www.dropbox.com/s/rpcyemuvfngd4rw/QFN1.7z?dl=0 Inside the folder you can find the projection images. Furthermore you will find two textfiles, positions.txt and calibration.txt. The positions.txt contains the physical position of the detector center. Position id 35 is the orthogonal view. All other projection ids are positions on a circular path around the center position 35. The calibration.txt contains the fod, odd and the physical detector size. All units given are in micrometers. Kind regards, Robert Von: Cyril Mory [mailto:cyril.mory at creatis.insa-lyon.fr] Gesendet: Mittwoch, 25. Oktober 2017 09:34 An: Robert Callie? Cc: rtk-users at public.kitware.com Betreff: Re: [Rtk-users] FDK for planar ct 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"