Re: [Rtk-users] Half Fan dataset

[Simon Rit]

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  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.berg...@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
> <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 
> 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.berg...@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  <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

Re: [Rtk-users] Half Fan dataset

[Simon Rit]

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  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.berg...@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  <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:gabriele.belotti.berg...@gmail.com>
> gabriele.belotti.berg...@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
>
>
&g

Re: [Rtk-users] Half Fan dataset

[Simon Rit]

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 <http://www.openrtk.org/Doxygen/DocGeo3D.html> helps to
understand this. So since you don't have any source offset in your geometry
file, you are in the first line and last line situation of your drawing
image.
Now, on the last line, what you're actually doing is imaging with the same
source arc but actually shifting the detector. This is equivalent to a 180°
source rotation with a larger rotation. You only need a weighting function
to account for the redundancy but this is not going to be the same one as
the one implemented because it needs to be on different side of the
detector/projections (as on the first line of your projections). In any
case, 180° is not enough, you need at least 180+fan angle and to combine
this with a short scan Parker weighting.
Simon

On Wed, Oct 30, 2019 at 6:00 PM  wrote:

> Hi Simon,
>
> Sorry for the late reply.
> I drew a sketch in two part to explain my doubts.
> First I drew 3 configurations for the geometry, representing my doubt
> towards what exactly is achieved by Isocenter Projection translation in the
> RTK geometry; i.e. does it result in a source translation or in a cone beam
> rotation (in XZ plane) to accommodate for the panel displacement? (I’m
> expecting the latter but I couldn’t properly check).
>
> The last two sketches represent the same concept with two of the possible
> geometries(of course I’d prefer the latter):
> The idea is to first rotate with the detector displaced on one side by
> 180° and then displace in the opposite direction and rotate of additional
> 180° (always clockwise rotation).
> Any comment or suggestion would be highly appreciated and eventually I
> will try to impose weights according to improve the reconstruction.
>
> PS: zoom in on the sketch, the resolution should be sufficient to read
> PPS: I’m also attaching a screenshot of a reconstruction achieved with the
> exotic geometry :^] and the xml I generated for it (beware that my detector
> is 298 mm wide and the displacement is of +/-120 mm)
>
> Best regards,
> Gabriele
>
>
>
> *Da:* Simon Rit 
> *Inviato:* martedì 29 ottobre 2019 18.21
> *A:* gabriele.belotti.berg...@gmail.com
> *Cc:* rtk-users 
> *Oggetto:* Re: [Rtk-users] Half Fan dataset
>
>
>
> Hi Gabriele,
>
> Great that you moved forward.
>
> It's quite sure that the current implementation does not handle this new
> exotic geometry. So my suggestion would be to implement your own weights
> (e.g., using the python package).
>
> It's not clear to me what you're trying to achieve here but it seems to me
> that only the central part seen by all source positions has enough data
> (point of space which see at least 180° of source positions) to be
> reconstructible. Maybe you should draw your two cones at 90° and -90° to be
> sure of what you're doing? Don't hesitate to share such a drawing on which
> we could comment.
>
> Best regards,
>
> Simon
>
>
>
> On Tue, Oct 29, 2019 at 4:10 PM 
> wrote:
>
> Dear Simon and RTK users,
>
> I’ve been experimenting on the generation of Half Fan CBCT images
> successfully from reprojections of CTs starting from Simon’s suggestions.
> So far I was able to reconstruct images by displacing the detector in the
> X direction (+ or -) and completing a single rotation. Results were good
> and the FOV was of course larger than the one obtained from using the same
> virtual detector without displacement.
>
> I’ve taken the simulation a step further and I’m currently creating a
> geometry which is similar to the combination of “rtksimulatedgeometry -n
> 180 --proj_iso_x  -o g_1” and “rtksimulatedgeometry -n 180
> --proj_iso_x <(-1)*displacement> -o g_2 -f 180” (I’m rotating first between
> 0° and 180° while displacing by half detector size on +X and then 180° and
> 360° while displacing by half detector size on -X).
> With this single .xml I’m reprojecting a CT into a single .mha using
> rtkforwardprojections and then I’m using the output as input for rtkfdk.
>
> My results however suffer from a centered artifact, of semi-cylindrical
> shape, in my opinion caused by the superimposition of rays from the two
> beams around the isocenter.
> This is further supported by the fact that the more I displace the
> detector the smaller the artefact becomes (of course I can’t displace more
> than 50% of detector size).
> I guess a possible solution would be to have a perfect half-cone x-ray
> beam by shaping it using a collimator, but I’m not sure how to proceed on
> this in the simulated environment.
> Have you got any suggestions or obser

Re: [Rtk-users] Half Fan dataset

[Simon Rit]

