From simon.rit at creatis.insa-lyon.fr  Thu Aug  1 22:43:18 2019
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 2 Aug 2019 04:43:18 +0200
Subject: [Rtk-users] wrong projection geometry?
In-Reply-To: <CAKr9h5V1BamYdRFZpZ6XMJhOnSSo9S9vSQ6dhvmxGnpPbSuG2g@mail.gmail.com>
References: <CAKr9h5V1BamYdRFZpZ6XMJhOnSSo9S9vSQ6dhvmxGnpPbSuG2g@mail.gmail.com>
Message-ID: <CAF0oig2yWJ+Be2DbtxokHtn8nu_wJ=7CzSOzeSb3EDCQ4QQhcA@mail.gmail.com>

Hi,
>From what I see in your reconstruction screenshot, you have mainly one
projection. 180? is too short for a short scan so I suggest to have at
least 180?+cone angle. Don't you get a warning when launching the command
line? It's hard to anticipate what happens if you don't use this amount of
data.
Since it's a Gate simulation, I suggest to start with a full acquisition to
check that everything else is correct (distances, rotation direction, etc).
Don't hesitate to share your Gate macro if you want us to check the
geometry.
Note that your spacing and origin parameters need commas instead of spaces
or quotes to be adequately interpreted
Simon

On Sun, Jul 28, 2019 at 5:15 PM Howard <lomahu at gmail.com> wrote:

> Hi,
>
> I tried to run the application rtkfdk to reconstruct CBCT from 180
> projections (from 0 degree to 180 degree only) that were generated using
> Gate simulation. Here is the geometry of the simulation:
>
> a cylindrical phantom (radius=8mm, height=20mm) sitting on a turntable
> X-ray source to isocenter (center of the cylindrical phantom) = 80mm (SAD)
> Flat panel imager (60mm x 60mm) to isocenter = 80mm (SDD=160mm)
>
> x direction: perpendicular to y direction which is the direction from
> detector to X-ray source;
> z direction: turntable rotation axis and pointing upward
>
> I used rtksimulatedgeometry application to generate the geometry xml file
> following the simulation geometry with the command:
> rtksimulatedgeometry -n 180 --arc 180 -o geo.xml --sid 80 -sdd 160
> --proj_iso_x -30 --proj_iso_y -30
>
> Subsequently the CBCT was reconstructed with the rtkfdk application with
> the command:
> rtkfdk -g geo.xml -p . -r proj.mha -o test.mha --spacing 0.1 0.1 0.2
> --dimension 160,160,100 --origin -8 -8 -10
>
> However, the reconstruction result does not look correct. Particularly the
> axial and sagittal views have a lot of streaks. For your reference, I am
> sharing the snapshots of the projections and the reconstructed CBCT in the
> following link:
>
> projection screenshot:         https://ibb.co/PCTjzrt
> reconstruction screenshot:  https://ibb.co/QCjjvQt
>
> What did I do wrong or miss? Or streaks are due to partial projections,
> ie, only 180 views? Your help would be greatly appreciated.
>
> Best,
> Howard
> _______________________________________________
> 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: <https://public.kitware.com/pipermail/rtk-users/attachments/20190802/bb82b1be/attachment.html>

From lomahu at gmail.com  Fri Aug  2 08:04:24 2019
From: lomahu at gmail.com (Howard)
Date: Fri, 2 Aug 2019 08:04:24 -0400
Subject: [Rtk-users] wrong projection geometry?
In-Reply-To: <CAF0oig2yWJ+Be2DbtxokHtn8nu_wJ=7CzSOzeSb3EDCQ4QQhcA@mail.gmail.com>
References: <CAKr9h5V1BamYdRFZpZ6XMJhOnSSo9S9vSQ6dhvmxGnpPbSuG2g@mail.gmail.com>
 <CAF0oig2yWJ+Be2DbtxokHtn8nu_wJ=7CzSOzeSb3EDCQ4QQhcA@mail.gmail.com>
Message-ID: <CAKr9h5XOCQUHv8S5saEdzo-hcCE5seOvbC_qy3k8HZaXT75k+g@mail.gmail.com>

Hi Simon,

I did run a full acquisition but with less projection views and it turned
out that the streaks were due to short angles, ie, 180 degree is not
sufficient. Thanks for your reply.

Howard

On Thu, Aug 1, 2019 at 10:42 PM Simon Rit <simon.rit at creatis.insa-lyon.fr>
wrote:

