[Rtk-users] sart back projection, weighting steps
Cyril Mory
cyril.mory at creatis.insa-lyon.fr
Tue Mar 3 09:13:51 EST 2015
Hi Robert,
Please use the mailing list for your questions, as the conversations
might be interesting to other users.
"So I think we will also have the same problem that we miss some voxels
depending on the projection image resolution."
-> Yes, that problem remains. Some voxels may not be hit at all, and for
them a specific processing has to be applied (median filtering, for
example). I do not think we do this in RTK, I think we just leave these
voxels set to zero. For all the others, which do get hit at least by one
ray, the division helps a lot.
->The procedure you describe is exact
Please keep asking if things remain unclear :)
Cyril
On 03/03/2015 03:04 PM, "Robert Calließ" wrote:
> Hello Cyril,
> I'm sorry that I need to ask for your help again, but I want to
> understand.
> >> 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
> Just to understand, if we back project a projection image of "1" we
> also "draw a line" and update the voxels (just like in josephs
> projector) but now we do not back project a projection value but a "1".
> And then we devide the current volume (result from joseph back
> projection) by this volume (result from back projection of "1").
> So I think we will also have the same problem that we miss some voxels
> depending on the projection image resolution.
> I tried to follow the code and the normalized backprojector uses the
> JosephProjector but works an
> a seperate volume and on an image filled with "1". And the steps would
> be...
> - forward projection
> - back projection
> - back projection of image filled with "1" in a seperate volume
> - divide current volume by this seperate volume
> is this right ?
> best regards,
> Robert
> *Gesendet:* Freitag, 27. Februar 2015 um 09:44 Uhr
> *Von:* "Cyril Mory" <cyril.mory at creatis.insa-lyon.fr>
> *An:* "Robert Calließ" <Robert.Calliess at gmx.de>
> *Betreff:* Re: Aw: Re: [Rtk-users] sart back projection, weighting steps
> 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://public.kitware.com/pipermail/rtk-users/attachments/20150303/fc042065/attachment-0008.html>
More information about the Rtk-users
mailing list