[Rtk-users] Reconstruction Artifact

Wed Jun 3 11:20:58 EDT 2020

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>