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

Wed Jul 15 15:14:13 EDT 2015

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 <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/a73d939a/attachment-0010.html>