Thanks for the report, I'll try to fix this issue (I have noted it on github here <https://github.com/SimonRit/RTK/issues/290>). And thanks in advance for the code! Simon
On Wed, Jan 22, 2020 at 4:11 PM <[email protected]> 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 <[email protected]> > *Inviato:* mercoledì 22 gennaio 2020 11.46 > *A:* [email protected] > *Cc:* rtk-users <[email protected]> > *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 > <http://www.fully3d.org/uploadfile/2017/0112/20170112020253842.pdf>): 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 <[email protected]> > 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 <[email protected]> > Inviato: giovedì 31 ottobre 2019 00.22 > A: [email protected] > Cc: rtk-users <[email protected]> > 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 <http://www.openrtk.org/Doxygen/DocGeo3D.html> 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 < > <mailto:[email protected]> > [email protected]> 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 < <mailto:[email protected]> > [email protected]> > Inviato: martedì 29 ottobre 2019 18.21 > A: <mailto:[email protected]> > [email protected] > Cc: rtk-users < <mailto:[email protected]> > [email protected]> > 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 < > <mailto:[email protected]> > [email protected]> 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 <displacement> -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 < <mailto:[email protected]> > [email protected]> > Inviato: venerdì 11 ottobre 2019 13.10 > A: <mailto:[email protected]> > [email protected] > Cc: rtk-users < <mailto:[email protected]> > [email protected]> > 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 > <http://wiki.openrtk.org/index.php/RTK/Scripts/ForwardProjection> this > example. > > Simon > > > > On Fri, Oct 11, 2019 at 9:58 AM < > <mailto:[email protected]> > [email protected]> 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 > <mailto:[email protected]> [email protected] > <https://public.kitware.com/mailman/listinfo/rtk-users> > https://public.kitware.com/mailman/listinfo/rtk-users > >
_______________________________________________ Rtk-users mailing list [email protected] https://public.kitware.com/mailman/listinfo/rtk-users