> Hi,
> From what I see in your reconstruction screenshot, you have mainly one
> projection. 180? is too short for a short scan so I suggest to have at
> least 180?+cone angle. Don't you get a warning when launching the command
> line? It's hard to anticipate what happens if you don't use this amount of
> data.
> Since it's a Gate simulation, I suggest to start with a full acquisition
> to check that everything else is correct (distances, rotation direction,
> etc).
> Don't hesitate to share your Gate macro if you want us to check the
> geometry.
> Note that your spacing and origin parameters need commas instead of spaces
> or quotes to be adequately interpreted
> Simon
>
> On Sun, Jul 28, 2019 at 5:15 PM Howard <lomahu at gmail.com> wrote:
>
>> Hi,
>>
>> I tried to run the application rtkfdk to reconstruct CBCT from 180
>> projections (from 0 degree to 180 degree only) that were generated using
>> Gate simulation. Here is the geometry of the simulation:
>>
>> a cylindrical phantom (radius=8mm, height=20mm) sitting on a turntable
>> X-ray source to isocenter (center of the cylindrical phantom) = 80mm (SAD)
>> Flat panel imager (60mm x 60mm) to isocenter = 80mm (SDD=160mm)
>>
>> x direction: perpendicular to y direction which is the direction from
>> detector to X-ray source;
>> z direction: turntable rotation axis and pointing upward
>>
>> I used rtksimulatedgeometry application to generate the geometry xml file
>> following the simulation geometry with the command:
>> rtksimulatedgeometry -n 180 --arc 180 -o geo.xml --sid 80 -sdd 160
>> --proj_iso_x -30 --proj_iso_y -30
>>
>> Subsequently the CBCT was reconstructed with the rtkfdk application with
>> the command:
>> rtkfdk -g geo.xml -p . -r proj.mha -o test.mha --spacing 0.1 0.1 0.2
>> --dimension 160,160,100 --origin -8 -8 -10
>>
>> However, the reconstruction result does not look correct. Particularly
>> the axial and sagittal views have a lot of streaks. For your reference, I
>> am sharing the snapshots of the projections and the reconstructed CBCT in
>> the following link:
>>
>> projection screenshot:         https://ibb.co/PCTjzrt
>> reconstruction screenshot:  https://ibb.co/QCjjvQt
>>
>> What did I do wrong or miss? Or streaks are due to partial projections,
>> ie, only 180 views? Your help would be greatly appreciated.
>>
>> Best,
>> Howard
>> _______________________________________________
>> 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: <https://public.kitware.com/pipermail/rtk-users/attachments/20190802/ff1313c2/attachment.html>

From pavel.kudrna83 at gmail.com  Thu Aug  8 02:46:55 2019
From: pavel.kudrna83 at gmail.com (Pavel Kudrna)
Date: Thu, 8 Aug 2019 08:46:55 +0200
Subject: [Rtk-users] RTK simulating projection from defined object (Shepp
 Logan like txt file) issue
Message-ID: <5d4bc55e.1c69fb81.ae618.5e3b@mx.google.com>

Hi,

I am prety new to RTK, but through I am learning with it I found a issue the is not clear to me. I followed the procedure from http://wiki.openrtk.org/index.php/RTK/Scripts/3DCG where I changed few things:

1) I simplified the Shepp Logan file to just simple sphere (in attachement).
2) I generated projections (using output_xml.xml ? two whole gantry rotation in two diffferent y offsets) ? the xml has been generated via python script (most of it-in attachment) which is reproducing procedure described in http://www.openrtk.org/Doxygen/DocGeo3D.html
3) Then I looked at the projections.mha in VolView (too large to send, please see the screenshot bellow)

My questions are 2:

1) Why there is a shift in Y-Z quadrant in generated projections.mha? It should be perfectly alligned ? two of my colleagues has been so kind to check the procedure for me and found no mistake (the sinogram of sphere in the zero position(x=y=z=0) should be symetric perfectly) ? what I am doing wrong?
2) I simulated corrected projection byte by byte (into MHA) and then tried to use back-projection  (rtkfdk) and Sart (rtksart)-you can see in output_xml.xml that the gantry angle is linear (not between -180? and 180? or between 0? and 360?), because when I put it into -180? and 180? it didn?t reconstruct anything properly ? why is it? It is not possible to use same angle value more then once in xml geometry file (even if it has different y shift of detector and source)?

Purpose of this testing is that I am going to reconstruct data from helical CT, but my first attemattempt failed and I am going step by step to find out hat is wrong in my procedure.

I use docker version of RTK given by http://wiki.openrtk.org/index.php/RTK_wiki_help

Thank you?

Kind regards?

p.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190808/c3f7a7fb/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: SheppLogan2.txt
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190808/c3f7a7fb/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output_xml.xml
Type: application/xml
Size: 245302 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190808/c3f7a7fb/attachment-0001.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: geometry.py
Type: application/octet-stream
Size: 3387 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190808/c3f7a7fb/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 08FF49AC74FA430CA987CFB67043208B.png
Type: image/png
Size: 100598 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190808/c3f7a7fb/attachment-0001.png>

From pavel.kudrna83 at gmail.com  Fri Aug  9 01:15:33 2019
From: pavel.kudrna83 at gmail.com (Pavel Kudrna)
Date: Fri, 9 Aug 2019 07:15:33 +0200
Subject: [Rtk-users] Rtk-users Digest, Vol 83, Issue 2
In-Reply-To: <mailman.491.1565246823.2707.rtk-users@public.kitware.com>
References: <mailman.491.1565246823.2707.rtk-users@public.kitware.com>
Message-ID: <5d4d0174.1c69fb81.aadb0.e949@mx.google.com>

