From yoonho94.na at gmail.com  Mon Jun  1 00:08:10 2020
From: yoonho94.na at gmail.com (=?UTF-8?B?64KY7Jyk7Zi4?=)
Date: Mon, 1 Jun 2020 13:08:10 +0900
Subject: [Rtk-users] setting input to rtkfdk
Message-ID: <CAPZFa=eDyvKps+7ZmFzp3=ZX5sdOPTvJRQ4oJLNVNT_5gxYS3Q@mail.gmail.com>

Hi, rtk-users.

I'm trying to reconstruct an image from one of my sinogram using fdk.

but some kind of error occurs.(I don't know what this means.)

How can I put my sinogram input to fdk?

Here is the error message that I got.
[image: image.png]

(sinogram.mha is my input.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200601/746a5d6d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 114690 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200601/746a5d6d/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image01.png
Type: image/png
Size: 115761 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200601/746a5d6d/attachment-0003.png>

From simon.rit at creatis.insa-lyon.fr  Mon Jun  1 15:41:57 2020
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 1 Jun 2020 21:41:57 +0200
Subject: [Rtk-users] setting input to rtkfdk
In-Reply-To: <CAPZFa=eDyvKps+7ZmFzp3=ZX5sdOPTvJRQ4oJLNVNT_5gxYS3Q@mail.gmail.com>
References: <CAPZFa=eDyvKps+7ZmFzp3=ZX5sdOPTvJRQ4oJLNVNT_5gxYS3Q@mail.gmail.com>
Message-ID: <CAF0oig3E+PN6D9jDU8-iry3vORN_Kz3_Mjd95_r7bYv4uLse9Q@mail.gmail.com>

Hi,
I don't see anything wrong in your command line. But apparently, it cannot
read your sinogram.mha file. What type is it?
Best regards,
Simon

On Mon, Jun 1, 2020 at 6:08 AM ??? <yoonho94.na at gmail.com> wrote:

> Hi, rtk-users.
>
> I'm trying to reconstruct an image from one of my sinogram using fdk.
>
> but some kind of error occurs.(I don't know what this means.)
>
> How can I put my sinogram input to fdk?
>
> Here is the error message that I got.
> [image: image.png]
>
> (sinogram.mha is my input.)
>
> _______________________________________________
> 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/20200601/dfb71605/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 114690 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200601/dfb71605/attachment-0001.png>

From yoonho94.na at gmail.com  Mon Jun  1 18:31:16 2020
From: yoonho94.na at gmail.com (=?UTF-8?B?64KY7Jyk7Zi4?=)
Date: Tue, 2 Jun 2020 07:31:16 +0900
Subject: [Rtk-users] setting input to rtkfdk
In-Reply-To: <CAF0oig3E+PN6D9jDU8-iry3vORN_Kz3_Mjd95_r7bYv4uLse9Q@mail.gmail.com>
References: <CAPZFa=eDyvKps+7ZmFzp3=ZX5sdOPTvJRQ4oJLNVNT_5gxYS3Q@mail.gmail.com>
 <CAF0oig3E+PN6D9jDU8-iry3vORN_Kz3_Mjd95_r7bYv4uLse9Q@mail.gmail.com>
Message-ID: <CAPZFa=fAfWyOtLi+ZJRoxzUjaP10XiJ_FNXoxQW4vCupKJ-qLw@mail.gmail.com>

Image type was itk::vectorimage<unsigned char, 2>

Image shape was (863, 91, 4)
(used python numpy just for checking array shape)

And I look into rtk::ProjectionsReader.hxx

I think It has to be float or double. Am I right?

2020? 6? 2? (?) ?? 4:40, Simon Rit <simon.rit at creatis.insa-lyon.fr>?? ??:

> Hi,
> I don't see anything wrong in your command line. But apparently, it cannot
> read your sinogram.mha file. What type is it?
> Best regards,
> Simon
>
> On Mon, Jun 1, 2020 at 6:08 AM ??? <yoonho94.na at gmail.com> wrote:
>
>> Hi, rtk-users.
>>
>> I'm trying to reconstruct an image from one of my sinogram using fdk.
>>
>> but some kind of error occurs.(I don't know what this means.)
>>
>> How can I put my sinogram input to fdk?
>>
>> Here is the error message that I got.
>> [image: image.png]
>>
>> (sinogram.mha is my input.)
>>
>> _______________________________________________
>> 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/20200602/7cf21453/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 114690 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200602/7cf21453/attachment-0001.png>

From yoonho94.na at gmail.com  Tue Jun  2 00:17:07 2020
From: yoonho94.na at gmail.com (=?UTF-8?B?64KY7Jyk7Zi4?=)
Date: Tue, 2 Jun 2020 13:17:07 +0900
Subject: [Rtk-users] How to fdk reconstruction properly
Message-ID: <CAPZFa=dW4c_omnSp7_uRoptWKomdyOT6imFkbZtbA0MOe2GiDg@mail.gmail.com>

Hi, I've been asking many questions recently, and I think I'm almost there.

finally I could get an output image, but It is not good at all.

The reconstructed image should be a round image but it doesn't look round.

I uploaded my code on github <https://github.com/yolkandwhite/fdk> in
python language, but for the actual computation I just used rtkfdk in C++

what I'm guessing is in the command line script setting the dimension was
wrong.

I have explained the situations in the code with annotations and markdowns
and few screenshots.

how can I fix it??

and I have another question.

in the rtkfdk 2D example <http://wiki.openrtk.org/index.php/RTK/Scripts/FDK>
,

rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2
--dimension 256,1,256

I don't understand what -p and . and -r is.

I cannot find one in rtkfdk.ggo.

Best regards.

Yoonho.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200602/8f0f912e/attachment.htm>

From simon.rit at creatis.insa-lyon.fr  Tue Jun  2 05:05:45 2020
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 2 Jun 2020 11:05:45 +0200
Subject: [Rtk-users] setting input to rtkfdk
In-Reply-To: <CAPZFa=fAfWyOtLi+ZJRoxzUjaP10XiJ_FNXoxQW4vCupKJ-qLw@mail.gmail.com>
References: <CAPZFa=eDyvKps+7ZmFzp3=ZX5sdOPTvJRQ4oJLNVNT_5gxYS3Q@mail.gmail.com>
 <CAF0oig3E+PN6D9jDU8-iry3vORN_Kz3_Mjd95_r7bYv4uLse9Q@mail.gmail.com>
 <CAPZFa=fAfWyOtLi+ZJRoxzUjaP10XiJ_FNXoxQW4vCupKJ-qLw@mail.gmail.com>
Message-ID: <CAF0oig3zHc-S+DC0z2Bq+SC8vx+xi9HV=O4B85Ai_NANZ5-5Ug@mail.gmail.com>

Hi,
Yes, you're right, it cannot handle this type. Do you know why your
sinogram has 2 components? unsigned char also seems to be an inadequate
format with poor precision so I would check this.
It does not have to be float or double. It can be any scalar which will be
automatially converted to float or double.
Best regards,
Simon

On Tue, Jun 2, 2020 at 12:31 AM ??? <yoonho94.na at gmail.com> wrote:

> Image type was itk::vectorimage<unsigned char, 2>
>
> Image shape was (863, 91, 4)
> (used python numpy just for checking array shape)
>
> And I look into rtk::ProjectionsReader.hxx
>
> I think It has to be float or double. Am I right?
>
> 2020? 6? 2? (?) ?? 4:40, Simon Rit <simon.rit at creatis.insa-lyon.fr>?? ??:
>
>> Hi,
>> I don't see anything wrong in your command line. But apparently, it
>> cannot read your sinogram.mha file. What type is it?
>> Best regards,
>> Simon
>>
>> On Mon, Jun 1, 2020 at 6:08 AM ??? <yoonho94.na at gmail.com> wrote:
>>
>>> Hi, rtk-users.
>>>
>>> I'm trying to reconstruct an image from one of my sinogram using fdk.
>>>
>>> but some kind of error occurs.(I don't know what this means.)
>>>
>>> How can I put my sinogram input to fdk?
>>>
>>> Here is the error message that I got.
>>> [image: image.png]
>>>
>>> (sinogram.mha is my input.)
>>>
>>> _______________________________________________
>>> 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/20200602/8884e87d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 114690 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200602/8884e87d/attachment-0001.png>

From simon.rit at creatis.insa-lyon.fr  Tue Jun  2 05:13:29 2020
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 2 Jun 2020 11:13:29 +0200
Subject: [Rtk-users] How to fdk reconstruction properly
In-Reply-To: <CAPZFa=dW4c_omnSp7_uRoptWKomdyOT6imFkbZtbA0MOe2GiDg@mail.gmail.com>
References: <CAPZFa=dW4c_omnSp7_uRoptWKomdyOT6imFkbZtbA0MOe2GiDg@mail.gmail.com>
Message-ID: <CAF0oig3U2mQsw0TTrtKBZKbeskicmXTAu-JTDX4JkP00yP2g_A@mail.gmail.com>

Hi,
Input projections are selected with a path (-p) and a regular expression
(-r) which are passed to an itk::RegularExpressionSeriesFileNames, see here
<https://github.com/SimonRit/RTK/blob/master/include/rtkGgoFunctions.h#L100-L174>
.
Your sinogram.mha file is 2D and RTK is meant for 3D. There are tricks to
reconstruct in 2D but you need to modify your input, see e.g. here
<http://wiki.openrtk.org/index.php/FanBeam> (with our old wrappings but
that should not be difficult to convert). Then the y dimension should be
the second coordinate, it's the first in the data you sent.
I would suggest to check what RTK sinograms look like from the wiki
<http://wiki.openrtk.org> examples and adapt your input accordingly.
Best regards,
Simon

On Tue, Jun 2, 2020 at 6:17 AM ??? <yoonho94.na at gmail.com> wrote:

> Hi, I've been asking many questions recently, and I think I'm almost there.
>
> finally I could get an output image, but It is not good at all.
>
> The reconstructed image should be a round image but it doesn't look round.
>
> I uploaded my code on github <https://github.com/yolkandwhite/fdk> in
> python language, but for the actual computation I just used rtkfdk in C++
>
> what I'm guessing is in the command line script setting the dimension was
> wrong.
>
> I have explained the situations in the code with annotations and markdowns
> and few screenshots.
>
> how can I fix it??
>
> and I have another question.
>
> in the rtkfdk 2D example
> <http://wiki.openrtk.org/index.php/RTK/Scripts/FDK>,
>
> rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256,1,256
>
> I don't understand what -p and . and -r is.
>
> I cannot find one in rtkfdk.ggo.
>
> Best regards.
>
> Yoonho.
> _______________________________________________
> 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/20200602/d5435ba6/attachment.htm>

From Benjamin.W.Maloney.TH at dartmouth.edu  Tue Jun  2 10:50:27 2020
From: Benjamin.W.Maloney.TH at dartmouth.edu (Benjamin W. Maloney)
Date: Tue, 2 Jun 2020 14:50:27 +0000
Subject: [Rtk-users] Reconstruction Artifact
Message-ID: <BL0PR03MB41316ECCACB28DA6B03B06F5F88B0@BL0PR03MB4131.namprd03.prod.outlook.com>

Hi all,

Not sure if this is the right group to post to but here's my question:

I have a code that pulls in my own projection images and uses the?FDKConeBeamReconstructionFilter for reconstruction

The reconstruction?I am getting has an artifact where it looks like there are two overlapping objects rotated.?
I have used other reconstruction toolboxes (mainly TIGRE in MATLAB) with the similar geometry inputs and not had this issue. I suspect the difference is in the parts of the geometry that are set by default. My question is if anyone has seen this before and what input I should look into?

I have a few more questions I may or may not be related:
1. I assume that since I set the origin etc of my images in pixel, sid and sdd should be in pixels as well??
2. Are there restrictions related the scalar values of the projection data? My data will be in detector counts rather than linear attenuation coefficients, is that okay?
I have attached an image to show this issue. It is supposed to be a rectangular mammography phantom. It is a slice in XZ plane

Thanks for the help!
Ben



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PhantomIssue.JPG
Type: image/jpeg
Size: 164369 bytes
Desc: PhantomIssue.JPG
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200602/d572a37b/attachment-0001.jpe>

From simon.rit at creatis.insa-lyon.fr  Tue Jun  2 17:28:19 2020
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 2 Jun 2020 23:28:19 +0200
Subject: [Rtk-users] Reconstruction Artifact
In-Reply-To: <BL0PR03MB41316ECCACB28DA6B03B06F5F88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
References: <BL0PR03MB41316ECCACB28DA6B03B06F5F88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
Message-ID: <CAF0oig3o-225=F8HDXc5cCZ9ui2FV-cTJ1i0YfyvLfN7rNVQnQ@mail.gmail.com>

Hi,
Sometimes rotating in the wrong direction gives this kind of artefacts.
It's quite possible that we don't use the same convention as other toolkits
regarding this.
For other questions:
1. Yes, you can use pixel as the unit. Then the image spacing should be 1
obviously and indeed, sdd and sid should be in pixels.
2. I don't fully understand. If your data is the output of a count
detector, then you either rely on RTK to guess the counts without object to
compute the line integral, or your preprocess your projections to pass line
integrals in a float format.
Simon

On Tue, Jun 2, 2020 at 4:51 PM Benjamin W. Maloney <
Benjamin.W.Maloney.TH at dartmouth.edu> wrote:

> Hi all,
>
> Not sure if this is the right group to post to but here's my question:
>
> I have a code that pulls in my own projection images and uses
> the FDKConeBeamReconstructionFilter for reconstruction
>
> The reconstruction I am getting has an artifact where it looks like there
> are two overlapping objects rotated.
> I have used other reconstruction toolboxes (mainly TIGRE in MATLAB) with
> the similar geometry inputs and not had this issue. I suspect the
> difference is in the parts of the geometry that are set by default. My
> question is if anyone has seen this before and what input I should look
> into?
>
> I have a few more questions I may or may not be related:
> 1. I assume that since I set the origin etc of my images in pixel, sid and
> sdd should be in pixels as well?
> 2. Are there restrictions related the scalar values of the projection
> data? My data will be in detector counts rather than linear attenuation
> coefficients, is that okay?
> I have attached an image to show this issue. It is supposed to be a
> rectangular mammography phantom. It is a slice in XZ plane
>
> Thanks for the help!
> Ben
>
>
>
> _______________________________________________
> 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/20200602/9883d26f/attachment.htm>

From Benjamin.W.Maloney.TH at dartmouth.edu  Tue Jun  2 21:33:56 2020
From: Benjamin.W.Maloney.TH at dartmouth.edu (Benjamin W. Maloney)
Date: Wed, 3 Jun 2020 01:33:56 +0000
Subject: [Rtk-users] Reconstruction Artifact
In-Reply-To: <CAF0oig3o-225=F8HDXc5cCZ9ui2FV-cTJ1i0YfyvLfN7rNVQnQ@mail.gmail.com>
References: <BL0PR03MB41316ECCACB28DA6B03B06F5F88B0@BL0PR03MB4131.namprd03.prod.outlook.com>,
 <CAF0oig3o-225=F8HDXc5cCZ9ui2FV-cTJ1i0YfyvLfN7rNVQnQ@mail.gmail.com>
Message-ID: <BL0PR03MB4131CBE48B4D2E5974B901CDF88B0@BL0PR03MB4131.namprd03.prod.outlook.com>

Hi,

I thought the same in regards to trying to rotating in the other direction. Unfortunately, that has a similar artifact but with the reconstruction flipped.
Interestingly the overlap happens in a similar place but the internal structures are flipped

?1. Thanks!
2. I should have worded that better. My projection images will be preprocessed in a float format. I wanted to check if there were restrictions on these float values. Can input image data have negative values or high values? Or are they expected to have values between 0 and 1? I ask because some of the tools I have used to do this preprocessing (outside of RTK) have given negative values or 'stretched' the data from 0 to 255 before saving.

Ben

________________________________
From: Simon Rit <simon.rit at creatis.insa-lyon.fr>
Sent: Tuesday, June 2, 2020 5:28 PM
To: Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu>
Cc: rtk-users at public.kitware.com <rtk-users at public.kitware.com>
Subject: Re: [Rtk-users] Reconstruction Artifact

Hi,
Sometimes rotating in the wrong direction gives this kind of artefacts. It's quite possible that we don't use the same convention as other toolkits regarding this.
For other questions:
1. Yes, you can use pixel as the unit. Then the image spacing should be 1 obviously and indeed, sdd and sid should be in pixels.
2. I don't fully understand. If your data is the output of a count detector, then you either rely on RTK to guess the counts without object to compute the line integral, or your preprocess your projections to pass line integrals in a float format.
Simon

On Tue, Jun 2, 2020 at 4:51 PM Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu<mailto:Benjamin.W.Maloney.TH at dartmouth.edu>> wrote:
Hi all,

Not sure if this is the right group to post to but here's my question:

I have a code that pulls in my own projection images and uses the FDKConeBeamReconstructionFilter for reconstruction

The reconstruction I am getting has an artifact where it looks like there are two overlapping objects rotated.
I have used other reconstruction toolboxes (mainly TIGRE in MATLAB) with the similar geometry inputs and not had this issue. I suspect the difference is in the parts of the geometry that are set by default. My question is if anyone has seen this before and what input I should look into?

I have a few more questions I may or may not be related:
1. I assume that since I set the origin etc of my images in pixel, sid and sdd should be in pixels as well?
2. Are there restrictions related the scalar values of the projection data? My data will be in detector counts rather than linear attenuation coefficients, is that okay?
I have attached an image to show this issue. It is supposed to be a rectangular mammography phantom. It is a slice in XZ plane

Thanks for the help!
Ben



_______________________________________________
Rtk-users mailing list
Rtk-users at public.kitware.com<mailto:Rtk-users at public.kitware.com>
https://public.kitware.com/mailman/listinfo/rtk-users<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Cf356eebd76e348edabd908d8073ba140%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267300000289534&sdata=72i1zusf0mqK%2BTPPzqJ%2FEcLg62KFiReV%2FyaB3jlUSU0%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200603/38ebb020/attachment.htm>

From andreasga22 at gmail.com  Wed Jun  3 07:56:20 2020
From: andreasga22 at gmail.com (Andreas Andersen)
Date: Wed, 3 Jun 2020 13:56:20 +0200
Subject: [Rtk-users] Reconstruction Artifact
In-Reply-To: <BL0PR03MB4131CBE48B4D2E5974B901CDF88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
References: <BL0PR03MB41316ECCACB28DA6B03B06F5F88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
 <CAF0oig3o-225=F8HDXc5cCZ9ui2FV-cTJ1i0YfyvLfN7rNVQnQ@mail.gmail.com>
 <BL0PR03MB4131CBE48B4D2E5974B901CDF88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
Message-ID: <CAE0aawG55-Cm3=Xc5qW0V1yyPv5uP_gLHoom8Qv8-Ec02NZbxw@mail.gmail.com>

I don't think there are any restrictions technically.
You should be able to use negative values, as the main arithmetic is just a
sum
<https://github.com/SimonRit/RTK/blob/master/include/rtkBackProjectionImageFilter.hxx#L106>
and a multiplication
<https://github.com/SimonRit/RTK/blob/master/include/rtkBackProjectionImageFilter.hxx#L115>
.

The only restriction I can see is that this sum and multiplication should
not overflow (or underflow for negative values) the underlying type of the
output image, as that would be undefined behaviour. Over- and underflow is
unlikely for float, unless you have extremely high values (see wikipedia
for floating point range
<https://en.wikipedia.org/wiki/Floating-point_arithmetic#Range_of_floating-point_numbers>
).

/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 Wed, 3 Jun 2020 at 03:34, Benjamin W. Maloney <
Benjamin.W.Maloney.TH at dartmouth.edu> wrote:

> Hi,
>
> I thought the same in regards to trying to rotating in the other
> direction. Unfortunately, that has a similar artifact but with the
> reconstruction flipped.
> Interestingly the overlap happens in a similar place but the internal
> structures are flipped
>
> ?1. Thanks!
> 2. I should have worded that better. My projection images will be
> preprocessed in a float format. I wanted to check if there were
> restrictions on these float values. Can input image data have negative
> values or high values? Or are they expected to have values between 0 and 1?
> I ask because some of the tools I have used to do this preprocessing
> (outside of RTK) have given negative values or 'stretched' the data from 0
> to 255 before saving.
>
> Ben
>
> ------------------------------
> *From:* Simon Rit <simon.rit at creatis.insa-lyon.fr>
> *Sent:* Tuesday, June 2, 2020 5:28 PM
> *To:* Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu>
> *Cc:* rtk-users at public.kitware.com <rtk-users at public.kitware.com>
> *Subject:* Re: [Rtk-users] Reconstruction Artifact
>
> Hi,
> Sometimes rotating in the wrong direction gives this kind of artefacts.
> It's quite possible that we don't use the same convention as other toolkits
> regarding this.
> For other questions:
> 1. Yes, you can use pixel as the unit. Then the image spacing should be 1
> obviously and indeed, sdd and sid should be in pixels.
> 2. I don't fully understand. If your data is the output of a count
> detector, then you either rely on RTK to guess the counts without object to
> compute the line integral, or your preprocess your projections to pass line
> integrals in a float format.
> Simon
>
> On Tue, Jun 2, 2020 at 4:51 PM Benjamin W. Maloney <
> Benjamin.W.Maloney.TH at dartmouth.edu> wrote:
>
> Hi all,
>
> Not sure if this is the right group to post to but here's my question:
>
> I have a code that pulls in my own projection images and uses
> the FDKConeBeamReconstructionFilter for reconstruction
>
> The reconstruction I am getting has an artifact where it looks like there
> are two overlapping objects rotated.
> I have used other reconstruction toolboxes (mainly TIGRE in MATLAB) with
> the similar geometry inputs and not had this issue. I suspect the
> difference is in the parts of the geometry that are set by default. My
> question is if anyone has seen this before and what input I should look
> into?
>
> I have a few more questions I may or may not be related:
> 1. I assume that since I set the origin etc of my images in pixel, sid and
> sdd should be in pixels as well?
> 2. Are there restrictions related the scalar values of the projection
> data? My data will be in detector counts rather than linear attenuation
> coefficients, is that okay?
> I have attached an image to show this issue. It is supposed to be a
> rectangular mammography phantom. It is a slice in XZ plane
>
> Thanks for the help!
> Ben
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Cf356eebd76e348edabd908d8073ba140%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267300000289534&sdata=72i1zusf0mqK%2BTPPzqJ%2FEcLg62KFiReV%2FyaB3jlUSU0%3D&reserved=0>
>
> _______________________________________________
> 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/20200603/26f7578b/attachment-0001.htm>

From simon.rit at creatis.insa-lyon.fr  Wed Jun  3 08:37:18 2020
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 3 Jun 2020 14:37:18 +0200
Subject: [Rtk-users] Reconstruction Artifact
In-Reply-To: <CAE0aawG55-Cm3=Xc5qW0V1yyPv5uP_gLHoom8Qv8-Ec02NZbxw@mail.gmail.com>
References: <BL0PR03MB41316ECCACB28DA6B03B06F5F88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
 <CAF0oig3o-225=F8HDXc5cCZ9ui2FV-cTJ1i0YfyvLfN7rNVQnQ@mail.gmail.com>
 <BL0PR03MB4131CBE48B4D2E5974B901CDF88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
 <CAE0aawG55-Cm3=Xc5qW0V1yyPv5uP_gLHoom8Qv8-Ec02NZbxw@mail.gmail.com>
Message-ID: <CAF0oig2COV-dkdtPueKMpOvM+1Qk4KNmbFAZvXyj-bknrdSg3w@mail.gmail.com>

Yes, there is no such limitation as far as I know, you can use negative
numbers and value above 1.
Your result is really strange, it it supposed to be a square? I don't know
what is the problem but that's clearly a geometry issue. We can always have
a look if you're able to share some data.
Simon

On Wed, Jun 3, 2020 at 1:56 PM Andreas Andersen <andreasga22 at gmail.com>
wrote:

> I don't think there are any restrictions technically.
> You should be able to use negative values, as the main arithmetic is just
> a sum
> <https://github.com/SimonRit/RTK/blob/master/include/rtkBackProjectionImageFilter.hxx#L106>
> and a multiplication
> <https://github.com/SimonRit/RTK/blob/master/include/rtkBackProjectionImageFilter.hxx#L115>
> .
>
> The only restriction I can see is that this sum and multiplication should
> not overflow (or underflow for negative values) the underlying type of the
> output image, as that would be undefined behaviour. Over- and underflow is
> unlikely for float, unless you have extremely high values (see wikipedia
> for floating point range
> <https://en.wikipedia.org/wiki/Floating-point_arithmetic#Range_of_floating-point_numbers>
> ).
>
> /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 Wed, 3 Jun 2020 at 03:34, Benjamin W. Maloney <
> Benjamin.W.Maloney.TH at dartmouth.edu> wrote:
>
>> Hi,
>>
>> I thought the same in regards to trying to rotating in the other
>> direction. Unfortunately, that has a similar artifact but with the
>> reconstruction flipped.
>> Interestingly the overlap happens in a similar place but the internal
>> structures are flipped
>>
>> ?1. Thanks!
>> 2. I should have worded that better. My projection images will be
>> preprocessed in a float format. I wanted to check if there were
>> restrictions on these float values. Can input image data have negative
>> values or high values? Or are they expected to have values between 0 and 1?
>> I ask because some of the tools I have used to do this preprocessing
>> (outside of RTK) have given negative values or 'stretched' the data from 0
>> to 255 before saving.
>>
>> Ben
>>
>> ------------------------------
>> *From:* Simon Rit <simon.rit at creatis.insa-lyon.fr>
>> *Sent:* Tuesday, June 2, 2020 5:28 PM
>> *To:* Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu>
>> *Cc:* rtk-users at public.kitware.com <rtk-users at public.kitware.com>
>> *Subject:* Re: [Rtk-users] Reconstruction Artifact
>>
>> Hi,
>> Sometimes rotating in the wrong direction gives this kind of artefacts.
>> It's quite possible that we don't use the same convention as other toolkits
>> regarding this.
>> For other questions:
>> 1. Yes, you can use pixel as the unit. Then the image spacing should be 1
>> obviously and indeed, sdd and sid should be in pixels.
>> 2. I don't fully understand. If your data is the output of a count
>> detector, then you either rely on RTK to guess the counts without object to
>> compute the line integral, or your preprocess your projections to pass line
>> integrals in a float format.
>> Simon
>>
>> On Tue, Jun 2, 2020 at 4:51 PM Benjamin W. Maloney <
>> Benjamin.W.Maloney.TH at dartmouth.edu> wrote:
>>
>> Hi all,
>>
>> Not sure if this is the right group to post to but here's my question:
>>
>> I have a code that pulls in my own projection images and uses
>> the FDKConeBeamReconstructionFilter for reconstruction
>>
>> The reconstruction I am getting has an artifact where it looks like there
>> are two overlapping objects rotated.
>> I have used other reconstruction toolboxes (mainly TIGRE in MATLAB) with
>> the similar geometry inputs and not had this issue. I suspect the
>> difference is in the parts of the geometry that are set by default. My
>> question is if anyone has seen this before and what input I should look
>> into?
>>
>> I have a few more questions I may or may not be related:
>> 1. I assume that since I set the origin etc of my images in pixel, sid
>> and sdd should be in pixels as well?
>> 2. Are there restrictions related the scalar values of the projection
>> data? My data will be in detector counts rather than linear attenuation
>> coefficients, is that okay?
>> I have attached an image to show this issue. It is supposed to be a
>> rectangular mammography phantom. It is a slice in XZ plane
>>
>> Thanks for the help!
>> Ben
>>
>>
>>
>> _______________________________________________
>> Rtk-users mailing list
>> Rtk-users at public.kitware.com
>> https://public.kitware.com/mailman/listinfo/rtk-users
>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Cf356eebd76e348edabd908d8073ba140%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267300000289534&sdata=72i1zusf0mqK%2BTPPzqJ%2FEcLg62KFiReV%2FyaB3jlUSU0%3D&reserved=0>
>>
>> _______________________________________________
>> 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/20200603/ede42b87/attachment.htm>

From wuchao04 at gmail.com  Wed Jun  3 11:20:58 2020
From: wuchao04 at gmail.com (Chao Wu)
Date: Wed, 3 Jun 2020 17:20:58 +0200
Subject: [Rtk-users] Reconstruction Artifact
In-Reply-To: <CAF0oig2COV-dkdtPueKMpOvM+1Qk4KNmbFAZvXyj-bknrdSg3w@mail.gmail.com>
References: <BL0PR03MB41316ECCACB28DA6B03B06F5F88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
 <CAF0oig3o-225=F8HDXc5cCZ9ui2FV-cTJ1i0YfyvLfN7rNVQnQ@mail.gmail.com>
 <BL0PR03MB4131CBE48B4D2E5974B901CDF88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
 <CAE0aawG55-Cm3=Xc5qW0V1yyPv5uP_gLHoom8Qv8-Ec02NZbxw@mail.gmail.com>
 <CAF0oig2COV-dkdtPueKMpOvM+1Qk4KNmbFAZvXyj-bknrdSg3w@mail.gmail.com>
Message-ID: <CAH+sHrVL8-nxrT0GDq1QNYiNVFRTe2=43bf3T=OXJ-17+XC-XA@mail.gmail.com>

If your projections record the number of X-ray photon counts instead of
attenuation, an I0 must be set correctly and a logarithmic operation is
needed before the projection data can be fed to the reconstruction loop.
Both the I0 and the logarithmic operation can be handled by the RTK
projection reader or manually, depending on your implementation. Zero and
negative numbers must be coerced for the logarithmic operation by you if
this is not the case in the RTK code you use.

Regards,
Chao

Simon Rit <simon.rit at creatis.insa-lyon.fr> ?2020?6?3??? ??2:35???

> Yes, there is no such limitation as far as I know, you can use negative
> numbers and value above 1.
> Your result is really strange, it it supposed to be a square? I don't know
> what is the problem but that's clearly a geometry issue. We can always have
> a look if you're able to share some data.
> Simon
>
> On Wed, Jun 3, 2020 at 1:56 PM Andreas Andersen <andreasga22 at gmail.com>
> wrote:
>
>> I don't think there are any restrictions technically.
>> You should be able to use negative values, as the main arithmetic is just
>> a sum
>> <https://github.com/SimonRit/RTK/blob/master/include/rtkBackProjectionImageFilter.hxx#L106>
>> and a multiplication
>> <https://github.com/SimonRit/RTK/blob/master/include/rtkBackProjectionImageFilter.hxx#L115>
>> .
>>
>> The only restriction I can see is that this sum and multiplication should
>> not overflow (or underflow for negative values) the underlying type of the
>> output image, as that would be undefined behaviour. Over- and underflow is
>> unlikely for float, unless you have extremely high values (see wikipedia
>> for floating point range
>> <https://en.wikipedia.org/wiki/Floating-point_arithmetic#Range_of_floating-point_numbers>
>> ).
>>
>> /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 Wed, 3 Jun 2020 at 03:34, Benjamin W. Maloney <
>> Benjamin.W.Maloney.TH at dartmouth.edu> wrote:
>>
>>> Hi,
>>>
>>> I thought the same in regards to trying to rotating in the other
>>> direction. Unfortunately, that has a similar artifact but with the
>>> reconstruction flipped.
>>> Interestingly the overlap happens in a similar place but the internal
>>> structures are flipped
>>>
>>> ?1. Thanks!
>>> 2. I should have worded that better. My projection images will be
>>> preprocessed in a float format. I wanted to check if there were
>>> restrictions on these float values. Can input image data have negative
>>> values or high values? Or are they expected to have values between 0 and 1?
>>> I ask because some of the tools I have used to do this preprocessing
>>> (outside of RTK) have given negative values or 'stretched' the data from 0
>>> to 255 before saving.
>>>
>>> Ben
>>>
>>> ------------------------------
>>> *From:* Simon Rit <simon.rit at creatis.insa-lyon.fr>
>>> *Sent:* Tuesday, June 2, 2020 5:28 PM
>>> *To:* Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu>
>>> *Cc:* rtk-users at public.kitware.com <rtk-users at public.kitware.com>
>>> *Subject:* Re: [Rtk-users] Reconstruction Artifact
>>>
>>> Hi,
>>> Sometimes rotating in the wrong direction gives this kind of artefacts.
>>> It's quite possible that we don't use the same convention as other toolkits
>>> regarding this.
>>> For other questions:
>>> 1. Yes, you can use pixel as the unit. Then the image spacing should be
>>> 1 obviously and indeed, sdd and sid should be in pixels.
>>> 2. I don't fully understand. If your data is the output of a count
>>> detector, then you either rely on RTK to guess the counts without object to
>>> compute the line integral, or your preprocess your projections to pass line
>>> integrals in a float format.
>>> Simon
>>>
>>> On Tue, Jun 2, 2020 at 4:51 PM Benjamin W. Maloney <
>>> Benjamin.W.Maloney.TH at dartmouth.edu> wrote:
>>>
>>> Hi all,
>>>
>>> Not sure if this is the right group to post to but here's my question:
>>>
>>> I have a code that pulls in my own projection images and uses
>>> the FDKConeBeamReconstructionFilter for reconstruction
>>>
>>> The reconstruction I am getting has an artifact where it looks like
>>> there are two overlapping objects rotated.
>>> I have used other reconstruction toolboxes (mainly TIGRE in MATLAB) with
>>> the similar geometry inputs and not had this issue. I suspect the
>>> difference is in the parts of the geometry that are set by default. My
>>> question is if anyone has seen this before and what input I should look
>>> into?
>>>
>>> I have a few more questions I may or may not be related:
>>> 1. I assume that since I set the origin etc of my images in pixel, sid
>>> and sdd should be in pixels as well?
>>> 2. Are there restrictions related the scalar values of the projection
>>> data? My data will be in detector counts rather than linear attenuation
>>> coefficients, is that okay?
>>> I have attached an image to show this issue. It is supposed to be a
>>> rectangular mammography phantom. It is a slice in XZ plane
>>>
>>> Thanks for the help!
>>> Ben
>>>
>>>
>>>
>>> _______________________________________________
>>> Rtk-users mailing list
>>> Rtk-users at public.kitware.com
>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Cf356eebd76e348edabd908d8073ba140%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267300000289534&sdata=72i1zusf0mqK%2BTPPzqJ%2FEcLg62KFiReV%2FyaB3jlUSU0%3D&reserved=0>
>>>
>>> _______________________________________________
>>> 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/20200603/8b199ae8/attachment-0001.htm>

From Benjamin.W.Maloney.TH at dartmouth.edu  Wed Jun  3 12:28:17 2020
From: Benjamin.W.Maloney.TH at dartmouth.edu (Benjamin W. Maloney)
Date: Wed, 3 Jun 2020 16:28:17 +0000
Subject: [Rtk-users] Reconstruction Artifact
In-Reply-To: <CAH+sHrVL8-nxrT0GDq1QNYiNVFRTe2=43bf3T=OXJ-17+XC-XA@mail.gmail.com>
References: <BL0PR03MB41316ECCACB28DA6B03B06F5F88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
 <CAF0oig3o-225=F8HDXc5cCZ9ui2FV-cTJ1i0YfyvLfN7rNVQnQ@mail.gmail.com>
 <BL0PR03MB4131CBE48B4D2E5974B901CDF88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
 <CAE0aawG55-Cm3=Xc5qW0V1yyPv5uP_gLHoom8Qv8-Ec02NZbxw@mail.gmail.com>
 <CAF0oig2COV-dkdtPueKMpOvM+1Qk4KNmbFAZvXyj-bknrdSg3w@mail.gmail.com>,
 <CAH+sHrVL8-nxrT0GDq1QNYiNVFRTe2=43bf3T=OXJ-17+XC-XA@mail.gmail.com>
Message-ID: <BL0PR03MB41318854B28E50B8312248CDF8880@BL0PR03MB4131.namprd03.prod.outlook.com>

Hi all,

Thanks for the help!
I'll be sure to make sure my preprocessed data is handled correctly.

The reconstruction is meant to be a square, it is of a CIRS ACR digital mammography phantom

I'm trying to send an example of my data but I can't get it under 147 MB data limit, is there a preferred method for sending this? I could send a google drive link if that is allowed

Thanks again!
Ben

________________________________
From: Chao Wu <wuchao04 at gmail.com>
Sent: Wednesday, June 3, 2020 11:20 AM
To: Simon Rit <simon.rit at creatis.insa-lyon.fr>
Cc: Andreas Andersen <andreasga22 at gmail.com>; rtk-users at public.kitware.com <rtk-users at public.kitware.com>; Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu>
Subject: Re: [Rtk-users] Reconstruction Artifact

If your projections record the number of X-ray photon counts instead of attenuation, an I0 must be set correctly and a logarithmic operation is needed before the projection data can be fed to the reconstruction loop. Both the I0 and the logarithmic operation can be handled by the RTK projection reader or manually, depending on your implementation. Zero and negative numbers must be coerced for the logarithmic operation by you if this is not the case in the RTK code you use.

Regards,
Chao

Simon Rit <simon.rit at creatis.insa-lyon.fr<mailto:simon.rit at creatis.insa-lyon.fr>> ?2020?6?3??? ??2:35???
Yes, there is no such limitation as far as I know, you can use negative numbers and value above 1.
Your result is really strange, it it supposed to be a square? I don't know what is the problem but that's clearly a geometry issue. We can always have a look if you're able to share some data.
Simon

On Wed, Jun 3, 2020 at 1:56 PM Andreas Andersen <andreasga22 at gmail.com<mailto:andreasga22 at gmail.com>> wrote:
I don't think there are any restrictions technically.
You should be able to use negative values, as the main arithmetic is just a sum<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSimonRit%2FRTK%2Fblob%2Fmaster%2Finclude%2FrtkBackProjectionImageFilter.hxx%23L106&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Ca9b964ae6a564833be9808d807d1be87%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267944718989010&sdata=vjk%2FNtQ43Dnf%2Bboaz1dCEIacZSG1gDh5LSqA76wDS%2Fg%3D&reserved=0> and a multiplication<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSimonRit%2FRTK%2Fblob%2Fmaster%2Finclude%2FrtkBackProjectionImageFilter.hxx%23L115&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Ca9b964ae6a564833be9808d807d1be87%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267944718989010&sdata=ehz4gp3sMhs%2Bi0onEIdlbC%2Fnc%2FG4YFT27qN6FAwlGgo%3D&reserved=0>.

The only restriction I can see is that this sum and multiplication should not overflow (or underflow for negative values) the underlying type of the output image, as that would be undefined behaviour. Over- and underflow is unlikely for float, unless you have extremely high values (see wikipedia for floating point range<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFloating-point_arithmetic%23Range_of_floating-point_numbers&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Ca9b964ae6a564833be9808d807d1be87%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267944718999001&sdata=0NX7PRKcro7Knu2wq8VuePPleTRH1MdAvJlL10xmQHk%3D&reserved=0>).

/Andreas

__________________________________

Andreas Gravgaard Andersen

Danish Center for Particle Therapy,

Aarhus University Hospital

Palle Juul-Jensens Blvd. 99,

8200, Aarhus

Mail:     agravgaard at protonmail.com<mailto:agravgaard at protonmail.com>

Cell:      +45 3165 8140


On Wed, 3 Jun 2020 at 03:34, Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu<mailto:Benjamin.W.Maloney.TH at dartmouth.edu>> wrote:
Hi,

I thought the same in regards to trying to rotating in the other direction. Unfortunately, that has a similar artifact but with the reconstruction flipped.
Interestingly the overlap happens in a similar place but the internal structures are flipped

?1. Thanks!
2. I should have worded that better. My projection images will be preprocessed in a float format. I wanted to check if there were restrictions on these float values. Can input image data have negative values or high values? Or are they expected to have values between 0 and 1? I ask because some of the tools I have used to do this preprocessing (outside of RTK) have given negative values or 'stretched' the data from 0 to 255 before saving.

Ben

________________________________
From: Simon Rit <simon.rit at creatis.insa-lyon.fr<mailto:simon.rit at creatis.insa-lyon.fr>>
Sent: Tuesday, June 2, 2020 5:28 PM
To: Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu<mailto:Benjamin.W.Maloney.TH at dartmouth.edu>>
Cc: rtk-users at public.kitware.com<mailto:rtk-users at public.kitware.com> <rtk-users at public.kitware.com<mailto:rtk-users at public.kitware.com>>
Subject: Re: [Rtk-users] Reconstruction Artifact

Hi,
Sometimes rotating in the wrong direction gives this kind of artefacts. It's quite possible that we don't use the same convention as other toolkits regarding this.
For other questions:
1. Yes, you can use pixel as the unit. Then the image spacing should be 1 obviously and indeed, sdd and sid should be in pixels.
2. I don't fully understand. If your data is the output of a count detector, then you either rely on RTK to guess the counts without object to compute the line integral, or your preprocess your projections to pass line integrals in a float format.
Simon

On Tue, Jun 2, 2020 at 4:51 PM Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu<mailto:Benjamin.W.Maloney.TH at dartmouth.edu>> wrote:
Hi all,

Not sure if this is the right group to post to but here's my question:

I have a code that pulls in my own projection images and uses the FDKConeBeamReconstructionFilter for reconstruction

The reconstruction I am getting has an artifact where it looks like there are two overlapping objects rotated.
I have used other reconstruction toolboxes (mainly TIGRE in MATLAB) with the similar geometry inputs and not had this issue. I suspect the difference is in the parts of the geometry that are set by default. My question is if anyone has seen this before and what input I should look into?

I have a few more questions I may or may not be related:
1. I assume that since I set the origin etc of my images in pixel, sid and sdd should be in pixels as well?
2. Are there restrictions related the scalar values of the projection data? My data will be in detector counts rather than linear attenuation coefficients, is that okay?
I have attached an image to show this issue. It is supposed to be a rectangular mammography phantom. It is a slice in XZ plane

Thanks for the help!
Ben



_______________________________________________
Rtk-users mailing list
Rtk-users at public.kitware.com<mailto:Rtk-users at public.kitware.com>
https://public.kitware.com/mailman/listinfo/rtk-users<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Ca9b964ae6a564833be9808d807d1be87%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267944718999001&sdata=5ekJcPKdQWlVJ6wBlE%2BWfU27jTthHxdY3l8pK3cT8QU%3D&reserved=0>
_______________________________________________
Rtk-users mailing list
Rtk-users at public.kitware.com<mailto:Rtk-users at public.kitware.com>
https://public.kitware.com/mailman/listinfo/rtk-users<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Ca9b964ae6a564833be9808d807d1be87%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267944719008995&sdata=QMk%2FdR8JyuuWAhr1ygl097rPZQlO5bg3RtbGE%2B%2F4V9I%3D&reserved=0>
_______________________________________________
Rtk-users mailing list
Rtk-users at public.kitware.com<mailto:Rtk-users at public.kitware.com>
https://public.kitware.com/mailman/listinfo/rtk-users<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Ca9b964ae6a564833be9808d807d1be87%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267944719008995&sdata=QMk%2FdR8JyuuWAhr1ygl097rPZQlO5bg3RtbGE%2B%2F4V9I%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200603/608d3d22/attachment-0001.htm>

From simon.rit at creatis.insa-lyon.fr  Wed Jun  3 13:04:45 2020
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 3 Jun 2020 19:04:45 +0200
Subject: [Rtk-users] Reconstruction Artifact
In-Reply-To: <BL0PR03MB41318854B28E50B8312248CDF8880@BL0PR03MB4131.namprd03.prod.outlook.com>
References: <BL0PR03MB41316ECCACB28DA6B03B06F5F88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
 <CAF0oig3o-225=F8HDXc5cCZ9ui2FV-cTJ1i0YfyvLfN7rNVQnQ@mail.gmail.com>
 <BL0PR03MB4131CBE48B4D2E5974B901CDF88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
 <CAE0aawG55-Cm3=Xc5qW0V1yyPv5uP_gLHoom8Qv8-Ec02NZbxw@mail.gmail.com>
 <CAF0oig2COV-dkdtPueKMpOvM+1Qk4KNmbFAZvXyj-bknrdSg3w@mail.gmail.com>
 <CAH+sHrVL8-nxrT0GDq1QNYiNVFRTe2=43bf3T=OXJ-17+XC-XA@mail.gmail.com>
 <BL0PR03MB41318854B28E50B8312248CDF8880@BL0PR03MB4131.namprd03.prod.outlook.com>
Message-ID: <CAF0oig3SZVP1yF3g46MoGyRaififUMYJDFN9wNAHttp3987NUw@mail.gmail.com>

Yes, that's allowed, other people did it before.

On Wed, Jun 3, 2020 at 6:28 PM Benjamin W. Maloney <
Benjamin.W.Maloney.TH at dartmouth.edu> wrote:

> Hi all,
>
> Thanks for the help!
> I'll be sure to make sure my preprocessed data is handled correctly.
>
> The reconstruction is meant to be a square, it is of a CIRS ACR digital
> mammography phantom
>
> I'm trying to send an example of my data but I can't get it under 147 MB
> data limit, is there a preferred method for sending this? I could send a
> google drive link if that is allowed
>
> Thanks again!
> Ben
>
> ------------------------------
> *From:* Chao Wu <wuchao04 at gmail.com>
> *Sent:* Wednesday, June 3, 2020 11:20 AM
> *To:* Simon Rit <simon.rit at creatis.insa-lyon.fr>
> *Cc:* Andreas Andersen <andreasga22 at gmail.com>;
> rtk-users at public.kitware.com <rtk-users at public.kitware.com>; Benjamin W.
> Maloney <Benjamin.W.Maloney.TH at dartmouth.edu>
> *Subject:* Re: [Rtk-users] Reconstruction Artifact
>
> If your projections record the number of X-ray photon counts instead of
> attenuation, an I0 must be set correctly and a logarithmic operation is
> needed before the projection data can be fed to the reconstruction loop.
> Both the I0 and the logarithmic operation can be handled by the RTK
> projection reader or manually, depending on your implementation. Zero and
> negative numbers must be coerced for the logarithmic operation by you if
> this is not the case in the RTK code you use.
>
> Regards,
> Chao
>
> Simon Rit <simon.rit at creatis.insa-lyon.fr> ?2020?6?3??? ??2:35???
>
> Yes, there is no such limitation as far as I know, you can use negative
> numbers and value above 1.
> Your result is really strange, it it supposed to be a square? I don't know
> what is the problem but that's clearly a geometry issue. We can always have
> a look if you're able to share some data.
> Simon
>
> On Wed, Jun 3, 2020 at 1:56 PM Andreas Andersen <andreasga22 at gmail.com>
> wrote:
>
> I don't think there are any restrictions technically.
> You should be able to use negative values, as the main arithmetic is just
> a sum
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSimonRit%2FRTK%2Fblob%2Fmaster%2Finclude%2FrtkBackProjectionImageFilter.hxx%23L106&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Ca9b964ae6a564833be9808d807d1be87%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267944718989010&sdata=vjk%2FNtQ43Dnf%2Bboaz1dCEIacZSG1gDh5LSqA76wDS%2Fg%3D&reserved=0>
> and a multiplication
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSimonRit%2FRTK%2Fblob%2Fmaster%2Finclude%2FrtkBackProjectionImageFilter.hxx%23L115&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Ca9b964ae6a564833be9808d807d1be87%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267944718989010&sdata=ehz4gp3sMhs%2Bi0onEIdlbC%2Fnc%2FG4YFT27qN6FAwlGgo%3D&reserved=0>
> .
>
> The only restriction I can see is that this sum and multiplication should
> not overflow (or underflow for negative values) the underlying type of the
> output image, as that would be undefined behaviour. Over- and underflow is
> unlikely for float, unless you have extremely high values (see wikipedia
> for floating point range
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFloating-point_arithmetic%23Range_of_floating-point_numbers&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Ca9b964ae6a564833be9808d807d1be87%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267944718999001&sdata=0NX7PRKcro7Knu2wq8VuePPleTRH1MdAvJlL10xmQHk%3D&reserved=0>
> ).
>
> /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 Wed, 3 Jun 2020 at 03:34, Benjamin W. Maloney <
> Benjamin.W.Maloney.TH at dartmouth.edu> wrote:
>
> Hi,
>
> I thought the same in regards to trying to rotating in the other
> direction. Unfortunately, that has a similar artifact but with the
> reconstruction flipped.
> Interestingly the overlap happens in a similar place but the internal
> structures are flipped
>
> ?1. Thanks!
> 2. I should have worded that better. My projection images will be
> preprocessed in a float format. I wanted to check if there were
> restrictions on these float values. Can input image data have negative
> values or high values? Or are they expected to have values between 0 and 1?
> I ask because some of the tools I have used to do this preprocessing
> (outside of RTK) have given negative values or 'stretched' the data from 0
> to 255 before saving.
>
> Ben
>
> ------------------------------
> *From:* Simon Rit <simon.rit at creatis.insa-lyon.fr>
> *Sent:* Tuesday, June 2, 2020 5:28 PM
> *To:* Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu>
> *Cc:* rtk-users at public.kitware.com <rtk-users at public.kitware.com>
> *Subject:* Re: [Rtk-users] Reconstruction Artifact
>
> Hi,
> Sometimes rotating in the wrong direction gives this kind of artefacts.
> It's quite possible that we don't use the same convention as other toolkits
> regarding this.
> For other questions:
> 1. Yes, you can use pixel as the unit. Then the image spacing should be 1
> obviously and indeed, sdd and sid should be in pixels.
> 2. I don't fully understand. If your data is the output of a count
> detector, then you either rely on RTK to guess the counts without object to
> compute the line integral, or your preprocess your projections to pass line
> integrals in a float format.
> Simon
>
> On Tue, Jun 2, 2020 at 4:51 PM Benjamin W. Maloney <
> Benjamin.W.Maloney.TH at dartmouth.edu> wrote:
>
> Hi all,
>
> Not sure if this is the right group to post to but here's my question:
>
> I have a code that pulls in my own projection images and uses
> the FDKConeBeamReconstructionFilter for reconstruction
>
> The reconstruction I am getting has an artifact where it looks like there
> are two overlapping objects rotated.
> I have used other reconstruction toolboxes (mainly TIGRE in MATLAB) with
> the similar geometry inputs and not had this issue. I suspect the
> difference is in the parts of the geometry that are set by default. My
> question is if anyone has seen this before and what input I should look
> into?
>
> I have a few more questions I may or may not be related:
> 1. I assume that since I set the origin etc of my images in pixel, sid and
> sdd should be in pixels as well?
> 2. Are there restrictions related the scalar values of the projection
> data? My data will be in detector counts rather than linear attenuation
> coefficients, is that okay?
> I have attached an image to show this issue. It is supposed to be a
> rectangular mammography phantom. It is a slice in XZ plane
>
> Thanks for the help!
> Ben
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Ca9b964ae6a564833be9808d807d1be87%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267944718999001&sdata=5ekJcPKdQWlVJ6wBlE%2BWfU27jTthHxdY3l8pK3cT8QU%3D&reserved=0>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Ca9b964ae6a564833be9808d807d1be87%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267944719008995&sdata=QMk%2FdR8JyuuWAhr1ygl097rPZQlO5bg3RtbGE%2B%2F4V9I%3D&reserved=0>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7Ca9b964ae6a564833be9808d807d1be87%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637267944719008995&sdata=QMk%2FdR8JyuuWAhr1ygl097rPZQlO5bg3RtbGE%2B%2F4V9I%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200603/a032f92c/attachment.htm>

From Benjamin.W.Maloney.TH at dartmouth.edu  Wed Jun  3 13:58:58 2020
From: Benjamin.W.Maloney.TH at dartmouth.edu (Benjamin W. Maloney)
Date: Wed, 3 Jun 2020 17:58:58 +0000
Subject: [Rtk-users] Reconstruction Artifact
In-Reply-To: <CAF0oig3SZVP1yF3g46MoGyRaififUMYJDFN9wNAHttp3987NUw@mail.gmail.com>
References: <BL0PR03MB41316ECCACB28DA6B03B06F5F88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
 <CAF0oig3o-225=F8HDXc5cCZ9ui2FV-cTJ1i0YfyvLfN7rNVQnQ@mail.gmail.com>
 <BL0PR03MB4131CBE48B4D2E5974B901CDF88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
 <CAE0aawG55-Cm3=Xc5qW0V1yyPv5uP_gLHoom8Qv8-Ec02NZbxw@mail.gmail.com>
 <CAF0oig2COV-dkdtPueKMpOvM+1Qk4KNmbFAZvXyj-bknrdSg3w@mail.gmail.com>
 <CAH+sHrVL8-nxrT0GDq1QNYiNVFRTe2=43bf3T=OXJ-17+XC-XA@mail.gmail.com>
 <BL0PR03MB41318854B28E50B8312248CDF8880@BL0PR03MB4131.namprd03.prod.outlook.com>,
 <CAF0oig3SZVP1yF3g46MoGyRaififUMYJDFN9wNAHttp3987NUw@mail.gmail.com>
Message-ID: <BL0PR03MB41316E77652EBBB460F03473F8880@BL0PR03MB4131.namprd03.prod.outlook.com>

Thanks.

https://drive.google.com/drive/folders/1DTREuI80fWrIcBa5LIUfnAzsEPSRvhyZ?usp=sharing

At that link are a .tif file for my projections and the .cxx reconstruction file I have been using

Some notes about my system:
SID: 306.6 mm
SDD: 561.3 mm

The detector panel is:
230mm x 70mm with a pixel matrix of 3072 x 864
The projections are binned by 4 resulting in a pixel size of ~0.03mm-1 and a pixel array of 768 x 216
There are 720 projection angles with an angular step of 0.5 degrees

The system also has the sample on a turntable with a fixed source and detector but I believe that should be mathematically equivalent

Thanks again!
Ben
________________________________
From: Simon Rit <simon.rit at creatis.insa-lyon.fr>
Sent: Wednesday, June 3, 2020 1:04 PM
To: Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu>
Cc: Chao Wu <wuchao04 at gmail.com>; Andreas Andersen <andreasga22 at gmail.com>; rtk-users at public.kitware.com <rtk-users at public.kitware.com>
Subject: Re: [Rtk-users] Reconstruction Artifact

Yes, that's allowed, other people did it before.

On Wed, Jun 3, 2020 at 6:28 PM Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu<mailto:Benjamin.W.Maloney.TH at dartmouth.edu>> wrote:
Hi all,

Thanks for the help!
I'll be sure to make sure my preprocessed data is handled correctly.

The reconstruction is meant to be a square, it is of a CIRS ACR digital mammography phantom

I'm trying to send an example of my data but I can't get it under 147 MB data limit, is there a preferred method for sending this? I could send a google drive link if that is allowed

Thanks again!
Ben

________________________________
From: Chao Wu <wuchao04 at gmail.com<mailto:wuchao04 at gmail.com>>
Sent: Wednesday, June 3, 2020 11:20 AM
To: Simon Rit <simon.rit at creatis.insa-lyon.fr<mailto:simon.rit at creatis.insa-lyon.fr>>
Cc: Andreas Andersen <andreasga22 at gmail.com<mailto:andreasga22 at gmail.com>>; rtk-users at public.kitware.com<mailto:rtk-users at public.kitware.com> <rtk-users at public.kitware.com<mailto:rtk-users at public.kitware.com>>; Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu<mailto:Benjamin.W.Maloney.TH at dartmouth.edu>>
Subject: Re: [Rtk-users] Reconstruction Artifact

If your projections record the number of X-ray photon counts instead of attenuation, an I0 must be set correctly and a logarithmic operation is needed before the projection data can be fed to the reconstruction loop. Both the I0 and the logarithmic operation can be handled by the RTK projection reader or manually, depending on your implementation. Zero and negative numbers must be coerced for the logarithmic operation by you if this is not the case in the RTK code you use.

Regards,
Chao

Simon Rit <simon.rit at creatis.insa-lyon.fr<mailto:simon.rit at creatis.insa-lyon.fr>> ?2020?6?3??? ??2:35???
Yes, there is no such limitation as far as I know, you can use negative numbers and value above 1.
Your result is really strange, it it supposed to be a square? I don't know what is the problem but that's clearly a geometry issue. We can always have a look if you're able to share some data.
Simon

On Wed, Jun 3, 2020 at 1:56 PM Andreas Andersen <andreasga22 at gmail.com<mailto:andreasga22 at gmail.com>> wrote:
I don't think there are any restrictions technically.
You should be able to use negative values, as the main arithmetic is just a sum<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSimonRit%2FRTK%2Fblob%2Fmaster%2Finclude%2FrtkBackProjectionImageFilter.hxx%23L106&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C7090376e438d462c76cf08d807dff9f4%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637268005857264400&sdata=ta2wjTGRMl8MRkv5qeqUZDYED%2FD%2BNtzkFEMdIHp7YfA%3D&reserved=0> and a multiplication<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSimonRit%2FRTK%2Fblob%2Fmaster%2Finclude%2FrtkBackProjectionImageFilter.hxx%23L115&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C7090376e438d462c76cf08d807dff9f4%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637268005857269384&sdata=pGY1uH5hjzUepFxR1AiDFKUFAxwNQM8mPIVDxwe%2B7N8%3D&reserved=0>.

The only restriction I can see is that this sum and multiplication should not overflow (or underflow for negative values) the underlying type of the output image, as that would be undefined behaviour. Over- and underflow is unlikely for float, unless you have extremely high values (see wikipedia for floating point range<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFloating-point_arithmetic%23Range_of_floating-point_numbers&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C7090376e438d462c76cf08d807dff9f4%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637268005857274380&sdata=0wwsrWW8ELu0WjD5Ed9pJcKPFNI%2FNrSrIcGOV45jdgA%3D&reserved=0>).

/Andreas

__________________________________

Andreas Gravgaard Andersen

Danish Center for Particle Therapy,

Aarhus University Hospital

Palle Juul-Jensens Blvd. 99,

8200, Aarhus

Mail:     agravgaard at protonmail.com<mailto:agravgaard at protonmail.com>

Cell:      +45 3165 8140


On Wed, 3 Jun 2020 at 03:34, Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu<mailto:Benjamin.W.Maloney.TH at dartmouth.edu>> wrote:
Hi,

I thought the same in regards to trying to rotating in the other direction. Unfortunately, that has a similar artifact but with the reconstruction flipped.
Interestingly the overlap happens in a similar place but the internal structures are flipped

?1. Thanks!
2. I should have worded that better. My projection images will be preprocessed in a float format. I wanted to check if there were restrictions on these float values. Can input image data have negative values or high values? Or are they expected to have values between 0 and 1? I ask because some of the tools I have used to do this preprocessing (outside of RTK) have given negative values or 'stretched' the data from 0 to 255 before saving.

Ben

________________________________
From: Simon Rit <simon.rit at creatis.insa-lyon.fr<mailto:simon.rit at creatis.insa-lyon.fr>>
Sent: Tuesday, June 2, 2020 5:28 PM
To: Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu<mailto:Benjamin.W.Maloney.TH at dartmouth.edu>>
Cc: rtk-users at public.kitware.com<mailto:rtk-users at public.kitware.com> <rtk-users at public.kitware.com<mailto:rtk-users at public.kitware.com>>
Subject: Re: [Rtk-users] Reconstruction Artifact

Hi,
Sometimes rotating in the wrong direction gives this kind of artefacts. It's quite possible that we don't use the same convention as other toolkits regarding this.
For other questions:
1. Yes, you can use pixel as the unit. Then the image spacing should be 1 obviously and indeed, sdd and sid should be in pixels.
2. I don't fully understand. If your data is the output of a count detector, then you either rely on RTK to guess the counts without object to compute the line integral, or your preprocess your projections to pass line integrals in a float format.
Simon

On Tue, Jun 2, 2020 at 4:51 PM Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu<mailto:Benjamin.W.Maloney.TH at dartmouth.edu>> wrote:
Hi all,

Not sure if this is the right group to post to but here's my question:

I have a code that pulls in my own projection images and uses the FDKConeBeamReconstructionFilter for reconstruction

The reconstruction I am getting has an artifact where it looks like there are two overlapping objects rotated.
I have used other reconstruction toolboxes (mainly TIGRE in MATLAB) with the similar geometry inputs and not had this issue. I suspect the difference is in the parts of the geometry that are set by default. My question is if anyone has seen this before and what input I should look into?

I have a few more questions I may or may not be related:
1. I assume that since I set the origin etc of my images in pixel, sid and sdd should be in pixels as well?
2. Are there restrictions related the scalar values of the projection data? My data will be in detector counts rather than linear attenuation coefficients, is that okay?
I have attached an image to show this issue. It is supposed to be a rectangular mammography phantom. It is a slice in XZ plane

Thanks for the help!
Ben



_______________________________________________
Rtk-users mailing list
Rtk-users at public.kitware.com<mailto:Rtk-users at public.kitware.com>
https://public.kitware.com/mailman/listinfo/rtk-users<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C7090376e438d462c76cf08d807dff9f4%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637268005857279367&sdata=rN0WtXgPU48YJ%2BDkxnnx2StLGljd1AGBRX6IaXgRaY0%3D&reserved=0>
_______________________________________________
Rtk-users mailing list
Rtk-users at public.kitware.com<mailto:Rtk-users at public.kitware.com>
https://public.kitware.com/mailman/listinfo/rtk-users<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C7090376e438d462c76cf08d807dff9f4%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637268005857284358&sdata=cbP3Anssi1CsT65ReQWUQACc4nprtjW%2Bx%2F279Q0GH1k%3D&reserved=0>
_______________________________________________
Rtk-users mailing list
Rtk-users at public.kitware.com<mailto:Rtk-users at public.kitware.com>
https://public.kitware.com/mailman/listinfo/rtk-users<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C7090376e438d462c76cf08d807dff9f4%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637268005857289350&sdata=L%2FfRy4pSoo7gTUgVUPupSI3gwHIV%2FAlDyTSTqVfPzIg%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200603/3e1f7362/attachment-0001.htm>

From simon.rit at creatis.insa-lyon.fr  Wed Jun  3 18:52:48 2020
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 4 Jun 2020 00:52:48 +0200
Subject: [Rtk-users] Reconstruction Artifact
In-Reply-To: <BL0PR03MB41316E77652EBBB460F03473F8880@BL0PR03MB4131.namprd03.prod.outlook.com>
References: <BL0PR03MB41316ECCACB28DA6B03B06F5F88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
 <CAF0oig3o-225=F8HDXc5cCZ9ui2FV-cTJ1i0YfyvLfN7rNVQnQ@mail.gmail.com>
 <BL0PR03MB4131CBE48B4D2E5974B901CDF88B0@BL0PR03MB4131.namprd03.prod.outlook.com>
 <CAE0aawG55-Cm3=Xc5qW0V1yyPv5uP_gLHoom8Qv8-Ec02NZbxw@mail.gmail.com>
 <CAF0oig2COV-dkdtPueKMpOvM+1Qk4KNmbFAZvXyj-bknrdSg3w@mail.gmail.com>
 <CAH+sHrVL8-nxrT0GDq1QNYiNVFRTe2=43bf3T=OXJ-17+XC-XA@mail.gmail.com>
 <BL0PR03MB41318854B28E50B8312248CDF8880@BL0PR03MB4131.namprd03.prod.outlook.com>
 <CAF0oig3SZVP1yF3g46MoGyRaififUMYJDFN9wNAHttp3987NUw@mail.gmail.com>
 <BL0PR03MB41316E77652EBBB460F03473F8880@BL0PR03MB4131.namprd03.prod.outlook.com>
Message-ID: <CAF0oig1EraQGtnjPzRTbdU+yAB=nt06kSV_whk1+vKGE5NZLbQ@mail.gmail.com>

I tried and I could not understand what you've done in your code. Enclosed
is what I would use which gives a more reasonable result but which is full
of cone-beam artefacts (I think).

On Wed, Jun 3, 2020 at 7:59 PM Benjamin W. Maloney <
Benjamin.W.Maloney.TH at dartmouth.edu> wrote:

> Thanks.
>
>
> https://drive.google.com/drive/folders/1DTREuI80fWrIcBa5LIUfnAzsEPSRvhyZ?usp=sharing
>
> At that link are a .tif file for my projections and the .cxx
> reconstruction file I have been using
>
> Some notes about my system:
> SID: 306.6 mm
> SDD: 561.3 mm
>
> The detector panel is:
> 230mm x 70mm with a pixel matrix of 3072 x 864
> The projections are binned by 4 resulting in a pixel size of ~0.03mm-1 and
> a pixel array of 768 x 216
> There are 720 projection angles with an angular step of 0.5 degrees
>
> The system also has the sample on a turntable with a fixed source and
> detector but I believe that should be mathematically equivalent
>
> Thanks again!
> Ben
> ------------------------------
> *From:* Simon Rit <simon.rit at creatis.insa-lyon.fr>
> *Sent:* Wednesday, June 3, 2020 1:04 PM
> *To:* Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu>
> *Cc:* Chao Wu <wuchao04 at gmail.com>; Andreas Andersen <
> andreasga22 at gmail.com>; rtk-users at public.kitware.com <
> rtk-users at public.kitware.com>
> *Subject:* Re: [Rtk-users] Reconstruction Artifact
>
> Yes, that's allowed, other people did it before.
>
> On Wed, Jun 3, 2020 at 6:28 PM Benjamin W. Maloney <
> Benjamin.W.Maloney.TH at dartmouth.edu> wrote:
>
> Hi all,
>
> Thanks for the help!
> I'll be sure to make sure my preprocessed data is handled correctly.
>
> The reconstruction is meant to be a square, it is of a CIRS ACR digital
> mammography phantom
>
> I'm trying to send an example of my data but I can't get it under 147 MB
> data limit, is there a preferred method for sending this? I could send a
> google drive link if that is allowed
>
> Thanks again!
> Ben
>
> ------------------------------
> *From:* Chao Wu <wuchao04 at gmail.com>
> *Sent:* Wednesday, June 3, 2020 11:20 AM
> *To:* Simon Rit <simon.rit at creatis.insa-lyon.fr>
> *Cc:* Andreas Andersen <andreasga22 at gmail.com>;
> rtk-users at public.kitware.com <rtk-users at public.kitware.com>; Benjamin W.
> Maloney <Benjamin.W.Maloney.TH at dartmouth.edu>
> *Subject:* Re: [Rtk-users] Reconstruction Artifact
>
> If your projections record the number of X-ray photon counts instead of
> attenuation, an I0 must be set correctly and a logarithmic operation is
> needed before the projection data can be fed to the reconstruction loop.
> Both the I0 and the logarithmic operation can be handled by the RTK
> projection reader or manually, depending on your implementation. Zero and
> negative numbers must be coerced for the logarithmic operation by you if
> this is not the case in the RTK code you use.
>
> Regards,
> Chao
>
> Simon Rit <simon.rit at creatis.insa-lyon.fr> ?2020?6?3??? ??2:35???
>
> Yes, there is no such limitation as far as I know, you can use negative
> numbers and value above 1.
> Your result is really strange, it it supposed to be a square? I don't know
> what is the problem but that's clearly a geometry issue. We can always have
> a look if you're able to share some data.
> Simon
>
> On Wed, Jun 3, 2020 at 1:56 PM Andreas Andersen <andreasga22 at gmail.com>
> wrote:
>
> I don't think there are any restrictions technically.
> You should be able to use negative values, as the main arithmetic is just
> a sum
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSimonRit%2FRTK%2Fblob%2Fmaster%2Finclude%2FrtkBackProjectionImageFilter.hxx%23L106&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C7090376e438d462c76cf08d807dff9f4%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637268005857264400&sdata=ta2wjTGRMl8MRkv5qeqUZDYED%2FD%2BNtzkFEMdIHp7YfA%3D&reserved=0>
> and a multiplication
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSimonRit%2FRTK%2Fblob%2Fmaster%2Finclude%2FrtkBackProjectionImageFilter.hxx%23L115&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C7090376e438d462c76cf08d807dff9f4%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637268005857269384&sdata=pGY1uH5hjzUepFxR1AiDFKUFAxwNQM8mPIVDxwe%2B7N8%3D&reserved=0>
> .
>
> The only restriction I can see is that this sum and multiplication should
> not overflow (or underflow for negative values) the underlying type of the
> output image, as that would be undefined behaviour. Over- and underflow is
> unlikely for float, unless you have extremely high values (see wikipedia
> for floating point range
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFloating-point_arithmetic%23Range_of_floating-point_numbers&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C7090376e438d462c76cf08d807dff9f4%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637268005857274380&sdata=0wwsrWW8ELu0WjD5Ed9pJcKPFNI%2FNrSrIcGOV45jdgA%3D&reserved=0>
> ).
>
> /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 Wed, 3 Jun 2020 at 03:34, Benjamin W. Maloney <
> Benjamin.W.Maloney.TH at dartmouth.edu> wrote:
>
> Hi,
>
> I thought the same in regards to trying to rotating in the other
> direction. Unfortunately, that has a similar artifact but with the
> reconstruction flipped.
> Interestingly the overlap happens in a similar place but the internal
> structures are flipped
>
> ?1. Thanks!
> 2. I should have worded that better. My projection images will be
> preprocessed in a float format. I wanted to check if there were
> restrictions on these float values. Can input image data have negative
> values or high values? Or are they expected to have values between 0 and 1?
> I ask because some of the tools I have used to do this preprocessing
> (outside of RTK) have given negative values or 'stretched' the data from 0
> to 255 before saving.
>
> Ben
>
> ------------------------------
> *From:* Simon Rit <simon.rit at creatis.insa-lyon.fr>
> *Sent:* Tuesday, June 2, 2020 5:28 PM
> *To:* Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu>
> *Cc:* rtk-users at public.kitware.com <rtk-users at public.kitware.com>
> *Subject:* Re: [Rtk-users] Reconstruction Artifact
>
> Hi,
> Sometimes rotating in the wrong direction gives this kind of artefacts.
> It's quite possible that we don't use the same convention as other toolkits
> regarding this.
> For other questions:
> 1. Yes, you can use pixel as the unit. Then the image spacing should be 1
> obviously and indeed, sdd and sid should be in pixels.
> 2. I don't fully understand. If your data is the output of a count
> detector, then you either rely on RTK to guess the counts without object to
> compute the line integral, or your preprocess your projections to pass line
> integrals in a float format.
> Simon
>
> On Tue, Jun 2, 2020 at 4:51 PM Benjamin W. Maloney <
> Benjamin.W.Maloney.TH at dartmouth.edu> wrote:
>
> Hi all,
>
> Not sure if this is the right group to post to but here's my question:
>
> I have a code that pulls in my own projection images and uses
> the FDKConeBeamReconstructionFilter for reconstruction
>
> The reconstruction I am getting has an artifact where it looks like there
> are two overlapping objects rotated.
> I have used other reconstruction toolboxes (mainly TIGRE in MATLAB) with
> the similar geometry inputs and not had this issue. I suspect the
> difference is in the parts of the geometry that are set by default. My
> question is if anyone has seen this before and what input I should look
> into?
>
> I have a few more questions I may or may not be related:
> 1. I assume that since I set the origin etc of my images in pixel, sid and
> sdd should be in pixels as well?
> 2. Are there restrictions related the scalar values of the projection
> data? My data will be in detector counts rather than linear attenuation
> coefficients, is that okay?
> I have attached an image to show this issue. It is supposed to be a
> rectangular mammography phantom. It is a slice in XZ plane
>
> Thanks for the help!
> Ben
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C7090376e438d462c76cf08d807dff9f4%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637268005857279367&sdata=rN0WtXgPU48YJ%2BDkxnnx2StLGljd1AGBRX6IaXgRaY0%3D&reserved=0>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C7090376e438d462c76cf08d807dff9f4%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637268005857284358&sdata=cbP3Anssi1CsT65ReQWUQACc4nprtjW%2Bx%2F279Q0GH1k%3D&reserved=0>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C7090376e438d462c76cf08d807dff9f4%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637268005857289350&sdata=L%2FfRy4pSoo7gTUgVUPupSI3gwHIV%2FAlDyTSTqVfPzIg%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200604/701d067d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FirstReconstruction.cxx
Type: text/x-c++src
Size: 3869 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200604/701d067d/attachment-0001.cxx>

From Benjamin.W.Maloney.TH at dartmouth.edu  Mon Jun  8 15:21:32 2020
From: Benjamin.W.Maloney.TH at dartmouth.edu (Benjamin W. Maloney)
Date: Mon, 8 Jun 2020 19:21:32 +0000
Subject: [Rtk-users] Iterative Reconstruction inputs
Message-ID: <BL0PR03MB4131ED528AFE332197515B71F8850@BL0PR03MB4131.namprd03.prod.outlook.com>

Hi all,

Thanks for the help getting my reconstruction up and running last week

I apologize if I missed something obvious
I was hoping to use an iterative technique but I'm having trouble getting it running
Is it required to set a forward projection filter?

The relevant code is:
using FDKGPUType = rtk::CudaIterativeFDKConeBeamReconstructionFilter;
FDKGPUType::Pointer feldkamp = FDKGPUType::New();
feldkamp->SetInput(0, constantImageSource2->GetOutput()); //Reconstruction Volume
feldkamp->SetInput(1, reader->GetOutput()); //Projection Images
feldkamp->SetGeometry(geometry);

I get an error here:
Exception thrown: read access violation.
this->m_ForwardProjectionFilter.m_Pointer was nullptr.
On line 121 of rtkIterativeFDKConeBeamReconstructionFilter.hxx

This looks like it doesn't set a forward projection filter by default. I'm struggling a bit to get the format for setting this correct

Thanks for the help!
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200608/3923f449/attachment.htm>

From simon.rit at creatis.insa-lyon.fr  Thu Jun 11 09:20:44 2020
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 11 Jun 2020 15:20:44 +0200
Subject: [Rtk-users] Iterative Reconstruction inputs
In-Reply-To: <BL0PR03MB4131ED528AFE332197515B71F8850@BL0PR03MB4131.namprd03.prod.outlook.com>
References: <BL0PR03MB4131ED528AFE332197515B71F8850@BL0PR03MB4131.namprd03.prod.outlook.com>
Message-ID: <CAF0oig1=b=mCPj_fKh4cobXckw-BghYvSAoTeqqdRpGpgUZm9w@mail.gmail.com>

Hi Ben,
This should have been fixed since this commit
<https://github.com/SimonRit/RTK/commit/2c8ae75f3d23dd6174f4bf707217e5cfc2b7e799>.
Maybe you can try to upgrade to RTK master?
Otherwise, check the doxygen documentation
<http://www.openrtk.org/Doxygen/classes.html> or you can check here
<https://github.com/SimonRit/RTK/blob/master/include/rtkGgoFunctions.h#L309-L338>
how it's done in the applications.
Simon

On Mon, Jun 8, 2020 at 9:22 PM Benjamin W. Maloney <
Benjamin.W.Maloney.TH at dartmouth.edu> wrote:

> Hi all,
>
> Thanks for the help getting my reconstruction up and running last week
>
> I apologize if I missed something obvious
> I was hoping to use an iterative technique but I'm having trouble getting
> it running
> Is it required to set a forward projection filter?
>
> The relevant code is:
> using FDKGPUType = rtk::CudaIterativeFDKConeBeamReconstructionFilter;
> FDKGPUType::Pointer feldkamp = FDKGPUType::New();
> feldkamp->SetInput(0, constantImageSource2->GetOutput()); //Reconstruction
> Volume
> feldkamp->SetInput(1, reader->GetOutput()); //Projection Images
> feldkamp->SetGeometry(geometry);
>
> I get an error here:
> Exception thrown: read access violation.
> this->m_ForwardProjectionFilter.m_Pointer was nullptr.
> On line 121 of rtkIterativeFDKConeBeamReconstructionFilter.hxx
>
> This looks like it doesn't set a forward projection filter by default. I'm
> struggling a bit to get the format for setting this correct
>
> Thanks for the help!
> Ben
> _______________________________________________
> 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/20200611/8ecc71d4/attachment.htm>

From Benjamin.W.Maloney.TH at dartmouth.edu  Thu Jun 11 14:34:09 2020
From: Benjamin.W.Maloney.TH at dartmouth.edu (Benjamin W. Maloney)
Date: Thu, 11 Jun 2020 18:34:09 +0000
Subject: [Rtk-users] Iterative Reconstruction inputs
In-Reply-To: <CAF0oig1=b=mCPj_fKh4cobXckw-BghYvSAoTeqqdRpGpgUZm9w@mail.gmail.com>
References: <BL0PR03MB4131ED528AFE332197515B71F8850@BL0PR03MB4131.namprd03.prod.outlook.com>,
 <CAF0oig1=b=mCPj_fKh4cobXckw-BghYvSAoTeqqdRpGpgUZm9w@mail.gmail.com>
Message-ID: <BL0PR03MB413114E732FC6F8F1465BD64F8800@BL0PR03MB4131.namprd03.prod.outlook.com>

Hi Simon,

Thanks! Updating to a newer release of RTK did the trick

Best,
Ben
________________________________
From: Simon Rit <simon.rit at creatis.insa-lyon.fr>
Sent: Thursday, June 11, 2020 9:20 AM
To: Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu>
Cc: rtk-users at public.kitware.com <rtk-users at public.kitware.com>
Subject: Re: [Rtk-users] Iterative Reconstruction inputs

Hi Ben,
This should have been fixed since this commit<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSimonRit%2FRTK%2Fcommit%2F2c8ae75f3d23dd6174f4bf707217e5cfc2b7e799&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C21f431af0b8d406cd15808d80e09ff47%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637274783398931102&sdata=2JECjsqwwo92xZGqrb7Lwwf1dEeo4biIMlrNzbr0%2F2Y%3D&reserved=0>. Maybe you can try to upgrade to RTK master?
Otherwise, check the doxygen documentation<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openrtk.org%2FDoxygen%2Fclasses.html&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C21f431af0b8d406cd15808d80e09ff47%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637274783398931102&sdata=8dfMtgF4VZwvcPUpVGN7ojdAEzRSms0TiFTgF1fIQ9M%3D&reserved=0> or you can check here<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSimonRit%2FRTK%2Fblob%2Fmaster%2Finclude%2FrtkGgoFunctions.h%23L309-L338&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C21f431af0b8d406cd15808d80e09ff47%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637274783398941096&sdata=BdkgS10Ns27%2FuV4xm1YW50y6oSa%2FrWK6a1EgljHlIWY%3D&reserved=0> how it's done in the applications.
Simon

On Mon, Jun 8, 2020 at 9:22 PM Benjamin W. Maloney <Benjamin.W.Maloney.TH at dartmouth.edu<mailto:Benjamin.W.Maloney.TH at dartmouth.edu>> wrote:
Hi all,

Thanks for the help getting my reconstruction up and running last week

I apologize if I missed something obvious
I was hoping to use an iterative technique but I'm having trouble getting it running
Is it required to set a forward projection filter?

The relevant code is:
using FDKGPUType = rtk::CudaIterativeFDKConeBeamReconstructionFilter;
FDKGPUType::Pointer feldkamp = FDKGPUType::New();
feldkamp->SetInput(0, constantImageSource2->GetOutput()); //Reconstruction Volume
feldkamp->SetInput(1, reader->GetOutput()); //Projection Images
feldkamp->SetGeometry(geometry);

I get an error here:
Exception thrown: read access violation.
this->m_ForwardProjectionFilter.m_Pointer was nullptr.
On line 121 of rtkIterativeFDKConeBeamReconstructionFilter.hxx

This looks like it doesn't set a forward projection filter by default. I'm struggling a bit to get the format for setting this correct

Thanks for the help!
Ben
_______________________________________________
Rtk-users mailing list
Rtk-users at public.kitware.com<mailto:Rtk-users at public.kitware.com>
https://public.kitware.com/mailman/listinfo/rtk-users<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7CBenjamin.W.Maloney.TH%40dartmouth.edu%7C21f431af0b8d406cd15808d80e09ff47%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637274783398941096&sdata=6kudwf%2B2UVN%2BqlHoq3fifngM9kMnOxYSDy3Mmc9gCn4%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200611/18f5f5d3/attachment.htm>

From simon.rit at creatis.insa-lyon.fr  Fri Jun 12 10:22:59 2020
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 12 Jun 2020 16:22:59 +0200
Subject: [Rtk-users] Blurry reconstructions in ROOSTER
In-Reply-To: <003801d632b4$51631b80$f4295280$@web.de>
References: <003801d632b4$51631b80$f4295280$@web.de>
Message-ID: <CAF0oig2+DSRDC1hdfJLnNw8hEMJ59aGM6pdNgNfc_i7ts3SVHQ@mail.gmail.com>

Hi Erwin,
I finally had time to look into this issue. I think the problem is that the
conjugate gradient step is not the same in the two algorithms. If you
carefully check Cyril's ROOSTER paper, he does not do a 3D conjugate
gradient per phase but a 4D conjugate gradient. In your case, you have set
the data such that each projection is used for one frame only but 4D CG is
still used. Minimizing all frames at the same time instead of each one
separately means that different steps are taken in the two algorithms.
Eventually, if we would go to convergence, they should both go the same
unique result but you clearly stop before convergence with a few iterations.
I checked the convergence behavior with the new iteration reporting feature
after correcting a bug (PR here <https://github.com/SimonRit/RTK/pull/355>):

rtkconjugategradient -p . -r subproj0.mha -o ./subCGedge7e-05_T0.mha -g
./subgeometry0.xml --fp CudaRayCast --nocudacg --bp CudaVoxelBased --niter
50 -v --spacing 0.8 --dimension 187,42,102 --origin -80.41,-22.84,-36.61
--output-every 1 --iteration-file-name iter3d_%03d.mha

rtkfourdconjugategradient -p . -r 'lineint_.mha' -g ./geometry.xml -o
./rooster4Dedge8e-05.mha --signal ./respSignal_edge.txt --frames 4 --fp
CudaRayCast --bp CudaVoxelBased -n 50 -v --spacing 0.8 --dimension
187,42,102 --origin -80.41,-22.84,-36.61 --output-every 1
--iteration-file-name iter4d_%03d.mha

I also tried to increase the number of cg iterations in ROOSTER and that
indeed seems to improve the match between the two results. So the solution
is to adjust the number of CG iterations which is one of the many
hyperparameters of this algorithm.

I hope this is clear, if not let me know. And sorry for taking so long to
(hopefully) clarify this.
Best regards,
Simon

On Mon, May 25, 2020 at 7:01 PM <erwinwalter11 at web.de> wrote:

> Hi,
>
> for my Master?s thesis I am testing some implementations for a 4D
> reconstruction of small mice set. For this I apply the rooster algorithm on
> the full projection set with a discretised phase signal. To compare the
> rooster reconstruction I also take a subset of the full set with
> rtksubselect considering the phase signal and apply the regularized
> conjugate gradient reconstruction algorithm on that subset of projections.
> This way I get a 3D reconstruction for each phase respectively.
>
>
>
> However with the same gamma_space=8e-6 (in regularized cg gammatv defined)
> in the total variation step both in rooster and regularized conjugate
> gradient and gamma_time equal to 0 in roosters algorithm, I do not get the
> same results. The rooster reconstruction is much more blurried compared to
> the regularized conjugate gradient reconstruction, which surprises me.
> Shouldn?t be both reconstructions nearly identical under same conditions?
> Outer and inner loops (n_iter=30, tv_iter=10, cg_iter=4) are equally set.
> The blurriness occurs only in respiratory phases with small amount of
> projections (approx. 90)
>
>
>
> For visualization I have added an example to the following link:
> https://gigamove.rz.rwth-aachen.de/d/id/P42uxboh472jzV
>
> The regularized conjugate gradient reconstruction is shown on both upper
> images and the rooster reconstruction is shown on both lower images.
>
>
>
> I appreciate any help or explanation.
>
>
>
> Erwin
> _______________________________________________
> 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/20200612/8d3401e2/attachment.htm>

From yoonho94.na at gmail.com  Sun Jun 14 21:24:01 2020
From: yoonho94.na at gmail.com (=?UTF-8?B?64KY7Jyk7Zi4?=)
Date: Mon, 15 Jun 2020 10:24:01 +0900
Subject: [Rtk-users] how does origin and spacing affects in reconstructing
 images?
Message-ID: <CAPZFa=dmk6Y4Qj--5WhY17FXSWb7yY0NC9+DTwkEokfB6GuEjg@mail.gmail.com>

Hi rtk-users.

I am curious about origin and spacing.

I only know that origin is where the pixel starts

and spacing is the distance between pixel coordinates.

how do they affect in reconstructing images?

does the computation begins with where pixel origin is?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200615/92ae8072/attachment.htm>

From Brani_Rusanov at hotmail.com  Mon Jun 15 04:55:16 2020
From: Brani_Rusanov at hotmail.com (Brani Rusanov)
Date: Mon, 15 Jun 2020 08:55:16 +0000
Subject: [Rtk-users] Insufficient Data For Proper Parker Weighting
Message-ID: <ME1PR01MB09792FC37C1CD676BFC36852849C0@ME1PR01MB0979.ausprd01.prod.outlook.com>


Hi,

I am attempting to reconstruct Varian raw cone-beam data. The specific type of scan is a short scan, 200 degrees generating 501 projections. During reconstruction I get the message: ?you do not have enough data for proper Parker weighting (short scan) Delta is 9.951 degrees and should be more than half the beam angle I.e. 11.2359 degrees.?

Since I have not generated the geometry myself, rather, used a pre-set Varian protocol, I am unsure why I get this error.

How could I rectify this issue? Furthermore, what consequences are there to not applying a Parker weighting?

The geometry header is attached.

Your response is greatly appreciated,
Brani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200615/6a565e3a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: geometry.xml
Type: text/xml
Size: 251109 bytes
Desc: geometry.xml
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200615/6a565e3a/attachment-0001.xml>

From simon.rit at creatis.insa-lyon.fr  Mon Jun 15 07:48:33 2020
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 15 Jun 2020 13:48:33 +0200
Subject: [Rtk-users] how does origin and spacing affects in
 reconstructing images?
In-Reply-To: <CAPZFa=dmk6Y4Qj--5WhY17FXSWb7yY0NC9+DTwkEokfB6GuEjg@mail.gmail.com>
References: <CAPZFa=dmk6Y4Qj--5WhY17FXSWb7yY0NC9+DTwkEokfB6GuEjg@mail.gmail.com>
Message-ID: <CAF0oig3ewDNiVu8_0zstLZDhdPzp4q2HenEwW7AGiEmjjz4CHw@mail.gmail.com>

Hi,
The origin, the direction and the spacing define the sampling grid of your
images, both in the projection space and in the image space. This is
explained here
<https://itk.org/ITKSoftwareGuide/html/Book1/ITKSoftwareGuide-Book1ch4.html#x45-500004.1>,
e.g., in Fig. 4.
Simon

On Mon, Jun 15, 2020 at 3:25 AM ??? <yoonho94.na at gmail.com> wrote:

> Hi rtk-users.
>
> I am curious about origin and spacing.
>
> I only know that origin is where the pixel starts
>
> and spacing is the distance between pixel coordinates.
>
> how do they affect in reconstructing images?
>
> does the computation begins with where pixel origin is?
> _______________________________________________
> 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/20200615/84e1fe0d/attachment.htm>

From simon.rit at creatis.insa-lyon.fr  Mon Jun 15 08:59:19 2020
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 15 Jun 2020 14:59:19 +0200
Subject: [Rtk-users] Insufficient Data For Proper Parker Weighting
In-Reply-To: <ME1PR01MB09792FC37C1CD676BFC36852849C0@ME1PR01MB0979.ausprd01.prod.outlook.com>
References: <ME1PR01MB09792FC37C1CD676BFC36852849C0@ME1PR01MB0979.ausprd01.prod.outlook.com>
Message-ID: <CAF0oig3yp_M6XU96hvfRmgxKxc9Ly930vR3=gTb8FtJNmJe+DQ@mail.gmail.com>

Hi,
You are getting this because RTK detects that the scan is too short. Parker
weighting requires pi + the fan-angle to be able to reconstruct exactly the
central slice of your scan. Check here
<https://github.com/SimonRit/RTK/blob/master/include/rtkParkerShortScanImageFilter.hxx#L139>
how this is calculated in RTK.
Possible solutions are cropping the projections to reduce the fan angle.
I'm not sure what are the consequences but they'll probably be small since
not much is missing in your case. It's even likely that RTK could be
improved by discretizing differently the integral in parker weighting, in
which case you'd get enough projections.
Simon


On Mon, Jun 15, 2020 at 10:56 AM Brani Rusanov <Brani_Rusanov at hotmail.com>
wrote:

>
> Hi,
>
> I am attempting to reconstruct Varian raw cone-beam data. The specific
> type of scan is a short scan, 200 degrees generating 501 projections.
> During reconstruction I get the message: ?you do not have enough data for
> proper Parker weighting (short scan) Delta is 9.951 degrees and should be
> more than half the beam angle I.e. 11.2359 degrees.?
>
> Since I have not generated the geometry myself, rather, used a pre-set
> Varian protocol, I am unsure why I get this error.
>
> How could I rectify this issue? Furthermore, what consequences are there
> to not applying a Parker weighting?
>
> The geometry header is attached.
>
> Your response is greatly appreciated,
> Brani
> _______________________________________________
> 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/20200615/2faae45a/attachment.htm>

From simon.rit at creatis.insa-lyon.fr  Thu Jun 18 08:17:16 2020
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 18 Jun 2020 14:17:16 +0200
Subject: [Rtk-users] itkPointSetD3 error
In-Reply-To: <CAGdQuQqe2Yry-T_Db9QriM8Gn+gfMoPK9qwifQeSn3oJjGG1fA@mail.gmail.com>
References: <CAGdQuQqe2Yry-T_Db9QriM8Gn+gfMoPK9qwifQeSn3oJjGG1fA@mail.gmail.com>
Message-ID: <CAF0oig13GxW=EBNaf3O8di+OyOqK2PKX1qu=QFFNXPE=8uhraA@mail.gmail.com>

Hi,
Please use the mailing list. I think you used the latest itk for which the
RTK version is not compatible. You should either downgrade to ITK v5.0.1 or
download an RTK package compiled against the latest version, e.g., here
<https://dev.azure.com/simonrit/RTK/_build/results?buildId=534&view=artifacts&type=publishedArtifacts>
.
Simon

On Thu, Jun 18, 2020 at 9:37 AM Sangroh Kim <sangroh.kim at gmail.com> wrote:

> Hi Simon,
>
> I am new in RTK and trying to learn how to use it.
> I use WinPython 3.6.7 and installed VTK, ITK and ITK_RTK using pip install
> command.
> Then I tried to run FirstReconstruction.py file in Jupyter and am having
> an error.
>
> itkPointSetD3 not loaded from module ITKRegistrationCommon because of
> exception: module 'itk.ITKRegistrationCommonPython' has no attribute
> 'itkPointSetD3'
> [image: image.png]
>
> Do you have any idea how to fix this?
> Thanks.
>
> Best Regards,
> Sangroh
>
> Sangroh Kim
> Medical Physicist
> Virginia Mason Medical Center
> Seattle, WA 98101
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200618/bcac2c7f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 131596 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200618/bcac2c7f/attachment-0001.png>

From brani_rusanov at hotmail.com  Sun Jun 28 23:51:34 2020
From: brani_rusanov at hotmail.com (Brani Rusanov)
Date: Mon, 29 Jun 2020 03:51:34 +0000
Subject: [Rtk-users] Insufficient Data For Proper Parker Weighting
In-Reply-To: <CAF0oig3yp_M6XU96hvfRmgxKxc9Ly930vR3=gTb8FtJNmJe+DQ@mail.gmail.com>
References: <ME1PR01MB09792FC37C1CD676BFC36852849C0@ME1PR01MB0979.ausprd01.prod.outlook.com>,
 <CAF0oig3yp_M6XU96hvfRmgxKxc9Ly930vR3=gTb8FtJNmJe+DQ@mail.gmail.com>
Message-ID: <ME1PR01MB09791A1E85A6DE09A5B656FC849B0@ME1PR01MB0979.ausprd01.prod.outlook.com>

Hi Simon,

Sorry for the late reply, I have been quite busy recently.
My projections are 1024x768. I cropped the largest dimension and noticed that "half the beam angle" value decreases slightly, gets close to the value 9.951, but with further reduction in dimension size the beam angle suddenly jumps to ~20 degrees (observed value during reconstruction). So cropping the projection does not seem to solve the problem. Do you have any ideas how to fix this?

If you require any geometry or projection files, I would be happy to send them over.

Kind regards,
Brani
________________________________
From: Simon Rit <simon.rit at creatis.insa-lyon.fr>
Sent: Monday, June 15, 2020 8:59:19 PM
To: Brani Rusanov <Brani_Rusanov at hotmail.com>
Cc: rtk-users at public.kitware.com <rtk-users at public.kitware.com>
Subject: Re: [Rtk-users] Insufficient Data For Proper Parker Weighting

Hi,
You are getting this because RTK detects that the scan is too short. Parker weighting requires pi + the fan-angle to be able to reconstruct exactly the central slice of your scan. Check here<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSimonRit%2FRTK%2Fblob%2Fmaster%2Finclude%2FrtkParkerShortScanImageFilter.hxx%23L139&data=02%7C01%7C%7C6a5c9d4d141144d23ea908d8112ba92a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637278226503872156&sdata=rhmqcGwHfDKDsJy62xyMD2jhf6KMyJ04OwwWwiF8bkM%3D&reserved=0> how this is calculated in RTK.
Possible solutions are cropping the projections to reduce the fan angle. I'm not sure what are the consequences but they'll probably be small since not much is missing in your case. It's even likely that RTK could be improved by discretizing differently the integral in parker weighting, in which case you'd get enough projections.
Simon


On Mon, Jun 15, 2020 at 10:56 AM Brani Rusanov <Brani_Rusanov at hotmail.com<mailto:Brani_Rusanov at hotmail.com>> wrote:

Hi,

I am attempting to reconstruct Varian raw cone-beam data. The specific type of scan is a short scan, 200 degrees generating 501 projections. During reconstruction I get the message: ?you do not have enough data for proper Parker weighting (short scan) Delta is 9.951 degrees and should be more than half the beam angle I.e. 11.2359 degrees.?

Since I have not generated the geometry myself, rather, used a pre-set Varian protocol, I am unsure why I get this error.

How could I rectify this issue? Furthermore, what consequences are there to not applying a Parker weighting?

The geometry header is attached.

Your response is greatly appreciated,
Brani
_______________________________________________
Rtk-users mailing list
Rtk-users at public.kitware.com<mailto:Rtk-users at public.kitware.com>
https://public.kitware.com/mailman/listinfo/rtk-users<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7C%7C6a5c9d4d141144d23ea908d8112ba92a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637278226503882155&sdata=7fBB%2Bv58W3WJtsK7KLgR8cTwu%2F4U7AZnn2V9sP8%2FtbM%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200629/339d1b3c/attachment.htm>

From simon.rit at creatis.insa-lyon.fr  Mon Jun 29 17:22:24 2020
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 29 Jun 2020 23:22:24 +0200
Subject: [Rtk-users] Insufficient Data For Proper Parker Weighting
In-Reply-To: <ME1PR01MB09791A1E85A6DE09A5B656FC849B0@ME1PR01MB0979.ausprd01.prod.outlook.com>
References: <ME1PR01MB09792FC37C1CD676BFC36852849C0@ME1PR01MB0979.ausprd01.prod.outlook.com>
 <CAF0oig3yp_M6XU96hvfRmgxKxc9Ly930vR3=gTb8FtJNmJe+DQ@mail.gmail.com>
 <ME1PR01MB09791A1E85A6DE09A5B656FC849B0@ME1PR01MB0979.ausprd01.prod.outlook.com>
Message-ID: <CAF0oig1LP_vsbOfbSo7fvwW47-2f+egWk=nTxg3CdANOoeR0Fw@mail.gmail.com>

Hi,
No, I don't really understand what you're describing. It's probably easier
if you can share the RTK geometry file and the header of your projection
images (no need to share the data, I'll simulate some).
Thanks,
Simon

On Mon, Jun 29, 2020 at 5:51 AM Brani Rusanov <brani_rusanov at hotmail.com>
wrote:

> Hi Simon,
>
> Sorry for the late reply, I have been quite busy recently.
> My projections are 1024x768. I cropped the largest dimension and noticed
> that "half the beam angle" value decreases slightly, gets close to the
> value 9.951, but with further reduction in dimension size the beam angle
> suddenly jumps to ~20 degrees (observed value during reconstruction). So
> cropping the projection does not seem to solve the problem. Do you have any
> ideas how to fix this?
>
> If you require any geometry or projection files, I would be happy to send
> them over.
>
> Kind regards,
> Brani
> ------------------------------
> *From:* Simon Rit <simon.rit at creatis.insa-lyon.fr>
> *Sent:* Monday, June 15, 2020 8:59:19 PM
> *To:* Brani Rusanov <Brani_Rusanov at hotmail.com>
> *Cc:* rtk-users at public.kitware.com <rtk-users at public.kitware.com>
> *Subject:* Re: [Rtk-users] Insufficient Data For Proper Parker Weighting
>
> Hi,
> You are getting this because RTK detects that the scan is too short.
> Parker weighting requires pi + the fan-angle to be able to reconstruct
> exactly the central slice of your scan. Check here
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSimonRit%2FRTK%2Fblob%2Fmaster%2Finclude%2FrtkParkerShortScanImageFilter.hxx%23L139&data=02%7C01%7C%7C6a5c9d4d141144d23ea908d8112ba92a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637278226503872156&sdata=rhmqcGwHfDKDsJy62xyMD2jhf6KMyJ04OwwWwiF8bkM%3D&reserved=0>
> how this is calculated in RTK.
> Possible solutions are cropping the projections to reduce the fan angle.
> I'm not sure what are the consequences but they'll probably be small since
> not much is missing in your case. It's even likely that RTK could be
> improved by discretizing differently the integral in parker weighting, in
> which case you'd get enough projections.
> Simon
>
>
> On Mon, Jun 15, 2020 at 10:56 AM Brani Rusanov <Brani_Rusanov at hotmail.com>
> wrote:
>
>
> Hi,
>
> I am attempting to reconstruct Varian raw cone-beam data. The specific
> type of scan is a short scan, 200 degrees generating 501 projections.
> During reconstruction I get the message: ?you do not have enough data for
> proper Parker weighting (short scan) Delta is 9.951 degrees and should be
> more than half the beam angle I.e. 11.2359 degrees.?
>
> Since I have not generated the geometry myself, rather, used a pre-set
> Varian protocol, I am unsure why I get this error.
>
> How could I rectify this issue? Furthermore, what consequences are there
> to not applying a Parker weighting?
>
> The geometry header is attached.
>
> Your response is greatly appreciated,
> Brani
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7C%7C6a5c9d4d141144d23ea908d8112ba92a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637278226503882155&sdata=7fBB%2Bv58W3WJtsK7KLgR8cTwu%2F4U7AZnn2V9sP8%2FtbM%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200629/65e9e2d0/attachment.htm>

From brani_rusanov at hotmail.com  Tue Jun 30 00:02:26 2020
From: brani_rusanov at hotmail.com (Brani Rusanov)
Date: Tue, 30 Jun 2020 04:02:26 +0000
Subject: [Rtk-users] Insufficient Data For Proper Parker Weighting
In-Reply-To: <CAF0oig1LP_vsbOfbSo7fvwW47-2f+egWk=nTxg3CdANOoeR0Fw@mail.gmail.com>
References: <ME1PR01MB09792FC37C1CD676BFC36852849C0@ME1PR01MB0979.ausprd01.prod.outlook.com>
 <CAF0oig3yp_M6XU96hvfRmgxKxc9Ly930vR3=gTb8FtJNmJe+DQ@mail.gmail.com>
 <ME1PR01MB09791A1E85A6DE09A5B656FC849B0@ME1PR01MB0979.ausprd01.prod.outlook.com>,
 <CAF0oig1LP_vsbOfbSo7fvwW47-2f+egWk=nTxg3CdANOoeR0Fw@mail.gmail.com>
Message-ID: <ME1PR01MB09792F7CBA757E0D1B92530F846F0@ME1PR01MB0979.ausprd01.prod.outlook.com>

Hi Simon,

Attached is the geometry file and projection header.

I appreciate your help and time very much.

Kind regards,
Brani

________________________________
From: Simon Rit <simon.rit at creatis.insa-lyon.fr>
Sent: Tuesday, 30 June 2020 5:22 AM
To: Brani Rusanov <brani_rusanov at hotmail.com>
Cc: rtk-users at public.kitware.com <rtk-users at public.kitware.com>
Subject: Re: [Rtk-users] Insufficient Data For Proper Parker Weighting

Hi,
No, I don't really understand what you're describing. It's probably easier if you can share the RTK geometry file and the header of your projection images (no need to share the data, I'll simulate some).
Thanks,
Simon

On Mon, Jun 29, 2020 at 5:51 AM Brani Rusanov <brani_rusanov at hotmail.com<mailto:brani_rusanov at hotmail.com>> wrote:
Hi Simon,

Sorry for the late reply, I have been quite busy recently.
My projections are 1024x768. I cropped the largest dimension and noticed that "half the beam angle" value decreases slightly, gets close to the value 9.951, but with further reduction in dimension size the beam angle suddenly jumps to ~20 degrees (observed value during reconstruction). So cropping the projection does not seem to solve the problem. Do you have any ideas how to fix this?

If you require any geometry or projection files, I would be happy to send them over.

Kind regards,
Brani
________________________________
From: Simon Rit <simon.rit at creatis.insa-lyon.fr<mailto:simon.rit at creatis.insa-lyon.fr>>
Sent: Monday, June 15, 2020 8:59:19 PM
To: Brani Rusanov <Brani_Rusanov at hotmail.com<mailto:Brani_Rusanov at hotmail.com>>
Cc: rtk-users at public.kitware.com<mailto:rtk-users at public.kitware.com> <rtk-users at public.kitware.com<mailto:rtk-users at public.kitware.com>>
Subject: Re: [Rtk-users] Insufficient Data For Proper Parker Weighting

Hi,
You are getting this because RTK detects that the scan is too short. Parker weighting requires pi + the fan-angle to be able to reconstruct exactly the central slice of your scan. Check here<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSimonRit%2FRTK%2Fblob%2Fmaster%2Finclude%2FrtkParkerShortScanImageFilter.hxx%23L139&data=02%7C01%7C%7Cdd34d79ef19149c0573e08d81c72539c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637290624638730119&sdata=ULmc3xlN2%2FTJlHJpo%2FYGvVLVayVbnewu8r%2B%2FrhVD6Ew%3D&reserved=0> how this is calculated in RTK.
Possible solutions are cropping the projections to reduce the fan angle. I'm not sure what are the consequences but they'll probably be small since not much is missing in your case. It's even likely that RTK could be improved by discretizing differently the integral in parker weighting, in which case you'd get enough projections.
Simon


On Mon, Jun 15, 2020 at 10:56 AM Brani Rusanov <Brani_Rusanov at hotmail.com<mailto:Brani_Rusanov at hotmail.com>> wrote:

Hi,

I am attempting to reconstruct Varian raw cone-beam data. The specific type of scan is a short scan, 200 degrees generating 501 projections. During reconstruction I get the message: ?you do not have enough data for proper Parker weighting (short scan) Delta is 9.951 degrees and should be more than half the beam angle I.e. 11.2359 degrees.?

Since I have not generated the geometry myself, rather, used a pre-set Varian protocol, I am unsure why I get this error.

How could I rectify this issue? Furthermore, what consequences are there to not applying a Parker weighting?

The geometry header is attached.

Your response is greatly appreciated,
Brani
_______________________________________________
Rtk-users mailing list
Rtk-users at public.kitware.com<mailto:Rtk-users at public.kitware.com>
https://public.kitware.com/mailman/listinfo/rtk-users<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7C%7Cdd34d79ef19149c0573e08d81c72539c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637290624638740143&sdata=rfrMAQf4nej0oPrbyDcIHHLvGGTVDUQaL1aqW7BnleE%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200630/2c12c4ff/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: geometry.xml
Type: text/xml
Size: 250408 bytes
Desc: geometry.xml
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200630/2c12c4ff/attachment-0001.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: projections.mhd
Type: application/octet-stream
Size: 370 bytes
Desc: projections.mhd
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200630/2c12c4ff/attachment-0001.obj>

From brani_rusanov at hotmail.com  Tue Jun 30 00:45:22 2020
From: brani_rusanov at hotmail.com (Brani Rusanov)
Date: Tue, 30 Jun 2020 04:45:22 +0000
Subject: [Rtk-users] Insufficient Data For Proper Parker Weighting
In-Reply-To: <CAF0oig1LP_vsbOfbSo7fvwW47-2f+egWk=nTxg3CdANOoeR0Fw@mail.gmail.com>
References: <ME1PR01MB09792FC37C1CD676BFC36852849C0@ME1PR01MB0979.ausprd01.prod.outlook.com>
 <CAF0oig3yp_M6XU96hvfRmgxKxc9Ly930vR3=gTb8FtJNmJe+DQ@mail.gmail.com>
 <ME1PR01MB09791A1E85A6DE09A5B656FC849B0@ME1PR01MB0979.ausprd01.prod.outlook.com>,
 <CAF0oig1LP_vsbOfbSo7fvwW47-2f+egWk=nTxg3CdANOoeR0Fw@mail.gmail.com>
Message-ID: <ME1PR01MB09797929586D4BCB53C8CCAC846F0@ME1PR01MB0979.ausprd01.prod.outlook.com>

Sorry I forgot to mention, the Parker message only appears when reconstructing with CUDA enabled.

________________________________
From: Simon Rit <simon.rit at creatis.insa-lyon.fr>
Sent: Tuesday, 30 June 2020 5:22 AM
To: Brani Rusanov <brani_rusanov at hotmail.com>
Cc: rtk-users at public.kitware.com <rtk-users at public.kitware.com>
Subject: Re: [Rtk-users] Insufficient Data For Proper Parker Weighting

Hi,
No, I don't really understand what you're describing. It's probably easier if you can share the RTK geometry file and the header of your projection images (no need to share the data, I'll simulate some).
Thanks,
Simon

On Mon, Jun 29, 2020 at 5:51 AM Brani Rusanov <brani_rusanov at hotmail.com<mailto:brani_rusanov at hotmail.com>> wrote:
Hi Simon,

Sorry for the late reply, I have been quite busy recently.
My projections are 1024x768. I cropped the largest dimension and noticed that "half the beam angle" value decreases slightly, gets close to the value 9.951, but with further reduction in dimension size the beam angle suddenly jumps to ~20 degrees (observed value during reconstruction). So cropping the projection does not seem to solve the problem. Do you have any ideas how to fix this?

If you require any geometry or projection files, I would be happy to send them over.

Kind regards,
Brani
________________________________
From: Simon Rit <simon.rit at creatis.insa-lyon.fr<mailto:simon.rit at creatis.insa-lyon.fr>>
Sent: Monday, June 15, 2020 8:59:19 PM
To: Brani Rusanov <Brani_Rusanov at hotmail.com<mailto:Brani_Rusanov at hotmail.com>>
Cc: rtk-users at public.kitware.com<mailto:rtk-users at public.kitware.com> <rtk-users at public.kitware.com<mailto:rtk-users at public.kitware.com>>
Subject: Re: [Rtk-users] Insufficient Data For Proper Parker Weighting

Hi,
You are getting this because RTK detects that the scan is too short. Parker weighting requires pi + the fan-angle to be able to reconstruct exactly the central slice of your scan. Check here<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSimonRit%2FRTK%2Fblob%2Fmaster%2Finclude%2FrtkParkerShortScanImageFilter.hxx%23L139&data=02%7C01%7C%7Cdd34d79ef19149c0573e08d81c72539c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637290624638730119&sdata=ULmc3xlN2%2FTJlHJpo%2FYGvVLVayVbnewu8r%2B%2FrhVD6Ew%3D&reserved=0> how this is calculated in RTK.
Possible solutions are cropping the projections to reduce the fan angle. I'm not sure what are the consequences but they'll probably be small since not much is missing in your case. It's even likely that RTK could be improved by discretizing differently the integral in parker weighting, in which case you'd get enough projections.
Simon


On Mon, Jun 15, 2020 at 10:56 AM Brani Rusanov <Brani_Rusanov at hotmail.com<mailto:Brani_Rusanov at hotmail.com>> wrote:

Hi,

I am attempting to reconstruct Varian raw cone-beam data. The specific type of scan is a short scan, 200 degrees generating 501 projections. During reconstruction I get the message: ?you do not have enough data for proper Parker weighting (short scan) Delta is 9.951 degrees and should be more than half the beam angle I.e. 11.2359 degrees.?

Since I have not generated the geometry myself, rather, used a pre-set Varian protocol, I am unsure why I get this error.

How could I rectify this issue? Furthermore, what consequences are there to not applying a Parker weighting?

The geometry header is attached.

Your response is greatly appreciated,
Brani
_______________________________________________
Rtk-users mailing list
Rtk-users at public.kitware.com<mailto:Rtk-users at public.kitware.com>
https://public.kitware.com/mailman/listinfo/rtk-users<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7C%7Cdd34d79ef19149c0573e08d81c72539c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637290624638740143&sdata=rfrMAQf4nej0oPrbyDcIHHLvGGTVDUQaL1aqW7BnleE%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200630/758c616f/attachment.htm>