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

[Simon Rit]

"f is set to the fraction along v multiplied by the length of the
intersection between the ray and the segment"
So MapSeg handles one side of the rectangle intersections and f
contains the length of the other side and the step length, i.e., the
distance between the intersection points of the ray and two
consecutive planes in the main direction.
Simon

On Wed, Jul 15, 2015 at 9:14 PM, Robert Calließ <robert.calliess at gmx.de> wrote:
> Hello Simon,
>
> thank you for the articles. May I ask you what do you mean by
>
> „voxel correction factor“ in the code you provided in your article ?
>
> float f) // Voxel correction factor
>
>
>
> Thank you and best regards,
>
> Robert
>
>
>
> Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon
> Rit
> Gesendet: Mittwoch, 15. Juli 2015 14:22
> An: Robert Calließ
> Cc: rtk-users at public.kitware.com
> Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified
> approach ?
>
>
>
> Sorry, this link indeed with the MapSeg function. And yes, I was projecting
> it to the detector plane directly.
>
> Simon
>
>
>
> On Wed, Jul 15, 2015 at 2:07 PM, "Robert Calließ" <Robert.Calliess at gmx.de>
> wrote:
>
> Hello Simon,
>
> thank you for your answer. I guess you linked the wrong article. But I know
> what article you are talking about.
>
> It's the articel from 2009 with a piece of code (MapSeq).
>
>
>
>>> I don't have time to go into the details of what you have proposed but,
>>> from a glance, the first step seems useless.
>
> You're right. It is that all pixels that are related to the overlap
> projected voxel overlap have to taken into account. So
>
> detector pixels that are totally covered by the overlap are weight with "1"
> and if the overlap is between detector pixels
>
> the pixels are weighted. Do you have a copy of the original article from the
> De Man and Basu ?
>
>
>
> I have the opinion that it's not neccessary to project the detector pixel
> boundaries and voxel boundaries onto a common plane
>
> if we use a flat panel detector. Instead we could project the voxel
> boundaries onto the detector plane directly.
>
> Do you agree with that or did I miss something ?
>
>
>
> best regards,
>
> Robert
>
>
>
> Gesendet: Mittwoch, 15. Juli 2015 um 07:32 Uhr
> Von: "Simon Rit" <simon.rit at creatis.insa-lyon.fr>
> An: "Robert Calließ" <Robert.Calliess at gmx.de>
> Cc: "rtk-users at public.kitware.com" <rtk-users at public.kitware.com>
> Betreff: Re: [Rtk-users] distance driven projector, a simplified approach ?
>
> Hi,
>
> Indeed, I have published an article 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
>
>
>