Hi, my bad, taking it back (solved). Sorry.

Pavel

Od: rtk-users-request at public.kitware.com
Odesl?no:?tvrtek 8. srpna 2019 8:47
Komu: rtk-users at public.kitware.com
P?edm?t: Rtk-users Digest, Vol 83, Issue 2

Send Rtk-users mailing list submissions to
	rtk-users at public.kitware.com

To subscribe or unsubscribe via the World Wide Web, visit
	https://public.kitware.com/mailman/listinfo/rtk-users
or, via email, send a message with subject or body 'help' to
	rtk-users-request at public.kitware.com

You can reach the person managing the list at
	rtk-users-owner at public.kitware.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Rtk-users digest..."


Today's Topics:

   1. RTK simulating projection from defined object (Shepp Logan
      like txt file) issue (Pavel Kudrna)


----------------------------------------------------------------------

Message: 1
Date: Thu, 8 Aug 2019 08:46:55 +0200
From: Pavel Kudrna <pavel.kudrna83 at gmail.com>
To: "rtk-users at public.kitware.com" <rtk-users at public.kitware.com>
Subject: [Rtk-users] RTK simulating projection from defined object
	(Shepp Logan like txt file) issue
Message-ID: <5d4bc55e.1c69fb81.ae618.5e3b at mx.google.com>
Content-Type: text/plain; charset="utf-8"

Hi,

I am prety new to RTK, but through I am learning with it I found a issue the is not clear to me. I followed the procedure from http://wiki.openrtk.org/index.php/RTK/Scripts/3DCG where I changed few things:

1) I simplified the Shepp Logan file to just simple sphere (in attachement).
2) I generated projections (using output_xml.xml ? two whole gantry rotation in two diffferent y offsets) ? the xml has been generated via python script (most of it-in attachment) which is reproducing procedure described in http://www.openrtk.org/Doxygen/DocGeo3D.html
3) Then I looked at the projections.mha in VolView (too large to send, please see the screenshot bellow)

My questions are 2:

1) Why there is a shift in Y-Z quadrant in generated projections.mha? It should be perfectly alligned ? two of my colleagues has been so kind to check the procedure for me and found no mistake (the sinogram of sphere in the zero position(x=y=z=0) should be symetric perfectly) ? what I am doing wrong?
2) I simulated corrected projection byte by byte (into MHA) and then tried to use back-projection  (rtkfdk) and Sart (rtksart)-you can see in output_xml.xml that the gantry angle is linear (not between -180? and 180? or between 0? and 360?), because when I put it into -180? and 180? it didn?t reconstruct anything properly ? why is it? It is not possible to use same angle value more then once in xml geometry file (even if it has different y shift of detector and source)?

Purpose of this testing is that I am going to reconstruct data from helical CT, but my first attemattempt failed and I am going step by step to find out hat is wrong in my procedure.

I use docker version of RTK given by http://wiki.openrtk.org/index.php/RTK_wiki_help

Thank you?

Kind regards?

p.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190808/c3f7a7fb/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: SheppLogan2.txt
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190808/c3f7a7fb/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output_xml.xml
Type: application/xml
Size: 245302 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190808/c3f7a7fb/attachment.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: geometry.py
Type: application/octet-stream
Size: 3387 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190808/c3f7a7fb/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 08FF49AC74FA430CA987CFB67043208B.png
Type: image/png
Size: 100598 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190808/c3f7a7fb/attachment.png>

------------------------------

Subject: Digest Footer

_______________________________________________
Rtk-users mailing list
Rtk-users at public.kitware.com
https://public.kitware.com/mailman/listinfo/rtk-users


------------------------------

End of Rtk-users Digest, Vol 83, Issue 2
****************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190809/a08f8d87/attachment.html>

From blacava at mevion.com  Tue Aug 13 14:03:45 2019
From: blacava at mevion.com (Brandon LaCava)
Date: Tue, 13 Aug 2019 14:03:45 -0400
Subject: [Rtk-users] Forward projector output discrepancy
Message-ID: <CAK+XoOvLmbtFFpdHnhKkK7XUKhRFebWwJ-+hWVj_uDod5gXS0w@mail.gmail.com>

Hi. I'm getting vastly different outputs from the Joseph forward projector
vs. Cuda, given the exact same inputs. I'm hoping someone has any idea why.
Here's some sample images:

1. Joseph

[image: drr_Jospeph.png]

2. Cuda

[image: drr_CudaRayCast.png]

The general orientation looks the same, but the FOV is wildly different.
I've attached a small stripped-down rtkforwardprojections.cxx which was
used to generate these images. Literally the only difference between the
two runs is the projector type. Everything else is identical. Input is from
a CT MHD, output to PNG. Same result on Windows and Linux.

Any help here would be appreciated. Thanks!

Cheers,
Brandon

