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

[Simon Rit]

Sorry, this link indeed
<http://www.creatis.insa-lyon.fr/~srit/biblio/rit2009c.pdf> 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
> <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://public.kitware.com/pipermail/rtk-users/attachments/20150715/8ce6f69a/attachment-0010.html>