[Rtk-users] RTK

[Simon Rit]

Hi,
Thank you for your interest in RTK. Please use the mailing list for
questions that are of interest to anyone using RTK.
There are many ways to model the direct problem (forward projection).
Without going into too many details (available in the publications of each
method) :
- "As far as I understand the goal of this approach is to calculate the
intersection length of a ray through a voxel, right ?" False. Joseph's
method samples the ray with one pixel per slice in the main direction but
it does not compute the intersection of the ray with each voxel. Siddon's
method <http://www.ncbi.nlm.nih.gov/pubmed/4000088> does that. In fig 2 of [Xu
and Mueller, 2006]
<http://www3.cs.stonybrook.edu/~mueller/papers/ISBI_06_quality_2.pdf>,
Joseph is referred to "slice interpolated" and Siddon to
"box-line-integrated".
- "I can calculate the intersection length of the ray within a voxel by a
simple substraction, this runs very fast." This sounds very interesting,
don't hesitate to share the code and/or the publication! BTW, what is DDA?
- Small voxels / pixels,  "Did you find a way to handle this ? " We don't
handle this in RTK except if you consider that spatial regularisation
(e.g., total variation) will overcome this problem in a way. But generally
we use matching resolution between pixels and voxels so the problem is
minimal. For the backprojection, we typically used voxel-based
backprojection using the center of the voxel which is faster than what you
(seem to) use. I think that if these things are a problem for you, there is
a nice solution called distance driven (back-)projection
<http://stacks.iop.org/PMB/49/2463> (by De Man and Basu). I think it will
do exactly what you want. I haven't implemented it in RTK (yet).
Thanks for the last trick, I am aware of it (Riddell published it calling
this "Rectification" <http://dx.doi.org/10.1109/TMI.2006.876169>), I'm not
sure that would change the computation time by a large factor but I should
check. I think you then need an additional interpolation no to resample the
"moved" object, no?
I hope this helps. Let me know if sg is not clear in my answer!
Cheers,
Simon

<http://in2p3.fr/home/q/quinones/simulations/pct_spiral/run.uSTG>

On Thu, Jan 29, 2015 at 12:31 PM, Robert Calließ <robert.calliess at gmx.de>
wrote:

> Dear Mr. Simon Rit,
>
> I had a look at the very interesting project RTK that you’re currently
>
> working on  and I’m also interested in methods you use for forward and
>
> back projection in the fields of S-ART. I saw that you use Joseph’s method
>
> for the projectors. As far as I understand the goal of this approach is to
> calculate
>
> the intersection length of a ray through a voxel, right ? I’m working on a
> S-ART
>
> reconstruction and use a modified 3D-DDA where I can calculate the
> intersection
>
> length of the ray within a voxel by a simple substraction, this runs very
> fast.
>
> So I think both approaches,  Joseph’s and mine, should bring the same
> results as
>
> they calculate the intersection  length of a ray in a voxel.
>
>
>
> However I encountered a problem with these raybased approaches. Because we
> use conebeam
>
> geometry there will be divergent rays. That means, the higher the volume
> resolution gets the more
>
> voxels will be missed during forward projection because some of them are
> between two adjacent ray.
>
> Also if the volume resolution gets higher the voxels get smaller and the
> intersection lengths (our weights)
>
> will get very small. I think this will also be a problem with Joseph’s
> method.
>
> Did you find a way to handle this ?
>
>
>
> For the backprojection there is  the same problem. I use a voxelbased
> backprojector where I project all 8 vertices
>
> of a voxel on the detector plane, then calculate the minimum bounding rect
> of the 8 intersection points in the detector plane
>
> and finally I send all rays through the voxel, that are within this
> bounding rect. The problem here is, as the volume resolution
>
> gets higher the voxels get smaller and the 8 vertices that are projected
> on the detector plane will produce a very small bounding rect
>
> that finally will contain only 1 or 2 rays.
>
>
>
> The only „workaround“ I found is, to virtually increase the number of rays
> for instance by upscaling the projection images. But this
>
> will increase computation time.
>
>
>
>
>
> A little performance trick (if you are not already used it) when using FDK
> for
>
> a circular conebeam geometry, you can calculate a correction
> transformation
>
> to align the detector to the z-plane. Of course this has to be applied to
> the object and
>
> source as well. So the whole scene-geometry is a little bit „moved“ so
> that the detector aligns
>
> with the z-plane. This will speed up reconstruction because we can now use
> the
>
> intercept theorem to determine where the voxel will hit the detector.
>
>
>
>
>
> Best regards,
>
> Robert Calließ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20150129/cac01a3b/attachment-0008.html>