-- 
This electronic mail (including any attachments) may contain information 
that is privileged, confidential, and/or otherwise protected from 
disclosure to anyone other than its intended recipient(s). Any 
dissemination or use of this electronic email or its contents (including 
any attachments) by persons other than the intended recipient(s) is 
strictly prohibited. If you have received this message in error, please 
notify us immediately by reply email so that we may correct our internal 
records. Please then delete the original message (including any 
attachments) in its entirety. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190813/f4668763/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drr_Jospeph.png
Type: image/png
Size: 48562 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190813/f4668763/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drr_CudaRayCast.png
Type: image/png
Size: 129213 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190813/f4668763/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtkforwardprojections.cxx
Type: application/octet-stream
Size: 5427 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190813/f4668763/attachment-0001.obj>

From simon.rit at creatis.insa-lyon.fr  Wed Aug 14 08:17:30 2019
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 14 Aug 2019 14:17:30 +0200
Subject: [Rtk-users] Forward projector output discrepancy
In-Reply-To: <CAK+XoOvLmbtFFpdHnhKkK7XUKhRFebWwJ-+hWVj_uDod5gXS0w@mail.gmail.com>
References: <CAK+XoOvLmbtFFpdHnhKkK7XUKhRFebWwJ-+hWVj_uDod5gXS0w@mail.gmail.com>
Message-ID: <CAF0oig31cTgM7z7NB2=peUwr5CjvSbspGmJDuE3+aXc2KtuFyA@mail.gmail.com>

Hi Brandon,
Thanks for reporting the weird behavior. This is a bug, you're trying to
project with a parallel geometry and the Cuda forward projector does not
support parallel geometry. I have fixed the code and you should now get the
expected exception, see this patch
<https://github.com/SimonRit/RTK/commit/b433503bcd38bf8b75bbd0e37fa009d0486228f1>
.
Sorry about that...
Simon

On Tue, Aug 13, 2019 at 8:04 PM Brandon LaCava via Rtk-users <
rtk-users at public.kitware.com> wrote:

> Hi. I'm getting vastly different outputs from the Joseph forward projector
> vs. Cuda, given the exact same inputs. I'm hoping someone has any idea why.
> Here's some sample images:
>
> 1. Joseph
>
> [image: drr_Jospeph.png]
>
> 2. Cuda
>
> [image: drr_CudaRayCast.png]
>
> The general orientation looks the same, but the FOV is wildly different.
> I've attached a small stripped-down rtkforwardprojections.cxx which was
> used to generate these images. Literally the only difference between the
> two runs is the projector type. Everything else is identical. Input is from
> a CT MHD, output to PNG. Same result on Windows and Linux.
>
> Any help here would be appreciated. Thanks!
>
> Cheers,
> Brandon
>
>
>
> This electronic mail (including any attachments) may contain information
> that is privileged, confidential, and/or otherwise protected from
> disclosure to anyone other than its intended recipient(s). Any
> dissemination or use of this electronic email or its contents (including
> any attachments) by persons other than the intended recipient(s) is
> strictly prohibited. If you have received this message in error, please
> notify us immediately by reply email so that we may correct our internal
> records. Please then delete the original message (including any
> attachments) in its entirety. Thank 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: <https://public.kitware.com/pipermail/rtk-users/attachments/20190814/08783a98/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drr_Jospeph.png
Type: image/png
Size: 48562 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190814/08783a98/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drr_CudaRayCast.png
Type: image/png
Size: 129213 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190814/08783a98/attachment-0003.png>

From blacava at mevion.com  Thu Aug 15 18:30:33 2019
From: blacava at mevion.com (Brandon LaCava)
Date: Thu, 15 Aug 2019 18:30:33 -0400
Subject: [Rtk-users] Forward projector output discrepancy
In-Reply-To: <CAF0oig31cTgM7z7NB2=peUwr5CjvSbspGmJDuE3+aXc2KtuFyA@mail.gmail.com>
References: <CAK+XoOvLmbtFFpdHnhKkK7XUKhRFebWwJ-+hWVj_uDod5gXS0w@mail.gmail.com>
 <CAF0oig31cTgM7z7NB2=peUwr5CjvSbspGmJDuE3+aXc2KtuFyA@mail.gmail.com>
Message-ID: <CAK+XoOuHg5LHf_=z7Cg+Qa7f7koE4AmsX+kL6147B7bxAQsLOw@mail.gmail.com>

No worries, thanks for the quick response.

Cheers,
Brandon

On Wed, Aug 14, 2019 at 8:16 AM Simon Rit <simon.rit at creatis.insa-lyon.fr>
wrote:

