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

Fri Jul 17 02:22:16 EDT 2015

Please keep on using the mailing list, I don't see a good reason to
keep this conversation private.
I won't have time to go back into these details. From a quick look, I
think this is correct although I would have simply said that D is the
center of the detector pixel.
Simon

On Thu, Jul 16, 2015 at 10:24 PM, Robert Calließ <robert.calliess at gmx.de> wrote:
> Hello,
> Sorry that I have to ask again. But I want to clear this before I start.
> I want to ask about the cosine weight DeMan mentioned in his article.
> He wrote:
>
> "
>  (1) The intersection length of the line of interest with the image slab S, the latter being
> defined as the slab parallel to the xz plane and containing voxel V. This intersection length
> is given by t/(cos α cos γ ), where t is the isotropic voxel size, and α and γ are the in- and
> out-of-plane angles of the line of interest with the y-axis.
> "
>
> So what he actually does, is that he calculates the intersection length of the slab s (that contains the voxel) with
> a ray going from xray source to the middle of two adjacent detector cell boundaries. Let's refare to Figure 5.
> So the length to be considered is calculated as the intersection length of slab S with the ray going from
> the source ( the black dot in figure 5) to the mid-point of D, that means the center of the two projected adjacent
> detector pixel boundaries.
>
>
> Sorry for asking again but I want it to make it clear to me.
>
> Best regards,
> Robert
>
>
> -----Ursprüngliche Nachricht-----
> Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon Rit
> Gesendet: Mittwoch, 15. Juli 2015 21:45
> An: Robert Calließ
> Cc: rtk-users at public.kitware.com
> Betreff: Re: Re: [Rtk-users] distance driven projector, a simplified approach ?
>
> "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
>>
>>
>>
>