[Rtk-users] distance driven projector, a simplified approach ?

[Simon Rit]

Hi,
Indeed, I have published an article
<http://www.creatis.insa-lyon.fr/~srit/biblio/rit2012b.pdf> on this
projector describing my implementation, you could use it if you want,
there's even a piece of code in it although I'm pretty sure it's not the
best implementation. This implementation dealt with the case where the
rotation axis is parallel to the detector. As far as I can remember, the
original article of De Man and Basu is also quite clear.
I don't have time to go into the details of what you have proposed but,
from a glance, the first step seems useless.
Good luck in your implementation and don't hesitate to send it to us when
you have a working RTK implementation,
Simon

On Tue, Jul 14, 2015 at 9:01 AM, "Robert Calließ" <Robert.Calliess at gmx.de>
wrote:

> Hell RTK User,
> I think there is a mistake in the described approach.
> Point a) and f) meight be wrong. As far as I Understand, all Pixels
> that are covered by the projected voxel vertices are update
> with weight * voxel_value. Where weight is the overlaping area
> of the projected voxel vertices polygon on the detector plane and the
> underlying detector pixels.
>
> Any opinions before implementing it ?
>
> regards,
> Robert
>
> *Gesendet:* Montag, 13. Juli 2015 um 19:21 Uhr
> *Von:* "Robert Calließ" <robert.calliess at gmx.de>
> *An:* rtk-users at public.kitware.com
> *Betreff:* [Rtk-users] distance driven projector, a simplified approach ?
>
> Hello RTK users,
>
> I guess you know about the distance-driven projector. The main idea,
>
> as far as I understand, of this algorithm is to project voxel boundaries
> onto
>
> a common plane and the detector cell boundaries also on this common plane.
>
> Then the voxel’s contribution (weight) is the area of this overlapping. I
> read that the
>
> projection of the voxel and detector cell boundaries on a common plane can
> be
>
> simplified if the detector is a flat panel detector (guess this is what
> they called fixed
>
> detector geometry). Even if they  mean by fixed-detector geometry that the
> detector
>
> is not moving, we could use this simplification in a circular cone beam
> geometry. We can
>
> either rotate the detector and source around the object or the object can
> be rotated
>
> and the detector and source are fixed. I think Simon also wrote a paper
> about the
>
> distance driven projector (?).
>
>
>
>
>
> So my simplified approach would be (fixed detector and source position,
> object is rotating):
>
>
>
> a)      project voxel center on detector plane to determine the
> corresponding detector cell
>
> b)      project voxel vertices on detector plane (dertemine area of this
> projected polygon)
>
> c)       for each projected voxel vertex dertermine the neares detector
> cell
>
> o   i.e. vertex(20.3, 10.1) => DetectorCell(20, 10)
>
> d)      dertermine the area of the polygon described by the corresponding
> detector cells (c)
>
> e)      weight = area_from_b / area_from_d
>
> f)       add voxel_value * weight in detector cell determined in a
>
>
>
> For the back projector the steps would be always the same (a – e). Value
> to back project
>
> Is taken from the correction image at position determined in step a.
>
> For step b and d we could determine the minimum bounding rect and use this
> as the polygons areas.
>
> So the weights should always be between 0 and 1 ( Wether the MEB lies
> exactly on the detector cells
>
> or in between)
>
>
>
> I’m new to this topic. I want to hear your opinion. Is this a possible
> interpretation of the distance-driven
>
> projector, since the main idea is to calculate the overlapping of voxel
> boundaries with detector cell bounderies.
>
>
>
>
>
> Best Regards,
>
> Robert
>
>
>  _______________________________________________ Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>
> _______________________________________________
> 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/20150715/d5fe91cb/attachment.htm>