> Hi Brandon,
> Thanks for reporting the weird behavior. This is a bug, you're trying to
> project with a parallel geometry and the Cuda forward projector does not
> support parallel geometry. I have fixed the code and you should now get the
> expected exception, see this patch
> <https://github.com/SimonRit/RTK/commit/b433503bcd38bf8b75bbd0e37fa009d0486228f1>
> .
> Sorry about that...
> Simon
>
> On Tue, Aug 13, 2019 at 8:04 PM Brandon LaCava via Rtk-users <
> rtk-users at public.kitware.com> wrote:
>
>> Hi. I'm getting vastly different outputs from the Joseph forward
>> projector vs. Cuda, given the exact same inputs. I'm hoping someone has any
>> idea why. Here's some sample images:
>>
>> 1. Joseph
>>
>> [image: drr_Jospeph.png]
>>
>> 2. Cuda
>>
>> [image: drr_CudaRayCast.png]
>>
>> The general orientation looks the same, but the FOV is wildly different.
>> I've attached a small stripped-down rtkforwardprojections.cxx which was
>> used to generate these images. Literally the only difference between the
>> two runs is the projector type. Everything else is identical. Input is from
>> a CT MHD, output to PNG. Same result on Windows and Linux.
>>
>> Any help here would be appreciated. Thanks!
>>
>> Cheers,
>> Brandon
>>
>>
>>
>> This electronic mail (including any attachments) may contain information
>> that is privileged, confidential, and/or otherwise protected from
>> disclosure to anyone other than its intended recipient(s). Any
>> dissemination or use of this electronic email or its contents (including
>> any attachments) by persons other than the intended recipient(s) is
>> strictly prohibited. If you have received this message in error, please
>> notify us immediately by reply email so that we may correct our internal
>> records. Please then delete the original message (including any
>> attachments) in its entirety. Thank you.
>> _______________________________________________
>> Rtk-users mailing list
>> Rtk-users at public.kitware.com
>> https://public.kitware.com/mailman/listinfo/rtk-users
>>
>

-- 

*Brandon LaCava*
Senior Software Engineer

*Mevion Medical Systems*
300 Foster Street
Littleton MA 01460
+1.978.540.1680 (office)

-- 
This electronic mail (including any attachments) may contain information 
that is privileged, confidential, and/or otherwise protected from 
disclosure to anyone other than its intended recipient(s). Any 
dissemination or use of this electronic email or its contents (including 
any attachments) by persons other than the intended recipient(s) is 
strictly prohibited. If you have received this message in error, please 
notify us immediately by reply email so that we may correct our internal 
records. Please then delete the original message (including any 
attachments) in its entirety. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190815/ebbf2648/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drr_Jospeph.png
Type: image/png
Size: 48562 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190815/ebbf2648/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drr_CudaRayCast.png
Type: image/png
Size: 129213 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190815/ebbf2648/attachment-0003.png>

From wuchao04 at gmail.com  Mon Aug 19 16:14:48 2019
From: wuchao04 at gmail.com (Chao Wu)
Date: Mon, 19 Aug 2019 22:14:48 +0200
Subject: [Rtk-users] bWithExternalHalfPixelBorder in
 RayBoxIntersectionImageFilter
Message-ID: <CAH+sHrUY+QCF=V66BW21T4q8aB7uTmam-Y7Lky50DWTdgsHxiQ@mail.gmail.com>

L.S.,

I have noticed a behaviour change in SART after commit 5dc1d78.
In SARTConeBeamReconstructionFilter,
m_RayBoxFilter->SetBoxFromImage(this->GetInput(0),
false) attempts to pass false to bWithExternalHalfPixelBorder, although
before this commit this variable was not used in
RayBoxIntersectionImageFilter::SetBoxFromImage and then when
rtk::BoxShape::SetBoxFromImage is called the default half pixel border flag
was set to true. After this commit a false can finally be passed through.
This gives slight different reconstruction results than before. I was just
wondering which one is more correct, with or without the half pixel border
for the volume used for the normalization. I tried to follow the external
link of explanation given in the code of SetBoxFromImage but found it
broken. Could anyone give a brief explanation? Thanks.

Best regards,
Chao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20190819/79e5d964/attachment.html>

From clem.schmid at gmail.com  Tue Aug 20 14:01:32 2019
From: clem.schmid at gmail.com (C S)
Date: Tue, 20 Aug 2019 14:01:32 -0400
Subject: [Rtk-users] GPU support of PyPI package
In-Reply-To: <CAF0oig2C3kPSdE_2efvXKY-S_0XW3_p+nWjBHyhOmXRoXmJSVw@mail.gmail.com>
References: <CAFf9RYav68J=jNBu5BWqkjsc=51ucqFW0z9oA3YJmEV7MyaFVw@mail.gmail.com>
 <CAF0oig0AvbDWKxvuWpcF7PftegKGGcdM2iTrU20wVuw=L4FM0A@mail.gmail.com>
 <CAFf9RYYjwnzJBMGVZ_khvS5yh_g6GSntr7gr41T1KOS52DZXfg@mail.gmail.com>
 <CAF0oig2C3kPSdE_2efvXKY-S_0XW3_p+nWjBHyhOmXRoXmJSVw@mail.gmail.com>
Message-ID: <CAFf9RYbdCmFjzQ3vLAWE7ddN+eUpt+FiJcZ3frfunNAcOLTGcg@mail.gmail.com>