Hi Gabriele,
Great that you moved forward.
It's quite sure that the current implementation does not handle this new
exotic geometry. So my suggestion would be to implement your own weights
(e.g., using the python package).
It's not clear to me what you're trying to achieve here but it seems to me
that only the central part seen by all source positions has enough data
(point of space which see at least 180° of source positions) to be
reconstructible. Maybe you should draw your two cones at 90° and -90° to be
sure of what you're doing? Don't hesitate to share such a drawing on which
we could comment.
Best regards,
Simon

On Tue, Oct 29, 2019 at 4:10 PM  wrote:

> Dear Simon and RTK users,
>
> I’ve been experimenting on the generation of Half Fan CBCT images
> successfully from reprojections of CTs starting from Simon’s suggestions.
> So far I was able to reconstruct images by displacing the detector in the
> X direction (+ or -) and completing a single rotation. Results were good
> and the FOV was of course larger than the one obtained from using the same
> virtual detector without displacement.
>
> I’ve taken the simulation a step further and I’m currently creating a
> geometry which is similar to the combination of “rtksimulatedgeometry -n
> 180 --proj_iso_x  -o g_1” and “rtksimulatedgeometry -n 180
> --proj_iso_x <(-1)*displacement> -o g_2 -f 180” (I’m rotating first between
> 0° and 180° while displacing by half detector size on +X and then 180° and
> 360° while displacing by half detector size on -X).
> With this single .xml I’m reprojecting a CT into a single .mha using
> rtkforwardprojections and then I’m using the output as input for rtkfdk.
>
> My results however suffer from a centered artifact, of semi-cylindrical
> shape, in my opinion caused by the superimposition of rays from the two
> beams around the isocenter.
> This is further supported by the fact that the more I displace the
> detector the smaller the artefact becomes (of course I can’t displace more
> than 50% of detector size).
> I guess a possible solution would be to have a perfect half-cone x-ray
> beam by shaping it using a collimator, but I’m not sure how to proceed on
> this in the simulated environment.
> Have you got any suggestions or observation on how to achieve a
> reconstruction based on this? (two rotations/acquistion given two opposite
> detector displacements)
>
> Thanks in advance,
> Gabriele
>
>
>
>
>
>
>
> *Da:* Simon Rit 
> *Inviato:* venerdì 11 ottobre 2019 13.10
> *A:* gabriele.belotti.berg...@gmail.com
> *Cc:* rtk-users 
> *Oggetto:* Re: [Rtk-users] Half Fan dataset
>
>
>
> Hi,
>
> It's easy to generate, you need to offset your detector, either via the
> RTK geometry or by setting the first coordinate of the origin of your
> projection to something which makes the projection uncentered. For example,
> in the geometry :
>
> rtksimulatedgeometry -n 180 --proj_iso_x 100 -o g
>
> rtkprojectshepploganphantom -g g -o proj.mha
>
> rtkfdk -p . -g g -r proj.mha -o fdk.mha
>
> You can simulate from a CT image by following this example
> <http://wiki.openrtk.org/index.php/RTK/Scripts/ForwardProjection>.
>
> Simon
>
>
>
> On Fri, Oct 11, 2019 at 9:58 AM 
> wrote:
>
> Dear RTK users and developers,
>
> I’m currently experimenting with FDK reconstruction and I’m struggling to
> find a Half-Fan projection dataset to fiddle around.. Do you know where I
> can find one? I’ve taken into consideration generating a set of DRRs from
> an existing phantom. Any help or advice you can give me would be greatly
> appreciated, thanks!
>
> Gabriele Belotti
>
>
>
>
>
> ___
> Rtk-users mailing list
> Rtk-users@public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
>
>
___
Rtk-users mailing list
Rtk-users@public.kitware.com
https://public.kitware.com/mailman/listinfo/rtk-users

Re: [Rtk-users] Half Fan dataset

[Simon Rit]

Hi,
It's easy to generate, you need to offset your detector, either via the RTK
geometry or by setting the first coordinate of the origin of your
projection to something which makes the projection uncentered. For example,
in the geometry :
rtksimulatedgeometry -n 180 --proj_iso_x 100 -o g
rtkprojectshepploganphantom -g g -o proj.mha
rtkfdk -p . -g g -r proj.mha -o fdk.mha
You can simulate from a CT image by following this example
.
Simon

On Fri, Oct 11, 2019 at 9:58 AM  wrote:

> Dear RTK users and developers,
>
> I’m currently experimenting with FDK reconstruction and I’m struggling to
> find a Half-Fan projection dataset to fiddle around.. Do you know where I
> can find one? I’ve taken into consideration generating a set of DRRs from
> an existing phantom. Any help or advice you can give me would be greatly
> appreciated, thanks!
>
> Gabriele Belotti
>
>
>
>
> ___
> Rtk-users mailing list
> Rtk-users@public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
>
___
Rtk-users mailing list
Rtk-users@public.kitware.com
https://public.kitware.com/mailman/listinfo/rtk-users

[Rtk-users] Half Fan dataset

[gabriele.belotti.bergamo]

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@public.kitware.com
https://public.kitware.com/mailman/listinfo/rtk-users