[Rtk-users] Fwd: Re: Aw: Re: sart back projection, weighting steps
Cyril Mory
cyril.mory at creatis.insa-lyon.fr
Fri Feb 27 09:45:24 CET 2015
Hi Robert,
No problem, glad to help.
I think either I have'nt been clear enough, or you're getting confused,
though :) Let me try again:
In joseph back projection, for each PIXEL, you "draw a line" between the
source and the pixel's center, and see which voxels it crosses. Your
line crosses each slice of the volume at an intersection point. You
determine what the interpolation weights would be if you were to
interpolate at this intersection point. And these weights are indeed
between 0 and 1. But instead of interpolating, you "splat", that means
you update the four nearest voxels by adding (projection's pixel value *
interpolationWeight) to each. And you move to the next slice. Once
you've considered all rays, you're done. Nothing in this process
guarantees that a voxel will receive any contribution. In fact, some
receive none, and some too many. The backprojected volume you obtain is
"biased". You could think of it as the product of what you really want
(the projection's pixel values smeared out along the lines of rays) with
a "sampling density map" (the cumulated splat weights each voxel has
been updated with).
If you back project a projection of ones, then your resulting volume is
exactly this sampling density map, and you can divide by it to obtain
what you really want.
In voxel based back projection, for each voxel, you "draw a line"
between the source and the voxel's center, see where it hits the 2D
projection, and add the value of that pixel (or interpolated at this
position between pixels) into the voxel. And that's it for this voxel,
so each voxel gets updated once and only once. And if the projection
contains only ones, then your volume gets filled with ones. Dividing by
one isn't going to change anything, so you just don't do it.
I hope it is clearer.
Cyril
On 02/26/2015 02:10 PM, "Robert Calließ" wrote:
> Hello Cyril,
> thank you for the fast reply and thank you for the support.
> Indeed I have some more questions. For the normalization step
> you on the one hand side create a projection image filled with "1"
> and on the other hand side you create an empty (zero) volume and
> then back project the image, ok.
> >>How many contributions a voxel receives is determined by the
> sampling of the projections
> Yes, I have the same problems with a voxel-based back projector. But
> don't you have
> this problem also with joseph's method when you use it for the back
> projection of the "1" projection
> image ? It's not clear to me how this kind of back projection actually
> works (or is calculated).
> And if the projection image consists of pixels with value "1" then we
> actually don't need it or do we ?
> So far I understand, no matter if we perform the forward or back
> projtion, the joseph projector calculates
> the weightings of the four voxels that are "around" the current plane
> intersection point. And this
> weights are always between 0 and 1.
> Or do I totally misunderstand the concept of this backprojection.
> I hope I did not confused you.
> best regards,
> Robert
> *Gesendet:* Dienstag, 24. Februar 2015 um 10:55 Uhr
> *Von:* "Cyril Mory" <cyril.mory at creatis.insa-lyon.fr>
> *An:* "Robert Calließ" <Robert.Calliess at gmx.de>, rtk-users at openrtk.org
> *Betreff:* Re: [Rtk-users] sart back projection, weighting steps
> Hi Robert,
>
> I'm glad to know that most of the explanation text is understandable :)
> You might want to check this filter:
> http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html
> You can use the command line application "rtkbackprojections" with
> argument --bp to compare "Joseph" and "NormalizedJoseph".
>
> When performing a back projection with non-normalized Joseph, the
> projection values are "splat" (splat is the adjoint operator of
> interpolation) between the four nearest voxels in each volume plane
> the ray intersects. Nothing guarantees that every voxel will receive a
> contribution during this process. How many contributions a voxel
> receives is determined by the sampling of the projections, which can
> be much looser or much denser (locally and globally) than what would
> be required. Dividing by the back projection of an image of ones
> mitigates this effect. In theory, as long as the forward and back
> projection operators are the adjoint of one another, it should not be
> a problem for SART. In practice, it does make a difference.
>
> I hope it helps. Please let me know if it is still unclear;
>
> Cyril
> On 02/24/2015 09:56 AM, "Robert Calließ" wrote:
>
> Hello,
> in the file rtkSARTConeBeamReconstructionFilter.h there is briefly
> written how the
> forward and back projection is performed. For the forward
> projection, every pixel is
> divided by the intersection length of the ray with the volume.
> That is clear to me.
> For the back projection applies the following text:
> "each voxel of the back projection must be divided by the value it
> would take if
> a projection filled with ones was being reprojected. This
> weighting step is not
> performed when using a voxel-based back projection, as the
> weights are all equal to one
> in this case. When using a ray-based backprojector, typically
> Joseph,it must be performed."
> That means a temporary projection image is created where all
> pixels have the value "1". So far I understand,
> if we use a voxel based back projector we do not need to apply
> this weighting step because the ray from source to voxel center
> somewhere hits the detector plane and usually there we interpolate
> the pixel value. But all of them are "1" so it's obsolete to
> interpolate inbetween.
> But if we use for instance the joseph back projector don't we
> calculate the four weightings at the current volume planes the
> ray intersects with ? So we already have weightings that range
> from 0 to 1. I'm a little bit confused about the projection image
> filled with "1". So how a this back projection of "1" actually
> happens ?
> I hope someone can help me with that. Thank you.
> best regards,
> Robert
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.creatis.insa-lyon.fr/pipermail/rtk-users/attachments/20150227/9ed31a84/attachment.htm>
More information about the Rtk-users
mailing list