Hi Simon,

I have a follow up question: When installing RTK as an ITK module as per
your suggestion, which RTK version is used? Is the latest release (2.0.1)
bundled with ITK or is the newest RTK pulled from Github?

I ask this because I have a feeling I would benefit from using this commit
<https://github.com/SimonRit/RTK/commit/99a6626f42e6654d11a780127610c95d3c1a063e>
and
am wondering what's the best pratice to install it.


Thank you very much
Clemens

On Wed, Jul 3, 2019 at 2:12 AM Simon Rit <simon.rit at creatis.insa-lyon.fr>
wrote:

> You never need this option except for using ExtractPhaseImageFilter
> <http://www.openrtk.org/Doxygen/classrtk_1_1ExtractPhaseImageFilter.html>
> but it makes the CPU version faster. So you don't need it if you only use
> the GPU version of FDK. I don't know anlything about ITK_USE_CUFFTW, it's a
> recent option I've never used...
> Cheers,
> Simon
>
> On Tue, Jul 2, 2019 at 11:01 PM C S <clem.schmid at gmail.com> wrote:
>
>> Hi Simon,
>>
>> thank you very much for your swift answer!
>>
>> If compiling for GPU, I don't need ITK_USE_FFTWD or ITK_USE_FFTWF, right?
>> Would you recommend using ITK_USE_CUFFTW?
>>
>>
>> Best
>> Clemens
>>
>> Am Di., 2. Juli 2019 um 11:56 Uhr schrieb Simon Rit <
>> simon.rit at creatis.insa-lyon.fr>:
>>
>>> Hi,
>>> No yet! We aim at proposing this soon but it's not ready. The best
>>> practice is to build from ITK, turn on Module_RTK, RTK_USE_CUDA and
>>> ITK_WRAP_PYTHON.
>>> Someone has already requested a proper compilation doc, we'll work on it
>>> asap, sorry for the inconvenience.
>>> Simon
>>>
>>> On Tue, Jul 2, 2019 at 5:51 PM C S <clem.schmid at gmail.com> wrote:
>>>
>>>> Dear RTK users,
>>>>
>>>> is there a possibility to get GPU support within RTK from the PyPI
>>>> package "itk-rtk"?
>>>> https://pypi.org/project/itk-rtk/
>>>>
>>>> If not, what is the current "best practice" building RTK with GPU and
>>>> Python bindings? I'm on Ubuntu 18.04 with CUDA 10.0.
>>>>
>>>>
>>>> Thank you very much for your help!
>>>> Clemens
>>>> _______________________________________________
>>>> 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: <https://public.kitware.com/pipermail/rtk-users/attachments/20190820/0fe54dac/attachment.html>

From andreasga22 at gmail.com  Wed Aug 21 10:12:42 2019
From: andreasga22 at gmail.com (Andreas Andersen)
Date: Wed, 21 Aug 2019 16:12:42 +0200
Subject: [Rtk-users] GPU support of PyPI package
In-Reply-To: <CAFf9RYbdCmFjzQ3vLAWE7ddN+eUpt+FiJcZ3frfunNAcOLTGcg@mail.gmail.com>
References: <CAFf9RYav68J=jNBu5BWqkjsc=51ucqFW0z9oA3YJmEV7MyaFVw@mail.gmail.com>
 <CAF0oig0AvbDWKxvuWpcF7PftegKGGcdM2iTrU20wVuw=L4FM0A@mail.gmail.com>
 <CAFf9RYYjwnzJBMGVZ_khvS5yh_g6GSntr7gr41T1KOS52DZXfg@mail.gmail.com>
 <CAF0oig2C3kPSdE_2efvXKY-S_0XW3_p+nWjBHyhOmXRoXmJSVw@mail.gmail.com>
 <CAFf9RYbdCmFjzQ3vLAWE7ddN+eUpt+FiJcZ3frfunNAcOLTGcg@mail.gmail.com>
Message-ID: <CAE0aawH0yWKv0gVoxbYAnJ6H4oNDXzg7J0HfmE1TC08yb4ey8w@mail.gmail.com>

Hi Clemens
You can use the CMake variable, REMOTE_GIT_TAG_RTK, to set the tag of RTK
you want to use, e.g. master
I think the default value is v2.0.1

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 Tue, 20 Aug 2019 at 20:01, C S <clem.schmid at gmail.com> wrote:

