[Rtk-users] rtk user : FDKConeBeamReconstructionFilter

[Chao Wu]

Hi Simon,

I have related questions. Maybe you or someone else has some empirical
experience
or something like a rule of thumb:

We talk about voxels and pixels of a virtual detector at isocenter, so no
influence from geometrical magnification.
Then we can say that the best practice would be setting voxel size similar
to the pixel size.

My questions are:

- If you are going to use a bigger voxel size as an arbitrary times of
pixel size such as 1.5x, 2.7x or 6.2x, how do you determine whether you
should do a binning of the detector images and which binning factor is
optimal? Should you always make the binned pixel size just bigger or
smaller than the voxel size (so for the example before you use 2x2, 3x3 and
7x7 binning, or 1x1, 2x2 and 6x6, respectively)?

- Instead of detector binning, another solution may be using an upsampled
voxel grid for reconstruction and then do the binning on the 3D volume. For
example you may reconstruct a volume in a 2x2x2 finner grid and then
perform a 2x2x2 binning to the output, if the voxel size is about 2 times
of the pixel size. Despite that the amount of computation is 8 times
higher, is there any obvious benefit (resolution, contrast, S/N etc.) under
this scheme?

Best regards,
Chao


2018-01-16 18:42 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:

> Hi Elena,
> Please post your questions to the mailing list, they can interest everyone
> in the community and you may get (better) answers before mine.
> FDK is very simple: it takes the projections, weight them with the cosine
> + angular gaps, apply the ramp filter with a kernel adapted to the number
> of pixels and backproject. The backprojection is voxel based so it does a
> linear interpolation between pixels. There is never any attemps to "adjust"
> one of these steps according to the pixel and the voxel spacings so the
> user must manage it. There are different solutions to do it:
> - do a binning of the projections (average 4 or 16 pixels as you maybe
> did?). In the command line tool, you can do it with the --binning option.
> - cut high frequencies during ramp filtering using --hann and --hannY
> options
> This is assuming larger voxels than pixels (there is no reason to have
> smaller voxels than pixels).
> Let me know if this does not answer your question.
> Simon
>
> On Tue, Jan 16, 2018 at 11:08 AM, Elena Padovani <e.padovani at r4p.it>
> wrote:
>
>> Dear Simon,
>> I am a new user of the Reconstruction toolkit. I've been testing some
>> tools lately and i was able to reconstruct using
>> FDKConeBeamReconstructionFilter. I am now trying to figure out something
>> more about it and i was wondering if you could help me understand how
>> rtkFDKConeBeamReconstructionFilter works.
>>
>> I am now reading raw images and importing them into the pipeline through
>> the importFilter and then a tilerFilter is used to create the stack of
>> projections. i was testing if the reconstructed volume would change using
>> as input to rtkFDKConeBeamReconstructionFilter images of different
>> resolutions. More precisely, i tested 2 cases:
>> - 1) the input images are 1536x1536 with spacing 0.2,0.2 and the
>> ConstantImageSource volume is 384,384,384 with spacing 0.8,0.8,0.8
>> - 2) the input images are scaled-down to 384,384 with spacing 0.8,0.8 and
>> the constantImageSource is again 384,384,384 with spacing 0.8,0.8,0.8
>> The reconstructed volumes appear to be different. Indeed, the range of
>> values is quite different and in the first case the image does not seem
>> totally right (even tough the volume is reconstructed). Can you explain me
>> how  rtkFDKConeBeamReconstructionFilter (or maybe other filters used
>> inside, such as ExtractImageFIlter) manages different resolution in input
>> and output ? Does it average the pixel value over the bigger voxel/pixel
>> area ?
>>
>> Thank you in advance for any hint,
>> Kind regards,
>>
>> Elena
>>
>>
>
> _______________________________________________
> 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/20180117/9b8ad97a/attachment.html>