From e.a.gh72 at gmail.com Mon Jan 6 07:07:37 2020 From: e.a.gh72 at gmail.com (Ali ghorbanian) Date: Mon, 6 Jan 2020 15:37:37 +0330 Subject: [Rtk-users] Spiral CT Message-ID: Hi, I have a spiral model for CT (Fan Beam) imaging; how can I reconstruct the output images with RTK? Tank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jan 6 08:25:59 2020 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 6 Jan 2020 14:25:59 +0100 Subject: [Rtk-users] Spiral CT In-Reply-To: References: Message-ID: Hi, There is no FBP implementation for spiral CT. The only way this could work is with iterative algorithms (e.g., conjugate gradient) using Joseph forward and backprojectors. Voxel-based backprojector (the default) won't work because it does a bilinear interpolation on the projections. I don't have an example available for you, sorry... Cheers, Simon On Mon, Jan 6, 2020 at 1:08 PM Ali ghorbanian wrote: > Hi, > > I have a spiral model for CT (Fan Beam) imaging; how can I reconstruct > the output images with RTK? > > Tank you. > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jan 6 08:43:16 2020 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 6 Jan 2020 14:43:16 +0100 Subject: [Rtk-users] Spiral CT In-Reply-To: References: Message-ID: Stay on the mailing list please. I don't understand your question... You need to know the geometry of your system if that's what you mean. This is usually not obtained by image registration but by a calibration procedure. Simon On Mon, Jan 6, 2020 at 2:38 PM Ali ghorbanian wrote: > Tank You, > Do I Need Registration and Matching Projection Before iterative > Algorithms(conjugate gradient, ...) Run? > > On Mon, Jan 6, 2020 at 4:54 PM Simon Rit > wrote: > >> Hi, >> There is no FBP implementation for spiral CT. The only way this could >> work is with iterative algorithms (e.g., conjugate gradient) using Joseph >> forward and backprojectors. Voxel-based backprojector (the default) won't >> work because it does a bilinear interpolation on the projections. I don't >> have an example available for you, sorry... >> Cheers, >> Simon >> >> On Mon, Jan 6, 2020 at 1:08 PM Ali ghorbanian wrote: >> >>> Hi, >>> >>> I have a spiral model for CT (Fan Beam) imaging; how can I reconstruct >>> the output images with RTK? >>> >>> Tank you. >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> https://public.kitware.com/mailman/listinfo/rtk-users >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stefanie.Kaser at oeaw.ac.at Tue Jan 7 11:32:58 2020 From: Stefanie.Kaser at oeaw.ac.at (Kaser, Stefanie) Date: Tue, 7 Jan 2020 16:32:58 +0000 Subject: [Rtk-users] Getting started with RTK - Problem with modifying First Reconstruction example Message-ID: Hi, I am currently trying to get started with RTK by modifying the FirstReconstruction example. In fact, I tried to replace the given projections of a sphere by some projections I created myself with Geant4. However, the result is not really convincing and I am not sure if I messed with the geometry or if I got something else wrong. I have 90 projections (128x128 pixels, 2 deg rotation each time); from source to detector it's 46cm and 30cm from source to the object (simple small cylinder) centre, which lies in the centre of rotation: unsigned int numberOfProjections = 90; double firstAngle = 0.; double angularArc = 178.; unsigned int sid = 300.; unsigned int sdd = 460.; To read in the file, I used the ITK ImageFileReader, which works well. I am handing in my projections stacked in .mha format because it seemed that the sphere projections were generated and handed to the FDK reconstruction algorithm in a similar way (is that correct?). My projection values are double type and are of a range between 0 (air) and 1. For the FDK reconstruction I am choosing for my constant image source: sizeOutput.Fill(128); // output should be 3D image 128x128x128 pixels origin.Fill(0.); // I'm not entirely sure about this parameter? If my object is placed in the isocenter, this should work, right? spacing.Fill(0.2); // pixel length in each direction is 0.2mm For the reconstruction itself, I didn't really change the original code but instead of 'rei', I handed my projections as input and then wrote the result to an output file. I don't get any error when I run the program but the FDK gives some strange result (I am adding one screenshot of the first projection and the first slice of the reconstructed volume to my mail). Maybe someone is familiar with this problem or sees what I am doing wrong? Thank you very much in advance! Best regards, Stefanie -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Reconstruction.png Type: image/png Size: 17437 bytes Desc: Reconstruction.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Projection_0deg.png Type: image/png Size: 14291 bytes Desc: Projection_0deg.png URL: From e.a.gh72 at gmail.com Wed Jan 8 00:40:05 2020 From: e.a.gh72 at gmail.com (Ali ghorbanian) Date: Wed, 8 Jan 2020 09:10:05 +0330 Subject: [Rtk-users] Spiral CT Message-ID: Hi, I Use a spiral model for CT (Fan Beam) imaging; how can I reconstruct the output images with RTK? Do I Need Registration and Matching Projection Before iterative Algorithms(conjugate gradient, ...) Run? Tank you. [image: spiral-ct-scanner.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: spiral-ct-scanner.png Type: image/png Size: 76760 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Wed Jan 8 15:31:48 2020 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 8 Jan 2020 21:31:48 +0100 Subject: [Rtk-users] Getting started with RTK - Problem with modifying First Reconstruction example In-Reply-To: References: Message-ID: Hi Stefanie, In the example, the projections are simulated and not read in from a file. Anyhow, using the mha file format seems to be a good way too proceed and what you've done sounds good (the rei part). The geometry is a bit tricky to master in RTK (as in any recon package I assume). The origin you've chosen does not seem right, if you check ITK's documentation, itk::Image::m_Origin is the coordinate of the first voxel and RTK uses the coordinate (0,0,0) (the origin of the coordinate system, not to be mixed with the origin of the image...). So if you want to center your image around the center of rotation (a typical choice), I would do here origin.Fill( -0.5*(128-1)*0.2 ) such that the first pixel has coordinate -12.7 and the last pixel has coordinate 12.7 (in each dimension). Something else is wrong looking at your image. If you share the projections and the code, we can probably help you to solve the other problem. Cheers, Simon On Tue, Jan 7, 2020 at 5:41 PM Kaser, Stefanie wrote: > Hi, > > > I am currently trying to get started with RTK by modifying the > FirstReconstruction example. In fact, I tried to replace the given > projections of a sphere by some projections I created myself with Geant4. > However, the result is not really convincing and I am not sure if I messed > with the geometry or if I got something else wrong. > > > I have 90 projections (128x128 pixels, 2 deg rotation each time); from > source to detector it's 46cm and 30cm from source to the object (simple > small cylinder) centre, which lies in the centre of rotation: > > > unsigned int numberOfProjections = 90; > > double firstAngle = 0.; > > double angularArc = 178.; > > unsigned int sid = 300.; > > unsigned int sdd = 460.; > > > To read in the file, I used the ITK ImageFileReader, which works well. I > am handing in my projections stacked in .mha format because it seemed that > the sphere projections were generated and handed to the FDK reconstruction > algorithm in a similar way (is that correct?). My projection values are > double type and are of a range between 0 (air) and 1. > > > For the FDK reconstruction I am choosing for my constant image source: > > sizeOutput.Fill(128); // output should be 3D image 128x128x128 pixels > > origin.Fill(0.); // I'm not entirely sure about this parameter? If my > object is placed in the isocenter, this should work, right? > > spacing.Fill(0.2); // pixel length in each direction is 0.2mm > > > For the reconstruction itself, I didn't really change the original code > but instead of 'rei', I handed my projections as input and then wrote the > result to an output file. > > I don't get any error when I run the program but the FDK gives some > strange result (I am adding one screenshot of the first projection and the > first slice of the reconstructed volume to my mail). > > Maybe someone is familiar with this problem or sees what I am doing wrong? > Thank you very much in advance! > > > Best regards, > > Stefanie > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stefanie.Kaser at oeaw.ac.at Mon Jan 13 03:46:40 2020 From: Stefanie.Kaser at oeaw.ac.at (Kaser, Stefanie) Date: Mon, 13 Jan 2020 08:46:40 +0000 Subject: [Rtk-users] Convex Hull Message-ID: Hello everyone, I just wanted to bring up another question since I haven't found anything recent on the topic yet. Is it possible to calculate the convex hull of an object with ITK/RTK? If so, which are the crucial modules to use? Best regards, Stefanie -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasga22 at gmail.com Mon Jan 13 08:17:20 2020 From: andreasga22 at gmail.com (Andreas Andersen) Date: Mon, 13 Jan 2020 14:17:20 +0100 Subject: [Rtk-users] Convex Hull In-Reply-To: References: Message-ID: Hi Stephanie, It depends on what you intend to compute more exactly: If it's to remove values outside the scanners field of view, then the filter "rtk::FieldOfViewImageFilter" does exactly this. ( It uses the lpsolve library to do this: https://github.com/SimonRit/RTK/blob/master/include/rtkFieldOfViewImageFilter.hxx#L41 ) If it has anything to do with structures/delineations from DICOM, then wouldn't they already be the convex set? ITK uses three formats for structures: labelmaps, mesh and polyline. But VTK has much better classes for this IMO, and may have what you need. I don't think RTK has any direct use of any of the structure classes(?) Best Regards Andreas __________________________________ Andreas Gravgaard Andersen Danish Center for Particle Therapy, Aarhus University Hospital Palle Juul-Jensens Blvd. 99, 8200, Aarhus Mail: agravgaard at protonmail.com Cell: +45 3165 8140 On Mon, 13 Jan 2020 at 09:46, Kaser, Stefanie wrote: > Hello everyone, > > > I just wanted to bring up another question since I haven't found anything > recent on the topic yet. Is it possible to calculate the convex hull of an > object with ITK/RTK? If so, which are the crucial modules to use? > > > Best regards, > > Stefanie > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Jan 13 09:14:40 2020 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 13 Jan 2020 15:14:40 +0100 Subject: [Rtk-users] Convex Hull In-Reply-To: References: Message-ID: Hi, No, there isn't a way to estimate the convex hull. VTK probably offers something like that but I haven't used it. Note that from x-ray projections, you can threshold projections between air and object, backproject and threshold the volume to have an approximation of the convex hull. Best regards, Simon On Mon, Jan 13, 2020 at 2:17 PM Andreas Andersen wrote: > Hi Stephanie, > It depends on what you intend to compute more exactly: > > If it's to remove values outside the scanners field of view, then the > filter "rtk::FieldOfViewImageFilter" does exactly this. ( It uses the > lpsolve library to do this: > https://github.com/SimonRit/RTK/blob/master/include/rtkFieldOfViewImageFilter.hxx#L41 > ) > > If it has anything to do with structures/delineations from DICOM, then > wouldn't they already be the convex set? > > ITK uses three formats for structures: labelmaps, mesh and polyline. But > VTK has much better classes for this IMO, and may have what you need. > I don't think RTK has any direct use of any of the structure classes(?) > > Best Regards > Andreas > > __________________________________ > > Andreas Gravgaard Andersen > > Danish Center for Particle Therapy, > > Aarhus University Hospital > > Palle Juul-Jensens Blvd. 99, > > 8200, Aarhus > > Mail: agravgaard at protonmail.com > > Cell: +45 3165 8140 > > > On Mon, 13 Jan 2020 at 09:46, Kaser, Stefanie > wrote: > >> Hello everyone, >> >> >> I just wanted to bring up another question since I haven't found anything >> recent on the topic yet. Is it possible to calculate the convex hull of an >> object with ITK/RTK? If so, which are the crucial modules to use? >> >> >> Best regards, >> >> Stefanie >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> https://public.kitware.com/mailman/listinfo/rtk-users >> > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.a.gh72 at gmail.com Tue Jan 21 01:30:04 2020 From: e.a.gh72 at gmail.com (Ali ghorbanian) Date: Tue, 21 Jan 2020 10:00:04 +0330 Subject: [Rtk-users] Spiral Reconstruct Message-ID: Hi, I Use a spiral model for CT (Fan Beam) imaging; how can I reconstruct the output images with RTK? Do I Need Registration and Matching Projection Before iterative Algorithms(conjugate gradient, ...) Run? Tank you. [image: spiral-ct-scanner.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: spiral-ct-scanner.png Type: image/png Size: 76760 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Wed Jan 22 05:45:34 2020 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 22 Jan 2020 11:45:34 +0100 Subject: [Rtk-users] Half Fan dataset In-Reply-To: <003301d5d075$68adcf70$3a096e50$@gmail.com> References: <000801d58009$a7828ef0$f687acd0$@gmail.com> <008501d58e6a$f7aa7a40$e6ff6ec0$@gmail.com> <001201d58f43$866a9390$933fbab0$@gmail.com> <003301d5d075$68adcf70$3a096e50$@gmail.com> Message-ID: Congratulations! Glad to here it worked out. From your attachment, I have the feeling that something is wrong since there is an artefact at the center. Do you know what that could be? Maybe you can read the Knaup's paper in the 13th fully 3D meeting proceedings (available here ): A General Projection Weight for Feldkamp?Type Cone?Beam Image Reconstruction from Arbitrary CT Scan Trajectories. Defining optimal weights is difficult because you have two competing criteria: best use of the dose to minimize dose and a smooth weighting (as described by Parker). It might be worth being included but the best would be to do it with minimal code copy. You can share the current code if you want us to have a look. Cheers, Simon On Tue, Jan 21, 2020 at 5:11 PM wrote: > Dear Simon and Rtk users, > > I picked this topic up again after some time. > I was able to properly weight my projections stack in order to accommodate > for two different detector displacement in a dual-rotation configuration ( > I > modified both CPU and GPU implementations of DisplacedDetectorImageFilter ) > under the same geometry.xml file. > Following, it was possible to directly use ParkerShortScanFilter to > compensate for the short scan conditions of two successive incomplete > rotations. > > The resulting reconstruction can be superimposed on a single-rotation > Half-Fan reconstruction with no difference except for a cylindrical > artefact > which is centred and extends along the Y axis of the reconstructed volume > (figure attached). > I suspect the weighting I?m using (which is a transposition of the one > currently implemented) is not ideal for dual-rotation reconstruction > whenever the detector is not fully displaced. > However I struggle to find literature on this topic! If you have any > suggestion I would be interested in investigating further on this topic, as > limited Range of Motion is a key factor in my project. > > > Of course if you feel this feature could be merged into Rtk tree I would be > glad to open a pull request on git and dive more into details. > > Best regards, > Gabriele > > > > Da: Simon Rit > Inviato: gioved? 31 ottobre 2019 00.22 > A: gabriele.belotti.bergamo at gmail.com > Cc: rtk-users > Oggetto: Re: [Rtk-users] Half Fan dataset > > > > Hi, > > with --proj_iso_x, you only move the detector, not the source. If you also > want to move the source, --source_x needs to be used. Hopefully the drawing > on the doc page helps to > understand this. So since you don't have any source offset in your geometry > file, you are in the first line and last line situation of your drawing > image. > > Now, on the last line, what you're actually doing is imaging with the same > source arc but actually shifting the detector. This is equivalent to a 180? > source rotation with a larger rotation. You only need a weighting function > to account for the redundancy but this is not going to be the same one as > the one implemented because it needs to be on different side of the > detector/projections (as on the first line of your projections). In any > case, 180? is not enough, you need at least 180+fan angle and to combine > this with a short scan Parker weighting. > > Simon > > > > On Wed, Oct 30, 2019 at 6:00 PM < > > gabriele.belotti.bergamo at gmail.com> wrote: > > Hi Simon, > > Sorry for the late reply. > I drew a sketch in two part to explain my doubts. > First I drew 3 configurations for the geometry, representing my doubt > towards what exactly is achieved by Isocenter Projection translation in the > RTK geometry; i.e. does it result in a source translation or in a cone beam > rotation (in XZ plane) to accommodate for the panel displacement? (I?m > expecting the latter but I couldn?t properly check). > > The last two sketches represent the same concept with two of the possible > geometries(of course I?d prefer the latter): > The idea is to first rotate with the detector displaced on one side by 180? > and then displace in the opposite direction and rotate of additional 180? > (always clockwise rotation). > Any comment or suggestion would be highly appreciated and eventually I will > try to impose weights according to improve the reconstruction. > > PS: zoom in on the sketch, the resolution should be sufficient to read > PPS: I?m also attaching a screenshot of a reconstruction achieved with the > exotic geometry :^] and the xml I generated for it (beware that my detector > is 298 mm wide and the displacement is of +/-120 mm) > > Best regards, > Gabriele > > > > Da: Simon Rit < > simon.rit at creatis.insa-lyon.fr> > Inviato: marted? 29 ottobre 2019 18.21 > A: > gabriele.belotti.bergamo at gmail.com > Cc: rtk-users < > rtk-users at public.kitware.com> > Oggetto: Re: [Rtk-users] Half Fan dataset > > > > Hi Gabriele, > > Great that you moved forward. > > It's quite sure that the current implementation does not handle this new > exotic geometry. So my suggestion would be to implement your own weights > (e.g., using the python package). > > It's not clear to me what you're trying to achieve here but it seems to me > that only the central part seen by all source positions has enough data > (point of space which see at least 180? of source positions) to be > reconstructible. Maybe you should draw your two cones at 90? and -90? to be > sure of what you're doing? Don't hesitate to share such a drawing on which > we could comment. > > Best regards, > > Simon > > > > On Tue, Oct 29, 2019 at 4:10 PM < > > gabriele.belotti.bergamo at gmail.com> wrote: > > Dear Simon and RTK users, > > I?ve been experimenting on the generation of Half Fan CBCT images > successfully from reprojections of CTs starting from Simon?s suggestions. > So far I was able to reconstruct images by displacing the detector in the X > direction (+ or -) and completing a single rotation. Results were good and > the FOV was of course larger than the one obtained from using the same > virtual detector without displacement. > > I?ve taken the simulation a step further and I?m currently creating a > geometry which is similar to the combination of ?rtksimulatedgeometry -n > 180 > --proj_iso_x -o g_1? and ?rtksimulatedgeometry -n 180 > --proj_iso_x <(-1)*displacement> -o g_2 -f 180? (I?m rotating first between > 0? and 180? while displacing by half detector size on +X and then 180? and > 360? while displacing by half detector size on -X). > With this single .xml I?m reprojecting a CT into a single .mha using > rtkforwardprojections and then I?m using the output as input for rtkfdk. > > My results however suffer from a centered artifact, of semi-cylindrical > shape, in my opinion caused by the superimposition of rays from the two > beams around the isocenter. > This is further supported by the fact that the more I displace the detector > the smaller the artefact becomes (of course I can?t displace more than 50% > of detector size). > I guess a possible solution would be to have a perfect half-cone x-ray beam > by shaping it using a collimator, but I?m not sure how to proceed on this > in > the simulated environment. > Have you got any suggestions or observation on how to achieve a > reconstruction based on this? (two rotations/acquistion given two opposite > detector displacements) > > Thanks in advance, > Gabriele > > > > > > > > Da: Simon Rit < > simon.rit at creatis.insa-lyon.fr> > Inviato: venerd? 11 ottobre 2019 13.10 > A: > gabriele.belotti.bergamo at gmail.com > Cc: rtk-users < > rtk-users at public.kitware.com> > Oggetto: Re: [Rtk-users] Half Fan dataset > > > > Hi, > > It's easy to generate, you need to offset your detector, either via the RTK > geometry or by setting the first coordinate of the origin of your > projection > to something which makes the projection uncentered. For example, in the > geometry : > > rtksimulatedgeometry -n 180 --proj_iso_x 100 -o g > > rtkprojectshepploganphantom -g g -o proj.mha > > rtkfdk -p . -g g -r proj.mha -o fdk.mha > > You can simulate from a CT image by following > this > example. > > Simon > > > > On Fri, Oct 11, 2019 at 9:58 AM < > > gabriele.belotti.bergamo at gmail.com> wrote: > > Dear RTK users and developers, > > I?m currently experimenting with FDK reconstruction and I?m struggling to > find a Half-Fan projection dataset to fiddle around.. Do you know where I > can find one? I?ve taken into consideration generating a set of DRRs from > an > existing phantom. Any help or advice you can give me would be greatly > appreciated, thanks! > > Gabriele Belotti > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > > https://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Jan 23 15:50:37 2020 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 23 Jan 2020 21:50:37 +0100 Subject: [Rtk-users] Half Fan dataset In-Reply-To: <003201d5d136$324b6a20$96e23e60$@gmail.com> References: <000801d58009$a7828ef0$f687acd0$@gmail.com> <008501d58e6a$f7aa7a40$e6ff6ec0$@gmail.com> <001201d58f43$866a9390$933fbab0$@gmail.com> <003301d5d075$68adcf70$3a096e50$@gmail.com> <003201d5d136$324b6a20$96e23e60$@gmail.com> Message-ID: Thanks for the report, I'll try to fix this issue (I have noted it on github here ). And thanks in advance for the code! Simon On Wed, Jan 22, 2020 at 4:11 PM wrote: > Thanks Simon! > My best guess is that the artefact is strongly related to the ?theta? > dependant weighting in DDF weighting. > An interesting fact is that displacing the isocenter projection on the > detector less and less, the artefact tends to disappear (see the attached > figures as reference). > On a smaller note, there is some inconsistency in the inferior/superior > image corner calculation between positive and negative isocenter projection > displacements of the same entity (say + or - 140), which in turn affect > ?theta? calculation. > > Thanks a lot for the literature reference, I?ll gladly study it. > > Regarding the code, I?ll transfer the changes to a clone of the current > release and share it as soon as possible and we?ll look into optimizing it. > > Best wishes, > Gabriele > > > > *Da:* Simon Rit > *Inviato:* mercoled? 22 gennaio 2020 11.46 > *A:* gabriele.belotti.bergamo at gmail.com > *Cc:* rtk-users > *Oggetto:* Re: [Rtk-users] Half Fan dataset > > > > Congratulations! Glad to here it worked out. From your attachment, I have > the feeling that something is wrong since there is an artefact at the > center. Do you know what that could be? > > Maybe you can read the Knaup's paper in the 13th fully 3D meeting > proceedings (available here > ): A > General Projection Weight for Feldkamp?Type Cone?Beam Image Reconstruction > from Arbitrary CT Scan Trajectories. > > Defining optimal weights is difficult because you have two competing > criteria: best use of the dose to minimize dose and a smooth weighting (as > described by Parker). > > It might be worth being included but the best would be to do it with > minimal code copy. You can share the current code if you want us to have a > look. > > Cheers, > > Simon > > > > On Tue, Jan 21, 2020 at 5:11 PM > wrote: > > Dear Simon and Rtk users, > > I picked this topic up again after some time. > I was able to properly weight my projections stack in order to accommodate > for two different detector displacement in a dual-rotation configuration ( > I > modified both CPU and GPU implementations of DisplacedDetectorImageFilter ) > under the same geometry.xml file. > Following, it was possible to directly use ParkerShortScanFilter to > compensate for the short scan conditions of two successive incomplete > rotations. > > The resulting reconstruction can be superimposed on a single-rotation > Half-Fan reconstruction with no difference except for a cylindrical > artefact > which is centred and extends along the Y axis of the reconstructed volume > (figure attached). > I suspect the weighting I?m using (which is a transposition of the one > currently implemented) is not ideal for dual-rotation reconstruction > whenever the detector is not fully displaced. > However I struggle to find literature on this topic! If you have any > suggestion I would be interested in investigating further on this topic, as > limited Range of Motion is a key factor in my project. > > > Of course if you feel this feature could be merged into Rtk tree I would be > glad to open a pull request on git and dive more into details. > > Best regards, > Gabriele > > > > Da: Simon Rit > Inviato: gioved? 31 ottobre 2019 00.22 > A: gabriele.belotti.bergamo at gmail.com > Cc: rtk-users > Oggetto: Re: [Rtk-users] Half Fan dataset > > > > Hi, > > with --proj_iso_x, you only move the detector, not the source. If you also > want to move the source, --source_x needs to be used. Hopefully the drawing > on the doc page helps to > understand this. So since you don't have any source offset in your geometry > file, you are in the first line and last line situation of your drawing > image. > > Now, on the last line, what you're actually doing is imaging with the same > source arc but actually shifting the detector. This is equivalent to a 180? > source rotation with a larger rotation. You only need a weighting function > to account for the redundancy but this is not going to be the same one as > the one implemented because it needs to be on different side of the > detector/projections (as on the first line of your projections). In any > case, 180? is not enough, you need at least 180+fan angle and to combine > this with a short scan Parker weighting. > > Simon > > > > On Wed, Oct 30, 2019 at 6:00 PM < > > gabriele.belotti.bergamo at gmail.com> wrote: > > Hi Simon, > > Sorry for the late reply. > I drew a sketch in two part to explain my doubts. > First I drew 3 configurations for the geometry, representing my doubt > towards what exactly is achieved by Isocenter Projection translation in the > RTK geometry; i.e. does it result in a source translation or in a cone beam > rotation (in XZ plane) to accommodate for the panel displacement? (I?m > expecting the latter but I couldn?t properly check). > > The last two sketches represent the same concept with two of the possible > geometries(of course I?d prefer the latter): > The idea is to first rotate with the detector displaced on one side by 180? > and then displace in the opposite direction and rotate of additional 180? > (always clockwise rotation). > Any comment or suggestion would be highly appreciated and eventually I will > try to impose weights according to improve the reconstruction. > > PS: zoom in on the sketch, the resolution should be sufficient to read > PPS: I?m also attaching a screenshot of a reconstruction achieved with the > exotic geometry :^] and the xml I generated for it (beware that my detector > is 298 mm wide and the displacement is of +/-120 mm) > > Best regards, > Gabriele > > > > Da: Simon Rit < > simon.rit at creatis.insa-lyon.fr> > Inviato: marted? 29 ottobre 2019 18.21 > A: > gabriele.belotti.bergamo at gmail.com > Cc: rtk-users < > rtk-users at public.kitware.com> > Oggetto: Re: [Rtk-users] Half Fan dataset > > > > Hi Gabriele, > > Great that you moved forward. > > It's quite sure that the current implementation does not handle this new > exotic geometry. So my suggestion would be to implement your own weights > (e.g., using the python package). > > It's not clear to me what you're trying to achieve here but it seems to me > that only the central part seen by all source positions has enough data > (point of space which see at least 180? of source positions) to be > reconstructible. Maybe you should draw your two cones at 90? and -90? to be > sure of what you're doing? Don't hesitate to share such a drawing on which > we could comment. > > Best regards, > > Simon > > > > On Tue, Oct 29, 2019 at 4:10 PM < > > gabriele.belotti.bergamo at gmail.com> wrote: > > Dear Simon and RTK users, > > I?ve been experimenting on the generation of Half Fan CBCT images > successfully from reprojections of CTs starting from Simon?s suggestions. > So far I was able to reconstruct images by displacing the detector in the X > direction (+ or -) and completing a single rotation. Results were good and > the FOV was of course larger than the one obtained from using the same > virtual detector without displacement. > > I?ve taken the simulation a step further and I?m currently creating a > geometry which is similar to the combination of ?rtksimulatedgeometry -n > 180 > --proj_iso_x -o g_1? and ?rtksimulatedgeometry -n 180 > --proj_iso_x <(-1)*displacement> -o g_2 -f 180? (I?m rotating first between > 0? and 180? while displacing by half detector size on +X and then 180? and > 360? while displacing by half detector size on -X). > With this single .xml I?m reprojecting a CT into a single .mha using > rtkforwardprojections and then I?m using the output as input for rtkfdk. > > My results however suffer from a centered artifact, of semi-cylindrical > shape, in my opinion caused by the superimposition of rays from the two > beams around the isocenter. > This is further supported by the fact that the more I displace the detector > the smaller the artefact becomes (of course I can?t displace more than 50% > of detector size). > I guess a possible solution would be to have a perfect half-cone x-ray beam > by shaping it using a collimator, but I?m not sure how to proceed on this > in > the simulated environment. > Have you got any suggestions or observation on how to achieve a > reconstruction based on this? (two rotations/acquistion given two opposite > detector displacements) > > Thanks in advance, > Gabriele > > > > > > > > Da: Simon Rit < > simon.rit at creatis.insa-lyon.fr> > Inviato: venerd? 11 ottobre 2019 13.10 > A: > gabriele.belotti.bergamo at gmail.com > Cc: rtk-users < > rtk-users at public.kitware.com> > Oggetto: Re: [Rtk-users] Half Fan dataset > > > > Hi, > > It's easy to generate, you need to offset your detector, either via the RTK > geometry or by setting the first coordinate of the origin of your > projection > to something which makes the projection uncentered. For example, in the > geometry : > > rtksimulatedgeometry -n 180 --proj_iso_x 100 -o g > > rtkprojectshepploganphantom -g g -o proj.mha > > rtkfdk -p . -g g -r proj.mha -o fdk.mha > > You can simulate from a CT image by following > this > example. > > Simon > > > > On Fri, Oct 11, 2019 at 9:58 AM < > > gabriele.belotti.bergamo at gmail.com> wrote: > > Dear RTK users and developers, > > I?m currently experimenting with FDK reconstruction and I?m struggling to > find a Half-Fan projection dataset to fiddle around.. Do you know where I > can find one? I?ve taken into consideration generating a set of DRRs from > an > existing phantom. Any help or advice you can give me would be greatly > appreciated, thanks! > > Gabriele Belotti > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > > https://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: