From simon.rit at creatis.insa-lyon.fr  Mon Sep  4 02:13:24 2017
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 4 Sep 2017 08:13:24 +0200
Subject: [Rtk-users] SIRT Reconstruction
In-Reply-To: <5a6fb32b-07f4-4c46-93af-87287ce17b5e@email.android.com>
References: <763665cf-80d7-261a-32b2-4fa4700d4e4d@maastro.nl>
 <5a6fb32b-07f4-4c46-93af-87287ce17b5e@email.android.com>
Message-ID: <CAF0oig0D3iuDf26vWjifonQKMVvBSdd=qkYd-3NM4BAMrk=MUg@mail.gmail.com>

Dear Lotte,
Thanks for the data. I have had a look (you can thank Ana for the
reminder).  The snapshots show indeed a bad result. My advice is to work on
a small example first, as the one enclosed for this test (you can create
one from real data to). Since I have never worked with SIRT before, I first
checked SIRT's definition and let's agree on this paper
dx.doi.org/10.1109/TMI.2008.923696 (which I recommend if you want to use
SIRT). Then I noticed that it does not update after the first iteration
and, indeed, the last subset was not used which gets unnoticed with SART
but not with SIRT... The fix is in a new branch named sirt and will be
merged later today if all tests pass. The results look more as expected,
i.e., no convergence after 100 iterations but something closer to the
solution. Check the mentionned reference for improving convergence (they
suggest 1.99 as a relaxation parameter) but my feeling is that the
conjugate gradient algorithm is more efficient (and it's been more tested
in RTK).
Best regards,
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20170904/59fd36b4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.sh
Type: application/x-sh
Size: 285 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20170904/59fd36b4/attachment.sh>

From simon.rit at creatis.insa-lyon.fr  Mon Sep  4 02:19:32 2017
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 4 Sep 2017 08:19:32 +0200
Subject: [Rtk-users] SIRT Reconstruction
In-Reply-To: <CAK3H5KUqy-tncBFrDxdo=bLZvs5Zidd+yYDsRcrzhKS7TpO5dw@mail.gmail.com>
References: <CAK3H5KUqy-tncBFrDxdo=bLZvs5Zidd+yYDsRcrzhKS7TpO5dw@mail.gmail.com>
Message-ID: <CAF0oig0u1=ZpeiBBkntBzFgjsJroFvk4B-_yefv1ALw=au+4_w@mail.gmail.com>

Thanks for the reminder. See:
https://public.kitware.com/pipermail/rtk-users/2017-September/010481.html

On Wed, Aug 30, 2017 at 11:46 AM, ana <anavaniqui at gmail.com> wrote:

> Hi,
>
> I was wondering if you guys had the opportunity to look into SIRT
> reconstruction.
> There was a thread on this topic on July 27th, in which a user, Lotte,
> described her results after 100 iterations. I am having the same issue
> myself. The SART reconstruction works perfectly fine but even after 100
> iterations, SIRT does not seem to improve.
> Regarding the example presented before, do you have any advice on how to
> improve it?
>
> Thank you very much.
>
> Kind regards,
> Ana
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20170904/179ee1ce/attachment.html>

From simon.rit at creatis.insa-lyon.fr  Wed Sep 20 15:18:23 2017
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 20 Sep 2017 21:18:23 +0200
Subject: [Rtk-users] Building RTK
In-Reply-To: <DM5PR01MB25221E18897B5B5BCAD0332DA8610@DM5PR01MB2522.prod.exchangelabs.com>
References: <DM5PR01MB25221E18897B5B5BCAD0332DA8610@DM5PR01MB2522.prod.exchangelabs.com>
Message-ID: <CAF0oig0EjiCfHYiGpezcoO10MZQWj5KBCOGEPtMOyMQWR_65_Q@mail.gmail.com>

Hi,
Please use the mailing list. I'm not a Windows user but I do have a
computer running nightly compilation but it's Win 7 and it might another
MSVC. I'll send what I have the next time I can access it (Friday or
Monday).
Normally, the default ITK modules are sufficient, for any ITK version more
recent than 4.2 and any CUDA more recent than 4.
Best regards,
Simon

On Wed, Sep 20, 2017 at 6:10 PM, Jie Ying Wu <jieying at jhu.edu> wrote:

> Hi Dr. Rit,
>
>
>
> I?m a PhD student at Johns Hopkins University and I?m trying to build RTK
> with CUDA, SimpleRTK and Python wrapping on Windows 10 and Visual Studio
> 2015. Unfortunately, I?m having a lot of trouble with it, in particular, it
> seems unable to  find a lot of ITK packages so I?m wondering if you give me
> some pointers.
>
>
>
> What version of ITK and CUDA did you compile against? Would you be willing
> to share your CMAKE configuration for both ITK and RTK so we can check if
> we are doing this correctly.
>
>
>
> Thanks for your help in advance!
>
> JieYing Wu
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20170920/ccbc9f88/attachment.html>

From jieying at jhu.edu  Thu Sep 21 11:53:51 2017
From: jieying at jhu.edu (Jie Ying Wu)
Date: Thu, 21 Sep 2017 11:53:51 -0400
Subject: [Rtk-users] Building RTK
In-Reply-To: <CAF0oig0EjiCfHYiGpezcoO10MZQWj5KBCOGEPtMOyMQWR_65_Q@mail.gmail.com>
References: <DM5PR01MB25221E18897B5B5BCAD0332DA8610@DM5PR01MB2522.prod.exchangelabs.com>
 <CAF0oig0EjiCfHYiGpezcoO10MZQWj5KBCOGEPtMOyMQWR_65_Q@mail.gmail.com>
Message-ID: <CY4PR01MB252064282C03A638D2AE763BA8660@CY4PR01MB2520.prod.exchangelabs.com>

Thanks for your prompt reply! We were having a bit of trouble subscribing to the mailing list but have fixed it now. We?ll email the list in the future. 

Jie Ying

From: Simon Rit
Sent: September 20, 2017 3:18 PM
To: Jie Ying Wu
Cc: rtk-users at openrtk.org
Subject: Re: Building RTK

Hi,
Please use the mailing list. I'm not a Windows user but I do have a computer running nightly compilation but it's Win 7 and it might another MSVC. I'll send what I have the next time I can access it (Friday or Monday).
Normally, the default ITK modules are sufficient, for any ITK version more recent than 4.2 and any CUDA more recent than 4.
Best regards,
Simon

On Wed, Sep 20, 2017 at 6:10 PM, Jie Ying Wu <jieying at jhu.edu> wrote:
Hi Dr. Rit,
?
I?m a PhD student at Johns Hopkins University and I?m trying to build RTK with CUDA, SimpleRTK and Python wrapping on Windows 10 and Visual Studio 2015. Unfortunately, I?m having a lot of trouble with it, in particular, it seems unable to? find a lot of ITK packages so I?m wondering if you give me some pointers. 
?
What version of ITK and CUDA did you compile against? Would you be willing to share your CMAKE configuration for both ITK and RTK so we can check if we are doing this correctly. 
?
Thanks for your help in advance!
JieYing Wu
?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20170921/e8b9e5b6/attachment.html>

From fredrik.hellman at gmail.com  Mon Sep 25 08:01:53 2017
From: fredrik.hellman at gmail.com (Fredrik Hellman)
Date: Mon, 25 Sep 2017 14:01:53 +0200
Subject: [Rtk-users] Parker short scan test for enough over scan
Message-ID: <CACMrisxjQ6ugg9eFxOk4eE-YmWTUxrAadyeaQQWPcLti4vfYTw@mail.gmail.com>

Hi,

In rtkParkerShortScanFilter.hxx (line 113) and
rtkCudaParkerShortScanFilter.cxx (line 95), the overscan angle is checked
to be large enough for the used beam fan angle. (There is a difference
between how this check is performed in the two cases. It seems like the
CUDA-version assumes that the piercing point is in the middle of the
detector. That's not what this question is about though.)

The beam fan angle seems to be computed as

arctan( halfDetectorWidth / sourceToIsocenterDistance )

Why sourceToIsocenterDistance? Shouldn't it be sourceToDetectorDistance? If
the detector is far away from the isocenter, the beam fan angle should also
be small as far as I understand. This is not reflected in this computation.

Best regards,
Fredrik Hellman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20170925/33b17fd1/attachment.html>

From wuchao04 at gmail.com  Mon Sep 25 08:26:32 2017
From: wuchao04 at gmail.com (Chao Wu)
Date: Mon, 25 Sep 2017 14:26:32 +0200
Subject: [Rtk-users] Parker short scan test for enough over scan
In-Reply-To: <CACMrisxjQ6ugg9eFxOk4eE-YmWTUxrAadyeaQQWPcLti4vfYTw@mail.gmail.com>
References: <CACMrisxjQ6ugg9eFxOk4eE-YmWTUxrAadyeaQQWPcLti4vfYTw@mail.gmail.com>
Message-ID: <CAH+sHrUX_HmhC1OqfHf0ihU03EGe-P9+vb_BWkV7c0RraOCXWg@mail.gmail.com>

Hi Fredrik,

It is because the "halfDetectorWidth" here is the value for an untilted
virtual detector at the isocenter which is equivalant to the real detector.

Regards,
Chao

2017-09-25 14:01 GMT+02:00 Fredrik Hellman <fredrik.hellman at gmail.com>:

> Hi,
>
> In rtkParkerShortScanFilter.hxx (line 113) and
> rtkCudaParkerShortScanFilter.cxx (line 95), the overscan angle is checked
> to be large enough for the used beam fan angle. (There is a difference
> between how this check is performed in the two cases. It seems like the
> CUDA-version assumes that the piercing point is in the middle of the
> detector. That's not what this question is about though.)
>
> The beam fan angle seems to be computed as
>
> arctan( halfDetectorWidth / sourceToIsocenterDistance )
>
> Why sourceToIsocenterDistance? Shouldn't it be sourceToDetectorDistance?
> If the detector is far away from the isocenter, the beam fan angle should
> also be small as far as I understand. This is not reflected in this
> computation.
>
> Best regards,
> Fredrik Hellman
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20170925/2f8ea5fc/attachment.html>

From simon.rit at creatis.insa-lyon.fr  Mon Sep 25 08:15:12 2017
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 25 Sep 2017 14:15:12 +0200
Subject: [Rtk-users] Parker short scan test for enough over scan
In-Reply-To: <CACMrisxjQ6ugg9eFxOk4eE-YmWTUxrAadyeaQQWPcLti4vfYTw@mail.gmail.com>
References: <CACMrisxjQ6ugg9eFxOk4eE-YmWTUxrAadyeaQQWPcLti4vfYTw@mail.gmail.com>
Message-ID: <CAF0oig3MDC=y-SeyicQBgStWr1B=bsh5Mrfugc6cpaKfJgHO7w@mail.gmail.com>

Hi,
Looking at the CPU code (which is more recent), it's because the width of
the detector is computed at the isocenter. You can have a look at function
ToUntiltedCoordinateAtIsocenter
<https://github.com/SimonRit/RTK/blob/master/code/rtkThreeDCircularProjectionGeometry.cxx#L519>
(in the standard case, you have sx=px=cosa=0). This complication comes to
deal with tilted detector, see this paper
<http://dx.doi.org/10.1118/1.4945418>.
There seems to be a bug in the GPU code, I'll submit an issue that it
should be fixed by making the two codes similar.
Simon

On Mon, Sep 25, 2017 at 2:01 PM, Fredrik Hellman <fredrik.hellman at gmail.com>
wrote:

> Hi,
>
> In rtkParkerShortScanFilter.hxx (line 113) and
> rtkCudaParkerShortScanFilter.cxx (line 95), the overscan angle is checked
> to be large enough for the used beam fan angle. (There is a difference
> between how this check is performed in the two cases. It seems like the
> CUDA-version assumes that the piercing point is in the middle of the
> detector. That's not what this question is about though.)
>
> The beam fan angle seems to be computed as
>
> arctan( halfDetectorWidth / sourceToIsocenterDistance )
>
> Why sourceToIsocenterDistance? Shouldn't it be sourceToDetectorDistance?
> If the detector is far away from the isocenter, the beam fan angle should
> also be small as far as I understand. This is not reflected in this
> computation.
>
> Best regards,
> Fredrik Hellman
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20170925/a1a66aa3/attachment.html>