> Hi Simon,
>
> I have a follow up question: When installing RTK as an ITK module as per
> your suggestion, which RTK version is used? Is the latest release (2.0.1)
> bundled with ITK or is the newest RTK pulled from Github?
>
> I ask this because I have a feeling I would benefit from using this commit
> <https://github.com/SimonRit/RTK/commit/99a6626f42e6654d11a780127610c95d3c1a063e> and
> am wondering what's the best pratice to install it.
>
>
> Thank you very much
> Clemens
>
> On Wed, Jul 3, 2019 at 2:12 AM Simon Rit <simon.rit at creatis.insa-lyon.fr>
> wrote:
>
>> You never need this option except for using ExtractPhaseImageFilter
>> <http://www.openrtk.org/Doxygen/classrtk_1_1ExtractPhaseImageFilter.html>
>> but it makes the CPU version faster. So you don't need it if you only use
>> the GPU version of FDK. I don't know anlything about ITK_USE_CUFFTW, it's a
>> recent option I've never used...
>> Cheers,
>> Simon
>>
>> On Tue, Jul 2, 2019 at 11:01 PM C S <clem.schmid at gmail.com> wrote:
>>
>>> Hi Simon,
>>>
>>> thank you very much for your swift answer!
>>>
>>> If compiling for GPU, I don't need ITK_USE_FFTWD or ITK_USE_FFTWF,
>>> right? Would you recommend using ITK_USE_CUFFTW?
>>>
>>>
>>> Best
>>> Clemens
>>>
>>> Am Di., 2. Juli 2019 um 11:56 Uhr schrieb Simon Rit <
>>> simon.rit at creatis.insa-lyon.fr>:
>>>
>>>> Hi,
>>>> No yet! We aim at proposing this soon but it's not ready. The best
>>>> practice is to build from ITK, turn on Module_RTK, RTK_USE_CUDA and
>>>> ITK_WRAP_PYTHON.
>>>> Someone has already requested a proper compilation doc, we'll work on
>>>> it asap, sorry for the inconvenience.
>>>> Simon
>>>>
>>>> On Tue, Jul 2, 2019 at 5:51 PM C S <clem.schmid at gmail.com> wrote:
>>>>
>>>>> Dear RTK users,
>>>>>
>>>>> is there a possibility to get GPU support within RTK from the PyPI
>>>>> package "itk-rtk"?
>>>>> https://pypi.org/project/itk-rtk/
>>>>>
>>>>> If not, what is the current "best practice" building RTK with GPU and
>>>>> Python bindings? I'm on Ubuntu 18.04 with CUDA 10.0.
>>>>>
>>>>>
>>>>> Thank you very much for your help!
>>>>> Clemens
>>>>> _______________________________________________
>>>>> 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: <https://public.kitware.com/pipermail/rtk-users/attachments/20190821/c6029dd6/attachment.html>

From simon.rit at creatis.insa-lyon.fr  Thu Aug 22 15:49:22 2019
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 22 Aug 2019 21:49:22 +0200
Subject: [Rtk-users] GPU support of PyPI package
In-Reply-To: <CAE0aawH0yWKv0gVoxbYAnJ6H4oNDXzg7J0HfmE1TC08yb4ey8w@mail.gmail.com>
References: <CAFf9RYav68J=jNBu5BWqkjsc=51ucqFW0z9oA3YJmEV7MyaFVw@mail.gmail.com>
 <CAF0oig0AvbDWKxvuWpcF7PftegKGGcdM2iTrU20wVuw=L4FM0A@mail.gmail.com>
 <CAFf9RYYjwnzJBMGVZ_khvS5yh_g6GSntr7gr41T1KOS52DZXfg@mail.gmail.com>
 <CAF0oig2C3kPSdE_2efvXKY-S_0XW3_p+nWjBHyhOmXRoXmJSVw@mail.gmail.com>
 <CAFf9RYbdCmFjzQ3vLAWE7ddN+eUpt+FiJcZ3frfunNAcOLTGcg@mail.gmail.com>
 <CAE0aawH0yWKv0gVoxbYAnJ6H4oNDXzg7J0HfmE1TC08yb4ey8w@mail.gmail.com>
Message-ID: <CAF0oig0WSv_WrYrs0twHLfouJeR4nYAwYp-ydTveBmv8rPCYuA@mail.gmail.com>

Hi,
Yes, v2.0.1 is the defauts (see here
<https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Remote/RTK.remote.cmake>)
but you can specify another tag as pointed out by Andreas.
Best regards,
Simon

On Wed, Aug 21, 2019 at 4:14 PM Andreas Andersen <andreasga22 at gmail.com>
wrote:

