<div dir="ltr">Hi Simon,<div><br></div><div>I have related questions. Maybe you or someone else has some empirical <span style="color:rgb(84,84,84)">experience or something like a rule of thumb:</span></div><div><span style="color:rgb(84,84,84)"><br></span></div><div><span style="color:rgb(84,84,84)">We talk about voxels and pixels of a virtual detector at isocenter, so no influence from geometrical magnification.</span></div><div><span style="color:rgb(84,84,84)">Then we can say that the best practice would be setting voxel size similar to the pixel size.</span></div><div><span style="color:rgb(84,84,84)"><br></span></div><div><span style="color:rgb(84,84,84)">My questions are:</span></div><div><span style="color:rgb(84,84,84)"><br></span></div><div><span style="color:rgb(84,84,84)">- If you are going to use a bigger voxel size as an </span><font color="#545454">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)?</font></div><div><font color="#545454"><br></font></div><div><font color="#545454">- 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?</font></div><div><font color="#545454"><br></font></div><div><font color="#545454">Best regards,</font></div><div><font color="#545454">Chao</font></div><div><font color="#545454"><br></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-01-16 18:42 GMT+01:00 Simon Rit <span dir="ltr"><<a href="mailto:simon.rit@creatis.insa-lyon.fr" target="_blank">simon.rit@creatis.insa-lyon.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi Elena,<br></div>Please post your questions to the mailing list, they can interest everyone in the community and you may get (better) answers before mine.<br>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:<br></div>- 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.<br></div>- cut high frequencies during ramp filtering using --hann and --hannY options<br></div>This is assuming larger voxels than pixels (there is no reason to have smaller voxels than pixels).<br></div><div>Let me know if this does not answer your question.</div><div>Simon<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 16, 2018 at 11:08 AM, Elena Padovani <span dir="ltr"><<a href="mailto:e.padovani@r4p.it" target="_blank">e.padovani@r4p.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dear Simon,<div>I am a new user of the Reconstruction toolkit. I've been testing some tools lately and i was able to reconstruct using FDKConeBeamReconstructionFilte<wbr>r. I am now trying to figure out something more about it and i was wondering if you could help me understand how rtkFDKConeBeamReconstructionFi<wbr>lter works. </div><div><br></div><div>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 rtkFDKConeBeamReconstructionFi<wbr>lter images of different resolutions. More precisely, i tested 2 cases: </div><div>- 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</div><div>- 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</div><div>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  rtkFDKConeBeamReconstructionFi<wbr>lter (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 ? </div><div><br></div><div>Thank you in advance for any hint,</div><div>Kind regards,</div><div><br></div><div>Elena </div><div><br></div></div>
</blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Rtk-users mailing list<br>
<a href="mailto:Rtk-users@public.kitware.com">Rtk-users@public.kitware.com</a><br>
<a href="https://public.kitware.com/mailman/listinfo/rtk-users" rel="noreferrer" target="_blank">https://public.kitware.com/<wbr>mailman/listinfo/rtk-users</a><br>
<br></blockquote></div><br></div>