> Hi Clemens
> You can use the CMake variable, REMOTE_GIT_TAG_RTK, to set the tag of RTK
> you want to use, e.g. master
> I think the default value is v2.0.1
>
> 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 Tue, 20 Aug 2019 at 20:01, C S <clem.schmid at gmail.com> wrote:
>
>> Hi Simon,
>>
>> I have a follow up question: When installing RTK as an ITK module as per
>> your suggestion, which RTK version is used? Is the latest release (2.0.1)
>> bundled with ITK or is the newest RTK pulled from Github?
>>
>> I ask this because I have a feeling I would benefit from using this
>> commit
>> <https://github.com/SimonRit/RTK/commit/99a6626f42e6654d11a780127610c95d3c1a063e> and
>> am wondering what's the best pratice to install it.
>>
>>
>> Thank you very much
>> Clemens
>>
>> On Wed, Jul 3, 2019 at 2:12 AM Simon Rit <simon.rit at creatis.insa-lyon.fr>
>> wrote:
>>
>>> You never need this option except for using ExtractPhaseImageFilter
>>> <http://www.openrtk.org/Doxygen/classrtk_1_1ExtractPhaseImageFilter.html>
>>> but it makes the CPU version faster. So you don't need it if you only use
>>> the GPU version of FDK. I don't know anlything about ITK_USE_CUFFTW, it's a
>>> recent option I've never used...
>>> Cheers,
>>> Simon
>>>
>>> On Tue, Jul 2, 2019 at 11:01 PM C S <clem.schmid at gmail.com> wrote:
>>>
>>>> Hi Simon,
>>>>
>>>> thank you very much for your swift answer!
>>>>
>>>> If compiling for GPU, I don't need ITK_USE_FFTWD or ITK_USE_FFTWF,
>>>> right? Would you recommend using ITK_USE_CUFFTW?
>>>>
>>>>
>>>> Best
>>>> Clemens
>>>>
>>>> Am Di., 2. Juli 2019 um 11:56 Uhr schrieb Simon Rit <
>>>> simon.rit at creatis.insa-lyon.fr>:
>>>>
>>>>> Hi,
>>>>> No yet! We aim at proposing this soon but it's not ready. The best
>>>>> practice is to build from ITK, turn on Module_RTK, RTK_USE_CUDA and
>>>>> ITK_WRAP_PYTHON.
>>>>> Someone has already requested a proper compilation doc, we'll work on
>>>>> it asap, sorry for the inconvenience.
>>>>> Simon
>>>>>
>>>>> On Tue, Jul 2, 2019 at 5:51 PM C S <clem.schmid at gmail.com> wrote:
>>>>>
>>>>>> Dear RTK users,
>>>>>>
>>>>>> is there a possibility to get GPU support within RTK from the PyPI
>>>>>> package "itk-rtk"?
>>>>>> https://pypi.org/project/itk-rtk/
>>>>>>
>>>>>> If not, what is the current "best practice" building RTK with GPU and
>>>>>> Python bindings? I'm on Ubuntu 18.04 with CUDA 10.0.
>>>>>>
>>>>>>
>>>>>> Thank you very much for your help!
>>>>>> Clemens
>>>>>> _______________________________________________
>>>>>> 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: <https://public.kitware.com/pipermail/rtk-users/attachments/20190822/20422530/attachment.html>

From simon.rit at creatis.insa-lyon.fr  Tue Aug 27 03:21:08 2019
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 27 Aug 2019 09:21:08 +0200
Subject: [Rtk-users] bWithExternalHalfPixelBorder in
 RayBoxIntersectionImageFilter
In-Reply-To: <CAH+sHrUY+QCF=V66BW21T4q8aB7uTmam-Y7Lky50DWTdgsHxiQ@mail.gmail.com>
References: <CAH+sHrUY+QCF=V66BW21T4q8aB7uTmam-Y7Lky50DWTdgsHxiQ@mail.gmail.com>
Message-ID: <CAF0oig3t7Uc2J+mOmgONMZ6Eyiv-jcNZH=Kts=4PQLsN+jxfiQ@mail.gmail.com>

Dear Chao,
Thanks for the question and sorry for the delay in answering it. The
boolean allows to determine if the box goes from itk::Image::Origin to the
coordinate of the last pixel or whether you want to add a half voxel
border, see code here
<https://github.com/SimonRit/RTK/blob/master/src/rtkBoxShape.cxx#L147-L168>.
In SART, you want to divide the difference between the projection and the
measure by the projection of a volume filled with one. Our projectors
consider that the intensity is 0 before Origin and after the coordinate of
the last pixel so I think the current version is the correct one. The
rtkforwardprojectiontest.cxx
<https://github.com/SimonRit/RTK/blob/master/test/rtkforwardprojectiontest.cxx>
tests this and you can check in it that there is indeed no half pixel
border. So I believe this is the right thing to do, yes.
Best regards,
Simon

On Mon, Aug 19, 2019 at 10:15 PM Chao Wu <wuchao04 at gmail.com> wrote:

> L.S.,
>
> I have noticed a behaviour change in SART after commit 5dc1d78.
> In SARTConeBeamReconstructionFilter, m_RayBoxFilter->SetBoxFromImage(this->GetInput(0),
> false) attempts to pass false to bWithExternalHalfPixelBorder, although
> before this commit this variable was not used in
> RayBoxIntersectionImageFilter::SetBoxFromImage and then when
> rtk::BoxShape::SetBoxFromImage is called the default half pixel border flag
> was set to true. After this commit a false can finally be passed through.
> This gives slight different reconstruction results than before. I was just
> wondering which one is more correct, with or without the half pixel border
> for the volume used for the normalization. I tried to follow the external
> link of explanation given in the code of SetBoxFromImage but found it
> broken. Could anyone give a brief explanation? Thanks.
>
> Best regards,
> Chao
> _______________________________________________
> 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: <https://public.kitware.com/pipermail/rtk-users/attachments/20190827/ec603658/attachment.html>