From simon.rit at creatis.insa-lyon.fr Fri Oct 12 05:19:16 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 12 Oct 2012 11:19:16 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: Message-ID: Hi Marta, Thanks for the feedback. Yes, we would be interested in knowing what are the problems with getopt.h. Could you send us more information (logs, Windows version, compiler, ...)? Regarding Cuda, this is a bit of a weird problem. I have tried to merge the latest version of Plastimatch cmake files with rtk. Could you update your RTK repository and give it another try? A simple Shepp Logan reconstruction example is available here http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are available here http://wiki.openrtk.org/index.php/RTK/Users. Good luck, Simon On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni wrote: > Dear Simon and David, > was a pleasure to meet you at MICCAI. As I mentioned, we are looking into > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a look > at IRTK. > > Now, problem is that we were not able to compile it neither on windows nor > linux (arch distrib). > > For windows, main issues were related to the windows version of getopt which > generate syntax error (Marco can provide you a log file, if you'd like). > > For linux, I had cuda problem. In particular, although correctly configured, > I am stuck with this: > [ 7%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, > surface, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:100: error: there are no arguments to > '__surf1Dreadc1' that depend on a template parameter, so a declaration of > '__surf1Dreadc1' must be available > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', G++ > will accept your code, but allowing the use of an undeclared name is > deprecated) > /usr/include/surface_functions.h:101: error: there are no arguments to > '__surf1Dreads1' that depend on a template parameter, so a declaration of > '__surf1Dreads1' must be available > /usr/include/surface_functions.h:102: error: there are no arguments to > '__surf1Dreadu1' that depend on a template parameter, so a declaration of > '__surf1Dreadu1' must be available > /usr/include/surface_functions.h:103: error: there are no arguments to > '__surf1Dreadu2' that depend on a template parameter, so a declaration of > '__surf1Dreadu2' must be available > /usr/include/surface_functions.h:104: error: there are no arguments to > '__surf1Dreadu4' that depend on a template parameter, so a declaration of > '__surf1Dreadu4' must be available > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, > surface, int, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:460: error: there are no arguments to > '__surf2Dreadc1' that depend on a template parameter, so a declaration of > '__surf2Dreadc1' must be available > /usr/include/surface_functions.h:461: error: there are no arguments to > '__surf2Dreads1' that depend on a template parameter, so a declaration of > '__surf2Dreads1' must be available > /usr/include/surface_functions.h:462: error: there are no arguments to > '__surf2Dreadu1' that depend on a template parameter, so a declaration of > '__surf2Dreadu1' must be available > /usr/include/surface_functions.h:463: error: there are no arguments to > '__surf2Dreadu2' that depend on a template parameter, so a declaration of > '__surf2Dreadu2' must be available > /usr/include/surface_functions.h:464: error: there are no arguments to > '__surf2Dreadu4' that depend on a template parameter, so a declaration of > '__surf2Dreadu4' must be available > CMake Error at > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 (message): > Error generating file > > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > > make[2]: *** > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] > Error 1 > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 > make: *** [all] Error 2 > > I remember having the same issue in plastimatch some time ago (it is due to > cuda version) and James added some -fpermissive to fix the issue. > > But anyhow, can you please guide us through a compilation to make it work > and test it on the new projections? > > thanks a lot > Best Regards, > Marta Peroni > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Mon Oct 15 13:53:13 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Mon, 15 Oct 2012 19:53:13 +0200 Subject: [Rtk-users] FirstReconstruction example Message-ID: <20121015175313.49610@gmx.net> Hello, I have questions concerning the FirstReconstruction example: Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? Sorry for the detailed questions, I just would like to understand how RTK is working. Thanks a lot! LF From simon.rit at creatis.insa-lyon.fr Mon Oct 15 16:17:59 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 15 Oct 2012 22:17:59 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121015175313.49610@gmx.net> References: <20121015175313.49610@gmx.net> Message-ID: Hi Lars, The geometry is described in the document geometry.tex, I have added links at the end of the user's wiki page http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with coordinates 0,0,0 of your volume is the isocenter, the point with coordinate 0,0 in projection images is the intersection of your flat panel with the line going through the x-ray source and the isocenter. The image origin is defined by ITK as the center of the pixel with index 0 in memory (first pixel in memory). I hope this helps, Simon On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars wrote: > Hello, > > I have questions concerning the FirstReconstruction example: > Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). > > How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. > > Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? > > Sorry for the detailed questions, I just would like to understand how RTK is working. > > Thanks a lot! > > LF > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:03:43 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:03:43 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> Message-ID: <20121016080343.49570@gmx.net> Hi Simon, thanks for your reply! I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. Basically, the first sentence in section 6 of the doc "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." along with another sentence in this section "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... Thanks so far! LF -------- Original-Nachricht -------- > Datum: Mon, 15 Oct 2012 22:17:59 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > Hi Lars, > The geometry is described in the document geometry.tex, I have added > links at the end of the user's wiki page > http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > coordinates 0,0,0 of your volume is the isocenter, the point with > coordinate 0,0 in projection images is the intersection of your flat > panel with the line going through the x-ray source and the isocenter. > The image origin is defined by ITK as the center of the pixel with > index 0 in memory (first pixel in memory). > I hope this helps, > Simon > > On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > wrote: > > Hello, > > > > I have questions concerning the FirstReconstruction example: > > Using the rtk::RayEllipsoidIntersectionImageFilter and > rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are > packed in the form of an image stack. The geometry of the projections is > described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the > images' metrics are described by the image stack itself (spacing, size and > ORIGIN). > > > > How should I interpret the origin? As far as I could find out by minor > modifications of the example, the origin of the projeciton image stack plays > a role (if I change it to 0,0,0, and retain constantImageSource2's origin > at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does > the origin of the image stack matter? Isn't the origin of a single > projection fully defined by the corresponding entry in the > rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the > offset from the detector central axis crossing point)? Am I right that the > effective origin of a single projection image emerges basically from the > detector (x/y of origin of image stack) and from consecutive application of > the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, > e.g. caused by gravity, wouldn't be simulatable. > > > > Morever, which point exactly does the image origin (x/y components) of > the projection stack describe? Is it the outer corner of the projection or > the center of the first voxel (as in DICOM). The size of a projection in the > example is 256.0x256.0 units. However, the stack's origin is at > -127.0,-127.0. If the origin should refer to the center of the first projection > pixel, it should be essentially -127.5,-127.5, right? > > > > Sorry for the detailed questions, I just would like to understand how > RTK is working. > > > > Thanks a lot! > > > > LF > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Tue Oct 16 04:23:17 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 16 Oct 2012 10:23:17 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121016080343.49570@gmx.net> References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: I agree, geometry is irritating! I'm sorry my comments were part of this irritation... It seemed obvious to me that the origin and the direction in itk::Image has to be accounted for but I'll add a comment in the header to make it clearer. Bear in mind that this on-going work so feel free to suggest improvements and clarifications. Regarding geometry conversion, we had done a work with my colleagues from the Universit? Catholique de Louvain to convert their geometry parameterization to RTK parameterization using Maxima. That allowed us to spare some hours spent on deriving the correct formulas... Would you be interested in the script file? Simon On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars wrote: > Hi Simon, > > thanks for your reply! > > I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > Basically, the first sentence in section 6 of the doc > "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." > along with another sentence in this section > "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." > irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. > > My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > Thanks so far! > > LF > > -------- Original-Nachricht -------- >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 >> Von: Simon Rit >> An: Lars Friedrich Lars >> CC: rtk-users at openrtk.org >> Betreff: Re: [Rtk-users] FirstReconstruction example > >> Hi Lars, >> The geometry is described in the document geometry.tex, I have added >> links at the end of the user's wiki page >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with >> coordinates 0,0,0 of your volume is the isocenter, the point with >> coordinate 0,0 in projection images is the intersection of your flat >> panel with the line going through the x-ray source and the isocenter. >> The image origin is defined by ITK as the center of the pixel with >> index 0 in memory (first pixel in memory). >> I hope this helps, >> Simon >> >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars >> wrote: >> > Hello, >> > >> > I have questions concerning the FirstReconstruction example: >> > Using the rtk::RayEllipsoidIntersectionImageFilter and >> rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are >> packed in the form of an image stack. The geometry of the projections is >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the >> images' metrics are described by the image stack itself (spacing, size and >> ORIGIN). >> > >> > How should I interpret the origin? As far as I could find out by minor >> modifications of the example, the origin of the projeciton image stack plays >> a role (if I change it to 0,0,0, and retain constantImageSource2's origin >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does >> the origin of the image stack matter? Isn't the origin of a single >> projection fully defined by the corresponding entry in the >> rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the >> offset from the detector central axis crossing point)? Am I right that the >> effective origin of a single projection image emerges basically from the >> detector (x/y of origin of image stack) and from consecutive application of >> the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, >> e.g. caused by gravity, wouldn't be simulatable. >> > >> > Morever, which point exactly does the image origin (x/y components) of >> the projection stack describe? Is it the outer corner of the projection or >> the center of the first voxel (as in DICOM). The size of a projection in the >> example is 256.0x256.0 units. However, the stack's origin is at >> -127.0,-127.0. If the origin should refer to the center of the first projection >> pixel, it should be essentially -127.5,-127.5, right? >> > >> > Sorry for the detailed questions, I just would like to understand how >> RTK is working. >> > >> > Thanks a lot! >> > >> > LF >> > _______________________________________________ >> > Rtk-users mailing list >> > Rtk-users at openrtk.org >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:55:04 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:55:04 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: <20121016085504.78840@gmx.net> Hi, thanks!! Yep, I would be very interested in the script since I would like to try first whether my geometry is generally a no go for the FDK-based approaches in RTK (which I cannot exclude at the moment), before shaping the code and implementing C++-based converters. Lars -------- Original-Nachricht -------- > Datum: Tue, 16 Oct 2012 10:23:17 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > I agree, geometry is irritating! I'm sorry my comments were part of > this irritation... It seemed obvious to me that the origin and the > direction in itk::Image has to be accounted for but I'll add a comment > in the header to make it clearer. Bear in mind that this on-going work > so feel free to suggest improvements and clarifications. > > Regarding geometry conversion, we had done a work with my colleagues > from the Universit? Catholique de Louvain to convert their geometry > parameterization to RTK parameterization using Maxima. That allowed us > to spare some hours spent on deriving the correct formulas... Would > you be interested in the script file? > > Simon > > On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars > wrote: > > Hi Simon, > > > > thanks for your reply! > > > > I read the geometry-doc and played around with > rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > > Basically, the first sentence in section 6 of the doc > > "This class is meant to define a set of 2D projection images, acquired > with a at panel along a circular trajectory, around a 3D tomography." > > along with another sentence in this section > > "9 parameters are used per projection to define the position of the > source and the detector relatively to the fixed coordinate system." > > irritated me a bit. I thought that the 3DCircGeom's task is, in addition > to defining the source position, to define the position and orientation of > the 2D projection images, and the 3DCircGeom is defined in the IEC WCS > (relates to it). I did not expect essential projection image metrics except > dimension (pixel size) and spacing (because image size in physical units is > not part of 3DCircGeom) having any influence on the position and orientation > of it, since this is already defined with the 3DCircGeom object. > > > > My issue at the moment is simply that I have source position, detector > position and detector row/column vectors defined in IEC WCS for each > projection, and have to convert it somehow into your projection geometry format + > (and that's news for me) adjust the image origin of the projection stack. > Unfortunately, my geometry is not really a standard circular one (as in case > of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > > > Thanks so far! > > > > LF > > > > -------- Original-Nachricht -------- > >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 > >> Von: Simon Rit > >> An: Lars Friedrich Lars > >> CC: rtk-users at openrtk.org > >> Betreff: Re: [Rtk-users] FirstReconstruction example > > > >> Hi Lars, > >> The geometry is described in the document geometry.tex, I have added > >> links at the end of the user's wiki page > >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > >> coordinates 0,0,0 of your volume is the isocenter, the point with > >> coordinate 0,0 in projection images is the intersection of your flat > >> panel with the line going through the x-ray source and the isocenter. > >> The image origin is defined by ITK as the center of the pixel with > >> index 0 in memory (first pixel in memory). > >> I hope this helps, > >> Simon > >> > >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > >> wrote: > >> > Hello, > >> > > >> > I have questions concerning the FirstReconstruction example: > >> > Using the rtk::RayEllipsoidIntersectionImageFilter and > >> rtk::ConstantImageSource artificial projections of an ellipsoid are > generated which are > >> packed in the form of an image stack. The geometry of the projections > is > >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, > the > >> images' metrics are described by the image stack itself (spacing, size > and > >> ORIGIN). > >> > > >> > How should I interpret the origin? As far as I could find out by > minor > >> modifications of the example, the origin of the projeciton image stack > plays > >> a role (if I change it to 0,0,0, and retain constantImageSource2's > origin > >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why > does > >> the origin of the image stack matter? Isn't the origin of a single > >> projection fully defined by the corresponding entry in the > >> rtk::ThreeDCircularProjectionGeometry object (I thought the > projOffsetX,projOffsetY args define the > >> offset from the detector central axis crossing point)? Am I right that > the > >> effective origin of a single projection image emerges basically from > the > >> detector (x/y of origin of image stack) and from consecutive > application of > >> the projOffsetX,projOffsetY args? Otherwise, deviating detector > positions, > >> e.g. caused by gravity, wouldn't be simulatable. > >> > > >> > Morever, which point exactly does the image origin (x/y components) > of > >> the projection stack describe? Is it the outer corner of the projection > or > >> the center of the first voxel (as in DICOM). The size of a projection > in the > >> example is 256.0x256.0 units. However, the stack's origin is at > >> -127.0,-127.0. If the origin should refer to the center of the first > projection > >> pixel, it should be essentially -127.5,-127.5, right? > >> > > >> > Sorry for the detailed questions, I just would like to understand how > >> RTK is working. > >> > > >> > Thanks a lot! > >> > > >> > LF > >> > _______________________________________________ > >> > Rtk-users mailing list > >> > Rtk-users at openrtk.org > >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Wed Oct 17 08:56:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 14:56:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> Message-ID: Hi Marta, Yes still ITK 3.20, see instructions here: http://wiki.openrtk.org/index.php/RTK/Users. I fixed the linux error, a commit of 2 days ago was causing it. I don't, however, understand some of your windows errors. It seems that it does not understand the ggo files with enum variables although this has been working on Windows and Linux so far. A potential explanation would be that you have installed an old version of gengetopt on your computer? Maybe you can send me your CMakeCache.txt to help me fixing it? You mentioned a problem with getopt.h in your first email but I did not see it in the log. There is also a linking problem with Cuda that your CMakeCache.txt might help me to understand. Thanks, Simon On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni wrote: > Hi! > sorry that it took soo long to answer. > For windows: > compiler is Visual Studio Express 2008 and we are using Windows 7 (see > log_windows attached) > > For Linux: > I downloaded the latest version from here: https://github.com/SimonRit/RTK > and tried to compile against ITK 3.20 (should I try with ITK4?) > Got over the usual nvcc error, but still could not compile unfortunately > (see log_linux attached) > > thanks a lot > Marta > > On 12 October 2012 11:19, Simon Rit wrote: >> >> Hi Marta, >> Thanks for the feedback. Yes, we would be interested in knowing what >> are the problems with getopt.h. Could you send us more information >> (logs, Windows version, compiler, ...)? >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> merge the latest version of Plastimatch cmake files with rtk. Could >> you update your RTK repository and give it another try? >> A simple Shepp Logan reconstruction example is available here >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> Good luck, >> Simon >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> wrote: >> > Dear Simon and David, >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> > into >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a >> > look >> > at IRTK. >> > >> > Now, problem is that we were not able to compile it neither on windows >> > nor >> > linux (arch distrib). >> > >> > For windows, main issues were related to the windows version of getopt >> > which >> > generate syntax error (Marco can provide you a log file, if you'd like). >> > >> > For linux, I had cuda problem. In particular, although correctly >> > configured, >> > I am stuck with this: >> > [ 7%] Building NVCC (Device) object >> > >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> > surface, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:100: error: there are no arguments to >> > '__surf1Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadc1' must be available >> > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', >> > G++ >> > will accept your code, but allowing the use of an undeclared name is >> > deprecated) >> > /usr/include/surface_functions.h:101: error: there are no arguments to >> > '__surf1Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreads1' must be available >> > /usr/include/surface_functions.h:102: error: there are no arguments to >> > '__surf1Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu1' must be available >> > /usr/include/surface_functions.h:103: error: there are no arguments to >> > '__surf1Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu2' must be available >> > /usr/include/surface_functions.h:104: error: there are no arguments to >> > '__surf1Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu4' must be available >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:460: error: there are no arguments to >> > '__surf2Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadc1' must be available >> > /usr/include/surface_functions.h:461: error: there are no arguments to >> > '__surf2Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreads1' must be available >> > /usr/include/surface_functions.h:462: error: there are no arguments to >> > '__surf2Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu1' must be available >> > /usr/include/surface_functions.h:463: error: there are no arguments to >> > '__surf2Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu2' must be available >> > /usr/include/surface_functions.h:464: error: there are no arguments to >> > '__surf2Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu4' must be available >> > CMake Error at >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> > (message): >> > Error generating file >> > >> > >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > >> > >> > make[2]: *** >> > >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> > Error 1 >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> > make: *** [all] Error 2 >> > >> > I remember having the same issue in plastimatch some time ago (it is due >> > to >> > cuda version) and James added some -fpermissive to fix the issue. >> > >> > But anyhow, can you please guide us through a compilation to make it >> > work >> > and test it on the new projections? >> > >> > thanks a lot >> > Best Regards, >> > Marta Peroni >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:18:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:18:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> Message-ID: The other linux compile errors have been fixed, they were caused by the recent gcc that you seem to be using. Sorry for this hassle, we do not have tested all possible combinations of gccs yet... >From your CMakeCache.txt, it seems that you have gengetopt installed here: C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe A way to solve this would be to remove it from the Windows path so that cmake doesn't use it because gengetopt code has been copied in RTK and will be compiled automatically if it's not in the path. In the future, we should check on gengetopt version and compile it automatically if the system version is too old. I have opened a bug: http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 This should fix the gengetopt enum errors but I still have to figure out the linking problem if it's still here. It's strange that it does not show up on my windows box... Simon On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni wrote: > Hi Simon! > that fixed the error thanks :) But I am afraid I have another one.... > (log_linux attached hed). > I also send you the CMakeCache.txt, but I am afraid your intuition might be > right... > For windows, where do you get the gengeopt? just to make sure we are > up-to-date > thanks a lot > Marta > > > On 17 October 2012 14:56, Simon Rit wrote: >> >> Hi Marta, >> >> Yes still ITK 3.20, see instructions here: >> http://wiki.openrtk.org/index.php/RTK/Users. >> I fixed the linux error, a commit of 2 days ago was causing it. >> I don't, however, understand some of your windows errors. It seems >> that it does not understand the ggo files with enum variables although >> this has been working on Windows and Linux so far. A potential >> explanation would be that you have installed an old version of >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> to help me fixing it? You mentioned a problem with getopt.h in your >> first email but I did not see it in the log. >> There is also a linking problem with Cuda that your CMakeCache.txt >> might help me to understand. >> Thanks, >> Simon >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> wrote: >> > Hi! >> > sorry that it took soo long to answer. >> > For windows: >> > compiler is Visual Studio Express 2008 and we are using Windows 7 (see >> > log_windows attached) >> > >> > For Linux: >> > I downloaded the latest version from here: >> > https://github.com/SimonRit/RTK >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> > Got over the usual nvcc error, but still could not compile unfortunately >> > (see log_linux attached) >> > >> > thanks a lot >> > Marta >> > >> > On 12 October 2012 11:19, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> are the problems with getopt.h. Could you send us more information >> >> (logs, Windows version, compiler, ...)? >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> you update your RTK repository and give it another try? >> >> A simple Shepp Logan reconstruction example is available here >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> Good luck, >> >> Simon >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> wrote: >> >> > Dear Simon and David, >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> >> > into >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had >> >> > a >> >> > look >> >> > at IRTK. >> >> > >> >> > Now, problem is that we were not able to compile it neither on >> >> > windows >> >> > nor >> >> > linux (arch distrib). >> >> > >> >> > For windows, main issues were related to the windows version of >> >> > getopt >> >> > which >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> > like). >> >> > >> >> > For linux, I had cuda problem. In particular, although correctly >> >> > configured, >> >> > I am stuck with this: >> >> > [ 7%] Building NVCC (Device) object >> >> > >> >> > >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:100: error: there are no arguments >> >> > to >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadc1' must be available >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> > '-fpermissive', >> >> > G++ >> >> > will accept your code, but allowing the use of an undeclared name is >> >> > deprecated) >> >> > /usr/include/surface_functions.h:101: error: there are no arguments >> >> > to >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreads1' must be available >> >> > /usr/include/surface_functions.h:102: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu1' must be available >> >> > /usr/include/surface_functions.h:103: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu2' must be available >> >> > /usr/include/surface_functions.h:104: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu4' must be available >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:460: error: there are no arguments >> >> > to >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadc1' must be available >> >> > /usr/include/surface_functions.h:461: error: there are no arguments >> >> > to >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreads1' must be available >> >> > /usr/include/surface_functions.h:462: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu1' must be available >> >> > /usr/include/surface_functions.h:463: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu2' must be available >> >> > /usr/include/surface_functions.h:464: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu4' must be available >> >> > CMake Error at >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> > (message): >> >> > Error generating file >> >> > >> >> > >> >> > >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > >> >> > >> >> > make[2]: *** >> >> > >> >> > >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> > Error 1 >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> > make: *** [all] Error 2 >> >> > >> >> > I remember having the same issue in plastimatch some time ago (it is >> >> > due >> >> > to >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> > >> >> > But anyhow, can you please guide us through a compilation to make it >> >> > work >> >> > and test it on the new projections? >> >> > >> >> > thanks a lot >> >> > Best Regards, >> >> > Marta Peroni >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Wed Oct 17 10:25:52 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Wed, 17 Oct 2012 16:25:52 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... Message-ID: <20121017142552.78880@gmx.net> Hi Simon, we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? Thank you. p From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:44:08 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:44:08 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... In-Reply-To: <20121017142552.78880@gmx.net> References: <20121017142552.78880@gmx.net> Message-ID: Hi, Yes, this is intentional. FDK requires more than matrices to compute, e.g., the angular gaps (http://www.openrtk.org/Doxygen/classrtk_1_1ThreeDCircularProjectionGeometry.html#ae821fb8a5d01b6dd947fc5f8e54cd676). Just search in the code for where the geometry object is used and you'll understand. What you describe is a rtk::ThreeDCircularProjectionGeometry so you are going to lose more time doing a new geometry file than learning how to use rtk::ThreeDCircularProjectionGeometry. If you give us some details and/or an example, we can help you doing the conversion. The parameters should be very intuitive. Simon On Wed, Oct 17, 2012 at 4:25 PM, Lars Friedrich Lars wrote: > Hi Simon, > > we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? > > Thank you. > > p > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Thu Oct 18 05:45:23 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 18 Oct 2012 11:45:23 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> <9115_1350483574_q9HEJWrs014386_CAF0oig0JumNrvzkF28RBGqCi0hRfZuG4OBDTMyyHZptNOZL5dQ@mail.gmail.com> Message-ID: Marta, Sorry, while we were working on compiling RTK for you there has been some other commits that may have caused the problem. Could you give it another try now? It should be fixed according to the dashboard: http://my.cdash.org/index.php?project=RTK Simon On Wed, Oct 17, 2012 at 4:37 PM, Marta Peroni wrote: > Hi Simon! > don't worry, I'm glad I can be useful for testing... > yet another gcc issue I believe: > [ 73%] Building C object > applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/rtkbackprojections_ggo.c.o > Linking CXX executable ../../bin/rtkbackprojections > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaFDKBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaFDKBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaFDKBackProjectionImageFilter::CudaFDKBackProjectionImageFilter()' > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaBackProjectionImageFilter::CudaBackProjectionImageFilter()' > collect2: error: ld returned 1 exit status > make[2]: *** [bin/rtkbackprojections] Error 1 > make[1]: *** > [applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/all] > Error 2 > > make: *** [all] Error 2 > > > I'll let you know very soon about the windows thing...I remember that we > tried to compile without installing gengetopt and it was not compiling it > automatically. Let me give it another shot... > Marta > > On 17 October 2012 16:18, Simon Rit wrote: >> >> The other linux compile errors have been fixed, they were caused by >> the recent gcc that you seem to be using. Sorry for this hassle, we do >> not have tested all possible combinations of gccs yet... >> >> From your CMakeCache.txt, it seems that you have gengetopt installed here: >> C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe >> A way to solve this would be to remove it from the Windows path so >> that cmake doesn't use it because gengetopt code has been copied in >> RTK and will be compiled automatically if it's not in the path. In the >> future, we should check on gengetopt version and compile it >> automatically if the system version is too old. I have opened a bug: >> http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 >> This should fix the gengetopt enum errors but I still have to figure >> out the linking problem if it's still here. It's strange that it does >> not show up on my windows box... >> >> Simon >> >> On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni >> wrote: >> > Hi Simon! >> > that fixed the error thanks :) But I am afraid I have another one.... >> > (log_linux attached hed). >> > I also send you the CMakeCache.txt, but I am afraid your intuition might >> > be >> > right... >> > For windows, where do you get the gengeopt? just to make sure we are >> > up-to-date >> > thanks a lot >> > Marta >> > >> > >> > On 17 October 2012 14:56, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> >> >> Yes still ITK 3.20, see instructions here: >> >> http://wiki.openrtk.org/index.php/RTK/Users. >> >> I fixed the linux error, a commit of 2 days ago was causing it. >> >> I don't, however, understand some of your windows errors. It seems >> >> that it does not understand the ggo files with enum variables although >> >> this has been working on Windows and Linux so far. A potential >> >> explanation would be that you have installed an old version of >> >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> >> to help me fixing it? You mentioned a problem with getopt.h in your >> >> first email but I did not see it in the log. >> >> There is also a linking problem with Cuda that your CMakeCache.txt >> >> might help me to understand. >> >> Thanks, >> >> Simon >> >> >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> >> >> wrote: >> >> > Hi! >> >> > sorry that it took soo long to answer. >> >> > For windows: >> >> > compiler is Visual Studio Express 2008 and we are using Windows 7 >> >> > (see >> >> > log_windows attached) >> >> > >> >> > For Linux: >> >> > I downloaded the latest version from here: >> >> > https://github.com/SimonRit/RTK >> >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> >> > Got over the usual nvcc error, but still could not compile >> >> > unfortunately >> >> > (see log_linux attached) >> >> > >> >> > thanks a lot >> >> > Marta >> >> > >> >> > On 12 October 2012 11:19, Simon Rit >> >> > wrote: >> >> >> >> >> >> Hi Marta, >> >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> >> are the problems with getopt.h. Could you send us more information >> >> >> (logs, Windows version, compiler, ...)? >> >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> >> you update your RTK repository and give it another try? >> >> >> A simple Shepp Logan reconstruction example is available here >> >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> >> Good luck, >> >> >> Simon >> >> >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> >> wrote: >> >> >> > Dear Simon and David, >> >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are >> >> >> > looking >> >> >> > into >> >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we >> >> >> > had >> >> >> > a >> >> >> > look >> >> >> > at IRTK. >> >> >> > >> >> >> > Now, problem is that we were not able to compile it neither on >> >> >> > windows >> >> >> > nor >> >> >> > linux (arch distrib). >> >> >> > >> >> >> > For windows, main issues were related to the windows version of >> >> >> > getopt >> >> >> > which >> >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> >> > like). >> >> >> > >> >> >> > For linux, I had cuda problem. In particular, although correctly >> >> >> > configured, >> >> >> > I am stuck with this: >> >> >> > [ 7%] Building NVCC (Device) object >> >> >> > >> >> >> > >> >> >> > >> >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:100: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> >> > '-fpermissive', >> >> >> > G++ >> >> >> > will accept your code, but allowing the use of an undeclared name >> >> >> > is >> >> >> > deprecated) >> >> >> > /usr/include/surface_functions.h:101: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:102: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:103: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:104: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu4' must be available >> >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:460: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:461: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:462: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:463: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:464: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu4' must be available >> >> >> > CMake Error at >> >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> >> > (message): >> >> >> > Error generating file >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > >> >> >> > >> >> >> > make[2]: *** >> >> >> > >> >> >> > >> >> >> > >> >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> >> > Error 1 >> >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> >> > make: *** [all] Error 2 >> >> >> > >> >> >> > I remember having the same issue in plastimatch some time ago (it >> >> >> > is >> >> >> > due >> >> >> > to >> >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> >> > >> >> >> > But anyhow, can you please guide us through a compilation to make >> >> >> > it >> >> >> > work >> >> >> > and test it on the new projections? >> >> >> > >> >> >> > thanks a lot >> >> >> > Best Regards, >> >> >> > Marta Peroni >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > >> >> >> > ******************************************************************* >> >> >> > Marta Peroni, PhD >> >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> >> > >> >> >> > contacts: >> >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> >> > mobile: +393488202136 (IT) >> >> >> > office: +39 02 2399 9022 >> >> >> > >> >> >> > >> >> >> > ******************************************************************** >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From hsieandy at gmail.com Tue Oct 23 08:48:32 2012 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 23 Oct 2012 23:48:32 +1100 Subject: [Rtk-users] RTK calculating attenuation from Varian projection Message-ID: Hi Simon, I was looking at "rtkVarianObiRawImageFilter.h", and realized that the attenuation is calculated from the projection image simply via a negative transformation (1-Intensity/HND_MaxIntensity). Is it usually the way this is done, and is there any reason for doing this? I would have thought attenuation should be calculated from intensity via logarithm (since I=I_0 exp(-mu x)). Thanks!! Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 23 12:16:07 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 23 Oct 2012 18:16:07 +0200 Subject: [Rtk-users] RTK calculating attenuation from Varian projection In-Reply-To: References: Message-ID: Hi Andy, Yes you're right, I have actually noticed recently that but I have not worked a lot on Varian images because we don't have a Varian CBCT in Lyon. I only had a sub-sampled acquisition from Greg of a Catphan that I used to roughly check the geometry. As far as I can remember, when I wrote this piece of code, I tried to use the same code as Plastimatch but I could well have done it wrongly. I'm actually waiting for a new complete Catphan acquisition from Greg to correct for this but if you already have a patch to suggest or a set of images to send, feel free to do it. Thanks, Simon On Tue, Oct 23, 2012 at 2:48 PM, Andy Shieh wrote: > Hi Simon, > > I was looking at "rtkVarianObiRawImageFilter.h", and realized that the > attenuation is calculated from the projection image simply via a negative > transformation (1-Intensity/HND_MaxIntensity). > Is it usually the way this is done, and is there any reason for doing this? > I would have thought attenuation should be calculated from intensity via > logarithm (since I=I_0 exp(-mu x)). > Thanks!! > > Cheers, > Andy > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From croow at yahoo.com Tue Oct 23 19:57:12 2012 From: croow at yahoo.com (M Miller) Date: Tue, 23 Oct 2012 16:57:12 -0700 (PDT) Subject: [Rtk-users] Reconstruct from projections; Starter tips Message-ID: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> I'm new to RTK and I'd like to reconstruct some projections into a volume. So far I've only been able to get an "InvalidRequestedRegionError", but I'd like to describe my steps with the hope that someone can point out what I've done wrong. I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample programs seem to work fine as I can successfully walk through the FDK SheppLogan example. My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, covering 360deg of rotation. The center of rotation is 65.93mm from the xray source, and the detector is 870.86mm from the source. The detector is 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. ? I create a geometry file: "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 --sdd=870.86 --sid=65.93" ? Attempt to reconstruct: "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml --path=d:\ct_projections\test\ --regexp=tif$ --output=d:\ct_projections\rtkfdk.mha --divisions=2" ? Output: >Regular expression matches 3143 file(s) >Reading geometry information from d:\ct_projections\geo.xml... >Reconstructing and writing... ExceptionObject caught with writer->Update() > >itk::InvalidRequestedRegionError (0000000000009FED10) >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) throw(class itk::InvalidRequestedRegionError)" >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx >Line: 397 >Description: Requested region is (at least partially) outside the largest possible region. ? I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( reader->Update() )" with just "reader->Update()", otherwise there is no debug information. The "lowmem" switch is required to keep ITK from crashing, which I think is an unrelated problem. I use "divisions=2" because plastimatch would crash for me without specifying something similar. Setting the "hardware" switch to either cpu or cuda produces the same error. The client machine has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. ? Is there any extra information necessary or anything that needs clarification? How can I use RTK to reconstruct a volume, if possible? ? Thanks Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Oct 24 04:27:13 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 24 Oct 2012 10:27:13 +0200 Subject: [Rtk-users] Reconstruct from projections; Starter tips In-Reply-To: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> References: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> Message-ID: Hi Micah, You did not do a mistake, you have successfully hit a bug. The truth is that I haven't used the divisions option in a very long time... This should now be fixed https://github.com/SimonRit/RTK/commit/10f8e1b0a5f6b69c943d04513135856968e3e62b and I have added an automated test to avoid future inconveniences https://github.com/SimonRit/RTK/commit/0932e38ad73d8e7214adda5103ced38c7b2754d0 Thanks for the report and keep us a posted. By the way, I have not done a lot of work with tif inputs so you might have to modify the tif conversion from raw to attenuation https://github.com/SimonRit/RTK/blob/master/code/rtkTiffLookupTableImageFilter.h Good luck! Simon On Wed, Oct 24, 2012 at 1:57 AM, M Miller wrote: > I'm new to RTK and I'd like to reconstruct some projections into a volume. > So far I've only been able to get an "InvalidRequestedRegionError", but I'd > like to describe my steps with the hope that someone can point out what > I've done wrong. > > I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample > programs seem to work fine as I can successfully walk through the FDK > SheppLogan example. > > My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, > covering 360deg of rotation. The center of rotation is 65.93mm from the > xray source, and the detector is 870.86mm from the source. The detector is > 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. > > I create a geometry file: > "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 > --sdd=870.86 --sid=65.93" > > Attempt to reconstruct: > "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml > --path=d:\ct_projections\test\ --regexp=tif$ > --output=d:\ct_projections\rtkfdk.mha --divisions=2" > > Output: > >Regular expression matches 3143 file(s) > >Reading geometry information from d:\ct_projections\geo.xml... > >Reconstructing and writing... ExceptionObject caught with writer->Update() > > > >itk::InvalidRequestedRegionError (0000000000009FED10) > >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) > throw(class itk::InvalidRequestedRegionError)" > >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx > >Line: 397 > >Description: Requested region is (at least partially) outside the largest > possible region. > > I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( > reader->Update() )" with just "reader->Update()", otherwise there is no > debug information. > > The "lowmem" switch is required to keep ITK from crashing, which I think > is an unrelated problem. I use "divisions=2" because plastimatch would > crash for me without specifying something similar. Setting the "hardware" > switch to either cpu or cuda produces the same error. The client machine > has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. > > Is there any extra information necessary or anything that needs > clarification? > How can I use RTK to reconstruct a volume, if possible? > > Thanks > Micah > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 12 05:19:16 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 12 Oct 2012 11:19:16 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: Message-ID: Hi Marta, Thanks for the feedback. Yes, we would be interested in knowing what are the problems with getopt.h. Could you send us more information (logs, Windows version, compiler, ...)? Regarding Cuda, this is a bit of a weird problem. I have tried to merge the latest version of Plastimatch cmake files with rtk. Could you update your RTK repository and give it another try? A simple Shepp Logan reconstruction example is available here http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are available here http://wiki.openrtk.org/index.php/RTK/Users. Good luck, Simon On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni wrote: > Dear Simon and David, > was a pleasure to meet you at MICCAI. As I mentioned, we are looking into > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a look > at IRTK. > > Now, problem is that we were not able to compile it neither on windows nor > linux (arch distrib). > > For windows, main issues were related to the windows version of getopt which > generate syntax error (Marco can provide you a log file, if you'd like). > > For linux, I had cuda problem. In particular, although correctly configured, > I am stuck with this: > [ 7%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, > surface, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:100: error: there are no arguments to > '__surf1Dreadc1' that depend on a template parameter, so a declaration of > '__surf1Dreadc1' must be available > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', G++ > will accept your code, but allowing the use of an undeclared name is > deprecated) > /usr/include/surface_functions.h:101: error: there are no arguments to > '__surf1Dreads1' that depend on a template parameter, so a declaration of > '__surf1Dreads1' must be available > /usr/include/surface_functions.h:102: error: there are no arguments to > '__surf1Dreadu1' that depend on a template parameter, so a declaration of > '__surf1Dreadu1' must be available > /usr/include/surface_functions.h:103: error: there are no arguments to > '__surf1Dreadu2' that depend on a template parameter, so a declaration of > '__surf1Dreadu2' must be available > /usr/include/surface_functions.h:104: error: there are no arguments to > '__surf1Dreadu4' that depend on a template parameter, so a declaration of > '__surf1Dreadu4' must be available > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, > surface, int, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:460: error: there are no arguments to > '__surf2Dreadc1' that depend on a template parameter, so a declaration of > '__surf2Dreadc1' must be available > /usr/include/surface_functions.h:461: error: there are no arguments to > '__surf2Dreads1' that depend on a template parameter, so a declaration of > '__surf2Dreads1' must be available > /usr/include/surface_functions.h:462: error: there are no arguments to > '__surf2Dreadu1' that depend on a template parameter, so a declaration of > '__surf2Dreadu1' must be available > /usr/include/surface_functions.h:463: error: there are no arguments to > '__surf2Dreadu2' that depend on a template parameter, so a declaration of > '__surf2Dreadu2' must be available > /usr/include/surface_functions.h:464: error: there are no arguments to > '__surf2Dreadu4' that depend on a template parameter, so a declaration of > '__surf2Dreadu4' must be available > CMake Error at > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 (message): > Error generating file > > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > > make[2]: *** > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] > Error 1 > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 > make: *** [all] Error 2 > > I remember having the same issue in plastimatch some time ago (it is due to > cuda version) and James added some -fpermissive to fix the issue. > > But anyhow, can you please guide us through a compilation to make it work > and test it on the new projections? > > thanks a lot > Best Regards, > Marta Peroni > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Mon Oct 15 13:53:13 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Mon, 15 Oct 2012 19:53:13 +0200 Subject: [Rtk-users] FirstReconstruction example Message-ID: <20121015175313.49610@gmx.net> Hello, I have questions concerning the FirstReconstruction example: Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? Sorry for the detailed questions, I just would like to understand how RTK is working. Thanks a lot! LF From simon.rit at creatis.insa-lyon.fr Mon Oct 15 16:17:59 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 15 Oct 2012 22:17:59 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121015175313.49610@gmx.net> References: <20121015175313.49610@gmx.net> Message-ID: Hi Lars, The geometry is described in the document geometry.tex, I have added links at the end of the user's wiki page http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with coordinates 0,0,0 of your volume is the isocenter, the point with coordinate 0,0 in projection images is the intersection of your flat panel with the line going through the x-ray source and the isocenter. The image origin is defined by ITK as the center of the pixel with index 0 in memory (first pixel in memory). I hope this helps, Simon On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars wrote: > Hello, > > I have questions concerning the FirstReconstruction example: > Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). > > How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. > > Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? > > Sorry for the detailed questions, I just would like to understand how RTK is working. > > Thanks a lot! > > LF > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:03:43 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:03:43 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> Message-ID: <20121016080343.49570@gmx.net> Hi Simon, thanks for your reply! I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. Basically, the first sentence in section 6 of the doc "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." along with another sentence in this section "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... Thanks so far! LF -------- Original-Nachricht -------- > Datum: Mon, 15 Oct 2012 22:17:59 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > Hi Lars, > The geometry is described in the document geometry.tex, I have added > links at the end of the user's wiki page > http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > coordinates 0,0,0 of your volume is the isocenter, the point with > coordinate 0,0 in projection images is the intersection of your flat > panel with the line going through the x-ray source and the isocenter. > The image origin is defined by ITK as the center of the pixel with > index 0 in memory (first pixel in memory). > I hope this helps, > Simon > > On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > wrote: > > Hello, > > > > I have questions concerning the FirstReconstruction example: > > Using the rtk::RayEllipsoidIntersectionImageFilter and > rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are > packed in the form of an image stack. The geometry of the projections is > described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the > images' metrics are described by the image stack itself (spacing, size and > ORIGIN). > > > > How should I interpret the origin? As far as I could find out by minor > modifications of the example, the origin of the projeciton image stack plays > a role (if I change it to 0,0,0, and retain constantImageSource2's origin > at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does > the origin of the image stack matter? Isn't the origin of a single > projection fully defined by the corresponding entry in the > rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the > offset from the detector central axis crossing point)? Am I right that the > effective origin of a single projection image emerges basically from the > detector (x/y of origin of image stack) and from consecutive application of > the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, > e.g. caused by gravity, wouldn't be simulatable. > > > > Morever, which point exactly does the image origin (x/y components) of > the projection stack describe? Is it the outer corner of the projection or > the center of the first voxel (as in DICOM). The size of a projection in the > example is 256.0x256.0 units. However, the stack's origin is at > -127.0,-127.0. If the origin should refer to the center of the first projection > pixel, it should be essentially -127.5,-127.5, right? > > > > Sorry for the detailed questions, I just would like to understand how > RTK is working. > > > > Thanks a lot! > > > > LF > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Tue Oct 16 04:23:17 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 16 Oct 2012 10:23:17 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121016080343.49570@gmx.net> References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: I agree, geometry is irritating! I'm sorry my comments were part of this irritation... It seemed obvious to me that the origin and the direction in itk::Image has to be accounted for but I'll add a comment in the header to make it clearer. Bear in mind that this on-going work so feel free to suggest improvements and clarifications. Regarding geometry conversion, we had done a work with my colleagues from the Universit? Catholique de Louvain to convert their geometry parameterization to RTK parameterization using Maxima. That allowed us to spare some hours spent on deriving the correct formulas... Would you be interested in the script file? Simon On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars wrote: > Hi Simon, > > thanks for your reply! > > I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > Basically, the first sentence in section 6 of the doc > "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." > along with another sentence in this section > "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." > irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. > > My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > Thanks so far! > > LF > > -------- Original-Nachricht -------- >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 >> Von: Simon Rit >> An: Lars Friedrich Lars >> CC: rtk-users at openrtk.org >> Betreff: Re: [Rtk-users] FirstReconstruction example > >> Hi Lars, >> The geometry is described in the document geometry.tex, I have added >> links at the end of the user's wiki page >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with >> coordinates 0,0,0 of your volume is the isocenter, the point with >> coordinate 0,0 in projection images is the intersection of your flat >> panel with the line going through the x-ray source and the isocenter. >> The image origin is defined by ITK as the center of the pixel with >> index 0 in memory (first pixel in memory). >> I hope this helps, >> Simon >> >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars >> wrote: >> > Hello, >> > >> > I have questions concerning the FirstReconstruction example: >> > Using the rtk::RayEllipsoidIntersectionImageFilter and >> rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are >> packed in the form of an image stack. The geometry of the projections is >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the >> images' metrics are described by the image stack itself (spacing, size and >> ORIGIN). >> > >> > How should I interpret the origin? As far as I could find out by minor >> modifications of the example, the origin of the projeciton image stack plays >> a role (if I change it to 0,0,0, and retain constantImageSource2's origin >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does >> the origin of the image stack matter? Isn't the origin of a single >> projection fully defined by the corresponding entry in the >> rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the >> offset from the detector central axis crossing point)? Am I right that the >> effective origin of a single projection image emerges basically from the >> detector (x/y of origin of image stack) and from consecutive application of >> the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, >> e.g. caused by gravity, wouldn't be simulatable. >> > >> > Morever, which point exactly does the image origin (x/y components) of >> the projection stack describe? Is it the outer corner of the projection or >> the center of the first voxel (as in DICOM). The size of a projection in the >> example is 256.0x256.0 units. However, the stack's origin is at >> -127.0,-127.0. If the origin should refer to the center of the first projection >> pixel, it should be essentially -127.5,-127.5, right? >> > >> > Sorry for the detailed questions, I just would like to understand how >> RTK is working. >> > >> > Thanks a lot! >> > >> > LF >> > _______________________________________________ >> > Rtk-users mailing list >> > Rtk-users at openrtk.org >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:55:04 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:55:04 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: <20121016085504.78840@gmx.net> Hi, thanks!! Yep, I would be very interested in the script since I would like to try first whether my geometry is generally a no go for the FDK-based approaches in RTK (which I cannot exclude at the moment), before shaping the code and implementing C++-based converters. Lars -------- Original-Nachricht -------- > Datum: Tue, 16 Oct 2012 10:23:17 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > I agree, geometry is irritating! I'm sorry my comments were part of > this irritation... It seemed obvious to me that the origin and the > direction in itk::Image has to be accounted for but I'll add a comment > in the header to make it clearer. Bear in mind that this on-going work > so feel free to suggest improvements and clarifications. > > Regarding geometry conversion, we had done a work with my colleagues > from the Universit? Catholique de Louvain to convert their geometry > parameterization to RTK parameterization using Maxima. That allowed us > to spare some hours spent on deriving the correct formulas... Would > you be interested in the script file? > > Simon > > On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars > wrote: > > Hi Simon, > > > > thanks for your reply! > > > > I read the geometry-doc and played around with > rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > > Basically, the first sentence in section 6 of the doc > > "This class is meant to define a set of 2D projection images, acquired > with a at panel along a circular trajectory, around a 3D tomography." > > along with another sentence in this section > > "9 parameters are used per projection to define the position of the > source and the detector relatively to the fixed coordinate system." > > irritated me a bit. I thought that the 3DCircGeom's task is, in addition > to defining the source position, to define the position and orientation of > the 2D projection images, and the 3DCircGeom is defined in the IEC WCS > (relates to it). I did not expect essential projection image metrics except > dimension (pixel size) and spacing (because image size in physical units is > not part of 3DCircGeom) having any influence on the position and orientation > of it, since this is already defined with the 3DCircGeom object. > > > > My issue at the moment is simply that I have source position, detector > position and detector row/column vectors defined in IEC WCS for each > projection, and have to convert it somehow into your projection geometry format + > (and that's news for me) adjust the image origin of the projection stack. > Unfortunately, my geometry is not really a standard circular one (as in case > of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > > > Thanks so far! > > > > LF > > > > -------- Original-Nachricht -------- > >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 > >> Von: Simon Rit > >> An: Lars Friedrich Lars > >> CC: rtk-users at openrtk.org > >> Betreff: Re: [Rtk-users] FirstReconstruction example > > > >> Hi Lars, > >> The geometry is described in the document geometry.tex, I have added > >> links at the end of the user's wiki page > >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > >> coordinates 0,0,0 of your volume is the isocenter, the point with > >> coordinate 0,0 in projection images is the intersection of your flat > >> panel with the line going through the x-ray source and the isocenter. > >> The image origin is defined by ITK as the center of the pixel with > >> index 0 in memory (first pixel in memory). > >> I hope this helps, > >> Simon > >> > >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > >> wrote: > >> > Hello, > >> > > >> > I have questions concerning the FirstReconstruction example: > >> > Using the rtk::RayEllipsoidIntersectionImageFilter and > >> rtk::ConstantImageSource artificial projections of an ellipsoid are > generated which are > >> packed in the form of an image stack. The geometry of the projections > is > >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, > the > >> images' metrics are described by the image stack itself (spacing, size > and > >> ORIGIN). > >> > > >> > How should I interpret the origin? As far as I could find out by > minor > >> modifications of the example, the origin of the projeciton image stack > plays > >> a role (if I change it to 0,0,0, and retain constantImageSource2's > origin > >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why > does > >> the origin of the image stack matter? Isn't the origin of a single > >> projection fully defined by the corresponding entry in the > >> rtk::ThreeDCircularProjectionGeometry object (I thought the > projOffsetX,projOffsetY args define the > >> offset from the detector central axis crossing point)? Am I right that > the > >> effective origin of a single projection image emerges basically from > the > >> detector (x/y of origin of image stack) and from consecutive > application of > >> the projOffsetX,projOffsetY args? Otherwise, deviating detector > positions, > >> e.g. caused by gravity, wouldn't be simulatable. > >> > > >> > Morever, which point exactly does the image origin (x/y components) > of > >> the projection stack describe? Is it the outer corner of the projection > or > >> the center of the first voxel (as in DICOM). The size of a projection > in the > >> example is 256.0x256.0 units. However, the stack's origin is at > >> -127.0,-127.0. If the origin should refer to the center of the first > projection > >> pixel, it should be essentially -127.5,-127.5, right? > >> > > >> > Sorry for the detailed questions, I just would like to understand how > >> RTK is working. > >> > > >> > Thanks a lot! > >> > > >> > LF > >> > _______________________________________________ > >> > Rtk-users mailing list > >> > Rtk-users at openrtk.org > >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Wed Oct 17 08:56:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 14:56:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> Message-ID: Hi Marta, Yes still ITK 3.20, see instructions here: http://wiki.openrtk.org/index.php/RTK/Users. I fixed the linux error, a commit of 2 days ago was causing it. I don't, however, understand some of your windows errors. It seems that it does not understand the ggo files with enum variables although this has been working on Windows and Linux so far. A potential explanation would be that you have installed an old version of gengetopt on your computer? Maybe you can send me your CMakeCache.txt to help me fixing it? You mentioned a problem with getopt.h in your first email but I did not see it in the log. There is also a linking problem with Cuda that your CMakeCache.txt might help me to understand. Thanks, Simon On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni wrote: > Hi! > sorry that it took soo long to answer. > For windows: > compiler is Visual Studio Express 2008 and we are using Windows 7 (see > log_windows attached) > > For Linux: > I downloaded the latest version from here: https://github.com/SimonRit/RTK > and tried to compile against ITK 3.20 (should I try with ITK4?) > Got over the usual nvcc error, but still could not compile unfortunately > (see log_linux attached) > > thanks a lot > Marta > > On 12 October 2012 11:19, Simon Rit wrote: >> >> Hi Marta, >> Thanks for the feedback. Yes, we would be interested in knowing what >> are the problems with getopt.h. Could you send us more information >> (logs, Windows version, compiler, ...)? >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> merge the latest version of Plastimatch cmake files with rtk. Could >> you update your RTK repository and give it another try? >> A simple Shepp Logan reconstruction example is available here >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> Good luck, >> Simon >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> wrote: >> > Dear Simon and David, >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> > into >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a >> > look >> > at IRTK. >> > >> > Now, problem is that we were not able to compile it neither on windows >> > nor >> > linux (arch distrib). >> > >> > For windows, main issues were related to the windows version of getopt >> > which >> > generate syntax error (Marco can provide you a log file, if you'd like). >> > >> > For linux, I had cuda problem. In particular, although correctly >> > configured, >> > I am stuck with this: >> > [ 7%] Building NVCC (Device) object >> > >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> > surface, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:100: error: there are no arguments to >> > '__surf1Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadc1' must be available >> > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', >> > G++ >> > will accept your code, but allowing the use of an undeclared name is >> > deprecated) >> > /usr/include/surface_functions.h:101: error: there are no arguments to >> > '__surf1Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreads1' must be available >> > /usr/include/surface_functions.h:102: error: there are no arguments to >> > '__surf1Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu1' must be available >> > /usr/include/surface_functions.h:103: error: there are no arguments to >> > '__surf1Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu2' must be available >> > /usr/include/surface_functions.h:104: error: there are no arguments to >> > '__surf1Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu4' must be available >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:460: error: there are no arguments to >> > '__surf2Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadc1' must be available >> > /usr/include/surface_functions.h:461: error: there are no arguments to >> > '__surf2Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreads1' must be available >> > /usr/include/surface_functions.h:462: error: there are no arguments to >> > '__surf2Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu1' must be available >> > /usr/include/surface_functions.h:463: error: there are no arguments to >> > '__surf2Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu2' must be available >> > /usr/include/surface_functions.h:464: error: there are no arguments to >> > '__surf2Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu4' must be available >> > CMake Error at >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> > (message): >> > Error generating file >> > >> > >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > >> > >> > make[2]: *** >> > >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> > Error 1 >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> > make: *** [all] Error 2 >> > >> > I remember having the same issue in plastimatch some time ago (it is due >> > to >> > cuda version) and James added some -fpermissive to fix the issue. >> > >> > But anyhow, can you please guide us through a compilation to make it >> > work >> > and test it on the new projections? >> > >> > thanks a lot >> > Best Regards, >> > Marta Peroni >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:18:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:18:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> Message-ID: The other linux compile errors have been fixed, they were caused by the recent gcc that you seem to be using. Sorry for this hassle, we do not have tested all possible combinations of gccs yet... >From your CMakeCache.txt, it seems that you have gengetopt installed here: C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe A way to solve this would be to remove it from the Windows path so that cmake doesn't use it because gengetopt code has been copied in RTK and will be compiled automatically if it's not in the path. In the future, we should check on gengetopt version and compile it automatically if the system version is too old. I have opened a bug: http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 This should fix the gengetopt enum errors but I still have to figure out the linking problem if it's still here. It's strange that it does not show up on my windows box... Simon On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni wrote: > Hi Simon! > that fixed the error thanks :) But I am afraid I have another one.... > (log_linux attached hed). > I also send you the CMakeCache.txt, but I am afraid your intuition might be > right... > For windows, where do you get the gengeopt? just to make sure we are > up-to-date > thanks a lot > Marta > > > On 17 October 2012 14:56, Simon Rit wrote: >> >> Hi Marta, >> >> Yes still ITK 3.20, see instructions here: >> http://wiki.openrtk.org/index.php/RTK/Users. >> I fixed the linux error, a commit of 2 days ago was causing it. >> I don't, however, understand some of your windows errors. It seems >> that it does not understand the ggo files with enum variables although >> this has been working on Windows and Linux so far. A potential >> explanation would be that you have installed an old version of >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> to help me fixing it? You mentioned a problem with getopt.h in your >> first email but I did not see it in the log. >> There is also a linking problem with Cuda that your CMakeCache.txt >> might help me to understand. >> Thanks, >> Simon >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> wrote: >> > Hi! >> > sorry that it took soo long to answer. >> > For windows: >> > compiler is Visual Studio Express 2008 and we are using Windows 7 (see >> > log_windows attached) >> > >> > For Linux: >> > I downloaded the latest version from here: >> > https://github.com/SimonRit/RTK >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> > Got over the usual nvcc error, but still could not compile unfortunately >> > (see log_linux attached) >> > >> > thanks a lot >> > Marta >> > >> > On 12 October 2012 11:19, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> are the problems with getopt.h. Could you send us more information >> >> (logs, Windows version, compiler, ...)? >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> you update your RTK repository and give it another try? >> >> A simple Shepp Logan reconstruction example is available here >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> Good luck, >> >> Simon >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> wrote: >> >> > Dear Simon and David, >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> >> > into >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had >> >> > a >> >> > look >> >> > at IRTK. >> >> > >> >> > Now, problem is that we were not able to compile it neither on >> >> > windows >> >> > nor >> >> > linux (arch distrib). >> >> > >> >> > For windows, main issues were related to the windows version of >> >> > getopt >> >> > which >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> > like). >> >> > >> >> > For linux, I had cuda problem. In particular, although correctly >> >> > configured, >> >> > I am stuck with this: >> >> > [ 7%] Building NVCC (Device) object >> >> > >> >> > >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:100: error: there are no arguments >> >> > to >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadc1' must be available >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> > '-fpermissive', >> >> > G++ >> >> > will accept your code, but allowing the use of an undeclared name is >> >> > deprecated) >> >> > /usr/include/surface_functions.h:101: error: there are no arguments >> >> > to >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreads1' must be available >> >> > /usr/include/surface_functions.h:102: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu1' must be available >> >> > /usr/include/surface_functions.h:103: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu2' must be available >> >> > /usr/include/surface_functions.h:104: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu4' must be available >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:460: error: there are no arguments >> >> > to >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadc1' must be available >> >> > /usr/include/surface_functions.h:461: error: there are no arguments >> >> > to >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreads1' must be available >> >> > /usr/include/surface_functions.h:462: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu1' must be available >> >> > /usr/include/surface_functions.h:463: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu2' must be available >> >> > /usr/include/surface_functions.h:464: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu4' must be available >> >> > CMake Error at >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> > (message): >> >> > Error generating file >> >> > >> >> > >> >> > >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > >> >> > >> >> > make[2]: *** >> >> > >> >> > >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> > Error 1 >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> > make: *** [all] Error 2 >> >> > >> >> > I remember having the same issue in plastimatch some time ago (it is >> >> > due >> >> > to >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> > >> >> > But anyhow, can you please guide us through a compilation to make it >> >> > work >> >> > and test it on the new projections? >> >> > >> >> > thanks a lot >> >> > Best Regards, >> >> > Marta Peroni >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Wed Oct 17 10:25:52 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Wed, 17 Oct 2012 16:25:52 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... Message-ID: <20121017142552.78880@gmx.net> Hi Simon, we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? Thank you. p From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:44:08 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:44:08 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... In-Reply-To: <20121017142552.78880@gmx.net> References: <20121017142552.78880@gmx.net> Message-ID: Hi, Yes, this is intentional. FDK requires more than matrices to compute, e.g., the angular gaps (http://www.openrtk.org/Doxygen/classrtk_1_1ThreeDCircularProjectionGeometry.html#ae821fb8a5d01b6dd947fc5f8e54cd676). Just search in the code for where the geometry object is used and you'll understand. What you describe is a rtk::ThreeDCircularProjectionGeometry so you are going to lose more time doing a new geometry file than learning how to use rtk::ThreeDCircularProjectionGeometry. If you give us some details and/or an example, we can help you doing the conversion. The parameters should be very intuitive. Simon On Wed, Oct 17, 2012 at 4:25 PM, Lars Friedrich Lars wrote: > Hi Simon, > > we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? > > Thank you. > > p > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Thu Oct 18 05:45:23 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 18 Oct 2012 11:45:23 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> <9115_1350483574_q9HEJWrs014386_CAF0oig0JumNrvzkF28RBGqCi0hRfZuG4OBDTMyyHZptNOZL5dQ@mail.gmail.com> Message-ID: Marta, Sorry, while we were working on compiling RTK for you there has been some other commits that may have caused the problem. Could you give it another try now? It should be fixed according to the dashboard: http://my.cdash.org/index.php?project=RTK Simon On Wed, Oct 17, 2012 at 4:37 PM, Marta Peroni wrote: > Hi Simon! > don't worry, I'm glad I can be useful for testing... > yet another gcc issue I believe: > [ 73%] Building C object > applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/rtkbackprojections_ggo.c.o > Linking CXX executable ../../bin/rtkbackprojections > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaFDKBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaFDKBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaFDKBackProjectionImageFilter::CudaFDKBackProjectionImageFilter()' > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaBackProjectionImageFilter::CudaBackProjectionImageFilter()' > collect2: error: ld returned 1 exit status > make[2]: *** [bin/rtkbackprojections] Error 1 > make[1]: *** > [applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/all] > Error 2 > > make: *** [all] Error 2 > > > I'll let you know very soon about the windows thing...I remember that we > tried to compile without installing gengetopt and it was not compiling it > automatically. Let me give it another shot... > Marta > > On 17 October 2012 16:18, Simon Rit wrote: >> >> The other linux compile errors have been fixed, they were caused by >> the recent gcc that you seem to be using. Sorry for this hassle, we do >> not have tested all possible combinations of gccs yet... >> >> From your CMakeCache.txt, it seems that you have gengetopt installed here: >> C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe >> A way to solve this would be to remove it from the Windows path so >> that cmake doesn't use it because gengetopt code has been copied in >> RTK and will be compiled automatically if it's not in the path. In the >> future, we should check on gengetopt version and compile it >> automatically if the system version is too old. I have opened a bug: >> http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 >> This should fix the gengetopt enum errors but I still have to figure >> out the linking problem if it's still here. It's strange that it does >> not show up on my windows box... >> >> Simon >> >> On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni >> wrote: >> > Hi Simon! >> > that fixed the error thanks :) But I am afraid I have another one.... >> > (log_linux attached hed). >> > I also send you the CMakeCache.txt, but I am afraid your intuition might >> > be >> > right... >> > For windows, where do you get the gengeopt? just to make sure we are >> > up-to-date >> > thanks a lot >> > Marta >> > >> > >> > On 17 October 2012 14:56, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> >> >> Yes still ITK 3.20, see instructions here: >> >> http://wiki.openrtk.org/index.php/RTK/Users. >> >> I fixed the linux error, a commit of 2 days ago was causing it. >> >> I don't, however, understand some of your windows errors. It seems >> >> that it does not understand the ggo files with enum variables although >> >> this has been working on Windows and Linux so far. A potential >> >> explanation would be that you have installed an old version of >> >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> >> to help me fixing it? You mentioned a problem with getopt.h in your >> >> first email but I did not see it in the log. >> >> There is also a linking problem with Cuda that your CMakeCache.txt >> >> might help me to understand. >> >> Thanks, >> >> Simon >> >> >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> >> >> wrote: >> >> > Hi! >> >> > sorry that it took soo long to answer. >> >> > For windows: >> >> > compiler is Visual Studio Express 2008 and we are using Windows 7 >> >> > (see >> >> > log_windows attached) >> >> > >> >> > For Linux: >> >> > I downloaded the latest version from here: >> >> > https://github.com/SimonRit/RTK >> >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> >> > Got over the usual nvcc error, but still could not compile >> >> > unfortunately >> >> > (see log_linux attached) >> >> > >> >> > thanks a lot >> >> > Marta >> >> > >> >> > On 12 October 2012 11:19, Simon Rit >> >> > wrote: >> >> >> >> >> >> Hi Marta, >> >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> >> are the problems with getopt.h. Could you send us more information >> >> >> (logs, Windows version, compiler, ...)? >> >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> >> you update your RTK repository and give it another try? >> >> >> A simple Shepp Logan reconstruction example is available here >> >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> >> Good luck, >> >> >> Simon >> >> >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> >> wrote: >> >> >> > Dear Simon and David, >> >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are >> >> >> > looking >> >> >> > into >> >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we >> >> >> > had >> >> >> > a >> >> >> > look >> >> >> > at IRTK. >> >> >> > >> >> >> > Now, problem is that we were not able to compile it neither on >> >> >> > windows >> >> >> > nor >> >> >> > linux (arch distrib). >> >> >> > >> >> >> > For windows, main issues were related to the windows version of >> >> >> > getopt >> >> >> > which >> >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> >> > like). >> >> >> > >> >> >> > For linux, I had cuda problem. In particular, although correctly >> >> >> > configured, >> >> >> > I am stuck with this: >> >> >> > [ 7%] Building NVCC (Device) object >> >> >> > >> >> >> > >> >> >> > >> >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:100: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> >> > '-fpermissive', >> >> >> > G++ >> >> >> > will accept your code, but allowing the use of an undeclared name >> >> >> > is >> >> >> > deprecated) >> >> >> > /usr/include/surface_functions.h:101: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:102: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:103: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:104: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu4' must be available >> >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:460: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:461: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:462: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:463: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:464: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu4' must be available >> >> >> > CMake Error at >> >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> >> > (message): >> >> >> > Error generating file >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > >> >> >> > >> >> >> > make[2]: *** >> >> >> > >> >> >> > >> >> >> > >> >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> >> > Error 1 >> >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> >> > make: *** [all] Error 2 >> >> >> > >> >> >> > I remember having the same issue in plastimatch some time ago (it >> >> >> > is >> >> >> > due >> >> >> > to >> >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> >> > >> >> >> > But anyhow, can you please guide us through a compilation to make >> >> >> > it >> >> >> > work >> >> >> > and test it on the new projections? >> >> >> > >> >> >> > thanks a lot >> >> >> > Best Regards, >> >> >> > Marta Peroni >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > >> >> >> > ******************************************************************* >> >> >> > Marta Peroni, PhD >> >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> >> > >> >> >> > contacts: >> >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> >> > mobile: +393488202136 (IT) >> >> >> > office: +39 02 2399 9022 >> >> >> > >> >> >> > >> >> >> > ******************************************************************** >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From hsieandy at gmail.com Tue Oct 23 08:48:32 2012 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 23 Oct 2012 23:48:32 +1100 Subject: [Rtk-users] RTK calculating attenuation from Varian projection Message-ID: Hi Simon, I was looking at "rtkVarianObiRawImageFilter.h", and realized that the attenuation is calculated from the projection image simply via a negative transformation (1-Intensity/HND_MaxIntensity). Is it usually the way this is done, and is there any reason for doing this? I would have thought attenuation should be calculated from intensity via logarithm (since I=I_0 exp(-mu x)). Thanks!! Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 23 12:16:07 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 23 Oct 2012 18:16:07 +0200 Subject: [Rtk-users] RTK calculating attenuation from Varian projection In-Reply-To: References: Message-ID: Hi Andy, Yes you're right, I have actually noticed recently that but I have not worked a lot on Varian images because we don't have a Varian CBCT in Lyon. I only had a sub-sampled acquisition from Greg of a Catphan that I used to roughly check the geometry. As far as I can remember, when I wrote this piece of code, I tried to use the same code as Plastimatch but I could well have done it wrongly. I'm actually waiting for a new complete Catphan acquisition from Greg to correct for this but if you already have a patch to suggest or a set of images to send, feel free to do it. Thanks, Simon On Tue, Oct 23, 2012 at 2:48 PM, Andy Shieh wrote: > Hi Simon, > > I was looking at "rtkVarianObiRawImageFilter.h", and realized that the > attenuation is calculated from the projection image simply via a negative > transformation (1-Intensity/HND_MaxIntensity). > Is it usually the way this is done, and is there any reason for doing this? > I would have thought attenuation should be calculated from intensity via > logarithm (since I=I_0 exp(-mu x)). > Thanks!! > > Cheers, > Andy > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From croow at yahoo.com Tue Oct 23 19:57:12 2012 From: croow at yahoo.com (M Miller) Date: Tue, 23 Oct 2012 16:57:12 -0700 (PDT) Subject: [Rtk-users] Reconstruct from projections; Starter tips Message-ID: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> I'm new to RTK and I'd like to reconstruct some projections into a volume. So far I've only been able to get an "InvalidRequestedRegionError", but I'd like to describe my steps with the hope that someone can point out what I've done wrong. I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample programs seem to work fine as I can successfully walk through the FDK SheppLogan example. My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, covering 360deg of rotation. The center of rotation is 65.93mm from the xray source, and the detector is 870.86mm from the source. The detector is 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. ? I create a geometry file: "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 --sdd=870.86 --sid=65.93" ? Attempt to reconstruct: "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml --path=d:\ct_projections\test\ --regexp=tif$ --output=d:\ct_projections\rtkfdk.mha --divisions=2" ? Output: >Regular expression matches 3143 file(s) >Reading geometry information from d:\ct_projections\geo.xml... >Reconstructing and writing... ExceptionObject caught with writer->Update() > >itk::InvalidRequestedRegionError (0000000000009FED10) >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) throw(class itk::InvalidRequestedRegionError)" >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx >Line: 397 >Description: Requested region is (at least partially) outside the largest possible region. ? I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( reader->Update() )" with just "reader->Update()", otherwise there is no debug information. The "lowmem" switch is required to keep ITK from crashing, which I think is an unrelated problem. I use "divisions=2" because plastimatch would crash for me without specifying something similar. Setting the "hardware" switch to either cpu or cuda produces the same error. The client machine has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. ? Is there any extra information necessary or anything that needs clarification? How can I use RTK to reconstruct a volume, if possible? ? Thanks Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Oct 24 04:27:13 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 24 Oct 2012 10:27:13 +0200 Subject: [Rtk-users] Reconstruct from projections; Starter tips In-Reply-To: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> References: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> Message-ID: Hi Micah, You did not do a mistake, you have successfully hit a bug. The truth is that I haven't used the divisions option in a very long time... This should now be fixed https://github.com/SimonRit/RTK/commit/10f8e1b0a5f6b69c943d04513135856968e3e62b and I have added an automated test to avoid future inconveniences https://github.com/SimonRit/RTK/commit/0932e38ad73d8e7214adda5103ced38c7b2754d0 Thanks for the report and keep us a posted. By the way, I have not done a lot of work with tif inputs so you might have to modify the tif conversion from raw to attenuation https://github.com/SimonRit/RTK/blob/master/code/rtkTiffLookupTableImageFilter.h Good luck! Simon On Wed, Oct 24, 2012 at 1:57 AM, M Miller wrote: > I'm new to RTK and I'd like to reconstruct some projections into a volume. > So far I've only been able to get an "InvalidRequestedRegionError", but I'd > like to describe my steps with the hope that someone can point out what > I've done wrong. > > I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample > programs seem to work fine as I can successfully walk through the FDK > SheppLogan example. > > My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, > covering 360deg of rotation. The center of rotation is 65.93mm from the > xray source, and the detector is 870.86mm from the source. The detector is > 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. > > I create a geometry file: > "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 > --sdd=870.86 --sid=65.93" > > Attempt to reconstruct: > "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml > --path=d:\ct_projections\test\ --regexp=tif$ > --output=d:\ct_projections\rtkfdk.mha --divisions=2" > > Output: > >Regular expression matches 3143 file(s) > >Reading geometry information from d:\ct_projections\geo.xml... > >Reconstructing and writing... ExceptionObject caught with writer->Update() > > > >itk::InvalidRequestedRegionError (0000000000009FED10) > >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) > throw(class itk::InvalidRequestedRegionError)" > >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx > >Line: 397 > >Description: Requested region is (at least partially) outside the largest > possible region. > > I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( > reader->Update() )" with just "reader->Update()", otherwise there is no > debug information. > > The "lowmem" switch is required to keep ITK from crashing, which I think > is an unrelated problem. I use "divisions=2" because plastimatch would > crash for me without specifying something similar. Setting the "hardware" > switch to either cpu or cuda produces the same error. The client machine > has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. > > Is there any extra information necessary or anything that needs > clarification? > How can I use RTK to reconstruct a volume, if possible? > > Thanks > Micah > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 12 05:19:16 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 12 Oct 2012 11:19:16 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: Message-ID: Hi Marta, Thanks for the feedback. Yes, we would be interested in knowing what are the problems with getopt.h. Could you send us more information (logs, Windows version, compiler, ...)? Regarding Cuda, this is a bit of a weird problem. I have tried to merge the latest version of Plastimatch cmake files with rtk. Could you update your RTK repository and give it another try? A simple Shepp Logan reconstruction example is available here http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are available here http://wiki.openrtk.org/index.php/RTK/Users. Good luck, Simon On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni wrote: > Dear Simon and David, > was a pleasure to meet you at MICCAI. As I mentioned, we are looking into > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a look > at IRTK. > > Now, problem is that we were not able to compile it neither on windows nor > linux (arch distrib). > > For windows, main issues were related to the windows version of getopt which > generate syntax error (Marco can provide you a log file, if you'd like). > > For linux, I had cuda problem. In particular, although correctly configured, > I am stuck with this: > [ 7%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, > surface, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:100: error: there are no arguments to > '__surf1Dreadc1' that depend on a template parameter, so a declaration of > '__surf1Dreadc1' must be available > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', G++ > will accept your code, but allowing the use of an undeclared name is > deprecated) > /usr/include/surface_functions.h:101: error: there are no arguments to > '__surf1Dreads1' that depend on a template parameter, so a declaration of > '__surf1Dreads1' must be available > /usr/include/surface_functions.h:102: error: there are no arguments to > '__surf1Dreadu1' that depend on a template parameter, so a declaration of > '__surf1Dreadu1' must be available > /usr/include/surface_functions.h:103: error: there are no arguments to > '__surf1Dreadu2' that depend on a template parameter, so a declaration of > '__surf1Dreadu2' must be available > /usr/include/surface_functions.h:104: error: there are no arguments to > '__surf1Dreadu4' that depend on a template parameter, so a declaration of > '__surf1Dreadu4' must be available > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, > surface, int, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:460: error: there are no arguments to > '__surf2Dreadc1' that depend on a template parameter, so a declaration of > '__surf2Dreadc1' must be available > /usr/include/surface_functions.h:461: error: there are no arguments to > '__surf2Dreads1' that depend on a template parameter, so a declaration of > '__surf2Dreads1' must be available > /usr/include/surface_functions.h:462: error: there are no arguments to > '__surf2Dreadu1' that depend on a template parameter, so a declaration of > '__surf2Dreadu1' must be available > /usr/include/surface_functions.h:463: error: there are no arguments to > '__surf2Dreadu2' that depend on a template parameter, so a declaration of > '__surf2Dreadu2' must be available > /usr/include/surface_functions.h:464: error: there are no arguments to > '__surf2Dreadu4' that depend on a template parameter, so a declaration of > '__surf2Dreadu4' must be available > CMake Error at > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 (message): > Error generating file > > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > > make[2]: *** > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] > Error 1 > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 > make: *** [all] Error 2 > > I remember having the same issue in plastimatch some time ago (it is due to > cuda version) and James added some -fpermissive to fix the issue. > > But anyhow, can you please guide us through a compilation to make it work > and test it on the new projections? > > thanks a lot > Best Regards, > Marta Peroni > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Mon Oct 15 13:53:13 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Mon, 15 Oct 2012 19:53:13 +0200 Subject: [Rtk-users] FirstReconstruction example Message-ID: <20121015175313.49610@gmx.net> Hello, I have questions concerning the FirstReconstruction example: Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? Sorry for the detailed questions, I just would like to understand how RTK is working. Thanks a lot! LF From simon.rit at creatis.insa-lyon.fr Mon Oct 15 16:17:59 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 15 Oct 2012 22:17:59 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121015175313.49610@gmx.net> References: <20121015175313.49610@gmx.net> Message-ID: Hi Lars, The geometry is described in the document geometry.tex, I have added links at the end of the user's wiki page http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with coordinates 0,0,0 of your volume is the isocenter, the point with coordinate 0,0 in projection images is the intersection of your flat panel with the line going through the x-ray source and the isocenter. The image origin is defined by ITK as the center of the pixel with index 0 in memory (first pixel in memory). I hope this helps, Simon On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars wrote: > Hello, > > I have questions concerning the FirstReconstruction example: > Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). > > How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. > > Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? > > Sorry for the detailed questions, I just would like to understand how RTK is working. > > Thanks a lot! > > LF > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:03:43 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:03:43 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> Message-ID: <20121016080343.49570@gmx.net> Hi Simon, thanks for your reply! I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. Basically, the first sentence in section 6 of the doc "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." along with another sentence in this section "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... Thanks so far! LF -------- Original-Nachricht -------- > Datum: Mon, 15 Oct 2012 22:17:59 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > Hi Lars, > The geometry is described in the document geometry.tex, I have added > links at the end of the user's wiki page > http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > coordinates 0,0,0 of your volume is the isocenter, the point with > coordinate 0,0 in projection images is the intersection of your flat > panel with the line going through the x-ray source and the isocenter. > The image origin is defined by ITK as the center of the pixel with > index 0 in memory (first pixel in memory). > I hope this helps, > Simon > > On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > wrote: > > Hello, > > > > I have questions concerning the FirstReconstruction example: > > Using the rtk::RayEllipsoidIntersectionImageFilter and > rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are > packed in the form of an image stack. The geometry of the projections is > described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the > images' metrics are described by the image stack itself (spacing, size and > ORIGIN). > > > > How should I interpret the origin? As far as I could find out by minor > modifications of the example, the origin of the projeciton image stack plays > a role (if I change it to 0,0,0, and retain constantImageSource2's origin > at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does > the origin of the image stack matter? Isn't the origin of a single > projection fully defined by the corresponding entry in the > rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the > offset from the detector central axis crossing point)? Am I right that the > effective origin of a single projection image emerges basically from the > detector (x/y of origin of image stack) and from consecutive application of > the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, > e.g. caused by gravity, wouldn't be simulatable. > > > > Morever, which point exactly does the image origin (x/y components) of > the projection stack describe? Is it the outer corner of the projection or > the center of the first voxel (as in DICOM). The size of a projection in the > example is 256.0x256.0 units. However, the stack's origin is at > -127.0,-127.0. If the origin should refer to the center of the first projection > pixel, it should be essentially -127.5,-127.5, right? > > > > Sorry for the detailed questions, I just would like to understand how > RTK is working. > > > > Thanks a lot! > > > > LF > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Tue Oct 16 04:23:17 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 16 Oct 2012 10:23:17 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121016080343.49570@gmx.net> References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: I agree, geometry is irritating! I'm sorry my comments were part of this irritation... It seemed obvious to me that the origin and the direction in itk::Image has to be accounted for but I'll add a comment in the header to make it clearer. Bear in mind that this on-going work so feel free to suggest improvements and clarifications. Regarding geometry conversion, we had done a work with my colleagues from the Universit? Catholique de Louvain to convert their geometry parameterization to RTK parameterization using Maxima. That allowed us to spare some hours spent on deriving the correct formulas... Would you be interested in the script file? Simon On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars wrote: > Hi Simon, > > thanks for your reply! > > I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > Basically, the first sentence in section 6 of the doc > "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." > along with another sentence in this section > "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." > irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. > > My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > Thanks so far! > > LF > > -------- Original-Nachricht -------- >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 >> Von: Simon Rit >> An: Lars Friedrich Lars >> CC: rtk-users at openrtk.org >> Betreff: Re: [Rtk-users] FirstReconstruction example > >> Hi Lars, >> The geometry is described in the document geometry.tex, I have added >> links at the end of the user's wiki page >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with >> coordinates 0,0,0 of your volume is the isocenter, the point with >> coordinate 0,0 in projection images is the intersection of your flat >> panel with the line going through the x-ray source and the isocenter. >> The image origin is defined by ITK as the center of the pixel with >> index 0 in memory (first pixel in memory). >> I hope this helps, >> Simon >> >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars >> wrote: >> > Hello, >> > >> > I have questions concerning the FirstReconstruction example: >> > Using the rtk::RayEllipsoidIntersectionImageFilter and >> rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are >> packed in the form of an image stack. The geometry of the projections is >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the >> images' metrics are described by the image stack itself (spacing, size and >> ORIGIN). >> > >> > How should I interpret the origin? As far as I could find out by minor >> modifications of the example, the origin of the projeciton image stack plays >> a role (if I change it to 0,0,0, and retain constantImageSource2's origin >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does >> the origin of the image stack matter? Isn't the origin of a single >> projection fully defined by the corresponding entry in the >> rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the >> offset from the detector central axis crossing point)? Am I right that the >> effective origin of a single projection image emerges basically from the >> detector (x/y of origin of image stack) and from consecutive application of >> the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, >> e.g. caused by gravity, wouldn't be simulatable. >> > >> > Morever, which point exactly does the image origin (x/y components) of >> the projection stack describe? Is it the outer corner of the projection or >> the center of the first voxel (as in DICOM). The size of a projection in the >> example is 256.0x256.0 units. However, the stack's origin is at >> -127.0,-127.0. If the origin should refer to the center of the first projection >> pixel, it should be essentially -127.5,-127.5, right? >> > >> > Sorry for the detailed questions, I just would like to understand how >> RTK is working. >> > >> > Thanks a lot! >> > >> > LF >> > _______________________________________________ >> > Rtk-users mailing list >> > Rtk-users at openrtk.org >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:55:04 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:55:04 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: <20121016085504.78840@gmx.net> Hi, thanks!! Yep, I would be very interested in the script since I would like to try first whether my geometry is generally a no go for the FDK-based approaches in RTK (which I cannot exclude at the moment), before shaping the code and implementing C++-based converters. Lars -------- Original-Nachricht -------- > Datum: Tue, 16 Oct 2012 10:23:17 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > I agree, geometry is irritating! I'm sorry my comments were part of > this irritation... It seemed obvious to me that the origin and the > direction in itk::Image has to be accounted for but I'll add a comment > in the header to make it clearer. Bear in mind that this on-going work > so feel free to suggest improvements and clarifications. > > Regarding geometry conversion, we had done a work with my colleagues > from the Universit? Catholique de Louvain to convert their geometry > parameterization to RTK parameterization using Maxima. That allowed us > to spare some hours spent on deriving the correct formulas... Would > you be interested in the script file? > > Simon > > On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars > wrote: > > Hi Simon, > > > > thanks for your reply! > > > > I read the geometry-doc and played around with > rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > > Basically, the first sentence in section 6 of the doc > > "This class is meant to define a set of 2D projection images, acquired > with a at panel along a circular trajectory, around a 3D tomography." > > along with another sentence in this section > > "9 parameters are used per projection to define the position of the > source and the detector relatively to the fixed coordinate system." > > irritated me a bit. I thought that the 3DCircGeom's task is, in addition > to defining the source position, to define the position and orientation of > the 2D projection images, and the 3DCircGeom is defined in the IEC WCS > (relates to it). I did not expect essential projection image metrics except > dimension (pixel size) and spacing (because image size in physical units is > not part of 3DCircGeom) having any influence on the position and orientation > of it, since this is already defined with the 3DCircGeom object. > > > > My issue at the moment is simply that I have source position, detector > position and detector row/column vectors defined in IEC WCS for each > projection, and have to convert it somehow into your projection geometry format + > (and that's news for me) adjust the image origin of the projection stack. > Unfortunately, my geometry is not really a standard circular one (as in case > of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > > > Thanks so far! > > > > LF > > > > -------- Original-Nachricht -------- > >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 > >> Von: Simon Rit > >> An: Lars Friedrich Lars > >> CC: rtk-users at openrtk.org > >> Betreff: Re: [Rtk-users] FirstReconstruction example > > > >> Hi Lars, > >> The geometry is described in the document geometry.tex, I have added > >> links at the end of the user's wiki page > >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > >> coordinates 0,0,0 of your volume is the isocenter, the point with > >> coordinate 0,0 in projection images is the intersection of your flat > >> panel with the line going through the x-ray source and the isocenter. > >> The image origin is defined by ITK as the center of the pixel with > >> index 0 in memory (first pixel in memory). > >> I hope this helps, > >> Simon > >> > >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > >> wrote: > >> > Hello, > >> > > >> > I have questions concerning the FirstReconstruction example: > >> > Using the rtk::RayEllipsoidIntersectionImageFilter and > >> rtk::ConstantImageSource artificial projections of an ellipsoid are > generated which are > >> packed in the form of an image stack. The geometry of the projections > is > >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, > the > >> images' metrics are described by the image stack itself (spacing, size > and > >> ORIGIN). > >> > > >> > How should I interpret the origin? As far as I could find out by > minor > >> modifications of the example, the origin of the projeciton image stack > plays > >> a role (if I change it to 0,0,0, and retain constantImageSource2's > origin > >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why > does > >> the origin of the image stack matter? Isn't the origin of a single > >> projection fully defined by the corresponding entry in the > >> rtk::ThreeDCircularProjectionGeometry object (I thought the > projOffsetX,projOffsetY args define the > >> offset from the detector central axis crossing point)? Am I right that > the > >> effective origin of a single projection image emerges basically from > the > >> detector (x/y of origin of image stack) and from consecutive > application of > >> the projOffsetX,projOffsetY args? Otherwise, deviating detector > positions, > >> e.g. caused by gravity, wouldn't be simulatable. > >> > > >> > Morever, which point exactly does the image origin (x/y components) > of > >> the projection stack describe? Is it the outer corner of the projection > or > >> the center of the first voxel (as in DICOM). The size of a projection > in the > >> example is 256.0x256.0 units. However, the stack's origin is at > >> -127.0,-127.0. If the origin should refer to the center of the first > projection > >> pixel, it should be essentially -127.5,-127.5, right? > >> > > >> > Sorry for the detailed questions, I just would like to understand how > >> RTK is working. > >> > > >> > Thanks a lot! > >> > > >> > LF > >> > _______________________________________________ > >> > Rtk-users mailing list > >> > Rtk-users at openrtk.org > >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Wed Oct 17 08:56:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 14:56:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> Message-ID: Hi Marta, Yes still ITK 3.20, see instructions here: http://wiki.openrtk.org/index.php/RTK/Users. I fixed the linux error, a commit of 2 days ago was causing it. I don't, however, understand some of your windows errors. It seems that it does not understand the ggo files with enum variables although this has been working on Windows and Linux so far. A potential explanation would be that you have installed an old version of gengetopt on your computer? Maybe you can send me your CMakeCache.txt to help me fixing it? You mentioned a problem with getopt.h in your first email but I did not see it in the log. There is also a linking problem with Cuda that your CMakeCache.txt might help me to understand. Thanks, Simon On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni wrote: > Hi! > sorry that it took soo long to answer. > For windows: > compiler is Visual Studio Express 2008 and we are using Windows 7 (see > log_windows attached) > > For Linux: > I downloaded the latest version from here: https://github.com/SimonRit/RTK > and tried to compile against ITK 3.20 (should I try with ITK4?) > Got over the usual nvcc error, but still could not compile unfortunately > (see log_linux attached) > > thanks a lot > Marta > > On 12 October 2012 11:19, Simon Rit wrote: >> >> Hi Marta, >> Thanks for the feedback. Yes, we would be interested in knowing what >> are the problems with getopt.h. Could you send us more information >> (logs, Windows version, compiler, ...)? >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> merge the latest version of Plastimatch cmake files with rtk. Could >> you update your RTK repository and give it another try? >> A simple Shepp Logan reconstruction example is available here >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> Good luck, >> Simon >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> wrote: >> > Dear Simon and David, >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> > into >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a >> > look >> > at IRTK. >> > >> > Now, problem is that we were not able to compile it neither on windows >> > nor >> > linux (arch distrib). >> > >> > For windows, main issues were related to the windows version of getopt >> > which >> > generate syntax error (Marco can provide you a log file, if you'd like). >> > >> > For linux, I had cuda problem. In particular, although correctly >> > configured, >> > I am stuck with this: >> > [ 7%] Building NVCC (Device) object >> > >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> > surface, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:100: error: there are no arguments to >> > '__surf1Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadc1' must be available >> > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', >> > G++ >> > will accept your code, but allowing the use of an undeclared name is >> > deprecated) >> > /usr/include/surface_functions.h:101: error: there are no arguments to >> > '__surf1Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreads1' must be available >> > /usr/include/surface_functions.h:102: error: there are no arguments to >> > '__surf1Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu1' must be available >> > /usr/include/surface_functions.h:103: error: there are no arguments to >> > '__surf1Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu2' must be available >> > /usr/include/surface_functions.h:104: error: there are no arguments to >> > '__surf1Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu4' must be available >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:460: error: there are no arguments to >> > '__surf2Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadc1' must be available >> > /usr/include/surface_functions.h:461: error: there are no arguments to >> > '__surf2Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreads1' must be available >> > /usr/include/surface_functions.h:462: error: there are no arguments to >> > '__surf2Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu1' must be available >> > /usr/include/surface_functions.h:463: error: there are no arguments to >> > '__surf2Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu2' must be available >> > /usr/include/surface_functions.h:464: error: there are no arguments to >> > '__surf2Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu4' must be available >> > CMake Error at >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> > (message): >> > Error generating file >> > >> > >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > >> > >> > make[2]: *** >> > >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> > Error 1 >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> > make: *** [all] Error 2 >> > >> > I remember having the same issue in plastimatch some time ago (it is due >> > to >> > cuda version) and James added some -fpermissive to fix the issue. >> > >> > But anyhow, can you please guide us through a compilation to make it >> > work >> > and test it on the new projections? >> > >> > thanks a lot >> > Best Regards, >> > Marta Peroni >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:18:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:18:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> Message-ID: The other linux compile errors have been fixed, they were caused by the recent gcc that you seem to be using. Sorry for this hassle, we do not have tested all possible combinations of gccs yet... >From your CMakeCache.txt, it seems that you have gengetopt installed here: C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe A way to solve this would be to remove it from the Windows path so that cmake doesn't use it because gengetopt code has been copied in RTK and will be compiled automatically if it's not in the path. In the future, we should check on gengetopt version and compile it automatically if the system version is too old. I have opened a bug: http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 This should fix the gengetopt enum errors but I still have to figure out the linking problem if it's still here. It's strange that it does not show up on my windows box... Simon On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni wrote: > Hi Simon! > that fixed the error thanks :) But I am afraid I have another one.... > (log_linux attached hed). > I also send you the CMakeCache.txt, but I am afraid your intuition might be > right... > For windows, where do you get the gengeopt? just to make sure we are > up-to-date > thanks a lot > Marta > > > On 17 October 2012 14:56, Simon Rit wrote: >> >> Hi Marta, >> >> Yes still ITK 3.20, see instructions here: >> http://wiki.openrtk.org/index.php/RTK/Users. >> I fixed the linux error, a commit of 2 days ago was causing it. >> I don't, however, understand some of your windows errors. It seems >> that it does not understand the ggo files with enum variables although >> this has been working on Windows and Linux so far. A potential >> explanation would be that you have installed an old version of >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> to help me fixing it? You mentioned a problem with getopt.h in your >> first email but I did not see it in the log. >> There is also a linking problem with Cuda that your CMakeCache.txt >> might help me to understand. >> Thanks, >> Simon >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> wrote: >> > Hi! >> > sorry that it took soo long to answer. >> > For windows: >> > compiler is Visual Studio Express 2008 and we are using Windows 7 (see >> > log_windows attached) >> > >> > For Linux: >> > I downloaded the latest version from here: >> > https://github.com/SimonRit/RTK >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> > Got over the usual nvcc error, but still could not compile unfortunately >> > (see log_linux attached) >> > >> > thanks a lot >> > Marta >> > >> > On 12 October 2012 11:19, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> are the problems with getopt.h. Could you send us more information >> >> (logs, Windows version, compiler, ...)? >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> you update your RTK repository and give it another try? >> >> A simple Shepp Logan reconstruction example is available here >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> Good luck, >> >> Simon >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> wrote: >> >> > Dear Simon and David, >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> >> > into >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had >> >> > a >> >> > look >> >> > at IRTK. >> >> > >> >> > Now, problem is that we were not able to compile it neither on >> >> > windows >> >> > nor >> >> > linux (arch distrib). >> >> > >> >> > For windows, main issues were related to the windows version of >> >> > getopt >> >> > which >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> > like). >> >> > >> >> > For linux, I had cuda problem. In particular, although correctly >> >> > configured, >> >> > I am stuck with this: >> >> > [ 7%] Building NVCC (Device) object >> >> > >> >> > >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:100: error: there are no arguments >> >> > to >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadc1' must be available >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> > '-fpermissive', >> >> > G++ >> >> > will accept your code, but allowing the use of an undeclared name is >> >> > deprecated) >> >> > /usr/include/surface_functions.h:101: error: there are no arguments >> >> > to >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreads1' must be available >> >> > /usr/include/surface_functions.h:102: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu1' must be available >> >> > /usr/include/surface_functions.h:103: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu2' must be available >> >> > /usr/include/surface_functions.h:104: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu4' must be available >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:460: error: there are no arguments >> >> > to >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadc1' must be available >> >> > /usr/include/surface_functions.h:461: error: there are no arguments >> >> > to >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreads1' must be available >> >> > /usr/include/surface_functions.h:462: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu1' must be available >> >> > /usr/include/surface_functions.h:463: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu2' must be available >> >> > /usr/include/surface_functions.h:464: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu4' must be available >> >> > CMake Error at >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> > (message): >> >> > Error generating file >> >> > >> >> > >> >> > >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > >> >> > >> >> > make[2]: *** >> >> > >> >> > >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> > Error 1 >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> > make: *** [all] Error 2 >> >> > >> >> > I remember having the same issue in plastimatch some time ago (it is >> >> > due >> >> > to >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> > >> >> > But anyhow, can you please guide us through a compilation to make it >> >> > work >> >> > and test it on the new projections? >> >> > >> >> > thanks a lot >> >> > Best Regards, >> >> > Marta Peroni >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Wed Oct 17 10:25:52 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Wed, 17 Oct 2012 16:25:52 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... Message-ID: <20121017142552.78880@gmx.net> Hi Simon, we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? Thank you. p From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:44:08 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:44:08 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... In-Reply-To: <20121017142552.78880@gmx.net> References: <20121017142552.78880@gmx.net> Message-ID: Hi, Yes, this is intentional. FDK requires more than matrices to compute, e.g., the angular gaps (http://www.openrtk.org/Doxygen/classrtk_1_1ThreeDCircularProjectionGeometry.html#ae821fb8a5d01b6dd947fc5f8e54cd676). Just search in the code for where the geometry object is used and you'll understand. What you describe is a rtk::ThreeDCircularProjectionGeometry so you are going to lose more time doing a new geometry file than learning how to use rtk::ThreeDCircularProjectionGeometry. If you give us some details and/or an example, we can help you doing the conversion. The parameters should be very intuitive. Simon On Wed, Oct 17, 2012 at 4:25 PM, Lars Friedrich Lars wrote: > Hi Simon, > > we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? > > Thank you. > > p > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Thu Oct 18 05:45:23 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 18 Oct 2012 11:45:23 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> <9115_1350483574_q9HEJWrs014386_CAF0oig0JumNrvzkF28RBGqCi0hRfZuG4OBDTMyyHZptNOZL5dQ@mail.gmail.com> Message-ID: Marta, Sorry, while we were working on compiling RTK for you there has been some other commits that may have caused the problem. Could you give it another try now? It should be fixed according to the dashboard: http://my.cdash.org/index.php?project=RTK Simon On Wed, Oct 17, 2012 at 4:37 PM, Marta Peroni wrote: > Hi Simon! > don't worry, I'm glad I can be useful for testing... > yet another gcc issue I believe: > [ 73%] Building C object > applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/rtkbackprojections_ggo.c.o > Linking CXX executable ../../bin/rtkbackprojections > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaFDKBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaFDKBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaFDKBackProjectionImageFilter::CudaFDKBackProjectionImageFilter()' > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaBackProjectionImageFilter::CudaBackProjectionImageFilter()' > collect2: error: ld returned 1 exit status > make[2]: *** [bin/rtkbackprojections] Error 1 > make[1]: *** > [applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/all] > Error 2 > > make: *** [all] Error 2 > > > I'll let you know very soon about the windows thing...I remember that we > tried to compile without installing gengetopt and it was not compiling it > automatically. Let me give it another shot... > Marta > > On 17 October 2012 16:18, Simon Rit wrote: >> >> The other linux compile errors have been fixed, they were caused by >> the recent gcc that you seem to be using. Sorry for this hassle, we do >> not have tested all possible combinations of gccs yet... >> >> From your CMakeCache.txt, it seems that you have gengetopt installed here: >> C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe >> A way to solve this would be to remove it from the Windows path so >> that cmake doesn't use it because gengetopt code has been copied in >> RTK and will be compiled automatically if it's not in the path. In the >> future, we should check on gengetopt version and compile it >> automatically if the system version is too old. I have opened a bug: >> http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 >> This should fix the gengetopt enum errors but I still have to figure >> out the linking problem if it's still here. It's strange that it does >> not show up on my windows box... >> >> Simon >> >> On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni >> wrote: >> > Hi Simon! >> > that fixed the error thanks :) But I am afraid I have another one.... >> > (log_linux attached hed). >> > I also send you the CMakeCache.txt, but I am afraid your intuition might >> > be >> > right... >> > For windows, where do you get the gengeopt? just to make sure we are >> > up-to-date >> > thanks a lot >> > Marta >> > >> > >> > On 17 October 2012 14:56, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> >> >> Yes still ITK 3.20, see instructions here: >> >> http://wiki.openrtk.org/index.php/RTK/Users. >> >> I fixed the linux error, a commit of 2 days ago was causing it. >> >> I don't, however, understand some of your windows errors. It seems >> >> that it does not understand the ggo files with enum variables although >> >> this has been working on Windows and Linux so far. A potential >> >> explanation would be that you have installed an old version of >> >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> >> to help me fixing it? You mentioned a problem with getopt.h in your >> >> first email but I did not see it in the log. >> >> There is also a linking problem with Cuda that your CMakeCache.txt >> >> might help me to understand. >> >> Thanks, >> >> Simon >> >> >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> >> >> wrote: >> >> > Hi! >> >> > sorry that it took soo long to answer. >> >> > For windows: >> >> > compiler is Visual Studio Express 2008 and we are using Windows 7 >> >> > (see >> >> > log_windows attached) >> >> > >> >> > For Linux: >> >> > I downloaded the latest version from here: >> >> > https://github.com/SimonRit/RTK >> >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> >> > Got over the usual nvcc error, but still could not compile >> >> > unfortunately >> >> > (see log_linux attached) >> >> > >> >> > thanks a lot >> >> > Marta >> >> > >> >> > On 12 October 2012 11:19, Simon Rit >> >> > wrote: >> >> >> >> >> >> Hi Marta, >> >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> >> are the problems with getopt.h. Could you send us more information >> >> >> (logs, Windows version, compiler, ...)? >> >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> >> you update your RTK repository and give it another try? >> >> >> A simple Shepp Logan reconstruction example is available here >> >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> >> Good luck, >> >> >> Simon >> >> >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> >> wrote: >> >> >> > Dear Simon and David, >> >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are >> >> >> > looking >> >> >> > into >> >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we >> >> >> > had >> >> >> > a >> >> >> > look >> >> >> > at IRTK. >> >> >> > >> >> >> > Now, problem is that we were not able to compile it neither on >> >> >> > windows >> >> >> > nor >> >> >> > linux (arch distrib). >> >> >> > >> >> >> > For windows, main issues were related to the windows version of >> >> >> > getopt >> >> >> > which >> >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> >> > like). >> >> >> > >> >> >> > For linux, I had cuda problem. In particular, although correctly >> >> >> > configured, >> >> >> > I am stuck with this: >> >> >> > [ 7%] Building NVCC (Device) object >> >> >> > >> >> >> > >> >> >> > >> >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:100: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> >> > '-fpermissive', >> >> >> > G++ >> >> >> > will accept your code, but allowing the use of an undeclared name >> >> >> > is >> >> >> > deprecated) >> >> >> > /usr/include/surface_functions.h:101: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:102: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:103: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:104: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu4' must be available >> >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:460: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:461: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:462: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:463: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:464: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu4' must be available >> >> >> > CMake Error at >> >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> >> > (message): >> >> >> > Error generating file >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > >> >> >> > >> >> >> > make[2]: *** >> >> >> > >> >> >> > >> >> >> > >> >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> >> > Error 1 >> >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> >> > make: *** [all] Error 2 >> >> >> > >> >> >> > I remember having the same issue in plastimatch some time ago (it >> >> >> > is >> >> >> > due >> >> >> > to >> >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> >> > >> >> >> > But anyhow, can you please guide us through a compilation to make >> >> >> > it >> >> >> > work >> >> >> > and test it on the new projections? >> >> >> > >> >> >> > thanks a lot >> >> >> > Best Regards, >> >> >> > Marta Peroni >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > >> >> >> > ******************************************************************* >> >> >> > Marta Peroni, PhD >> >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> >> > >> >> >> > contacts: >> >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> >> > mobile: +393488202136 (IT) >> >> >> > office: +39 02 2399 9022 >> >> >> > >> >> >> > >> >> >> > ******************************************************************** >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From hsieandy at gmail.com Tue Oct 23 08:48:32 2012 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 23 Oct 2012 23:48:32 +1100 Subject: [Rtk-users] RTK calculating attenuation from Varian projection Message-ID: Hi Simon, I was looking at "rtkVarianObiRawImageFilter.h", and realized that the attenuation is calculated from the projection image simply via a negative transformation (1-Intensity/HND_MaxIntensity). Is it usually the way this is done, and is there any reason for doing this? I would have thought attenuation should be calculated from intensity via logarithm (since I=I_0 exp(-mu x)). Thanks!! Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 23 12:16:07 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 23 Oct 2012 18:16:07 +0200 Subject: [Rtk-users] RTK calculating attenuation from Varian projection In-Reply-To: References: Message-ID: Hi Andy, Yes you're right, I have actually noticed recently that but I have not worked a lot on Varian images because we don't have a Varian CBCT in Lyon. I only had a sub-sampled acquisition from Greg of a Catphan that I used to roughly check the geometry. As far as I can remember, when I wrote this piece of code, I tried to use the same code as Plastimatch but I could well have done it wrongly. I'm actually waiting for a new complete Catphan acquisition from Greg to correct for this but if you already have a patch to suggest or a set of images to send, feel free to do it. Thanks, Simon On Tue, Oct 23, 2012 at 2:48 PM, Andy Shieh wrote: > Hi Simon, > > I was looking at "rtkVarianObiRawImageFilter.h", and realized that the > attenuation is calculated from the projection image simply via a negative > transformation (1-Intensity/HND_MaxIntensity). > Is it usually the way this is done, and is there any reason for doing this? > I would have thought attenuation should be calculated from intensity via > logarithm (since I=I_0 exp(-mu x)). > Thanks!! > > Cheers, > Andy > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From croow at yahoo.com Tue Oct 23 19:57:12 2012 From: croow at yahoo.com (M Miller) Date: Tue, 23 Oct 2012 16:57:12 -0700 (PDT) Subject: [Rtk-users] Reconstruct from projections; Starter tips Message-ID: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> I'm new to RTK and I'd like to reconstruct some projections into a volume. So far I've only been able to get an "InvalidRequestedRegionError", but I'd like to describe my steps with the hope that someone can point out what I've done wrong. I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample programs seem to work fine as I can successfully walk through the FDK SheppLogan example. My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, covering 360deg of rotation. The center of rotation is 65.93mm from the xray source, and the detector is 870.86mm from the source. The detector is 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. ? I create a geometry file: "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 --sdd=870.86 --sid=65.93" ? Attempt to reconstruct: "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml --path=d:\ct_projections\test\ --regexp=tif$ --output=d:\ct_projections\rtkfdk.mha --divisions=2" ? Output: >Regular expression matches 3143 file(s) >Reading geometry information from d:\ct_projections\geo.xml... >Reconstructing and writing... ExceptionObject caught with writer->Update() > >itk::InvalidRequestedRegionError (0000000000009FED10) >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) throw(class itk::InvalidRequestedRegionError)" >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx >Line: 397 >Description: Requested region is (at least partially) outside the largest possible region. ? I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( reader->Update() )" with just "reader->Update()", otherwise there is no debug information. The "lowmem" switch is required to keep ITK from crashing, which I think is an unrelated problem. I use "divisions=2" because plastimatch would crash for me without specifying something similar. Setting the "hardware" switch to either cpu or cuda produces the same error. The client machine has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. ? Is there any extra information necessary or anything that needs clarification? How can I use RTK to reconstruct a volume, if possible? ? Thanks Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Oct 24 04:27:13 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 24 Oct 2012 10:27:13 +0200 Subject: [Rtk-users] Reconstruct from projections; Starter tips In-Reply-To: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> References: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> Message-ID: Hi Micah, You did not do a mistake, you have successfully hit a bug. The truth is that I haven't used the divisions option in a very long time... This should now be fixed https://github.com/SimonRit/RTK/commit/10f8e1b0a5f6b69c943d04513135856968e3e62b and I have added an automated test to avoid future inconveniences https://github.com/SimonRit/RTK/commit/0932e38ad73d8e7214adda5103ced38c7b2754d0 Thanks for the report and keep us a posted. By the way, I have not done a lot of work with tif inputs so you might have to modify the tif conversion from raw to attenuation https://github.com/SimonRit/RTK/blob/master/code/rtkTiffLookupTableImageFilter.h Good luck! Simon On Wed, Oct 24, 2012 at 1:57 AM, M Miller wrote: > I'm new to RTK and I'd like to reconstruct some projections into a volume. > So far I've only been able to get an "InvalidRequestedRegionError", but I'd > like to describe my steps with the hope that someone can point out what > I've done wrong. > > I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample > programs seem to work fine as I can successfully walk through the FDK > SheppLogan example. > > My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, > covering 360deg of rotation. The center of rotation is 65.93mm from the > xray source, and the detector is 870.86mm from the source. The detector is > 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. > > I create a geometry file: > "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 > --sdd=870.86 --sid=65.93" > > Attempt to reconstruct: > "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml > --path=d:\ct_projections\test\ --regexp=tif$ > --output=d:\ct_projections\rtkfdk.mha --divisions=2" > > Output: > >Regular expression matches 3143 file(s) > >Reading geometry information from d:\ct_projections\geo.xml... > >Reconstructing and writing... ExceptionObject caught with writer->Update() > > > >itk::InvalidRequestedRegionError (0000000000009FED10) > >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) > throw(class itk::InvalidRequestedRegionError)" > >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx > >Line: 397 > >Description: Requested region is (at least partially) outside the largest > possible region. > > I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( > reader->Update() )" with just "reader->Update()", otherwise there is no > debug information. > > The "lowmem" switch is required to keep ITK from crashing, which I think > is an unrelated problem. I use "divisions=2" because plastimatch would > crash for me without specifying something similar. Setting the "hardware" > switch to either cpu or cuda produces the same error. The client machine > has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. > > Is there any extra information necessary or anything that needs > clarification? > How can I use RTK to reconstruct a volume, if possible? > > Thanks > Micah > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 12 05:19:16 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 12 Oct 2012 11:19:16 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: Message-ID: Hi Marta, Thanks for the feedback. Yes, we would be interested in knowing what are the problems with getopt.h. Could you send us more information (logs, Windows version, compiler, ...)? Regarding Cuda, this is a bit of a weird problem. I have tried to merge the latest version of Plastimatch cmake files with rtk. Could you update your RTK repository and give it another try? A simple Shepp Logan reconstruction example is available here http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are available here http://wiki.openrtk.org/index.php/RTK/Users. Good luck, Simon On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni wrote: > Dear Simon and David, > was a pleasure to meet you at MICCAI. As I mentioned, we are looking into > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a look > at IRTK. > > Now, problem is that we were not able to compile it neither on windows nor > linux (arch distrib). > > For windows, main issues were related to the windows version of getopt which > generate syntax error (Marco can provide you a log file, if you'd like). > > For linux, I had cuda problem. In particular, although correctly configured, > I am stuck with this: > [ 7%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, > surface, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:100: error: there are no arguments to > '__surf1Dreadc1' that depend on a template parameter, so a declaration of > '__surf1Dreadc1' must be available > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', G++ > will accept your code, but allowing the use of an undeclared name is > deprecated) > /usr/include/surface_functions.h:101: error: there are no arguments to > '__surf1Dreads1' that depend on a template parameter, so a declaration of > '__surf1Dreads1' must be available > /usr/include/surface_functions.h:102: error: there are no arguments to > '__surf1Dreadu1' that depend on a template parameter, so a declaration of > '__surf1Dreadu1' must be available > /usr/include/surface_functions.h:103: error: there are no arguments to > '__surf1Dreadu2' that depend on a template parameter, so a declaration of > '__surf1Dreadu2' must be available > /usr/include/surface_functions.h:104: error: there are no arguments to > '__surf1Dreadu4' that depend on a template parameter, so a declaration of > '__surf1Dreadu4' must be available > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, > surface, int, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:460: error: there are no arguments to > '__surf2Dreadc1' that depend on a template parameter, so a declaration of > '__surf2Dreadc1' must be available > /usr/include/surface_functions.h:461: error: there are no arguments to > '__surf2Dreads1' that depend on a template parameter, so a declaration of > '__surf2Dreads1' must be available > /usr/include/surface_functions.h:462: error: there are no arguments to > '__surf2Dreadu1' that depend on a template parameter, so a declaration of > '__surf2Dreadu1' must be available > /usr/include/surface_functions.h:463: error: there are no arguments to > '__surf2Dreadu2' that depend on a template parameter, so a declaration of > '__surf2Dreadu2' must be available > /usr/include/surface_functions.h:464: error: there are no arguments to > '__surf2Dreadu4' that depend on a template parameter, so a declaration of > '__surf2Dreadu4' must be available > CMake Error at > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 (message): > Error generating file > > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > > make[2]: *** > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] > Error 1 > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 > make: *** [all] Error 2 > > I remember having the same issue in plastimatch some time ago (it is due to > cuda version) and James added some -fpermissive to fix the issue. > > But anyhow, can you please guide us through a compilation to make it work > and test it on the new projections? > > thanks a lot > Best Regards, > Marta Peroni > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Mon Oct 15 13:53:13 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Mon, 15 Oct 2012 19:53:13 +0200 Subject: [Rtk-users] FirstReconstruction example Message-ID: <20121015175313.49610@gmx.net> Hello, I have questions concerning the FirstReconstruction example: Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? Sorry for the detailed questions, I just would like to understand how RTK is working. Thanks a lot! LF From simon.rit at creatis.insa-lyon.fr Mon Oct 15 16:17:59 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 15 Oct 2012 22:17:59 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121015175313.49610@gmx.net> References: <20121015175313.49610@gmx.net> Message-ID: Hi Lars, The geometry is described in the document geometry.tex, I have added links at the end of the user's wiki page http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with coordinates 0,0,0 of your volume is the isocenter, the point with coordinate 0,0 in projection images is the intersection of your flat panel with the line going through the x-ray source and the isocenter. The image origin is defined by ITK as the center of the pixel with index 0 in memory (first pixel in memory). I hope this helps, Simon On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars wrote: > Hello, > > I have questions concerning the FirstReconstruction example: > Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). > > How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. > > Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? > > Sorry for the detailed questions, I just would like to understand how RTK is working. > > Thanks a lot! > > LF > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:03:43 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:03:43 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> Message-ID: <20121016080343.49570@gmx.net> Hi Simon, thanks for your reply! I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. Basically, the first sentence in section 6 of the doc "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." along with another sentence in this section "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... Thanks so far! LF -------- Original-Nachricht -------- > Datum: Mon, 15 Oct 2012 22:17:59 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > Hi Lars, > The geometry is described in the document geometry.tex, I have added > links at the end of the user's wiki page > http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > coordinates 0,0,0 of your volume is the isocenter, the point with > coordinate 0,0 in projection images is the intersection of your flat > panel with the line going through the x-ray source and the isocenter. > The image origin is defined by ITK as the center of the pixel with > index 0 in memory (first pixel in memory). > I hope this helps, > Simon > > On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > wrote: > > Hello, > > > > I have questions concerning the FirstReconstruction example: > > Using the rtk::RayEllipsoidIntersectionImageFilter and > rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are > packed in the form of an image stack. The geometry of the projections is > described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the > images' metrics are described by the image stack itself (spacing, size and > ORIGIN). > > > > How should I interpret the origin? As far as I could find out by minor > modifications of the example, the origin of the projeciton image stack plays > a role (if I change it to 0,0,0, and retain constantImageSource2's origin > at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does > the origin of the image stack matter? Isn't the origin of a single > projection fully defined by the corresponding entry in the > rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the > offset from the detector central axis crossing point)? Am I right that the > effective origin of a single projection image emerges basically from the > detector (x/y of origin of image stack) and from consecutive application of > the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, > e.g. caused by gravity, wouldn't be simulatable. > > > > Morever, which point exactly does the image origin (x/y components) of > the projection stack describe? Is it the outer corner of the projection or > the center of the first voxel (as in DICOM). The size of a projection in the > example is 256.0x256.0 units. However, the stack's origin is at > -127.0,-127.0. If the origin should refer to the center of the first projection > pixel, it should be essentially -127.5,-127.5, right? > > > > Sorry for the detailed questions, I just would like to understand how > RTK is working. > > > > Thanks a lot! > > > > LF > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Tue Oct 16 04:23:17 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 16 Oct 2012 10:23:17 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121016080343.49570@gmx.net> References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: I agree, geometry is irritating! I'm sorry my comments were part of this irritation... It seemed obvious to me that the origin and the direction in itk::Image has to be accounted for but I'll add a comment in the header to make it clearer. Bear in mind that this on-going work so feel free to suggest improvements and clarifications. Regarding geometry conversion, we had done a work with my colleagues from the Universit? Catholique de Louvain to convert their geometry parameterization to RTK parameterization using Maxima. That allowed us to spare some hours spent on deriving the correct formulas... Would you be interested in the script file? Simon On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars wrote: > Hi Simon, > > thanks for your reply! > > I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > Basically, the first sentence in section 6 of the doc > "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." > along with another sentence in this section > "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." > irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. > > My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > Thanks so far! > > LF > > -------- Original-Nachricht -------- >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 >> Von: Simon Rit >> An: Lars Friedrich Lars >> CC: rtk-users at openrtk.org >> Betreff: Re: [Rtk-users] FirstReconstruction example > >> Hi Lars, >> The geometry is described in the document geometry.tex, I have added >> links at the end of the user's wiki page >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with >> coordinates 0,0,0 of your volume is the isocenter, the point with >> coordinate 0,0 in projection images is the intersection of your flat >> panel with the line going through the x-ray source and the isocenter. >> The image origin is defined by ITK as the center of the pixel with >> index 0 in memory (first pixel in memory). >> I hope this helps, >> Simon >> >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars >> wrote: >> > Hello, >> > >> > I have questions concerning the FirstReconstruction example: >> > Using the rtk::RayEllipsoidIntersectionImageFilter and >> rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are >> packed in the form of an image stack. The geometry of the projections is >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the >> images' metrics are described by the image stack itself (spacing, size and >> ORIGIN). >> > >> > How should I interpret the origin? As far as I could find out by minor >> modifications of the example, the origin of the projeciton image stack plays >> a role (if I change it to 0,0,0, and retain constantImageSource2's origin >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does >> the origin of the image stack matter? Isn't the origin of a single >> projection fully defined by the corresponding entry in the >> rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the >> offset from the detector central axis crossing point)? Am I right that the >> effective origin of a single projection image emerges basically from the >> detector (x/y of origin of image stack) and from consecutive application of >> the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, >> e.g. caused by gravity, wouldn't be simulatable. >> > >> > Morever, which point exactly does the image origin (x/y components) of >> the projection stack describe? Is it the outer corner of the projection or >> the center of the first voxel (as in DICOM). The size of a projection in the >> example is 256.0x256.0 units. However, the stack's origin is at >> -127.0,-127.0. If the origin should refer to the center of the first projection >> pixel, it should be essentially -127.5,-127.5, right? >> > >> > Sorry for the detailed questions, I just would like to understand how >> RTK is working. >> > >> > Thanks a lot! >> > >> > LF >> > _______________________________________________ >> > Rtk-users mailing list >> > Rtk-users at openrtk.org >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:55:04 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:55:04 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: <20121016085504.78840@gmx.net> Hi, thanks!! Yep, I would be very interested in the script since I would like to try first whether my geometry is generally a no go for the FDK-based approaches in RTK (which I cannot exclude at the moment), before shaping the code and implementing C++-based converters. Lars -------- Original-Nachricht -------- > Datum: Tue, 16 Oct 2012 10:23:17 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > I agree, geometry is irritating! I'm sorry my comments were part of > this irritation... It seemed obvious to me that the origin and the > direction in itk::Image has to be accounted for but I'll add a comment > in the header to make it clearer. Bear in mind that this on-going work > so feel free to suggest improvements and clarifications. > > Regarding geometry conversion, we had done a work with my colleagues > from the Universit? Catholique de Louvain to convert their geometry > parameterization to RTK parameterization using Maxima. That allowed us > to spare some hours spent on deriving the correct formulas... Would > you be interested in the script file? > > Simon > > On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars > wrote: > > Hi Simon, > > > > thanks for your reply! > > > > I read the geometry-doc and played around with > rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > > Basically, the first sentence in section 6 of the doc > > "This class is meant to define a set of 2D projection images, acquired > with a at panel along a circular trajectory, around a 3D tomography." > > along with another sentence in this section > > "9 parameters are used per projection to define the position of the > source and the detector relatively to the fixed coordinate system." > > irritated me a bit. I thought that the 3DCircGeom's task is, in addition > to defining the source position, to define the position and orientation of > the 2D projection images, and the 3DCircGeom is defined in the IEC WCS > (relates to it). I did not expect essential projection image metrics except > dimension (pixel size) and spacing (because image size in physical units is > not part of 3DCircGeom) having any influence on the position and orientation > of it, since this is already defined with the 3DCircGeom object. > > > > My issue at the moment is simply that I have source position, detector > position and detector row/column vectors defined in IEC WCS for each > projection, and have to convert it somehow into your projection geometry format + > (and that's news for me) adjust the image origin of the projection stack. > Unfortunately, my geometry is not really a standard circular one (as in case > of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > > > Thanks so far! > > > > LF > > > > -------- Original-Nachricht -------- > >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 > >> Von: Simon Rit > >> An: Lars Friedrich Lars > >> CC: rtk-users at openrtk.org > >> Betreff: Re: [Rtk-users] FirstReconstruction example > > > >> Hi Lars, > >> The geometry is described in the document geometry.tex, I have added > >> links at the end of the user's wiki page > >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > >> coordinates 0,0,0 of your volume is the isocenter, the point with > >> coordinate 0,0 in projection images is the intersection of your flat > >> panel with the line going through the x-ray source and the isocenter. > >> The image origin is defined by ITK as the center of the pixel with > >> index 0 in memory (first pixel in memory). > >> I hope this helps, > >> Simon > >> > >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > >> wrote: > >> > Hello, > >> > > >> > I have questions concerning the FirstReconstruction example: > >> > Using the rtk::RayEllipsoidIntersectionImageFilter and > >> rtk::ConstantImageSource artificial projections of an ellipsoid are > generated which are > >> packed in the form of an image stack. The geometry of the projections > is > >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, > the > >> images' metrics are described by the image stack itself (spacing, size > and > >> ORIGIN). > >> > > >> > How should I interpret the origin? As far as I could find out by > minor > >> modifications of the example, the origin of the projeciton image stack > plays > >> a role (if I change it to 0,0,0, and retain constantImageSource2's > origin > >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why > does > >> the origin of the image stack matter? Isn't the origin of a single > >> projection fully defined by the corresponding entry in the > >> rtk::ThreeDCircularProjectionGeometry object (I thought the > projOffsetX,projOffsetY args define the > >> offset from the detector central axis crossing point)? Am I right that > the > >> effective origin of a single projection image emerges basically from > the > >> detector (x/y of origin of image stack) and from consecutive > application of > >> the projOffsetX,projOffsetY args? Otherwise, deviating detector > positions, > >> e.g. caused by gravity, wouldn't be simulatable. > >> > > >> > Morever, which point exactly does the image origin (x/y components) > of > >> the projection stack describe? Is it the outer corner of the projection > or > >> the center of the first voxel (as in DICOM). The size of a projection > in the > >> example is 256.0x256.0 units. However, the stack's origin is at > >> -127.0,-127.0. If the origin should refer to the center of the first > projection > >> pixel, it should be essentially -127.5,-127.5, right? > >> > > >> > Sorry for the detailed questions, I just would like to understand how > >> RTK is working. > >> > > >> > Thanks a lot! > >> > > >> > LF > >> > _______________________________________________ > >> > Rtk-users mailing list > >> > Rtk-users at openrtk.org > >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Wed Oct 17 08:56:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 14:56:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> Message-ID: Hi Marta, Yes still ITK 3.20, see instructions here: http://wiki.openrtk.org/index.php/RTK/Users. I fixed the linux error, a commit of 2 days ago was causing it. I don't, however, understand some of your windows errors. It seems that it does not understand the ggo files with enum variables although this has been working on Windows and Linux so far. A potential explanation would be that you have installed an old version of gengetopt on your computer? Maybe you can send me your CMakeCache.txt to help me fixing it? You mentioned a problem with getopt.h in your first email but I did not see it in the log. There is also a linking problem with Cuda that your CMakeCache.txt might help me to understand. Thanks, Simon On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni wrote: > Hi! > sorry that it took soo long to answer. > For windows: > compiler is Visual Studio Express 2008 and we are using Windows 7 (see > log_windows attached) > > For Linux: > I downloaded the latest version from here: https://github.com/SimonRit/RTK > and tried to compile against ITK 3.20 (should I try with ITK4?) > Got over the usual nvcc error, but still could not compile unfortunately > (see log_linux attached) > > thanks a lot > Marta > > On 12 October 2012 11:19, Simon Rit wrote: >> >> Hi Marta, >> Thanks for the feedback. Yes, we would be interested in knowing what >> are the problems with getopt.h. Could you send us more information >> (logs, Windows version, compiler, ...)? >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> merge the latest version of Plastimatch cmake files with rtk. Could >> you update your RTK repository and give it another try? >> A simple Shepp Logan reconstruction example is available here >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> Good luck, >> Simon >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> wrote: >> > Dear Simon and David, >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> > into >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a >> > look >> > at IRTK. >> > >> > Now, problem is that we were not able to compile it neither on windows >> > nor >> > linux (arch distrib). >> > >> > For windows, main issues were related to the windows version of getopt >> > which >> > generate syntax error (Marco can provide you a log file, if you'd like). >> > >> > For linux, I had cuda problem. In particular, although correctly >> > configured, >> > I am stuck with this: >> > [ 7%] Building NVCC (Device) object >> > >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> > surface, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:100: error: there are no arguments to >> > '__surf1Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadc1' must be available >> > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', >> > G++ >> > will accept your code, but allowing the use of an undeclared name is >> > deprecated) >> > /usr/include/surface_functions.h:101: error: there are no arguments to >> > '__surf1Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreads1' must be available >> > /usr/include/surface_functions.h:102: error: there are no arguments to >> > '__surf1Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu1' must be available >> > /usr/include/surface_functions.h:103: error: there are no arguments to >> > '__surf1Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu2' must be available >> > /usr/include/surface_functions.h:104: error: there are no arguments to >> > '__surf1Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu4' must be available >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:460: error: there are no arguments to >> > '__surf2Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadc1' must be available >> > /usr/include/surface_functions.h:461: error: there are no arguments to >> > '__surf2Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreads1' must be available >> > /usr/include/surface_functions.h:462: error: there are no arguments to >> > '__surf2Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu1' must be available >> > /usr/include/surface_functions.h:463: error: there are no arguments to >> > '__surf2Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu2' must be available >> > /usr/include/surface_functions.h:464: error: there are no arguments to >> > '__surf2Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu4' must be available >> > CMake Error at >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> > (message): >> > Error generating file >> > >> > >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > >> > >> > make[2]: *** >> > >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> > Error 1 >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> > make: *** [all] Error 2 >> > >> > I remember having the same issue in plastimatch some time ago (it is due >> > to >> > cuda version) and James added some -fpermissive to fix the issue. >> > >> > But anyhow, can you please guide us through a compilation to make it >> > work >> > and test it on the new projections? >> > >> > thanks a lot >> > Best Regards, >> > Marta Peroni >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:18:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:18:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> Message-ID: The other linux compile errors have been fixed, they were caused by the recent gcc that you seem to be using. Sorry for this hassle, we do not have tested all possible combinations of gccs yet... >From your CMakeCache.txt, it seems that you have gengetopt installed here: C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe A way to solve this would be to remove it from the Windows path so that cmake doesn't use it because gengetopt code has been copied in RTK and will be compiled automatically if it's not in the path. In the future, we should check on gengetopt version and compile it automatically if the system version is too old. I have opened a bug: http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 This should fix the gengetopt enum errors but I still have to figure out the linking problem if it's still here. It's strange that it does not show up on my windows box... Simon On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni wrote: > Hi Simon! > that fixed the error thanks :) But I am afraid I have another one.... > (log_linux attached hed). > I also send you the CMakeCache.txt, but I am afraid your intuition might be > right... > For windows, where do you get the gengeopt? just to make sure we are > up-to-date > thanks a lot > Marta > > > On 17 October 2012 14:56, Simon Rit wrote: >> >> Hi Marta, >> >> Yes still ITK 3.20, see instructions here: >> http://wiki.openrtk.org/index.php/RTK/Users. >> I fixed the linux error, a commit of 2 days ago was causing it. >> I don't, however, understand some of your windows errors. It seems >> that it does not understand the ggo files with enum variables although >> this has been working on Windows and Linux so far. A potential >> explanation would be that you have installed an old version of >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> to help me fixing it? You mentioned a problem with getopt.h in your >> first email but I did not see it in the log. >> There is also a linking problem with Cuda that your CMakeCache.txt >> might help me to understand. >> Thanks, >> Simon >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> wrote: >> > Hi! >> > sorry that it took soo long to answer. >> > For windows: >> > compiler is Visual Studio Express 2008 and we are using Windows 7 (see >> > log_windows attached) >> > >> > For Linux: >> > I downloaded the latest version from here: >> > https://github.com/SimonRit/RTK >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> > Got over the usual nvcc error, but still could not compile unfortunately >> > (see log_linux attached) >> > >> > thanks a lot >> > Marta >> > >> > On 12 October 2012 11:19, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> are the problems with getopt.h. Could you send us more information >> >> (logs, Windows version, compiler, ...)? >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> you update your RTK repository and give it another try? >> >> A simple Shepp Logan reconstruction example is available here >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> Good luck, >> >> Simon >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> wrote: >> >> > Dear Simon and David, >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> >> > into >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had >> >> > a >> >> > look >> >> > at IRTK. >> >> > >> >> > Now, problem is that we were not able to compile it neither on >> >> > windows >> >> > nor >> >> > linux (arch distrib). >> >> > >> >> > For windows, main issues were related to the windows version of >> >> > getopt >> >> > which >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> > like). >> >> > >> >> > For linux, I had cuda problem. In particular, although correctly >> >> > configured, >> >> > I am stuck with this: >> >> > [ 7%] Building NVCC (Device) object >> >> > >> >> > >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:100: error: there are no arguments >> >> > to >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadc1' must be available >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> > '-fpermissive', >> >> > G++ >> >> > will accept your code, but allowing the use of an undeclared name is >> >> > deprecated) >> >> > /usr/include/surface_functions.h:101: error: there are no arguments >> >> > to >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreads1' must be available >> >> > /usr/include/surface_functions.h:102: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu1' must be available >> >> > /usr/include/surface_functions.h:103: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu2' must be available >> >> > /usr/include/surface_functions.h:104: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu4' must be available >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:460: error: there are no arguments >> >> > to >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadc1' must be available >> >> > /usr/include/surface_functions.h:461: error: there are no arguments >> >> > to >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreads1' must be available >> >> > /usr/include/surface_functions.h:462: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu1' must be available >> >> > /usr/include/surface_functions.h:463: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu2' must be available >> >> > /usr/include/surface_functions.h:464: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu4' must be available >> >> > CMake Error at >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> > (message): >> >> > Error generating file >> >> > >> >> > >> >> > >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > >> >> > >> >> > make[2]: *** >> >> > >> >> > >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> > Error 1 >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> > make: *** [all] Error 2 >> >> > >> >> > I remember having the same issue in plastimatch some time ago (it is >> >> > due >> >> > to >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> > >> >> > But anyhow, can you please guide us through a compilation to make it >> >> > work >> >> > and test it on the new projections? >> >> > >> >> > thanks a lot >> >> > Best Regards, >> >> > Marta Peroni >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Wed Oct 17 10:25:52 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Wed, 17 Oct 2012 16:25:52 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... Message-ID: <20121017142552.78880@gmx.net> Hi Simon, we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? Thank you. p From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:44:08 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:44:08 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... In-Reply-To: <20121017142552.78880@gmx.net> References: <20121017142552.78880@gmx.net> Message-ID: Hi, Yes, this is intentional. FDK requires more than matrices to compute, e.g., the angular gaps (http://www.openrtk.org/Doxygen/classrtk_1_1ThreeDCircularProjectionGeometry.html#ae821fb8a5d01b6dd947fc5f8e54cd676). Just search in the code for where the geometry object is used and you'll understand. What you describe is a rtk::ThreeDCircularProjectionGeometry so you are going to lose more time doing a new geometry file than learning how to use rtk::ThreeDCircularProjectionGeometry. If you give us some details and/or an example, we can help you doing the conversion. The parameters should be very intuitive. Simon On Wed, Oct 17, 2012 at 4:25 PM, Lars Friedrich Lars wrote: > Hi Simon, > > we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? > > Thank you. > > p > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Thu Oct 18 05:45:23 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 18 Oct 2012 11:45:23 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> <9115_1350483574_q9HEJWrs014386_CAF0oig0JumNrvzkF28RBGqCi0hRfZuG4OBDTMyyHZptNOZL5dQ@mail.gmail.com> Message-ID: Marta, Sorry, while we were working on compiling RTK for you there has been some other commits that may have caused the problem. Could you give it another try now? It should be fixed according to the dashboard: http://my.cdash.org/index.php?project=RTK Simon On Wed, Oct 17, 2012 at 4:37 PM, Marta Peroni wrote: > Hi Simon! > don't worry, I'm glad I can be useful for testing... > yet another gcc issue I believe: > [ 73%] Building C object > applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/rtkbackprojections_ggo.c.o > Linking CXX executable ../../bin/rtkbackprojections > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaFDKBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaFDKBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaFDKBackProjectionImageFilter::CudaFDKBackProjectionImageFilter()' > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaBackProjectionImageFilter::CudaBackProjectionImageFilter()' > collect2: error: ld returned 1 exit status > make[2]: *** [bin/rtkbackprojections] Error 1 > make[1]: *** > [applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/all] > Error 2 > > make: *** [all] Error 2 > > > I'll let you know very soon about the windows thing...I remember that we > tried to compile without installing gengetopt and it was not compiling it > automatically. Let me give it another shot... > Marta > > On 17 October 2012 16:18, Simon Rit wrote: >> >> The other linux compile errors have been fixed, they were caused by >> the recent gcc that you seem to be using. Sorry for this hassle, we do >> not have tested all possible combinations of gccs yet... >> >> From your CMakeCache.txt, it seems that you have gengetopt installed here: >> C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe >> A way to solve this would be to remove it from the Windows path so >> that cmake doesn't use it because gengetopt code has been copied in >> RTK and will be compiled automatically if it's not in the path. In the >> future, we should check on gengetopt version and compile it >> automatically if the system version is too old. I have opened a bug: >> http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 >> This should fix the gengetopt enum errors but I still have to figure >> out the linking problem if it's still here. It's strange that it does >> not show up on my windows box... >> >> Simon >> >> On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni >> wrote: >> > Hi Simon! >> > that fixed the error thanks :) But I am afraid I have another one.... >> > (log_linux attached hed). >> > I also send you the CMakeCache.txt, but I am afraid your intuition might >> > be >> > right... >> > For windows, where do you get the gengeopt? just to make sure we are >> > up-to-date >> > thanks a lot >> > Marta >> > >> > >> > On 17 October 2012 14:56, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> >> >> Yes still ITK 3.20, see instructions here: >> >> http://wiki.openrtk.org/index.php/RTK/Users. >> >> I fixed the linux error, a commit of 2 days ago was causing it. >> >> I don't, however, understand some of your windows errors. It seems >> >> that it does not understand the ggo files with enum variables although >> >> this has been working on Windows and Linux so far. A potential >> >> explanation would be that you have installed an old version of >> >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> >> to help me fixing it? You mentioned a problem with getopt.h in your >> >> first email but I did not see it in the log. >> >> There is also a linking problem with Cuda that your CMakeCache.txt >> >> might help me to understand. >> >> Thanks, >> >> Simon >> >> >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> >> >> wrote: >> >> > Hi! >> >> > sorry that it took soo long to answer. >> >> > For windows: >> >> > compiler is Visual Studio Express 2008 and we are using Windows 7 >> >> > (see >> >> > log_windows attached) >> >> > >> >> > For Linux: >> >> > I downloaded the latest version from here: >> >> > https://github.com/SimonRit/RTK >> >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> >> > Got over the usual nvcc error, but still could not compile >> >> > unfortunately >> >> > (see log_linux attached) >> >> > >> >> > thanks a lot >> >> > Marta >> >> > >> >> > On 12 October 2012 11:19, Simon Rit >> >> > wrote: >> >> >> >> >> >> Hi Marta, >> >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> >> are the problems with getopt.h. Could you send us more information >> >> >> (logs, Windows version, compiler, ...)? >> >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> >> you update your RTK repository and give it another try? >> >> >> A simple Shepp Logan reconstruction example is available here >> >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> >> Good luck, >> >> >> Simon >> >> >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> >> wrote: >> >> >> > Dear Simon and David, >> >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are >> >> >> > looking >> >> >> > into >> >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we >> >> >> > had >> >> >> > a >> >> >> > look >> >> >> > at IRTK. >> >> >> > >> >> >> > Now, problem is that we were not able to compile it neither on >> >> >> > windows >> >> >> > nor >> >> >> > linux (arch distrib). >> >> >> > >> >> >> > For windows, main issues were related to the windows version of >> >> >> > getopt >> >> >> > which >> >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> >> > like). >> >> >> > >> >> >> > For linux, I had cuda problem. In particular, although correctly >> >> >> > configured, >> >> >> > I am stuck with this: >> >> >> > [ 7%] Building NVCC (Device) object >> >> >> > >> >> >> > >> >> >> > >> >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:100: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> >> > '-fpermissive', >> >> >> > G++ >> >> >> > will accept your code, but allowing the use of an undeclared name >> >> >> > is >> >> >> > deprecated) >> >> >> > /usr/include/surface_functions.h:101: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:102: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:103: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:104: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu4' must be available >> >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:460: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:461: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:462: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:463: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:464: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu4' must be available >> >> >> > CMake Error at >> >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> >> > (message): >> >> >> > Error generating file >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > >> >> >> > >> >> >> > make[2]: *** >> >> >> > >> >> >> > >> >> >> > >> >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> >> > Error 1 >> >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> >> > make: *** [all] Error 2 >> >> >> > >> >> >> > I remember having the same issue in plastimatch some time ago (it >> >> >> > is >> >> >> > due >> >> >> > to >> >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> >> > >> >> >> > But anyhow, can you please guide us through a compilation to make >> >> >> > it >> >> >> > work >> >> >> > and test it on the new projections? >> >> >> > >> >> >> > thanks a lot >> >> >> > Best Regards, >> >> >> > Marta Peroni >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > >> >> >> > ******************************************************************* >> >> >> > Marta Peroni, PhD >> >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> >> > >> >> >> > contacts: >> >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> >> > mobile: +393488202136 (IT) >> >> >> > office: +39 02 2399 9022 >> >> >> > >> >> >> > >> >> >> > ******************************************************************** >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From hsieandy at gmail.com Tue Oct 23 08:48:32 2012 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 23 Oct 2012 23:48:32 +1100 Subject: [Rtk-users] RTK calculating attenuation from Varian projection Message-ID: Hi Simon, I was looking at "rtkVarianObiRawImageFilter.h", and realized that the attenuation is calculated from the projection image simply via a negative transformation (1-Intensity/HND_MaxIntensity). Is it usually the way this is done, and is there any reason for doing this? I would have thought attenuation should be calculated from intensity via logarithm (since I=I_0 exp(-mu x)). Thanks!! Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 23 12:16:07 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 23 Oct 2012 18:16:07 +0200 Subject: [Rtk-users] RTK calculating attenuation from Varian projection In-Reply-To: References: Message-ID: Hi Andy, Yes you're right, I have actually noticed recently that but I have not worked a lot on Varian images because we don't have a Varian CBCT in Lyon. I only had a sub-sampled acquisition from Greg of a Catphan that I used to roughly check the geometry. As far as I can remember, when I wrote this piece of code, I tried to use the same code as Plastimatch but I could well have done it wrongly. I'm actually waiting for a new complete Catphan acquisition from Greg to correct for this but if you already have a patch to suggest or a set of images to send, feel free to do it. Thanks, Simon On Tue, Oct 23, 2012 at 2:48 PM, Andy Shieh wrote: > Hi Simon, > > I was looking at "rtkVarianObiRawImageFilter.h", and realized that the > attenuation is calculated from the projection image simply via a negative > transformation (1-Intensity/HND_MaxIntensity). > Is it usually the way this is done, and is there any reason for doing this? > I would have thought attenuation should be calculated from intensity via > logarithm (since I=I_0 exp(-mu x)). > Thanks!! > > Cheers, > Andy > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From croow at yahoo.com Tue Oct 23 19:57:12 2012 From: croow at yahoo.com (M Miller) Date: Tue, 23 Oct 2012 16:57:12 -0700 (PDT) Subject: [Rtk-users] Reconstruct from projections; Starter tips Message-ID: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> I'm new to RTK and I'd like to reconstruct some projections into a volume. So far I've only been able to get an "InvalidRequestedRegionError", but I'd like to describe my steps with the hope that someone can point out what I've done wrong. I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample programs seem to work fine as I can successfully walk through the FDK SheppLogan example. My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, covering 360deg of rotation. The center of rotation is 65.93mm from the xray source, and the detector is 870.86mm from the source. The detector is 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. ? I create a geometry file: "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 --sdd=870.86 --sid=65.93" ? Attempt to reconstruct: "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml --path=d:\ct_projections\test\ --regexp=tif$ --output=d:\ct_projections\rtkfdk.mha --divisions=2" ? Output: >Regular expression matches 3143 file(s) >Reading geometry information from d:\ct_projections\geo.xml... >Reconstructing and writing... ExceptionObject caught with writer->Update() > >itk::InvalidRequestedRegionError (0000000000009FED10) >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) throw(class itk::InvalidRequestedRegionError)" >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx >Line: 397 >Description: Requested region is (at least partially) outside the largest possible region. ? I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( reader->Update() )" with just "reader->Update()", otherwise there is no debug information. The "lowmem" switch is required to keep ITK from crashing, which I think is an unrelated problem. I use "divisions=2" because plastimatch would crash for me without specifying something similar. Setting the "hardware" switch to either cpu or cuda produces the same error. The client machine has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. ? Is there any extra information necessary or anything that needs clarification? How can I use RTK to reconstruct a volume, if possible? ? Thanks Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Oct 24 04:27:13 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 24 Oct 2012 10:27:13 +0200 Subject: [Rtk-users] Reconstruct from projections; Starter tips In-Reply-To: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> References: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> Message-ID: Hi Micah, You did not do a mistake, you have successfully hit a bug. The truth is that I haven't used the divisions option in a very long time... This should now be fixed https://github.com/SimonRit/RTK/commit/10f8e1b0a5f6b69c943d04513135856968e3e62b and I have added an automated test to avoid future inconveniences https://github.com/SimonRit/RTK/commit/0932e38ad73d8e7214adda5103ced38c7b2754d0 Thanks for the report and keep us a posted. By the way, I have not done a lot of work with tif inputs so you might have to modify the tif conversion from raw to attenuation https://github.com/SimonRit/RTK/blob/master/code/rtkTiffLookupTableImageFilter.h Good luck! Simon On Wed, Oct 24, 2012 at 1:57 AM, M Miller wrote: > I'm new to RTK and I'd like to reconstruct some projections into a volume. > So far I've only been able to get an "InvalidRequestedRegionError", but I'd > like to describe my steps with the hope that someone can point out what > I've done wrong. > > I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample > programs seem to work fine as I can successfully walk through the FDK > SheppLogan example. > > My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, > covering 360deg of rotation. The center of rotation is 65.93mm from the > xray source, and the detector is 870.86mm from the source. The detector is > 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. > > I create a geometry file: > "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 > --sdd=870.86 --sid=65.93" > > Attempt to reconstruct: > "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml > --path=d:\ct_projections\test\ --regexp=tif$ > --output=d:\ct_projections\rtkfdk.mha --divisions=2" > > Output: > >Regular expression matches 3143 file(s) > >Reading geometry information from d:\ct_projections\geo.xml... > >Reconstructing and writing... ExceptionObject caught with writer->Update() > > > >itk::InvalidRequestedRegionError (0000000000009FED10) > >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) > throw(class itk::InvalidRequestedRegionError)" > >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx > >Line: 397 > >Description: Requested region is (at least partially) outside the largest > possible region. > > I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( > reader->Update() )" with just "reader->Update()", otherwise there is no > debug information. > > The "lowmem" switch is required to keep ITK from crashing, which I think > is an unrelated problem. I use "divisions=2" because plastimatch would > crash for me without specifying something similar. Setting the "hardware" > switch to either cpu or cuda produces the same error. The client machine > has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. > > Is there any extra information necessary or anything that needs > clarification? > How can I use RTK to reconstruct a volume, if possible? > > Thanks > Micah > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 12 05:19:16 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 12 Oct 2012 11:19:16 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: Message-ID: Hi Marta, Thanks for the feedback. Yes, we would be interested in knowing what are the problems with getopt.h. Could you send us more information (logs, Windows version, compiler, ...)? Regarding Cuda, this is a bit of a weird problem. I have tried to merge the latest version of Plastimatch cmake files with rtk. Could you update your RTK repository and give it another try? A simple Shepp Logan reconstruction example is available here http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are available here http://wiki.openrtk.org/index.php/RTK/Users. Good luck, Simon On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni wrote: > Dear Simon and David, > was a pleasure to meet you at MICCAI. As I mentioned, we are looking into > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a look > at IRTK. > > Now, problem is that we were not able to compile it neither on windows nor > linux (arch distrib). > > For windows, main issues were related to the windows version of getopt which > generate syntax error (Marco can provide you a log file, if you'd like). > > For linux, I had cuda problem. In particular, although correctly configured, > I am stuck with this: > [ 7%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, > surface, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:100: error: there are no arguments to > '__surf1Dreadc1' that depend on a template parameter, so a declaration of > '__surf1Dreadc1' must be available > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', G++ > will accept your code, but allowing the use of an undeclared name is > deprecated) > /usr/include/surface_functions.h:101: error: there are no arguments to > '__surf1Dreads1' that depend on a template parameter, so a declaration of > '__surf1Dreads1' must be available > /usr/include/surface_functions.h:102: error: there are no arguments to > '__surf1Dreadu1' that depend on a template parameter, so a declaration of > '__surf1Dreadu1' must be available > /usr/include/surface_functions.h:103: error: there are no arguments to > '__surf1Dreadu2' that depend on a template parameter, so a declaration of > '__surf1Dreadu2' must be available > /usr/include/surface_functions.h:104: error: there are no arguments to > '__surf1Dreadu4' that depend on a template parameter, so a declaration of > '__surf1Dreadu4' must be available > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, > surface, int, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:460: error: there are no arguments to > '__surf2Dreadc1' that depend on a template parameter, so a declaration of > '__surf2Dreadc1' must be available > /usr/include/surface_functions.h:461: error: there are no arguments to > '__surf2Dreads1' that depend on a template parameter, so a declaration of > '__surf2Dreads1' must be available > /usr/include/surface_functions.h:462: error: there are no arguments to > '__surf2Dreadu1' that depend on a template parameter, so a declaration of > '__surf2Dreadu1' must be available > /usr/include/surface_functions.h:463: error: there are no arguments to > '__surf2Dreadu2' that depend on a template parameter, so a declaration of > '__surf2Dreadu2' must be available > /usr/include/surface_functions.h:464: error: there are no arguments to > '__surf2Dreadu4' that depend on a template parameter, so a declaration of > '__surf2Dreadu4' must be available > CMake Error at > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 (message): > Error generating file > > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > > make[2]: *** > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] > Error 1 > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 > make: *** [all] Error 2 > > I remember having the same issue in plastimatch some time ago (it is due to > cuda version) and James added some -fpermissive to fix the issue. > > But anyhow, can you please guide us through a compilation to make it work > and test it on the new projections? > > thanks a lot > Best Regards, > Marta Peroni > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Mon Oct 15 13:53:13 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Mon, 15 Oct 2012 19:53:13 +0200 Subject: [Rtk-users] FirstReconstruction example Message-ID: <20121015175313.49610@gmx.net> Hello, I have questions concerning the FirstReconstruction example: Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? Sorry for the detailed questions, I just would like to understand how RTK is working. Thanks a lot! LF From simon.rit at creatis.insa-lyon.fr Mon Oct 15 16:17:59 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 15 Oct 2012 22:17:59 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121015175313.49610@gmx.net> References: <20121015175313.49610@gmx.net> Message-ID: Hi Lars, The geometry is described in the document geometry.tex, I have added links at the end of the user's wiki page http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with coordinates 0,0,0 of your volume is the isocenter, the point with coordinate 0,0 in projection images is the intersection of your flat panel with the line going through the x-ray source and the isocenter. The image origin is defined by ITK as the center of the pixel with index 0 in memory (first pixel in memory). I hope this helps, Simon On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars wrote: > Hello, > > I have questions concerning the FirstReconstruction example: > Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). > > How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. > > Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? > > Sorry for the detailed questions, I just would like to understand how RTK is working. > > Thanks a lot! > > LF > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:03:43 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:03:43 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> Message-ID: <20121016080343.49570@gmx.net> Hi Simon, thanks for your reply! I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. Basically, the first sentence in section 6 of the doc "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." along with another sentence in this section "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... Thanks so far! LF -------- Original-Nachricht -------- > Datum: Mon, 15 Oct 2012 22:17:59 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > Hi Lars, > The geometry is described in the document geometry.tex, I have added > links at the end of the user's wiki page > http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > coordinates 0,0,0 of your volume is the isocenter, the point with > coordinate 0,0 in projection images is the intersection of your flat > panel with the line going through the x-ray source and the isocenter. > The image origin is defined by ITK as the center of the pixel with > index 0 in memory (first pixel in memory). > I hope this helps, > Simon > > On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > wrote: > > Hello, > > > > I have questions concerning the FirstReconstruction example: > > Using the rtk::RayEllipsoidIntersectionImageFilter and > rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are > packed in the form of an image stack. The geometry of the projections is > described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the > images' metrics are described by the image stack itself (spacing, size and > ORIGIN). > > > > How should I interpret the origin? As far as I could find out by minor > modifications of the example, the origin of the projeciton image stack plays > a role (if I change it to 0,0,0, and retain constantImageSource2's origin > at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does > the origin of the image stack matter? Isn't the origin of a single > projection fully defined by the corresponding entry in the > rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the > offset from the detector central axis crossing point)? Am I right that the > effective origin of a single projection image emerges basically from the > detector (x/y of origin of image stack) and from consecutive application of > the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, > e.g. caused by gravity, wouldn't be simulatable. > > > > Morever, which point exactly does the image origin (x/y components) of > the projection stack describe? Is it the outer corner of the projection or > the center of the first voxel (as in DICOM). The size of a projection in the > example is 256.0x256.0 units. However, the stack's origin is at > -127.0,-127.0. If the origin should refer to the center of the first projection > pixel, it should be essentially -127.5,-127.5, right? > > > > Sorry for the detailed questions, I just would like to understand how > RTK is working. > > > > Thanks a lot! > > > > LF > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Tue Oct 16 04:23:17 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 16 Oct 2012 10:23:17 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121016080343.49570@gmx.net> References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: I agree, geometry is irritating! I'm sorry my comments were part of this irritation... It seemed obvious to me that the origin and the direction in itk::Image has to be accounted for but I'll add a comment in the header to make it clearer. Bear in mind that this on-going work so feel free to suggest improvements and clarifications. Regarding geometry conversion, we had done a work with my colleagues from the Universit? Catholique de Louvain to convert their geometry parameterization to RTK parameterization using Maxima. That allowed us to spare some hours spent on deriving the correct formulas... Would you be interested in the script file? Simon On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars wrote: > Hi Simon, > > thanks for your reply! > > I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > Basically, the first sentence in section 6 of the doc > "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." > along with another sentence in this section > "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." > irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. > > My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > Thanks so far! > > LF > > -------- Original-Nachricht -------- >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 >> Von: Simon Rit >> An: Lars Friedrich Lars >> CC: rtk-users at openrtk.org >> Betreff: Re: [Rtk-users] FirstReconstruction example > >> Hi Lars, >> The geometry is described in the document geometry.tex, I have added >> links at the end of the user's wiki page >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with >> coordinates 0,0,0 of your volume is the isocenter, the point with >> coordinate 0,0 in projection images is the intersection of your flat >> panel with the line going through the x-ray source and the isocenter. >> The image origin is defined by ITK as the center of the pixel with >> index 0 in memory (first pixel in memory). >> I hope this helps, >> Simon >> >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars >> wrote: >> > Hello, >> > >> > I have questions concerning the FirstReconstruction example: >> > Using the rtk::RayEllipsoidIntersectionImageFilter and >> rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are >> packed in the form of an image stack. The geometry of the projections is >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the >> images' metrics are described by the image stack itself (spacing, size and >> ORIGIN). >> > >> > How should I interpret the origin? As far as I could find out by minor >> modifications of the example, the origin of the projeciton image stack plays >> a role (if I change it to 0,0,0, and retain constantImageSource2's origin >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does >> the origin of the image stack matter? Isn't the origin of a single >> projection fully defined by the corresponding entry in the >> rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the >> offset from the detector central axis crossing point)? Am I right that the >> effective origin of a single projection image emerges basically from the >> detector (x/y of origin of image stack) and from consecutive application of >> the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, >> e.g. caused by gravity, wouldn't be simulatable. >> > >> > Morever, which point exactly does the image origin (x/y components) of >> the projection stack describe? Is it the outer corner of the projection or >> the center of the first voxel (as in DICOM). The size of a projection in the >> example is 256.0x256.0 units. However, the stack's origin is at >> -127.0,-127.0. If the origin should refer to the center of the first projection >> pixel, it should be essentially -127.5,-127.5, right? >> > >> > Sorry for the detailed questions, I just would like to understand how >> RTK is working. >> > >> > Thanks a lot! >> > >> > LF >> > _______________________________________________ >> > Rtk-users mailing list >> > Rtk-users at openrtk.org >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:55:04 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:55:04 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: <20121016085504.78840@gmx.net> Hi, thanks!! Yep, I would be very interested in the script since I would like to try first whether my geometry is generally a no go for the FDK-based approaches in RTK (which I cannot exclude at the moment), before shaping the code and implementing C++-based converters. Lars -------- Original-Nachricht -------- > Datum: Tue, 16 Oct 2012 10:23:17 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > I agree, geometry is irritating! I'm sorry my comments were part of > this irritation... It seemed obvious to me that the origin and the > direction in itk::Image has to be accounted for but I'll add a comment > in the header to make it clearer. Bear in mind that this on-going work > so feel free to suggest improvements and clarifications. > > Regarding geometry conversion, we had done a work with my colleagues > from the Universit? Catholique de Louvain to convert their geometry > parameterization to RTK parameterization using Maxima. That allowed us > to spare some hours spent on deriving the correct formulas... Would > you be interested in the script file? > > Simon > > On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars > wrote: > > Hi Simon, > > > > thanks for your reply! > > > > I read the geometry-doc and played around with > rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > > Basically, the first sentence in section 6 of the doc > > "This class is meant to define a set of 2D projection images, acquired > with a at panel along a circular trajectory, around a 3D tomography." > > along with another sentence in this section > > "9 parameters are used per projection to define the position of the > source and the detector relatively to the fixed coordinate system." > > irritated me a bit. I thought that the 3DCircGeom's task is, in addition > to defining the source position, to define the position and orientation of > the 2D projection images, and the 3DCircGeom is defined in the IEC WCS > (relates to it). I did not expect essential projection image metrics except > dimension (pixel size) and spacing (because image size in physical units is > not part of 3DCircGeom) having any influence on the position and orientation > of it, since this is already defined with the 3DCircGeom object. > > > > My issue at the moment is simply that I have source position, detector > position and detector row/column vectors defined in IEC WCS for each > projection, and have to convert it somehow into your projection geometry format + > (and that's news for me) adjust the image origin of the projection stack. > Unfortunately, my geometry is not really a standard circular one (as in case > of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > > > Thanks so far! > > > > LF > > > > -------- Original-Nachricht -------- > >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 > >> Von: Simon Rit > >> An: Lars Friedrich Lars > >> CC: rtk-users at openrtk.org > >> Betreff: Re: [Rtk-users] FirstReconstruction example > > > >> Hi Lars, > >> The geometry is described in the document geometry.tex, I have added > >> links at the end of the user's wiki page > >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > >> coordinates 0,0,0 of your volume is the isocenter, the point with > >> coordinate 0,0 in projection images is the intersection of your flat > >> panel with the line going through the x-ray source and the isocenter. > >> The image origin is defined by ITK as the center of the pixel with > >> index 0 in memory (first pixel in memory). > >> I hope this helps, > >> Simon > >> > >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > >> wrote: > >> > Hello, > >> > > >> > I have questions concerning the FirstReconstruction example: > >> > Using the rtk::RayEllipsoidIntersectionImageFilter and > >> rtk::ConstantImageSource artificial projections of an ellipsoid are > generated which are > >> packed in the form of an image stack. The geometry of the projections > is > >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, > the > >> images' metrics are described by the image stack itself (spacing, size > and > >> ORIGIN). > >> > > >> > How should I interpret the origin? As far as I could find out by > minor > >> modifications of the example, the origin of the projeciton image stack > plays > >> a role (if I change it to 0,0,0, and retain constantImageSource2's > origin > >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why > does > >> the origin of the image stack matter? Isn't the origin of a single > >> projection fully defined by the corresponding entry in the > >> rtk::ThreeDCircularProjectionGeometry object (I thought the > projOffsetX,projOffsetY args define the > >> offset from the detector central axis crossing point)? Am I right that > the > >> effective origin of a single projection image emerges basically from > the > >> detector (x/y of origin of image stack) and from consecutive > application of > >> the projOffsetX,projOffsetY args? Otherwise, deviating detector > positions, > >> e.g. caused by gravity, wouldn't be simulatable. > >> > > >> > Morever, which point exactly does the image origin (x/y components) > of > >> the projection stack describe? Is it the outer corner of the projection > or > >> the center of the first voxel (as in DICOM). The size of a projection > in the > >> example is 256.0x256.0 units. However, the stack's origin is at > >> -127.0,-127.0. If the origin should refer to the center of the first > projection > >> pixel, it should be essentially -127.5,-127.5, right? > >> > > >> > Sorry for the detailed questions, I just would like to understand how > >> RTK is working. > >> > > >> > Thanks a lot! > >> > > >> > LF > >> > _______________________________________________ > >> > Rtk-users mailing list > >> > Rtk-users at openrtk.org > >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Wed Oct 17 08:56:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 14:56:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> Message-ID: Hi Marta, Yes still ITK 3.20, see instructions here: http://wiki.openrtk.org/index.php/RTK/Users. I fixed the linux error, a commit of 2 days ago was causing it. I don't, however, understand some of your windows errors. It seems that it does not understand the ggo files with enum variables although this has been working on Windows and Linux so far. A potential explanation would be that you have installed an old version of gengetopt on your computer? Maybe you can send me your CMakeCache.txt to help me fixing it? You mentioned a problem with getopt.h in your first email but I did not see it in the log. There is also a linking problem with Cuda that your CMakeCache.txt might help me to understand. Thanks, Simon On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni wrote: > Hi! > sorry that it took soo long to answer. > For windows: > compiler is Visual Studio Express 2008 and we are using Windows 7 (see > log_windows attached) > > For Linux: > I downloaded the latest version from here: https://github.com/SimonRit/RTK > and tried to compile against ITK 3.20 (should I try with ITK4?) > Got over the usual nvcc error, but still could not compile unfortunately > (see log_linux attached) > > thanks a lot > Marta > > On 12 October 2012 11:19, Simon Rit wrote: >> >> Hi Marta, >> Thanks for the feedback. Yes, we would be interested in knowing what >> are the problems with getopt.h. Could you send us more information >> (logs, Windows version, compiler, ...)? >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> merge the latest version of Plastimatch cmake files with rtk. Could >> you update your RTK repository and give it another try? >> A simple Shepp Logan reconstruction example is available here >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> Good luck, >> Simon >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> wrote: >> > Dear Simon and David, >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> > into >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a >> > look >> > at IRTK. >> > >> > Now, problem is that we were not able to compile it neither on windows >> > nor >> > linux (arch distrib). >> > >> > For windows, main issues were related to the windows version of getopt >> > which >> > generate syntax error (Marco can provide you a log file, if you'd like). >> > >> > For linux, I had cuda problem. In particular, although correctly >> > configured, >> > I am stuck with this: >> > [ 7%] Building NVCC (Device) object >> > >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> > surface, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:100: error: there are no arguments to >> > '__surf1Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadc1' must be available >> > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', >> > G++ >> > will accept your code, but allowing the use of an undeclared name is >> > deprecated) >> > /usr/include/surface_functions.h:101: error: there are no arguments to >> > '__surf1Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreads1' must be available >> > /usr/include/surface_functions.h:102: error: there are no arguments to >> > '__surf1Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu1' must be available >> > /usr/include/surface_functions.h:103: error: there are no arguments to >> > '__surf1Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu2' must be available >> > /usr/include/surface_functions.h:104: error: there are no arguments to >> > '__surf1Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu4' must be available >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:460: error: there are no arguments to >> > '__surf2Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadc1' must be available >> > /usr/include/surface_functions.h:461: error: there are no arguments to >> > '__surf2Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreads1' must be available >> > /usr/include/surface_functions.h:462: error: there are no arguments to >> > '__surf2Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu1' must be available >> > /usr/include/surface_functions.h:463: error: there are no arguments to >> > '__surf2Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu2' must be available >> > /usr/include/surface_functions.h:464: error: there are no arguments to >> > '__surf2Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu4' must be available >> > CMake Error at >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> > (message): >> > Error generating file >> > >> > >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > >> > >> > make[2]: *** >> > >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> > Error 1 >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> > make: *** [all] Error 2 >> > >> > I remember having the same issue in plastimatch some time ago (it is due >> > to >> > cuda version) and James added some -fpermissive to fix the issue. >> > >> > But anyhow, can you please guide us through a compilation to make it >> > work >> > and test it on the new projections? >> > >> > thanks a lot >> > Best Regards, >> > Marta Peroni >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:18:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:18:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> Message-ID: The other linux compile errors have been fixed, they were caused by the recent gcc that you seem to be using. Sorry for this hassle, we do not have tested all possible combinations of gccs yet... >From your CMakeCache.txt, it seems that you have gengetopt installed here: C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe A way to solve this would be to remove it from the Windows path so that cmake doesn't use it because gengetopt code has been copied in RTK and will be compiled automatically if it's not in the path. In the future, we should check on gengetopt version and compile it automatically if the system version is too old. I have opened a bug: http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 This should fix the gengetopt enum errors but I still have to figure out the linking problem if it's still here. It's strange that it does not show up on my windows box... Simon On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni wrote: > Hi Simon! > that fixed the error thanks :) But I am afraid I have another one.... > (log_linux attached hed). > I also send you the CMakeCache.txt, but I am afraid your intuition might be > right... > For windows, where do you get the gengeopt? just to make sure we are > up-to-date > thanks a lot > Marta > > > On 17 October 2012 14:56, Simon Rit wrote: >> >> Hi Marta, >> >> Yes still ITK 3.20, see instructions here: >> http://wiki.openrtk.org/index.php/RTK/Users. >> I fixed the linux error, a commit of 2 days ago was causing it. >> I don't, however, understand some of your windows errors. It seems >> that it does not understand the ggo files with enum variables although >> this has been working on Windows and Linux so far. A potential >> explanation would be that you have installed an old version of >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> to help me fixing it? You mentioned a problem with getopt.h in your >> first email but I did not see it in the log. >> There is also a linking problem with Cuda that your CMakeCache.txt >> might help me to understand. >> Thanks, >> Simon >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> wrote: >> > Hi! >> > sorry that it took soo long to answer. >> > For windows: >> > compiler is Visual Studio Express 2008 and we are using Windows 7 (see >> > log_windows attached) >> > >> > For Linux: >> > I downloaded the latest version from here: >> > https://github.com/SimonRit/RTK >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> > Got over the usual nvcc error, but still could not compile unfortunately >> > (see log_linux attached) >> > >> > thanks a lot >> > Marta >> > >> > On 12 October 2012 11:19, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> are the problems with getopt.h. Could you send us more information >> >> (logs, Windows version, compiler, ...)? >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> you update your RTK repository and give it another try? >> >> A simple Shepp Logan reconstruction example is available here >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> Good luck, >> >> Simon >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> wrote: >> >> > Dear Simon and David, >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> >> > into >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had >> >> > a >> >> > look >> >> > at IRTK. >> >> > >> >> > Now, problem is that we were not able to compile it neither on >> >> > windows >> >> > nor >> >> > linux (arch distrib). >> >> > >> >> > For windows, main issues were related to the windows version of >> >> > getopt >> >> > which >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> > like). >> >> > >> >> > For linux, I had cuda problem. In particular, although correctly >> >> > configured, >> >> > I am stuck with this: >> >> > [ 7%] Building NVCC (Device) object >> >> > >> >> > >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:100: error: there are no arguments >> >> > to >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadc1' must be available >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> > '-fpermissive', >> >> > G++ >> >> > will accept your code, but allowing the use of an undeclared name is >> >> > deprecated) >> >> > /usr/include/surface_functions.h:101: error: there are no arguments >> >> > to >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreads1' must be available >> >> > /usr/include/surface_functions.h:102: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu1' must be available >> >> > /usr/include/surface_functions.h:103: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu2' must be available >> >> > /usr/include/surface_functions.h:104: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu4' must be available >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:460: error: there are no arguments >> >> > to >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadc1' must be available >> >> > /usr/include/surface_functions.h:461: error: there are no arguments >> >> > to >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreads1' must be available >> >> > /usr/include/surface_functions.h:462: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu1' must be available >> >> > /usr/include/surface_functions.h:463: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu2' must be available >> >> > /usr/include/surface_functions.h:464: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu4' must be available >> >> > CMake Error at >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> > (message): >> >> > Error generating file >> >> > >> >> > >> >> > >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > >> >> > >> >> > make[2]: *** >> >> > >> >> > >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> > Error 1 >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> > make: *** [all] Error 2 >> >> > >> >> > I remember having the same issue in plastimatch some time ago (it is >> >> > due >> >> > to >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> > >> >> > But anyhow, can you please guide us through a compilation to make it >> >> > work >> >> > and test it on the new projections? >> >> > >> >> > thanks a lot >> >> > Best Regards, >> >> > Marta Peroni >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Wed Oct 17 10:25:52 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Wed, 17 Oct 2012 16:25:52 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... Message-ID: <20121017142552.78880@gmx.net> Hi Simon, we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? Thank you. p From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:44:08 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:44:08 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... In-Reply-To: <20121017142552.78880@gmx.net> References: <20121017142552.78880@gmx.net> Message-ID: Hi, Yes, this is intentional. FDK requires more than matrices to compute, e.g., the angular gaps (http://www.openrtk.org/Doxygen/classrtk_1_1ThreeDCircularProjectionGeometry.html#ae821fb8a5d01b6dd947fc5f8e54cd676). Just search in the code for where the geometry object is used and you'll understand. What you describe is a rtk::ThreeDCircularProjectionGeometry so you are going to lose more time doing a new geometry file than learning how to use rtk::ThreeDCircularProjectionGeometry. If you give us some details and/or an example, we can help you doing the conversion. The parameters should be very intuitive. Simon On Wed, Oct 17, 2012 at 4:25 PM, Lars Friedrich Lars wrote: > Hi Simon, > > we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? > > Thank you. > > p > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Thu Oct 18 05:45:23 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 18 Oct 2012 11:45:23 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> <9115_1350483574_q9HEJWrs014386_CAF0oig0JumNrvzkF28RBGqCi0hRfZuG4OBDTMyyHZptNOZL5dQ@mail.gmail.com> Message-ID: Marta, Sorry, while we were working on compiling RTK for you there has been some other commits that may have caused the problem. Could you give it another try now? It should be fixed according to the dashboard: http://my.cdash.org/index.php?project=RTK Simon On Wed, Oct 17, 2012 at 4:37 PM, Marta Peroni wrote: > Hi Simon! > don't worry, I'm glad I can be useful for testing... > yet another gcc issue I believe: > [ 73%] Building C object > applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/rtkbackprojections_ggo.c.o > Linking CXX executable ../../bin/rtkbackprojections > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaFDKBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaFDKBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaFDKBackProjectionImageFilter::CudaFDKBackProjectionImageFilter()' > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaBackProjectionImageFilter::CudaBackProjectionImageFilter()' > collect2: error: ld returned 1 exit status > make[2]: *** [bin/rtkbackprojections] Error 1 > make[1]: *** > [applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/all] > Error 2 > > make: *** [all] Error 2 > > > I'll let you know very soon about the windows thing...I remember that we > tried to compile without installing gengetopt and it was not compiling it > automatically. Let me give it another shot... > Marta > > On 17 October 2012 16:18, Simon Rit wrote: >> >> The other linux compile errors have been fixed, they were caused by >> the recent gcc that you seem to be using. Sorry for this hassle, we do >> not have tested all possible combinations of gccs yet... >> >> From your CMakeCache.txt, it seems that you have gengetopt installed here: >> C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe >> A way to solve this would be to remove it from the Windows path so >> that cmake doesn't use it because gengetopt code has been copied in >> RTK and will be compiled automatically if it's not in the path. In the >> future, we should check on gengetopt version and compile it >> automatically if the system version is too old. I have opened a bug: >> http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 >> This should fix the gengetopt enum errors but I still have to figure >> out the linking problem if it's still here. It's strange that it does >> not show up on my windows box... >> >> Simon >> >> On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni >> wrote: >> > Hi Simon! >> > that fixed the error thanks :) But I am afraid I have another one.... >> > (log_linux attached hed). >> > I also send you the CMakeCache.txt, but I am afraid your intuition might >> > be >> > right... >> > For windows, where do you get the gengeopt? just to make sure we are >> > up-to-date >> > thanks a lot >> > Marta >> > >> > >> > On 17 October 2012 14:56, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> >> >> Yes still ITK 3.20, see instructions here: >> >> http://wiki.openrtk.org/index.php/RTK/Users. >> >> I fixed the linux error, a commit of 2 days ago was causing it. >> >> I don't, however, understand some of your windows errors. It seems >> >> that it does not understand the ggo files with enum variables although >> >> this has been working on Windows and Linux so far. A potential >> >> explanation would be that you have installed an old version of >> >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> >> to help me fixing it? You mentioned a problem with getopt.h in your >> >> first email but I did not see it in the log. >> >> There is also a linking problem with Cuda that your CMakeCache.txt >> >> might help me to understand. >> >> Thanks, >> >> Simon >> >> >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> >> >> wrote: >> >> > Hi! >> >> > sorry that it took soo long to answer. >> >> > For windows: >> >> > compiler is Visual Studio Express 2008 and we are using Windows 7 >> >> > (see >> >> > log_windows attached) >> >> > >> >> > For Linux: >> >> > I downloaded the latest version from here: >> >> > https://github.com/SimonRit/RTK >> >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> >> > Got over the usual nvcc error, but still could not compile >> >> > unfortunately >> >> > (see log_linux attached) >> >> > >> >> > thanks a lot >> >> > Marta >> >> > >> >> > On 12 October 2012 11:19, Simon Rit >> >> > wrote: >> >> >> >> >> >> Hi Marta, >> >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> >> are the problems with getopt.h. Could you send us more information >> >> >> (logs, Windows version, compiler, ...)? >> >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> >> you update your RTK repository and give it another try? >> >> >> A simple Shepp Logan reconstruction example is available here >> >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> >> Good luck, >> >> >> Simon >> >> >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> >> wrote: >> >> >> > Dear Simon and David, >> >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are >> >> >> > looking >> >> >> > into >> >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we >> >> >> > had >> >> >> > a >> >> >> > look >> >> >> > at IRTK. >> >> >> > >> >> >> > Now, problem is that we were not able to compile it neither on >> >> >> > windows >> >> >> > nor >> >> >> > linux (arch distrib). >> >> >> > >> >> >> > For windows, main issues were related to the windows version of >> >> >> > getopt >> >> >> > which >> >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> >> > like). >> >> >> > >> >> >> > For linux, I had cuda problem. In particular, although correctly >> >> >> > configured, >> >> >> > I am stuck with this: >> >> >> > [ 7%] Building NVCC (Device) object >> >> >> > >> >> >> > >> >> >> > >> >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:100: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> >> > '-fpermissive', >> >> >> > G++ >> >> >> > will accept your code, but allowing the use of an undeclared name >> >> >> > is >> >> >> > deprecated) >> >> >> > /usr/include/surface_functions.h:101: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:102: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:103: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:104: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu4' must be available >> >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:460: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:461: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:462: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:463: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:464: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu4' must be available >> >> >> > CMake Error at >> >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> >> > (message): >> >> >> > Error generating file >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > >> >> >> > >> >> >> > make[2]: *** >> >> >> > >> >> >> > >> >> >> > >> >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> >> > Error 1 >> >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> >> > make: *** [all] Error 2 >> >> >> > >> >> >> > I remember having the same issue in plastimatch some time ago (it >> >> >> > is >> >> >> > due >> >> >> > to >> >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> >> > >> >> >> > But anyhow, can you please guide us through a compilation to make >> >> >> > it >> >> >> > work >> >> >> > and test it on the new projections? >> >> >> > >> >> >> > thanks a lot >> >> >> > Best Regards, >> >> >> > Marta Peroni >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > >> >> >> > ******************************************************************* >> >> >> > Marta Peroni, PhD >> >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> >> > >> >> >> > contacts: >> >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> >> > mobile: +393488202136 (IT) >> >> >> > office: +39 02 2399 9022 >> >> >> > >> >> >> > >> >> >> > ******************************************************************** >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From hsieandy at gmail.com Tue Oct 23 08:48:32 2012 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 23 Oct 2012 23:48:32 +1100 Subject: [Rtk-users] RTK calculating attenuation from Varian projection Message-ID: Hi Simon, I was looking at "rtkVarianObiRawImageFilter.h", and realized that the attenuation is calculated from the projection image simply via a negative transformation (1-Intensity/HND_MaxIntensity). Is it usually the way this is done, and is there any reason for doing this? I would have thought attenuation should be calculated from intensity via logarithm (since I=I_0 exp(-mu x)). Thanks!! Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 23 12:16:07 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 23 Oct 2012 18:16:07 +0200 Subject: [Rtk-users] RTK calculating attenuation from Varian projection In-Reply-To: References: Message-ID: Hi Andy, Yes you're right, I have actually noticed recently that but I have not worked a lot on Varian images because we don't have a Varian CBCT in Lyon. I only had a sub-sampled acquisition from Greg of a Catphan that I used to roughly check the geometry. As far as I can remember, when I wrote this piece of code, I tried to use the same code as Plastimatch but I could well have done it wrongly. I'm actually waiting for a new complete Catphan acquisition from Greg to correct for this but if you already have a patch to suggest or a set of images to send, feel free to do it. Thanks, Simon On Tue, Oct 23, 2012 at 2:48 PM, Andy Shieh wrote: > Hi Simon, > > I was looking at "rtkVarianObiRawImageFilter.h", and realized that the > attenuation is calculated from the projection image simply via a negative > transformation (1-Intensity/HND_MaxIntensity). > Is it usually the way this is done, and is there any reason for doing this? > I would have thought attenuation should be calculated from intensity via > logarithm (since I=I_0 exp(-mu x)). > Thanks!! > > Cheers, > Andy > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From croow at yahoo.com Tue Oct 23 19:57:12 2012 From: croow at yahoo.com (M Miller) Date: Tue, 23 Oct 2012 16:57:12 -0700 (PDT) Subject: [Rtk-users] Reconstruct from projections; Starter tips Message-ID: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> I'm new to RTK and I'd like to reconstruct some projections into a volume. So far I've only been able to get an "InvalidRequestedRegionError", but I'd like to describe my steps with the hope that someone can point out what I've done wrong. I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample programs seem to work fine as I can successfully walk through the FDK SheppLogan example. My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, covering 360deg of rotation. The center of rotation is 65.93mm from the xray source, and the detector is 870.86mm from the source. The detector is 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. ? I create a geometry file: "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 --sdd=870.86 --sid=65.93" ? Attempt to reconstruct: "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml --path=d:\ct_projections\test\ --regexp=tif$ --output=d:\ct_projections\rtkfdk.mha --divisions=2" ? Output: >Regular expression matches 3143 file(s) >Reading geometry information from d:\ct_projections\geo.xml... >Reconstructing and writing... ExceptionObject caught with writer->Update() > >itk::InvalidRequestedRegionError (0000000000009FED10) >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) throw(class itk::InvalidRequestedRegionError)" >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx >Line: 397 >Description: Requested region is (at least partially) outside the largest possible region. ? I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( reader->Update() )" with just "reader->Update()", otherwise there is no debug information. The "lowmem" switch is required to keep ITK from crashing, which I think is an unrelated problem. I use "divisions=2" because plastimatch would crash for me without specifying something similar. Setting the "hardware" switch to either cpu or cuda produces the same error. The client machine has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. ? Is there any extra information necessary or anything that needs clarification? How can I use RTK to reconstruct a volume, if possible? ? Thanks Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Oct 24 04:27:13 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 24 Oct 2012 10:27:13 +0200 Subject: [Rtk-users] Reconstruct from projections; Starter tips In-Reply-To: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> References: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> Message-ID: Hi Micah, You did not do a mistake, you have successfully hit a bug. The truth is that I haven't used the divisions option in a very long time... This should now be fixed https://github.com/SimonRit/RTK/commit/10f8e1b0a5f6b69c943d04513135856968e3e62b and I have added an automated test to avoid future inconveniences https://github.com/SimonRit/RTK/commit/0932e38ad73d8e7214adda5103ced38c7b2754d0 Thanks for the report and keep us a posted. By the way, I have not done a lot of work with tif inputs so you might have to modify the tif conversion from raw to attenuation https://github.com/SimonRit/RTK/blob/master/code/rtkTiffLookupTableImageFilter.h Good luck! Simon On Wed, Oct 24, 2012 at 1:57 AM, M Miller wrote: > I'm new to RTK and I'd like to reconstruct some projections into a volume. > So far I've only been able to get an "InvalidRequestedRegionError", but I'd > like to describe my steps with the hope that someone can point out what > I've done wrong. > > I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample > programs seem to work fine as I can successfully walk through the FDK > SheppLogan example. > > My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, > covering 360deg of rotation. The center of rotation is 65.93mm from the > xray source, and the detector is 870.86mm from the source. The detector is > 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. > > I create a geometry file: > "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 > --sdd=870.86 --sid=65.93" > > Attempt to reconstruct: > "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml > --path=d:\ct_projections\test\ --regexp=tif$ > --output=d:\ct_projections\rtkfdk.mha --divisions=2" > > Output: > >Regular expression matches 3143 file(s) > >Reading geometry information from d:\ct_projections\geo.xml... > >Reconstructing and writing... ExceptionObject caught with writer->Update() > > > >itk::InvalidRequestedRegionError (0000000000009FED10) > >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) > throw(class itk::InvalidRequestedRegionError)" > >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx > >Line: 397 > >Description: Requested region is (at least partially) outside the largest > possible region. > > I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( > reader->Update() )" with just "reader->Update()", otherwise there is no > debug information. > > The "lowmem" switch is required to keep ITK from crashing, which I think > is an unrelated problem. I use "divisions=2" because plastimatch would > crash for me without specifying something similar. Setting the "hardware" > switch to either cpu or cuda produces the same error. The client machine > has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. > > Is there any extra information necessary or anything that needs > clarification? > How can I use RTK to reconstruct a volume, if possible? > > Thanks > Micah > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 12 05:19:16 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 12 Oct 2012 11:19:16 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: Message-ID: Hi Marta, Thanks for the feedback. Yes, we would be interested in knowing what are the problems with getopt.h. Could you send us more information (logs, Windows version, compiler, ...)? Regarding Cuda, this is a bit of a weird problem. I have tried to merge the latest version of Plastimatch cmake files with rtk. Could you update your RTK repository and give it another try? A simple Shepp Logan reconstruction example is available here http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are available here http://wiki.openrtk.org/index.php/RTK/Users. Good luck, Simon On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni wrote: > Dear Simon and David, > was a pleasure to meet you at MICCAI. As I mentioned, we are looking into > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a look > at IRTK. > > Now, problem is that we were not able to compile it neither on windows nor > linux (arch distrib). > > For windows, main issues were related to the windows version of getopt which > generate syntax error (Marco can provide you a log file, if you'd like). > > For linux, I had cuda problem. In particular, although correctly configured, > I am stuck with this: > [ 7%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, > surface, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:100: error: there are no arguments to > '__surf1Dreadc1' that depend on a template parameter, so a declaration of > '__surf1Dreadc1' must be available > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', G++ > will accept your code, but allowing the use of an undeclared name is > deprecated) > /usr/include/surface_functions.h:101: error: there are no arguments to > '__surf1Dreads1' that depend on a template parameter, so a declaration of > '__surf1Dreads1' must be available > /usr/include/surface_functions.h:102: error: there are no arguments to > '__surf1Dreadu1' that depend on a template parameter, so a declaration of > '__surf1Dreadu1' must be available > /usr/include/surface_functions.h:103: error: there are no arguments to > '__surf1Dreadu2' that depend on a template parameter, so a declaration of > '__surf1Dreadu2' must be available > /usr/include/surface_functions.h:104: error: there are no arguments to > '__surf1Dreadu4' that depend on a template parameter, so a declaration of > '__surf1Dreadu4' must be available > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, > surface, int, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:460: error: there are no arguments to > '__surf2Dreadc1' that depend on a template parameter, so a declaration of > '__surf2Dreadc1' must be available > /usr/include/surface_functions.h:461: error: there are no arguments to > '__surf2Dreads1' that depend on a template parameter, so a declaration of > '__surf2Dreads1' must be available > /usr/include/surface_functions.h:462: error: there are no arguments to > '__surf2Dreadu1' that depend on a template parameter, so a declaration of > '__surf2Dreadu1' must be available > /usr/include/surface_functions.h:463: error: there are no arguments to > '__surf2Dreadu2' that depend on a template parameter, so a declaration of > '__surf2Dreadu2' must be available > /usr/include/surface_functions.h:464: error: there are no arguments to > '__surf2Dreadu4' that depend on a template parameter, so a declaration of > '__surf2Dreadu4' must be available > CMake Error at > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 (message): > Error generating file > > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > > make[2]: *** > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] > Error 1 > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 > make: *** [all] Error 2 > > I remember having the same issue in plastimatch some time ago (it is due to > cuda version) and James added some -fpermissive to fix the issue. > > But anyhow, can you please guide us through a compilation to make it work > and test it on the new projections? > > thanks a lot > Best Regards, > Marta Peroni > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Mon Oct 15 13:53:13 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Mon, 15 Oct 2012 19:53:13 +0200 Subject: [Rtk-users] FirstReconstruction example Message-ID: <20121015175313.49610@gmx.net> Hello, I have questions concerning the FirstReconstruction example: Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? Sorry for the detailed questions, I just would like to understand how RTK is working. Thanks a lot! LF From simon.rit at creatis.insa-lyon.fr Mon Oct 15 16:17:59 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 15 Oct 2012 22:17:59 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121015175313.49610@gmx.net> References: <20121015175313.49610@gmx.net> Message-ID: Hi Lars, The geometry is described in the document geometry.tex, I have added links at the end of the user's wiki page http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with coordinates 0,0,0 of your volume is the isocenter, the point with coordinate 0,0 in projection images is the intersection of your flat panel with the line going through the x-ray source and the isocenter. The image origin is defined by ITK as the center of the pixel with index 0 in memory (first pixel in memory). I hope this helps, Simon On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars wrote: > Hello, > > I have questions concerning the FirstReconstruction example: > Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). > > How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. > > Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? > > Sorry for the detailed questions, I just would like to understand how RTK is working. > > Thanks a lot! > > LF > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:03:43 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:03:43 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> Message-ID: <20121016080343.49570@gmx.net> Hi Simon, thanks for your reply! I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. Basically, the first sentence in section 6 of the doc "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." along with another sentence in this section "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... Thanks so far! LF -------- Original-Nachricht -------- > Datum: Mon, 15 Oct 2012 22:17:59 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > Hi Lars, > The geometry is described in the document geometry.tex, I have added > links at the end of the user's wiki page > http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > coordinates 0,0,0 of your volume is the isocenter, the point with > coordinate 0,0 in projection images is the intersection of your flat > panel with the line going through the x-ray source and the isocenter. > The image origin is defined by ITK as the center of the pixel with > index 0 in memory (first pixel in memory). > I hope this helps, > Simon > > On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > wrote: > > Hello, > > > > I have questions concerning the FirstReconstruction example: > > Using the rtk::RayEllipsoidIntersectionImageFilter and > rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are > packed in the form of an image stack. The geometry of the projections is > described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the > images' metrics are described by the image stack itself (spacing, size and > ORIGIN). > > > > How should I interpret the origin? As far as I could find out by minor > modifications of the example, the origin of the projeciton image stack plays > a role (if I change it to 0,0,0, and retain constantImageSource2's origin > at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does > the origin of the image stack matter? Isn't the origin of a single > projection fully defined by the corresponding entry in the > rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the > offset from the detector central axis crossing point)? Am I right that the > effective origin of a single projection image emerges basically from the > detector (x/y of origin of image stack) and from consecutive application of > the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, > e.g. caused by gravity, wouldn't be simulatable. > > > > Morever, which point exactly does the image origin (x/y components) of > the projection stack describe? Is it the outer corner of the projection or > the center of the first voxel (as in DICOM). The size of a projection in the > example is 256.0x256.0 units. However, the stack's origin is at > -127.0,-127.0. If the origin should refer to the center of the first projection > pixel, it should be essentially -127.5,-127.5, right? > > > > Sorry for the detailed questions, I just would like to understand how > RTK is working. > > > > Thanks a lot! > > > > LF > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Tue Oct 16 04:23:17 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 16 Oct 2012 10:23:17 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121016080343.49570@gmx.net> References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: I agree, geometry is irritating! I'm sorry my comments were part of this irritation... It seemed obvious to me that the origin and the direction in itk::Image has to be accounted for but I'll add a comment in the header to make it clearer. Bear in mind that this on-going work so feel free to suggest improvements and clarifications. Regarding geometry conversion, we had done a work with my colleagues from the Universit? Catholique de Louvain to convert their geometry parameterization to RTK parameterization using Maxima. That allowed us to spare some hours spent on deriving the correct formulas... Would you be interested in the script file? Simon On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars wrote: > Hi Simon, > > thanks for your reply! > > I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > Basically, the first sentence in section 6 of the doc > "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." > along with another sentence in this section > "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." > irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. > > My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > Thanks so far! > > LF > > -------- Original-Nachricht -------- >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 >> Von: Simon Rit >> An: Lars Friedrich Lars >> CC: rtk-users at openrtk.org >> Betreff: Re: [Rtk-users] FirstReconstruction example > >> Hi Lars, >> The geometry is described in the document geometry.tex, I have added >> links at the end of the user's wiki page >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with >> coordinates 0,0,0 of your volume is the isocenter, the point with >> coordinate 0,0 in projection images is the intersection of your flat >> panel with the line going through the x-ray source and the isocenter. >> The image origin is defined by ITK as the center of the pixel with >> index 0 in memory (first pixel in memory). >> I hope this helps, >> Simon >> >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars >> wrote: >> > Hello, >> > >> > I have questions concerning the FirstReconstruction example: >> > Using the rtk::RayEllipsoidIntersectionImageFilter and >> rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are >> packed in the form of an image stack. The geometry of the projections is >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the >> images' metrics are described by the image stack itself (spacing, size and >> ORIGIN). >> > >> > How should I interpret the origin? As far as I could find out by minor >> modifications of the example, the origin of the projeciton image stack plays >> a role (if I change it to 0,0,0, and retain constantImageSource2's origin >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does >> the origin of the image stack matter? Isn't the origin of a single >> projection fully defined by the corresponding entry in the >> rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the >> offset from the detector central axis crossing point)? Am I right that the >> effective origin of a single projection image emerges basically from the >> detector (x/y of origin of image stack) and from consecutive application of >> the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, >> e.g. caused by gravity, wouldn't be simulatable. >> > >> > Morever, which point exactly does the image origin (x/y components) of >> the projection stack describe? Is it the outer corner of the projection or >> the center of the first voxel (as in DICOM). The size of a projection in the >> example is 256.0x256.0 units. However, the stack's origin is at >> -127.0,-127.0. If the origin should refer to the center of the first projection >> pixel, it should be essentially -127.5,-127.5, right? >> > >> > Sorry for the detailed questions, I just would like to understand how >> RTK is working. >> > >> > Thanks a lot! >> > >> > LF >> > _______________________________________________ >> > Rtk-users mailing list >> > Rtk-users at openrtk.org >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:55:04 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:55:04 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: <20121016085504.78840@gmx.net> Hi, thanks!! Yep, I would be very interested in the script since I would like to try first whether my geometry is generally a no go for the FDK-based approaches in RTK (which I cannot exclude at the moment), before shaping the code and implementing C++-based converters. Lars -------- Original-Nachricht -------- > Datum: Tue, 16 Oct 2012 10:23:17 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > I agree, geometry is irritating! I'm sorry my comments were part of > this irritation... It seemed obvious to me that the origin and the > direction in itk::Image has to be accounted for but I'll add a comment > in the header to make it clearer. Bear in mind that this on-going work > so feel free to suggest improvements and clarifications. > > Regarding geometry conversion, we had done a work with my colleagues > from the Universit? Catholique de Louvain to convert their geometry > parameterization to RTK parameterization using Maxima. That allowed us > to spare some hours spent on deriving the correct formulas... Would > you be interested in the script file? > > Simon > > On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars > wrote: > > Hi Simon, > > > > thanks for your reply! > > > > I read the geometry-doc and played around with > rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > > Basically, the first sentence in section 6 of the doc > > "This class is meant to define a set of 2D projection images, acquired > with a at panel along a circular trajectory, around a 3D tomography." > > along with another sentence in this section > > "9 parameters are used per projection to define the position of the > source and the detector relatively to the fixed coordinate system." > > irritated me a bit. I thought that the 3DCircGeom's task is, in addition > to defining the source position, to define the position and orientation of > the 2D projection images, and the 3DCircGeom is defined in the IEC WCS > (relates to it). I did not expect essential projection image metrics except > dimension (pixel size) and spacing (because image size in physical units is > not part of 3DCircGeom) having any influence on the position and orientation > of it, since this is already defined with the 3DCircGeom object. > > > > My issue at the moment is simply that I have source position, detector > position and detector row/column vectors defined in IEC WCS for each > projection, and have to convert it somehow into your projection geometry format + > (and that's news for me) adjust the image origin of the projection stack. > Unfortunately, my geometry is not really a standard circular one (as in case > of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > > > Thanks so far! > > > > LF > > > > -------- Original-Nachricht -------- > >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 > >> Von: Simon Rit > >> An: Lars Friedrich Lars > >> CC: rtk-users at openrtk.org > >> Betreff: Re: [Rtk-users] FirstReconstruction example > > > >> Hi Lars, > >> The geometry is described in the document geometry.tex, I have added > >> links at the end of the user's wiki page > >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > >> coordinates 0,0,0 of your volume is the isocenter, the point with > >> coordinate 0,0 in projection images is the intersection of your flat > >> panel with the line going through the x-ray source and the isocenter. > >> The image origin is defined by ITK as the center of the pixel with > >> index 0 in memory (first pixel in memory). > >> I hope this helps, > >> Simon > >> > >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > >> wrote: > >> > Hello, > >> > > >> > I have questions concerning the FirstReconstruction example: > >> > Using the rtk::RayEllipsoidIntersectionImageFilter and > >> rtk::ConstantImageSource artificial projections of an ellipsoid are > generated which are > >> packed in the form of an image stack. The geometry of the projections > is > >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, > the > >> images' metrics are described by the image stack itself (spacing, size > and > >> ORIGIN). > >> > > >> > How should I interpret the origin? As far as I could find out by > minor > >> modifications of the example, the origin of the projeciton image stack > plays > >> a role (if I change it to 0,0,0, and retain constantImageSource2's > origin > >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why > does > >> the origin of the image stack matter? Isn't the origin of a single > >> projection fully defined by the corresponding entry in the > >> rtk::ThreeDCircularProjectionGeometry object (I thought the > projOffsetX,projOffsetY args define the > >> offset from the detector central axis crossing point)? Am I right that > the > >> effective origin of a single projection image emerges basically from > the > >> detector (x/y of origin of image stack) and from consecutive > application of > >> the projOffsetX,projOffsetY args? Otherwise, deviating detector > positions, > >> e.g. caused by gravity, wouldn't be simulatable. > >> > > >> > Morever, which point exactly does the image origin (x/y components) > of > >> the projection stack describe? Is it the outer corner of the projection > or > >> the center of the first voxel (as in DICOM). The size of a projection > in the > >> example is 256.0x256.0 units. However, the stack's origin is at > >> -127.0,-127.0. If the origin should refer to the center of the first > projection > >> pixel, it should be essentially -127.5,-127.5, right? > >> > > >> > Sorry for the detailed questions, I just would like to understand how > >> RTK is working. > >> > > >> > Thanks a lot! > >> > > >> > LF > >> > _______________________________________________ > >> > Rtk-users mailing list > >> > Rtk-users at openrtk.org > >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Wed Oct 17 08:56:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 14:56:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> Message-ID: Hi Marta, Yes still ITK 3.20, see instructions here: http://wiki.openrtk.org/index.php/RTK/Users. I fixed the linux error, a commit of 2 days ago was causing it. I don't, however, understand some of your windows errors. It seems that it does not understand the ggo files with enum variables although this has been working on Windows and Linux so far. A potential explanation would be that you have installed an old version of gengetopt on your computer? Maybe you can send me your CMakeCache.txt to help me fixing it? You mentioned a problem with getopt.h in your first email but I did not see it in the log. There is also a linking problem with Cuda that your CMakeCache.txt might help me to understand. Thanks, Simon On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni wrote: > Hi! > sorry that it took soo long to answer. > For windows: > compiler is Visual Studio Express 2008 and we are using Windows 7 (see > log_windows attached) > > For Linux: > I downloaded the latest version from here: https://github.com/SimonRit/RTK > and tried to compile against ITK 3.20 (should I try with ITK4?) > Got over the usual nvcc error, but still could not compile unfortunately > (see log_linux attached) > > thanks a lot > Marta > > On 12 October 2012 11:19, Simon Rit wrote: >> >> Hi Marta, >> Thanks for the feedback. Yes, we would be interested in knowing what >> are the problems with getopt.h. Could you send us more information >> (logs, Windows version, compiler, ...)? >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> merge the latest version of Plastimatch cmake files with rtk. Could >> you update your RTK repository and give it another try? >> A simple Shepp Logan reconstruction example is available here >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> Good luck, >> Simon >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> wrote: >> > Dear Simon and David, >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> > into >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a >> > look >> > at IRTK. >> > >> > Now, problem is that we were not able to compile it neither on windows >> > nor >> > linux (arch distrib). >> > >> > For windows, main issues were related to the windows version of getopt >> > which >> > generate syntax error (Marco can provide you a log file, if you'd like). >> > >> > For linux, I had cuda problem. In particular, although correctly >> > configured, >> > I am stuck with this: >> > [ 7%] Building NVCC (Device) object >> > >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> > surface, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:100: error: there are no arguments to >> > '__surf1Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadc1' must be available >> > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', >> > G++ >> > will accept your code, but allowing the use of an undeclared name is >> > deprecated) >> > /usr/include/surface_functions.h:101: error: there are no arguments to >> > '__surf1Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreads1' must be available >> > /usr/include/surface_functions.h:102: error: there are no arguments to >> > '__surf1Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu1' must be available >> > /usr/include/surface_functions.h:103: error: there are no arguments to >> > '__surf1Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu2' must be available >> > /usr/include/surface_functions.h:104: error: there are no arguments to >> > '__surf1Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu4' must be available >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:460: error: there are no arguments to >> > '__surf2Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadc1' must be available >> > /usr/include/surface_functions.h:461: error: there are no arguments to >> > '__surf2Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreads1' must be available >> > /usr/include/surface_functions.h:462: error: there are no arguments to >> > '__surf2Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu1' must be available >> > /usr/include/surface_functions.h:463: error: there are no arguments to >> > '__surf2Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu2' must be available >> > /usr/include/surface_functions.h:464: error: there are no arguments to >> > '__surf2Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu4' must be available >> > CMake Error at >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> > (message): >> > Error generating file >> > >> > >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > >> > >> > make[2]: *** >> > >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> > Error 1 >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> > make: *** [all] Error 2 >> > >> > I remember having the same issue in plastimatch some time ago (it is due >> > to >> > cuda version) and James added some -fpermissive to fix the issue. >> > >> > But anyhow, can you please guide us through a compilation to make it >> > work >> > and test it on the new projections? >> > >> > thanks a lot >> > Best Regards, >> > Marta Peroni >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:18:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:18:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> Message-ID: The other linux compile errors have been fixed, they were caused by the recent gcc that you seem to be using. Sorry for this hassle, we do not have tested all possible combinations of gccs yet... >From your CMakeCache.txt, it seems that you have gengetopt installed here: C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe A way to solve this would be to remove it from the Windows path so that cmake doesn't use it because gengetopt code has been copied in RTK and will be compiled automatically if it's not in the path. In the future, we should check on gengetopt version and compile it automatically if the system version is too old. I have opened a bug: http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 This should fix the gengetopt enum errors but I still have to figure out the linking problem if it's still here. It's strange that it does not show up on my windows box... Simon On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni wrote: > Hi Simon! > that fixed the error thanks :) But I am afraid I have another one.... > (log_linux attached hed). > I also send you the CMakeCache.txt, but I am afraid your intuition might be > right... > For windows, where do you get the gengeopt? just to make sure we are > up-to-date > thanks a lot > Marta > > > On 17 October 2012 14:56, Simon Rit wrote: >> >> Hi Marta, >> >> Yes still ITK 3.20, see instructions here: >> http://wiki.openrtk.org/index.php/RTK/Users. >> I fixed the linux error, a commit of 2 days ago was causing it. >> I don't, however, understand some of your windows errors. It seems >> that it does not understand the ggo files with enum variables although >> this has been working on Windows and Linux so far. A potential >> explanation would be that you have installed an old version of >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> to help me fixing it? You mentioned a problem with getopt.h in your >> first email but I did not see it in the log. >> There is also a linking problem with Cuda that your CMakeCache.txt >> might help me to understand. >> Thanks, >> Simon >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> wrote: >> > Hi! >> > sorry that it took soo long to answer. >> > For windows: >> > compiler is Visual Studio Express 2008 and we are using Windows 7 (see >> > log_windows attached) >> > >> > For Linux: >> > I downloaded the latest version from here: >> > https://github.com/SimonRit/RTK >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> > Got over the usual nvcc error, but still could not compile unfortunately >> > (see log_linux attached) >> > >> > thanks a lot >> > Marta >> > >> > On 12 October 2012 11:19, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> are the problems with getopt.h. Could you send us more information >> >> (logs, Windows version, compiler, ...)? >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> you update your RTK repository and give it another try? >> >> A simple Shepp Logan reconstruction example is available here >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> Good luck, >> >> Simon >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> wrote: >> >> > Dear Simon and David, >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> >> > into >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had >> >> > a >> >> > look >> >> > at IRTK. >> >> > >> >> > Now, problem is that we were not able to compile it neither on >> >> > windows >> >> > nor >> >> > linux (arch distrib). >> >> > >> >> > For windows, main issues were related to the windows version of >> >> > getopt >> >> > which >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> > like). >> >> > >> >> > For linux, I had cuda problem. In particular, although correctly >> >> > configured, >> >> > I am stuck with this: >> >> > [ 7%] Building NVCC (Device) object >> >> > >> >> > >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:100: error: there are no arguments >> >> > to >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadc1' must be available >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> > '-fpermissive', >> >> > G++ >> >> > will accept your code, but allowing the use of an undeclared name is >> >> > deprecated) >> >> > /usr/include/surface_functions.h:101: error: there are no arguments >> >> > to >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreads1' must be available >> >> > /usr/include/surface_functions.h:102: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu1' must be available >> >> > /usr/include/surface_functions.h:103: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu2' must be available >> >> > /usr/include/surface_functions.h:104: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu4' must be available >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:460: error: there are no arguments >> >> > to >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadc1' must be available >> >> > /usr/include/surface_functions.h:461: error: there are no arguments >> >> > to >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreads1' must be available >> >> > /usr/include/surface_functions.h:462: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu1' must be available >> >> > /usr/include/surface_functions.h:463: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu2' must be available >> >> > /usr/include/surface_functions.h:464: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu4' must be available >> >> > CMake Error at >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> > (message): >> >> > Error generating file >> >> > >> >> > >> >> > >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > >> >> > >> >> > make[2]: *** >> >> > >> >> > >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> > Error 1 >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> > make: *** [all] Error 2 >> >> > >> >> > I remember having the same issue in plastimatch some time ago (it is >> >> > due >> >> > to >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> > >> >> > But anyhow, can you please guide us through a compilation to make it >> >> > work >> >> > and test it on the new projections? >> >> > >> >> > thanks a lot >> >> > Best Regards, >> >> > Marta Peroni >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Wed Oct 17 10:25:52 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Wed, 17 Oct 2012 16:25:52 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... Message-ID: <20121017142552.78880@gmx.net> Hi Simon, we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? Thank you. p From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:44:08 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:44:08 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... In-Reply-To: <20121017142552.78880@gmx.net> References: <20121017142552.78880@gmx.net> Message-ID: Hi, Yes, this is intentional. FDK requires more than matrices to compute, e.g., the angular gaps (http://www.openrtk.org/Doxygen/classrtk_1_1ThreeDCircularProjectionGeometry.html#ae821fb8a5d01b6dd947fc5f8e54cd676). Just search in the code for where the geometry object is used and you'll understand. What you describe is a rtk::ThreeDCircularProjectionGeometry so you are going to lose more time doing a new geometry file than learning how to use rtk::ThreeDCircularProjectionGeometry. If you give us some details and/or an example, we can help you doing the conversion. The parameters should be very intuitive. Simon On Wed, Oct 17, 2012 at 4:25 PM, Lars Friedrich Lars wrote: > Hi Simon, > > we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? > > Thank you. > > p > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Thu Oct 18 05:45:23 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 18 Oct 2012 11:45:23 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> <9115_1350483574_q9HEJWrs014386_CAF0oig0JumNrvzkF28RBGqCi0hRfZuG4OBDTMyyHZptNOZL5dQ@mail.gmail.com> Message-ID: Marta, Sorry, while we were working on compiling RTK for you there has been some other commits that may have caused the problem. Could you give it another try now? It should be fixed according to the dashboard: http://my.cdash.org/index.php?project=RTK Simon On Wed, Oct 17, 2012 at 4:37 PM, Marta Peroni wrote: > Hi Simon! > don't worry, I'm glad I can be useful for testing... > yet another gcc issue I believe: > [ 73%] Building C object > applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/rtkbackprojections_ggo.c.o > Linking CXX executable ../../bin/rtkbackprojections > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaFDKBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaFDKBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaFDKBackProjectionImageFilter::CudaFDKBackProjectionImageFilter()' > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaBackProjectionImageFilter::CudaBackProjectionImageFilter()' > collect2: error: ld returned 1 exit status > make[2]: *** [bin/rtkbackprojections] Error 1 > make[1]: *** > [applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/all] > Error 2 > > make: *** [all] Error 2 > > > I'll let you know very soon about the windows thing...I remember that we > tried to compile without installing gengetopt and it was not compiling it > automatically. Let me give it another shot... > Marta > > On 17 October 2012 16:18, Simon Rit wrote: >> >> The other linux compile errors have been fixed, they were caused by >> the recent gcc that you seem to be using. Sorry for this hassle, we do >> not have tested all possible combinations of gccs yet... >> >> From your CMakeCache.txt, it seems that you have gengetopt installed here: >> C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe >> A way to solve this would be to remove it from the Windows path so >> that cmake doesn't use it because gengetopt code has been copied in >> RTK and will be compiled automatically if it's not in the path. In the >> future, we should check on gengetopt version and compile it >> automatically if the system version is too old. I have opened a bug: >> http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 >> This should fix the gengetopt enum errors but I still have to figure >> out the linking problem if it's still here. It's strange that it does >> not show up on my windows box... >> >> Simon >> >> On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni >> wrote: >> > Hi Simon! >> > that fixed the error thanks :) But I am afraid I have another one.... >> > (log_linux attached hed). >> > I also send you the CMakeCache.txt, but I am afraid your intuition might >> > be >> > right... >> > For windows, where do you get the gengeopt? just to make sure we are >> > up-to-date >> > thanks a lot >> > Marta >> > >> > >> > On 17 October 2012 14:56, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> >> >> Yes still ITK 3.20, see instructions here: >> >> http://wiki.openrtk.org/index.php/RTK/Users. >> >> I fixed the linux error, a commit of 2 days ago was causing it. >> >> I don't, however, understand some of your windows errors. It seems >> >> that it does not understand the ggo files with enum variables although >> >> this has been working on Windows and Linux so far. A potential >> >> explanation would be that you have installed an old version of >> >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> >> to help me fixing it? You mentioned a problem with getopt.h in your >> >> first email but I did not see it in the log. >> >> There is also a linking problem with Cuda that your CMakeCache.txt >> >> might help me to understand. >> >> Thanks, >> >> Simon >> >> >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> >> >> wrote: >> >> > Hi! >> >> > sorry that it took soo long to answer. >> >> > For windows: >> >> > compiler is Visual Studio Express 2008 and we are using Windows 7 >> >> > (see >> >> > log_windows attached) >> >> > >> >> > For Linux: >> >> > I downloaded the latest version from here: >> >> > https://github.com/SimonRit/RTK >> >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> >> > Got over the usual nvcc error, but still could not compile >> >> > unfortunately >> >> > (see log_linux attached) >> >> > >> >> > thanks a lot >> >> > Marta >> >> > >> >> > On 12 October 2012 11:19, Simon Rit >> >> > wrote: >> >> >> >> >> >> Hi Marta, >> >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> >> are the problems with getopt.h. Could you send us more information >> >> >> (logs, Windows version, compiler, ...)? >> >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> >> you update your RTK repository and give it another try? >> >> >> A simple Shepp Logan reconstruction example is available here >> >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> >> Good luck, >> >> >> Simon >> >> >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> >> wrote: >> >> >> > Dear Simon and David, >> >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are >> >> >> > looking >> >> >> > into >> >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we >> >> >> > had >> >> >> > a >> >> >> > look >> >> >> > at IRTK. >> >> >> > >> >> >> > Now, problem is that we were not able to compile it neither on >> >> >> > windows >> >> >> > nor >> >> >> > linux (arch distrib). >> >> >> > >> >> >> > For windows, main issues were related to the windows version of >> >> >> > getopt >> >> >> > which >> >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> >> > like). >> >> >> > >> >> >> > For linux, I had cuda problem. In particular, although correctly >> >> >> > configured, >> >> >> > I am stuck with this: >> >> >> > [ 7%] Building NVCC (Device) object >> >> >> > >> >> >> > >> >> >> > >> >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:100: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> >> > '-fpermissive', >> >> >> > G++ >> >> >> > will accept your code, but allowing the use of an undeclared name >> >> >> > is >> >> >> > deprecated) >> >> >> > /usr/include/surface_functions.h:101: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:102: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:103: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:104: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu4' must be available >> >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:460: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:461: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:462: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:463: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:464: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu4' must be available >> >> >> > CMake Error at >> >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> >> > (message): >> >> >> > Error generating file >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > >> >> >> > >> >> >> > make[2]: *** >> >> >> > >> >> >> > >> >> >> > >> >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> >> > Error 1 >> >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> >> > make: *** [all] Error 2 >> >> >> > >> >> >> > I remember having the same issue in plastimatch some time ago (it >> >> >> > is >> >> >> > due >> >> >> > to >> >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> >> > >> >> >> > But anyhow, can you please guide us through a compilation to make >> >> >> > it >> >> >> > work >> >> >> > and test it on the new projections? >> >> >> > >> >> >> > thanks a lot >> >> >> > Best Regards, >> >> >> > Marta Peroni >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > >> >> >> > ******************************************************************* >> >> >> > Marta Peroni, PhD >> >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> >> > >> >> >> > contacts: >> >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> >> > mobile: +393488202136 (IT) >> >> >> > office: +39 02 2399 9022 >> >> >> > >> >> >> > >> >> >> > ******************************************************************** >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From hsieandy at gmail.com Tue Oct 23 08:48:32 2012 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 23 Oct 2012 23:48:32 +1100 Subject: [Rtk-users] RTK calculating attenuation from Varian projection Message-ID: Hi Simon, I was looking at "rtkVarianObiRawImageFilter.h", and realized that the attenuation is calculated from the projection image simply via a negative transformation (1-Intensity/HND_MaxIntensity). Is it usually the way this is done, and is there any reason for doing this? I would have thought attenuation should be calculated from intensity via logarithm (since I=I_0 exp(-mu x)). Thanks!! Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 23 12:16:07 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 23 Oct 2012 18:16:07 +0200 Subject: [Rtk-users] RTK calculating attenuation from Varian projection In-Reply-To: References: Message-ID: Hi Andy, Yes you're right, I have actually noticed recently that but I have not worked a lot on Varian images because we don't have a Varian CBCT in Lyon. I only had a sub-sampled acquisition from Greg of a Catphan that I used to roughly check the geometry. As far as I can remember, when I wrote this piece of code, I tried to use the same code as Plastimatch but I could well have done it wrongly. I'm actually waiting for a new complete Catphan acquisition from Greg to correct for this but if you already have a patch to suggest or a set of images to send, feel free to do it. Thanks, Simon On Tue, Oct 23, 2012 at 2:48 PM, Andy Shieh wrote: > Hi Simon, > > I was looking at "rtkVarianObiRawImageFilter.h", and realized that the > attenuation is calculated from the projection image simply via a negative > transformation (1-Intensity/HND_MaxIntensity). > Is it usually the way this is done, and is there any reason for doing this? > I would have thought attenuation should be calculated from intensity via > logarithm (since I=I_0 exp(-mu x)). > Thanks!! > > Cheers, > Andy > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From croow at yahoo.com Tue Oct 23 19:57:12 2012 From: croow at yahoo.com (M Miller) Date: Tue, 23 Oct 2012 16:57:12 -0700 (PDT) Subject: [Rtk-users] Reconstruct from projections; Starter tips Message-ID: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> I'm new to RTK and I'd like to reconstruct some projections into a volume. So far I've only been able to get an "InvalidRequestedRegionError", but I'd like to describe my steps with the hope that someone can point out what I've done wrong. I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample programs seem to work fine as I can successfully walk through the FDK SheppLogan example. My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, covering 360deg of rotation. The center of rotation is 65.93mm from the xray source, and the detector is 870.86mm from the source. The detector is 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. ? I create a geometry file: "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 --sdd=870.86 --sid=65.93" ? Attempt to reconstruct: "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml --path=d:\ct_projections\test\ --regexp=tif$ --output=d:\ct_projections\rtkfdk.mha --divisions=2" ? Output: >Regular expression matches 3143 file(s) >Reading geometry information from d:\ct_projections\geo.xml... >Reconstructing and writing... ExceptionObject caught with writer->Update() > >itk::InvalidRequestedRegionError (0000000000009FED10) >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) throw(class itk::InvalidRequestedRegionError)" >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx >Line: 397 >Description: Requested region is (at least partially) outside the largest possible region. ? I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( reader->Update() )" with just "reader->Update()", otherwise there is no debug information. The "lowmem" switch is required to keep ITK from crashing, which I think is an unrelated problem. I use "divisions=2" because plastimatch would crash for me without specifying something similar. Setting the "hardware" switch to either cpu or cuda produces the same error. The client machine has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. ? Is there any extra information necessary or anything that needs clarification? How can I use RTK to reconstruct a volume, if possible? ? Thanks Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Oct 24 04:27:13 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 24 Oct 2012 10:27:13 +0200 Subject: [Rtk-users] Reconstruct from projections; Starter tips In-Reply-To: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> References: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> Message-ID: Hi Micah, You did not do a mistake, you have successfully hit a bug. The truth is that I haven't used the divisions option in a very long time... This should now be fixed https://github.com/SimonRit/RTK/commit/10f8e1b0a5f6b69c943d04513135856968e3e62b and I have added an automated test to avoid future inconveniences https://github.com/SimonRit/RTK/commit/0932e38ad73d8e7214adda5103ced38c7b2754d0 Thanks for the report and keep us a posted. By the way, I have not done a lot of work with tif inputs so you might have to modify the tif conversion from raw to attenuation https://github.com/SimonRit/RTK/blob/master/code/rtkTiffLookupTableImageFilter.h Good luck! Simon On Wed, Oct 24, 2012 at 1:57 AM, M Miller wrote: > I'm new to RTK and I'd like to reconstruct some projections into a volume. > So far I've only been able to get an "InvalidRequestedRegionError", but I'd > like to describe my steps with the hope that someone can point out what > I've done wrong. > > I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample > programs seem to work fine as I can successfully walk through the FDK > SheppLogan example. > > My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, > covering 360deg of rotation. The center of rotation is 65.93mm from the > xray source, and the detector is 870.86mm from the source. The detector is > 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. > > I create a geometry file: > "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 > --sdd=870.86 --sid=65.93" > > Attempt to reconstruct: > "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml > --path=d:\ct_projections\test\ --regexp=tif$ > --output=d:\ct_projections\rtkfdk.mha --divisions=2" > > Output: > >Regular expression matches 3143 file(s) > >Reading geometry information from d:\ct_projections\geo.xml... > >Reconstructing and writing... ExceptionObject caught with writer->Update() > > > >itk::InvalidRequestedRegionError (0000000000009FED10) > >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) > throw(class itk::InvalidRequestedRegionError)" > >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx > >Line: 397 > >Description: Requested region is (at least partially) outside the largest > possible region. > > I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( > reader->Update() )" with just "reader->Update()", otherwise there is no > debug information. > > The "lowmem" switch is required to keep ITK from crashing, which I think > is an unrelated problem. I use "divisions=2" because plastimatch would > crash for me without specifying something similar. Setting the "hardware" > switch to either cpu or cuda produces the same error. The client machine > has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. > > Is there any extra information necessary or anything that needs > clarification? > How can I use RTK to reconstruct a volume, if possible? > > Thanks > Micah > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 12 05:19:16 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 12 Oct 2012 11:19:16 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: Message-ID: Hi Marta, Thanks for the feedback. Yes, we would be interested in knowing what are the problems with getopt.h. Could you send us more information (logs, Windows version, compiler, ...)? Regarding Cuda, this is a bit of a weird problem. I have tried to merge the latest version of Plastimatch cmake files with rtk. Could you update your RTK repository and give it another try? A simple Shepp Logan reconstruction example is available here http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are available here http://wiki.openrtk.org/index.php/RTK/Users. Good luck, Simon On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni wrote: > Dear Simon and David, > was a pleasure to meet you at MICCAI. As I mentioned, we are looking into > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a look > at IRTK. > > Now, problem is that we were not able to compile it neither on windows nor > linux (arch distrib). > > For windows, main issues were related to the windows version of getopt which > generate syntax error (Marco can provide you a log file, if you'd like). > > For linux, I had cuda problem. In particular, although correctly configured, > I am stuck with this: > [ 7%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, > surface, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:100: error: there are no arguments to > '__surf1Dreadc1' that depend on a template parameter, so a declaration of > '__surf1Dreadc1' must be available > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', G++ > will accept your code, but allowing the use of an undeclared name is > deprecated) > /usr/include/surface_functions.h:101: error: there are no arguments to > '__surf1Dreads1' that depend on a template parameter, so a declaration of > '__surf1Dreads1' must be available > /usr/include/surface_functions.h:102: error: there are no arguments to > '__surf1Dreadu1' that depend on a template parameter, so a declaration of > '__surf1Dreadu1' must be available > /usr/include/surface_functions.h:103: error: there are no arguments to > '__surf1Dreadu2' that depend on a template parameter, so a declaration of > '__surf1Dreadu2' must be available > /usr/include/surface_functions.h:104: error: there are no arguments to > '__surf1Dreadu4' that depend on a template parameter, so a declaration of > '__surf1Dreadu4' must be available > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, > surface, int, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:460: error: there are no arguments to > '__surf2Dreadc1' that depend on a template parameter, so a declaration of > '__surf2Dreadc1' must be available > /usr/include/surface_functions.h:461: error: there are no arguments to > '__surf2Dreads1' that depend on a template parameter, so a declaration of > '__surf2Dreads1' must be available > /usr/include/surface_functions.h:462: error: there are no arguments to > '__surf2Dreadu1' that depend on a template parameter, so a declaration of > '__surf2Dreadu1' must be available > /usr/include/surface_functions.h:463: error: there are no arguments to > '__surf2Dreadu2' that depend on a template parameter, so a declaration of > '__surf2Dreadu2' must be available > /usr/include/surface_functions.h:464: error: there are no arguments to > '__surf2Dreadu4' that depend on a template parameter, so a declaration of > '__surf2Dreadu4' must be available > CMake Error at > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 (message): > Error generating file > > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > > make[2]: *** > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] > Error 1 > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 > make: *** [all] Error 2 > > I remember having the same issue in plastimatch some time ago (it is due to > cuda version) and James added some -fpermissive to fix the issue. > > But anyhow, can you please guide us through a compilation to make it work > and test it on the new projections? > > thanks a lot > Best Regards, > Marta Peroni > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Mon Oct 15 13:53:13 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Mon, 15 Oct 2012 19:53:13 +0200 Subject: [Rtk-users] FirstReconstruction example Message-ID: <20121015175313.49610@gmx.net> Hello, I have questions concerning the FirstReconstruction example: Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? Sorry for the detailed questions, I just would like to understand how RTK is working. Thanks a lot! LF From simon.rit at creatis.insa-lyon.fr Mon Oct 15 16:17:59 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 15 Oct 2012 22:17:59 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121015175313.49610@gmx.net> References: <20121015175313.49610@gmx.net> Message-ID: Hi Lars, The geometry is described in the document geometry.tex, I have added links at the end of the user's wiki page http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with coordinates 0,0,0 of your volume is the isocenter, the point with coordinate 0,0 in projection images is the intersection of your flat panel with the line going through the x-ray source and the isocenter. The image origin is defined by ITK as the center of the pixel with index 0 in memory (first pixel in memory). I hope this helps, Simon On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars wrote: > Hello, > > I have questions concerning the FirstReconstruction example: > Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). > > How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. > > Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? > > Sorry for the detailed questions, I just would like to understand how RTK is working. > > Thanks a lot! > > LF > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:03:43 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:03:43 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> Message-ID: <20121016080343.49570@gmx.net> Hi Simon, thanks for your reply! I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. Basically, the first sentence in section 6 of the doc "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." along with another sentence in this section "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... Thanks so far! LF -------- Original-Nachricht -------- > Datum: Mon, 15 Oct 2012 22:17:59 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > Hi Lars, > The geometry is described in the document geometry.tex, I have added > links at the end of the user's wiki page > http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > coordinates 0,0,0 of your volume is the isocenter, the point with > coordinate 0,0 in projection images is the intersection of your flat > panel with the line going through the x-ray source and the isocenter. > The image origin is defined by ITK as the center of the pixel with > index 0 in memory (first pixel in memory). > I hope this helps, > Simon > > On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > wrote: > > Hello, > > > > I have questions concerning the FirstReconstruction example: > > Using the rtk::RayEllipsoidIntersectionImageFilter and > rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are > packed in the form of an image stack. The geometry of the projections is > described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the > images' metrics are described by the image stack itself (spacing, size and > ORIGIN). > > > > How should I interpret the origin? As far as I could find out by minor > modifications of the example, the origin of the projeciton image stack plays > a role (if I change it to 0,0,0, and retain constantImageSource2's origin > at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does > the origin of the image stack matter? Isn't the origin of a single > projection fully defined by the corresponding entry in the > rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the > offset from the detector central axis crossing point)? Am I right that the > effective origin of a single projection image emerges basically from the > detector (x/y of origin of image stack) and from consecutive application of > the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, > e.g. caused by gravity, wouldn't be simulatable. > > > > Morever, which point exactly does the image origin (x/y components) of > the projection stack describe? Is it the outer corner of the projection or > the center of the first voxel (as in DICOM). The size of a projection in the > example is 256.0x256.0 units. However, the stack's origin is at > -127.0,-127.0. If the origin should refer to the center of the first projection > pixel, it should be essentially -127.5,-127.5, right? > > > > Sorry for the detailed questions, I just would like to understand how > RTK is working. > > > > Thanks a lot! > > > > LF > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Tue Oct 16 04:23:17 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 16 Oct 2012 10:23:17 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121016080343.49570@gmx.net> References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: I agree, geometry is irritating! I'm sorry my comments were part of this irritation... It seemed obvious to me that the origin and the direction in itk::Image has to be accounted for but I'll add a comment in the header to make it clearer. Bear in mind that this on-going work so feel free to suggest improvements and clarifications. Regarding geometry conversion, we had done a work with my colleagues from the Universit? Catholique de Louvain to convert their geometry parameterization to RTK parameterization using Maxima. That allowed us to spare some hours spent on deriving the correct formulas... Would you be interested in the script file? Simon On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars wrote: > Hi Simon, > > thanks for your reply! > > I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > Basically, the first sentence in section 6 of the doc > "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." > along with another sentence in this section > "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." > irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. > > My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > Thanks so far! > > LF > > -------- Original-Nachricht -------- >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 >> Von: Simon Rit >> An: Lars Friedrich Lars >> CC: rtk-users at openrtk.org >> Betreff: Re: [Rtk-users] FirstReconstruction example > >> Hi Lars, >> The geometry is described in the document geometry.tex, I have added >> links at the end of the user's wiki page >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with >> coordinates 0,0,0 of your volume is the isocenter, the point with >> coordinate 0,0 in projection images is the intersection of your flat >> panel with the line going through the x-ray source and the isocenter. >> The image origin is defined by ITK as the center of the pixel with >> index 0 in memory (first pixel in memory). >> I hope this helps, >> Simon >> >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars >> wrote: >> > Hello, >> > >> > I have questions concerning the FirstReconstruction example: >> > Using the rtk::RayEllipsoidIntersectionImageFilter and >> rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are >> packed in the form of an image stack. The geometry of the projections is >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the >> images' metrics are described by the image stack itself (spacing, size and >> ORIGIN). >> > >> > How should I interpret the origin? As far as I could find out by minor >> modifications of the example, the origin of the projeciton image stack plays >> a role (if I change it to 0,0,0, and retain constantImageSource2's origin >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does >> the origin of the image stack matter? Isn't the origin of a single >> projection fully defined by the corresponding entry in the >> rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the >> offset from the detector central axis crossing point)? Am I right that the >> effective origin of a single projection image emerges basically from the >> detector (x/y of origin of image stack) and from consecutive application of >> the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, >> e.g. caused by gravity, wouldn't be simulatable. >> > >> > Morever, which point exactly does the image origin (x/y components) of >> the projection stack describe? Is it the outer corner of the projection or >> the center of the first voxel (as in DICOM). The size of a projection in the >> example is 256.0x256.0 units. However, the stack's origin is at >> -127.0,-127.0. If the origin should refer to the center of the first projection >> pixel, it should be essentially -127.5,-127.5, right? >> > >> > Sorry for the detailed questions, I just would like to understand how >> RTK is working. >> > >> > Thanks a lot! >> > >> > LF >> > _______________________________________________ >> > Rtk-users mailing list >> > Rtk-users at openrtk.org >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:55:04 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:55:04 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: <20121016085504.78840@gmx.net> Hi, thanks!! Yep, I would be very interested in the script since I would like to try first whether my geometry is generally a no go for the FDK-based approaches in RTK (which I cannot exclude at the moment), before shaping the code and implementing C++-based converters. Lars -------- Original-Nachricht -------- > Datum: Tue, 16 Oct 2012 10:23:17 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > I agree, geometry is irritating! I'm sorry my comments were part of > this irritation... It seemed obvious to me that the origin and the > direction in itk::Image has to be accounted for but I'll add a comment > in the header to make it clearer. Bear in mind that this on-going work > so feel free to suggest improvements and clarifications. > > Regarding geometry conversion, we had done a work with my colleagues > from the Universit? Catholique de Louvain to convert their geometry > parameterization to RTK parameterization using Maxima. That allowed us > to spare some hours spent on deriving the correct formulas... Would > you be interested in the script file? > > Simon > > On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars > wrote: > > Hi Simon, > > > > thanks for your reply! > > > > I read the geometry-doc and played around with > rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > > Basically, the first sentence in section 6 of the doc > > "This class is meant to define a set of 2D projection images, acquired > with a at panel along a circular trajectory, around a 3D tomography." > > along with another sentence in this section > > "9 parameters are used per projection to define the position of the > source and the detector relatively to the fixed coordinate system." > > irritated me a bit. I thought that the 3DCircGeom's task is, in addition > to defining the source position, to define the position and orientation of > the 2D projection images, and the 3DCircGeom is defined in the IEC WCS > (relates to it). I did not expect essential projection image metrics except > dimension (pixel size) and spacing (because image size in physical units is > not part of 3DCircGeom) having any influence on the position and orientation > of it, since this is already defined with the 3DCircGeom object. > > > > My issue at the moment is simply that I have source position, detector > position and detector row/column vectors defined in IEC WCS for each > projection, and have to convert it somehow into your projection geometry format + > (and that's news for me) adjust the image origin of the projection stack. > Unfortunately, my geometry is not really a standard circular one (as in case > of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > > > Thanks so far! > > > > LF > > > > -------- Original-Nachricht -------- > >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 > >> Von: Simon Rit > >> An: Lars Friedrich Lars > >> CC: rtk-users at openrtk.org > >> Betreff: Re: [Rtk-users] FirstReconstruction example > > > >> Hi Lars, > >> The geometry is described in the document geometry.tex, I have added > >> links at the end of the user's wiki page > >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > >> coordinates 0,0,0 of your volume is the isocenter, the point with > >> coordinate 0,0 in projection images is the intersection of your flat > >> panel with the line going through the x-ray source and the isocenter. > >> The image origin is defined by ITK as the center of the pixel with > >> index 0 in memory (first pixel in memory). > >> I hope this helps, > >> Simon > >> > >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > >> wrote: > >> > Hello, > >> > > >> > I have questions concerning the FirstReconstruction example: > >> > Using the rtk::RayEllipsoidIntersectionImageFilter and > >> rtk::ConstantImageSource artificial projections of an ellipsoid are > generated which are > >> packed in the form of an image stack. The geometry of the projections > is > >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, > the > >> images' metrics are described by the image stack itself (spacing, size > and > >> ORIGIN). > >> > > >> > How should I interpret the origin? As far as I could find out by > minor > >> modifications of the example, the origin of the projeciton image stack > plays > >> a role (if I change it to 0,0,0, and retain constantImageSource2's > origin > >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why > does > >> the origin of the image stack matter? Isn't the origin of a single > >> projection fully defined by the corresponding entry in the > >> rtk::ThreeDCircularProjectionGeometry object (I thought the > projOffsetX,projOffsetY args define the > >> offset from the detector central axis crossing point)? Am I right that > the > >> effective origin of a single projection image emerges basically from > the > >> detector (x/y of origin of image stack) and from consecutive > application of > >> the projOffsetX,projOffsetY args? Otherwise, deviating detector > positions, > >> e.g. caused by gravity, wouldn't be simulatable. > >> > > >> > Morever, which point exactly does the image origin (x/y components) > of > >> the projection stack describe? Is it the outer corner of the projection > or > >> the center of the first voxel (as in DICOM). The size of a projection > in the > >> example is 256.0x256.0 units. However, the stack's origin is at > >> -127.0,-127.0. If the origin should refer to the center of the first > projection > >> pixel, it should be essentially -127.5,-127.5, right? > >> > > >> > Sorry for the detailed questions, I just would like to understand how > >> RTK is working. > >> > > >> > Thanks a lot! > >> > > >> > LF > >> > _______________________________________________ > >> > Rtk-users mailing list > >> > Rtk-users at openrtk.org > >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Wed Oct 17 08:56:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 14:56:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> Message-ID: Hi Marta, Yes still ITK 3.20, see instructions here: http://wiki.openrtk.org/index.php/RTK/Users. I fixed the linux error, a commit of 2 days ago was causing it. I don't, however, understand some of your windows errors. It seems that it does not understand the ggo files with enum variables although this has been working on Windows and Linux so far. A potential explanation would be that you have installed an old version of gengetopt on your computer? Maybe you can send me your CMakeCache.txt to help me fixing it? You mentioned a problem with getopt.h in your first email but I did not see it in the log. There is also a linking problem with Cuda that your CMakeCache.txt might help me to understand. Thanks, Simon On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni wrote: > Hi! > sorry that it took soo long to answer. > For windows: > compiler is Visual Studio Express 2008 and we are using Windows 7 (see > log_windows attached) > > For Linux: > I downloaded the latest version from here: https://github.com/SimonRit/RTK > and tried to compile against ITK 3.20 (should I try with ITK4?) > Got over the usual nvcc error, but still could not compile unfortunately > (see log_linux attached) > > thanks a lot > Marta > > On 12 October 2012 11:19, Simon Rit wrote: >> >> Hi Marta, >> Thanks for the feedback. Yes, we would be interested in knowing what >> are the problems with getopt.h. Could you send us more information >> (logs, Windows version, compiler, ...)? >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> merge the latest version of Plastimatch cmake files with rtk. Could >> you update your RTK repository and give it another try? >> A simple Shepp Logan reconstruction example is available here >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> Good luck, >> Simon >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> wrote: >> > Dear Simon and David, >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> > into >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a >> > look >> > at IRTK. >> > >> > Now, problem is that we were not able to compile it neither on windows >> > nor >> > linux (arch distrib). >> > >> > For windows, main issues were related to the windows version of getopt >> > which >> > generate syntax error (Marco can provide you a log file, if you'd like). >> > >> > For linux, I had cuda problem. In particular, although correctly >> > configured, >> > I am stuck with this: >> > [ 7%] Building NVCC (Device) object >> > >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> > surface, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:100: error: there are no arguments to >> > '__surf1Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadc1' must be available >> > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', >> > G++ >> > will accept your code, but allowing the use of an undeclared name is >> > deprecated) >> > /usr/include/surface_functions.h:101: error: there are no arguments to >> > '__surf1Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreads1' must be available >> > /usr/include/surface_functions.h:102: error: there are no arguments to >> > '__surf1Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu1' must be available >> > /usr/include/surface_functions.h:103: error: there are no arguments to >> > '__surf1Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu2' must be available >> > /usr/include/surface_functions.h:104: error: there are no arguments to >> > '__surf1Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu4' must be available >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:460: error: there are no arguments to >> > '__surf2Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadc1' must be available >> > /usr/include/surface_functions.h:461: error: there are no arguments to >> > '__surf2Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreads1' must be available >> > /usr/include/surface_functions.h:462: error: there are no arguments to >> > '__surf2Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu1' must be available >> > /usr/include/surface_functions.h:463: error: there are no arguments to >> > '__surf2Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu2' must be available >> > /usr/include/surface_functions.h:464: error: there are no arguments to >> > '__surf2Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu4' must be available >> > CMake Error at >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> > (message): >> > Error generating file >> > >> > >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > >> > >> > make[2]: *** >> > >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> > Error 1 >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> > make: *** [all] Error 2 >> > >> > I remember having the same issue in plastimatch some time ago (it is due >> > to >> > cuda version) and James added some -fpermissive to fix the issue. >> > >> > But anyhow, can you please guide us through a compilation to make it >> > work >> > and test it on the new projections? >> > >> > thanks a lot >> > Best Regards, >> > Marta Peroni >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:18:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:18:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> Message-ID: The other linux compile errors have been fixed, they were caused by the recent gcc that you seem to be using. Sorry for this hassle, we do not have tested all possible combinations of gccs yet... >From your CMakeCache.txt, it seems that you have gengetopt installed here: C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe A way to solve this would be to remove it from the Windows path so that cmake doesn't use it because gengetopt code has been copied in RTK and will be compiled automatically if it's not in the path. In the future, we should check on gengetopt version and compile it automatically if the system version is too old. I have opened a bug: http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 This should fix the gengetopt enum errors but I still have to figure out the linking problem if it's still here. It's strange that it does not show up on my windows box... Simon On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni wrote: > Hi Simon! > that fixed the error thanks :) But I am afraid I have another one.... > (log_linux attached hed). > I also send you the CMakeCache.txt, but I am afraid your intuition might be > right... > For windows, where do you get the gengeopt? just to make sure we are > up-to-date > thanks a lot > Marta > > > On 17 October 2012 14:56, Simon Rit wrote: >> >> Hi Marta, >> >> Yes still ITK 3.20, see instructions here: >> http://wiki.openrtk.org/index.php/RTK/Users. >> I fixed the linux error, a commit of 2 days ago was causing it. >> I don't, however, understand some of your windows errors. It seems >> that it does not understand the ggo files with enum variables although >> this has been working on Windows and Linux so far. A potential >> explanation would be that you have installed an old version of >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> to help me fixing it? You mentioned a problem with getopt.h in your >> first email but I did not see it in the log. >> There is also a linking problem with Cuda that your CMakeCache.txt >> might help me to understand. >> Thanks, >> Simon >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> wrote: >> > Hi! >> > sorry that it took soo long to answer. >> > For windows: >> > compiler is Visual Studio Express 2008 and we are using Windows 7 (see >> > log_windows attached) >> > >> > For Linux: >> > I downloaded the latest version from here: >> > https://github.com/SimonRit/RTK >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> > Got over the usual nvcc error, but still could not compile unfortunately >> > (see log_linux attached) >> > >> > thanks a lot >> > Marta >> > >> > On 12 October 2012 11:19, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> are the problems with getopt.h. Could you send us more information >> >> (logs, Windows version, compiler, ...)? >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> you update your RTK repository and give it another try? >> >> A simple Shepp Logan reconstruction example is available here >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> Good luck, >> >> Simon >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> wrote: >> >> > Dear Simon and David, >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> >> > into >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had >> >> > a >> >> > look >> >> > at IRTK. >> >> > >> >> > Now, problem is that we were not able to compile it neither on >> >> > windows >> >> > nor >> >> > linux (arch distrib). >> >> > >> >> > For windows, main issues were related to the windows version of >> >> > getopt >> >> > which >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> > like). >> >> > >> >> > For linux, I had cuda problem. In particular, although correctly >> >> > configured, >> >> > I am stuck with this: >> >> > [ 7%] Building NVCC (Device) object >> >> > >> >> > >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:100: error: there are no arguments >> >> > to >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadc1' must be available >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> > '-fpermissive', >> >> > G++ >> >> > will accept your code, but allowing the use of an undeclared name is >> >> > deprecated) >> >> > /usr/include/surface_functions.h:101: error: there are no arguments >> >> > to >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreads1' must be available >> >> > /usr/include/surface_functions.h:102: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu1' must be available >> >> > /usr/include/surface_functions.h:103: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu2' must be available >> >> > /usr/include/surface_functions.h:104: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu4' must be available >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:460: error: there are no arguments >> >> > to >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadc1' must be available >> >> > /usr/include/surface_functions.h:461: error: there are no arguments >> >> > to >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreads1' must be available >> >> > /usr/include/surface_functions.h:462: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu1' must be available >> >> > /usr/include/surface_functions.h:463: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu2' must be available >> >> > /usr/include/surface_functions.h:464: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu4' must be available >> >> > CMake Error at >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> > (message): >> >> > Error generating file >> >> > >> >> > >> >> > >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > >> >> > >> >> > make[2]: *** >> >> > >> >> > >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> > Error 1 >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> > make: *** [all] Error 2 >> >> > >> >> > I remember having the same issue in plastimatch some time ago (it is >> >> > due >> >> > to >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> > >> >> > But anyhow, can you please guide us through a compilation to make it >> >> > work >> >> > and test it on the new projections? >> >> > >> >> > thanks a lot >> >> > Best Regards, >> >> > Marta Peroni >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Wed Oct 17 10:25:52 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Wed, 17 Oct 2012 16:25:52 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... Message-ID: <20121017142552.78880@gmx.net> Hi Simon, we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? Thank you. p From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:44:08 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:44:08 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... In-Reply-To: <20121017142552.78880@gmx.net> References: <20121017142552.78880@gmx.net> Message-ID: Hi, Yes, this is intentional. FDK requires more than matrices to compute, e.g., the angular gaps (http://www.openrtk.org/Doxygen/classrtk_1_1ThreeDCircularProjectionGeometry.html#ae821fb8a5d01b6dd947fc5f8e54cd676). Just search in the code for where the geometry object is used and you'll understand. What you describe is a rtk::ThreeDCircularProjectionGeometry so you are going to lose more time doing a new geometry file than learning how to use rtk::ThreeDCircularProjectionGeometry. If you give us some details and/or an example, we can help you doing the conversion. The parameters should be very intuitive. Simon On Wed, Oct 17, 2012 at 4:25 PM, Lars Friedrich Lars wrote: > Hi Simon, > > we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? > > Thank you. > > p > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Thu Oct 18 05:45:23 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 18 Oct 2012 11:45:23 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> <9115_1350483574_q9HEJWrs014386_CAF0oig0JumNrvzkF28RBGqCi0hRfZuG4OBDTMyyHZptNOZL5dQ@mail.gmail.com> Message-ID: Marta, Sorry, while we were working on compiling RTK for you there has been some other commits that may have caused the problem. Could you give it another try now? It should be fixed according to the dashboard: http://my.cdash.org/index.php?project=RTK Simon On Wed, Oct 17, 2012 at 4:37 PM, Marta Peroni wrote: > Hi Simon! > don't worry, I'm glad I can be useful for testing... > yet another gcc issue I believe: > [ 73%] Building C object > applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/rtkbackprojections_ggo.c.o > Linking CXX executable ../../bin/rtkbackprojections > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaFDKBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaFDKBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaFDKBackProjectionImageFilter::CudaFDKBackProjectionImageFilter()' > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaBackProjectionImageFilter::CudaBackProjectionImageFilter()' > collect2: error: ld returned 1 exit status > make[2]: *** [bin/rtkbackprojections] Error 1 > make[1]: *** > [applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/all] > Error 2 > > make: *** [all] Error 2 > > > I'll let you know very soon about the windows thing...I remember that we > tried to compile without installing gengetopt and it was not compiling it > automatically. Let me give it another shot... > Marta > > On 17 October 2012 16:18, Simon Rit wrote: >> >> The other linux compile errors have been fixed, they were caused by >> the recent gcc that you seem to be using. Sorry for this hassle, we do >> not have tested all possible combinations of gccs yet... >> >> From your CMakeCache.txt, it seems that you have gengetopt installed here: >> C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe >> A way to solve this would be to remove it from the Windows path so >> that cmake doesn't use it because gengetopt code has been copied in >> RTK and will be compiled automatically if it's not in the path. In the >> future, we should check on gengetopt version and compile it >> automatically if the system version is too old. I have opened a bug: >> http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 >> This should fix the gengetopt enum errors but I still have to figure >> out the linking problem if it's still here. It's strange that it does >> not show up on my windows box... >> >> Simon >> >> On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni >> wrote: >> > Hi Simon! >> > that fixed the error thanks :) But I am afraid I have another one.... >> > (log_linux attached hed). >> > I also send you the CMakeCache.txt, but I am afraid your intuition might >> > be >> > right... >> > For windows, where do you get the gengeopt? just to make sure we are >> > up-to-date >> > thanks a lot >> > Marta >> > >> > >> > On 17 October 2012 14:56, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> >> >> Yes still ITK 3.20, see instructions here: >> >> http://wiki.openrtk.org/index.php/RTK/Users. >> >> I fixed the linux error, a commit of 2 days ago was causing it. >> >> I don't, however, understand some of your windows errors. It seems >> >> that it does not understand the ggo files with enum variables although >> >> this has been working on Windows and Linux so far. A potential >> >> explanation would be that you have installed an old version of >> >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> >> to help me fixing it? You mentioned a problem with getopt.h in your >> >> first email but I did not see it in the log. >> >> There is also a linking problem with Cuda that your CMakeCache.txt >> >> might help me to understand. >> >> Thanks, >> >> Simon >> >> >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> >> >> wrote: >> >> > Hi! >> >> > sorry that it took soo long to answer. >> >> > For windows: >> >> > compiler is Visual Studio Express 2008 and we are using Windows 7 >> >> > (see >> >> > log_windows attached) >> >> > >> >> > For Linux: >> >> > I downloaded the latest version from here: >> >> > https://github.com/SimonRit/RTK >> >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> >> > Got over the usual nvcc error, but still could not compile >> >> > unfortunately >> >> > (see log_linux attached) >> >> > >> >> > thanks a lot >> >> > Marta >> >> > >> >> > On 12 October 2012 11:19, Simon Rit >> >> > wrote: >> >> >> >> >> >> Hi Marta, >> >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> >> are the problems with getopt.h. Could you send us more information >> >> >> (logs, Windows version, compiler, ...)? >> >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> >> you update your RTK repository and give it another try? >> >> >> A simple Shepp Logan reconstruction example is available here >> >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> >> Good luck, >> >> >> Simon >> >> >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> >> wrote: >> >> >> > Dear Simon and David, >> >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are >> >> >> > looking >> >> >> > into >> >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we >> >> >> > had >> >> >> > a >> >> >> > look >> >> >> > at IRTK. >> >> >> > >> >> >> > Now, problem is that we were not able to compile it neither on >> >> >> > windows >> >> >> > nor >> >> >> > linux (arch distrib). >> >> >> > >> >> >> > For windows, main issues were related to the windows version of >> >> >> > getopt >> >> >> > which >> >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> >> > like). >> >> >> > >> >> >> > For linux, I had cuda problem. In particular, although correctly >> >> >> > configured, >> >> >> > I am stuck with this: >> >> >> > [ 7%] Building NVCC (Device) object >> >> >> > >> >> >> > >> >> >> > >> >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:100: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> >> > '-fpermissive', >> >> >> > G++ >> >> >> > will accept your code, but allowing the use of an undeclared name >> >> >> > is >> >> >> > deprecated) >> >> >> > /usr/include/surface_functions.h:101: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:102: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:103: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:104: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu4' must be available >> >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:460: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:461: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:462: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:463: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:464: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu4' must be available >> >> >> > CMake Error at >> >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> >> > (message): >> >> >> > Error generating file >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > >> >> >> > >> >> >> > make[2]: *** >> >> >> > >> >> >> > >> >> >> > >> >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> >> > Error 1 >> >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> >> > make: *** [all] Error 2 >> >> >> > >> >> >> > I remember having the same issue in plastimatch some time ago (it >> >> >> > is >> >> >> > due >> >> >> > to >> >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> >> > >> >> >> > But anyhow, can you please guide us through a compilation to make >> >> >> > it >> >> >> > work >> >> >> > and test it on the new projections? >> >> >> > >> >> >> > thanks a lot >> >> >> > Best Regards, >> >> >> > Marta Peroni >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > >> >> >> > ******************************************************************* >> >> >> > Marta Peroni, PhD >> >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> >> > >> >> >> > contacts: >> >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> >> > mobile: +393488202136 (IT) >> >> >> > office: +39 02 2399 9022 >> >> >> > >> >> >> > >> >> >> > ******************************************************************** >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From hsieandy at gmail.com Tue Oct 23 08:48:32 2012 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 23 Oct 2012 23:48:32 +1100 Subject: [Rtk-users] RTK calculating attenuation from Varian projection Message-ID: Hi Simon, I was looking at "rtkVarianObiRawImageFilter.h", and realized that the attenuation is calculated from the projection image simply via a negative transformation (1-Intensity/HND_MaxIntensity). Is it usually the way this is done, and is there any reason for doing this? I would have thought attenuation should be calculated from intensity via logarithm (since I=I_0 exp(-mu x)). Thanks!! Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 23 12:16:07 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 23 Oct 2012 18:16:07 +0200 Subject: [Rtk-users] RTK calculating attenuation from Varian projection In-Reply-To: References: Message-ID: Hi Andy, Yes you're right, I have actually noticed recently that but I have not worked a lot on Varian images because we don't have a Varian CBCT in Lyon. I only had a sub-sampled acquisition from Greg of a Catphan that I used to roughly check the geometry. As far as I can remember, when I wrote this piece of code, I tried to use the same code as Plastimatch but I could well have done it wrongly. I'm actually waiting for a new complete Catphan acquisition from Greg to correct for this but if you already have a patch to suggest or a set of images to send, feel free to do it. Thanks, Simon On Tue, Oct 23, 2012 at 2:48 PM, Andy Shieh wrote: > Hi Simon, > > I was looking at "rtkVarianObiRawImageFilter.h", and realized that the > attenuation is calculated from the projection image simply via a negative > transformation (1-Intensity/HND_MaxIntensity). > Is it usually the way this is done, and is there any reason for doing this? > I would have thought attenuation should be calculated from intensity via > logarithm (since I=I_0 exp(-mu x)). > Thanks!! > > Cheers, > Andy > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From croow at yahoo.com Tue Oct 23 19:57:12 2012 From: croow at yahoo.com (M Miller) Date: Tue, 23 Oct 2012 16:57:12 -0700 (PDT) Subject: [Rtk-users] Reconstruct from projections; Starter tips Message-ID: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> I'm new to RTK and I'd like to reconstruct some projections into a volume. So far I've only been able to get an "InvalidRequestedRegionError", but I'd like to describe my steps with the hope that someone can point out what I've done wrong. I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample programs seem to work fine as I can successfully walk through the FDK SheppLogan example. My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, covering 360deg of rotation. The center of rotation is 65.93mm from the xray source, and the detector is 870.86mm from the source. The detector is 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. ? I create a geometry file: "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 --sdd=870.86 --sid=65.93" ? Attempt to reconstruct: "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml --path=d:\ct_projections\test\ --regexp=tif$ --output=d:\ct_projections\rtkfdk.mha --divisions=2" ? Output: >Regular expression matches 3143 file(s) >Reading geometry information from d:\ct_projections\geo.xml... >Reconstructing and writing... ExceptionObject caught with writer->Update() > >itk::InvalidRequestedRegionError (0000000000009FED10) >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) throw(class itk::InvalidRequestedRegionError)" >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx >Line: 397 >Description: Requested region is (at least partially) outside the largest possible region. ? I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( reader->Update() )" with just "reader->Update()", otherwise there is no debug information. The "lowmem" switch is required to keep ITK from crashing, which I think is an unrelated problem. I use "divisions=2" because plastimatch would crash for me without specifying something similar. Setting the "hardware" switch to either cpu or cuda produces the same error. The client machine has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. ? Is there any extra information necessary or anything that needs clarification? How can I use RTK to reconstruct a volume, if possible? ? Thanks Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Oct 24 04:27:13 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 24 Oct 2012 10:27:13 +0200 Subject: [Rtk-users] Reconstruct from projections; Starter tips In-Reply-To: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> References: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> Message-ID: Hi Micah, You did not do a mistake, you have successfully hit a bug. The truth is that I haven't used the divisions option in a very long time... This should now be fixed https://github.com/SimonRit/RTK/commit/10f8e1b0a5f6b69c943d04513135856968e3e62b and I have added an automated test to avoid future inconveniences https://github.com/SimonRit/RTK/commit/0932e38ad73d8e7214adda5103ced38c7b2754d0 Thanks for the report and keep us a posted. By the way, I have not done a lot of work with tif inputs so you might have to modify the tif conversion from raw to attenuation https://github.com/SimonRit/RTK/blob/master/code/rtkTiffLookupTableImageFilter.h Good luck! Simon On Wed, Oct 24, 2012 at 1:57 AM, M Miller wrote: > I'm new to RTK and I'd like to reconstruct some projections into a volume. > So far I've only been able to get an "InvalidRequestedRegionError", but I'd > like to describe my steps with the hope that someone can point out what > I've done wrong. > > I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample > programs seem to work fine as I can successfully walk through the FDK > SheppLogan example. > > My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, > covering 360deg of rotation. The center of rotation is 65.93mm from the > xray source, and the detector is 870.86mm from the source. The detector is > 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. > > I create a geometry file: > "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 > --sdd=870.86 --sid=65.93" > > Attempt to reconstruct: > "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml > --path=d:\ct_projections\test\ --regexp=tif$ > --output=d:\ct_projections\rtkfdk.mha --divisions=2" > > Output: > >Regular expression matches 3143 file(s) > >Reading geometry information from d:\ct_projections\geo.xml... > >Reconstructing and writing... ExceptionObject caught with writer->Update() > > > >itk::InvalidRequestedRegionError (0000000000009FED10) > >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) > throw(class itk::InvalidRequestedRegionError)" > >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx > >Line: 397 > >Description: Requested region is (at least partially) outside the largest > possible region. > > I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( > reader->Update() )" with just "reader->Update()", otherwise there is no > debug information. > > The "lowmem" switch is required to keep ITK from crashing, which I think > is an unrelated problem. I use "divisions=2" because plastimatch would > crash for me without specifying something similar. Setting the "hardware" > switch to either cpu or cuda produces the same error. The client machine > has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. > > Is there any extra information necessary or anything that needs > clarification? > How can I use RTK to reconstruct a volume, if possible? > > Thanks > Micah > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 12 05:19:16 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 12 Oct 2012 11:19:16 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: Message-ID: Hi Marta, Thanks for the feedback. Yes, we would be interested in knowing what are the problems with getopt.h. Could you send us more information (logs, Windows version, compiler, ...)? Regarding Cuda, this is a bit of a weird problem. I have tried to merge the latest version of Plastimatch cmake files with rtk. Could you update your RTK repository and give it another try? A simple Shepp Logan reconstruction example is available here http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are available here http://wiki.openrtk.org/index.php/RTK/Users. Good luck, Simon On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni wrote: > Dear Simon and David, > was a pleasure to meet you at MICCAI. As I mentioned, we are looking into > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a look > at IRTK. > > Now, problem is that we were not able to compile it neither on windows nor > linux (arch distrib). > > For windows, main issues were related to the windows version of getopt which > generate syntax error (Marco can provide you a log file, if you'd like). > > For linux, I had cuda problem. In particular, although correctly configured, > I am stuck with this: > [ 7%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, > surface, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:100: error: there are no arguments to > '__surf1Dreadc1' that depend on a template parameter, so a declaration of > '__surf1Dreadc1' must be available > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', G++ > will accept your code, but allowing the use of an undeclared name is > deprecated) > /usr/include/surface_functions.h:101: error: there are no arguments to > '__surf1Dreads1' that depend on a template parameter, so a declaration of > '__surf1Dreads1' must be available > /usr/include/surface_functions.h:102: error: there are no arguments to > '__surf1Dreadu1' that depend on a template parameter, so a declaration of > '__surf1Dreadu1' must be available > /usr/include/surface_functions.h:103: error: there are no arguments to > '__surf1Dreadu2' that depend on a template parameter, so a declaration of > '__surf1Dreadu2' must be available > /usr/include/surface_functions.h:104: error: there are no arguments to > '__surf1Dreadu4' that depend on a template parameter, so a declaration of > '__surf1Dreadu4' must be available > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, > surface, int, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:460: error: there are no arguments to > '__surf2Dreadc1' that depend on a template parameter, so a declaration of > '__surf2Dreadc1' must be available > /usr/include/surface_functions.h:461: error: there are no arguments to > '__surf2Dreads1' that depend on a template parameter, so a declaration of > '__surf2Dreads1' must be available > /usr/include/surface_functions.h:462: error: there are no arguments to > '__surf2Dreadu1' that depend on a template parameter, so a declaration of > '__surf2Dreadu1' must be available > /usr/include/surface_functions.h:463: error: there are no arguments to > '__surf2Dreadu2' that depend on a template parameter, so a declaration of > '__surf2Dreadu2' must be available > /usr/include/surface_functions.h:464: error: there are no arguments to > '__surf2Dreadu4' that depend on a template parameter, so a declaration of > '__surf2Dreadu4' must be available > CMake Error at > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 (message): > Error generating file > > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > > make[2]: *** > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] > Error 1 > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 > make: *** [all] Error 2 > > I remember having the same issue in plastimatch some time ago (it is due to > cuda version) and James added some -fpermissive to fix the issue. > > But anyhow, can you please guide us through a compilation to make it work > and test it on the new projections? > > thanks a lot > Best Regards, > Marta Peroni > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Mon Oct 15 13:53:13 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Mon, 15 Oct 2012 19:53:13 +0200 Subject: [Rtk-users] FirstReconstruction example Message-ID: <20121015175313.49610@gmx.net> Hello, I have questions concerning the FirstReconstruction example: Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? Sorry for the detailed questions, I just would like to understand how RTK is working. Thanks a lot! LF From simon.rit at creatis.insa-lyon.fr Mon Oct 15 16:17:59 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 15 Oct 2012 22:17:59 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121015175313.49610@gmx.net> References: <20121015175313.49610@gmx.net> Message-ID: Hi Lars, The geometry is described in the document geometry.tex, I have added links at the end of the user's wiki page http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with coordinates 0,0,0 of your volume is the isocenter, the point with coordinate 0,0 in projection images is the intersection of your flat panel with the line going through the x-ray source and the isocenter. The image origin is defined by ITK as the center of the pixel with index 0 in memory (first pixel in memory). I hope this helps, Simon On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars wrote: > Hello, > > I have questions concerning the FirstReconstruction example: > Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). > > How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. > > Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? > > Sorry for the detailed questions, I just would like to understand how RTK is working. > > Thanks a lot! > > LF > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:03:43 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:03:43 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> Message-ID: <20121016080343.49570@gmx.net> Hi Simon, thanks for your reply! I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. Basically, the first sentence in section 6 of the doc "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." along with another sentence in this section "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... Thanks so far! LF -------- Original-Nachricht -------- > Datum: Mon, 15 Oct 2012 22:17:59 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > Hi Lars, > The geometry is described in the document geometry.tex, I have added > links at the end of the user's wiki page > http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > coordinates 0,0,0 of your volume is the isocenter, the point with > coordinate 0,0 in projection images is the intersection of your flat > panel with the line going through the x-ray source and the isocenter. > The image origin is defined by ITK as the center of the pixel with > index 0 in memory (first pixel in memory). > I hope this helps, > Simon > > On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > wrote: > > Hello, > > > > I have questions concerning the FirstReconstruction example: > > Using the rtk::RayEllipsoidIntersectionImageFilter and > rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are > packed in the form of an image stack. The geometry of the projections is > described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the > images' metrics are described by the image stack itself (spacing, size and > ORIGIN). > > > > How should I interpret the origin? As far as I could find out by minor > modifications of the example, the origin of the projeciton image stack plays > a role (if I change it to 0,0,0, and retain constantImageSource2's origin > at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does > the origin of the image stack matter? Isn't the origin of a single > projection fully defined by the corresponding entry in the > rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the > offset from the detector central axis crossing point)? Am I right that the > effective origin of a single projection image emerges basically from the > detector (x/y of origin of image stack) and from consecutive application of > the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, > e.g. caused by gravity, wouldn't be simulatable. > > > > Morever, which point exactly does the image origin (x/y components) of > the projection stack describe? Is it the outer corner of the projection or > the center of the first voxel (as in DICOM). The size of a projection in the > example is 256.0x256.0 units. However, the stack's origin is at > -127.0,-127.0. If the origin should refer to the center of the first projection > pixel, it should be essentially -127.5,-127.5, right? > > > > Sorry for the detailed questions, I just would like to understand how > RTK is working. > > > > Thanks a lot! > > > > LF > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Tue Oct 16 04:23:17 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 16 Oct 2012 10:23:17 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121016080343.49570@gmx.net> References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: I agree, geometry is irritating! I'm sorry my comments were part of this irritation... It seemed obvious to me that the origin and the direction in itk::Image has to be accounted for but I'll add a comment in the header to make it clearer. Bear in mind that this on-going work so feel free to suggest improvements and clarifications. Regarding geometry conversion, we had done a work with my colleagues from the Universit? Catholique de Louvain to convert their geometry parameterization to RTK parameterization using Maxima. That allowed us to spare some hours spent on deriving the correct formulas... Would you be interested in the script file? Simon On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars wrote: > Hi Simon, > > thanks for your reply! > > I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > Basically, the first sentence in section 6 of the doc > "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." > along with another sentence in this section > "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." > irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. > > My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > Thanks so far! > > LF > > -------- Original-Nachricht -------- >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 >> Von: Simon Rit >> An: Lars Friedrich Lars >> CC: rtk-users at openrtk.org >> Betreff: Re: [Rtk-users] FirstReconstruction example > >> Hi Lars, >> The geometry is described in the document geometry.tex, I have added >> links at the end of the user's wiki page >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with >> coordinates 0,0,0 of your volume is the isocenter, the point with >> coordinate 0,0 in projection images is the intersection of your flat >> panel with the line going through the x-ray source and the isocenter. >> The image origin is defined by ITK as the center of the pixel with >> index 0 in memory (first pixel in memory). >> I hope this helps, >> Simon >> >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars >> wrote: >> > Hello, >> > >> > I have questions concerning the FirstReconstruction example: >> > Using the rtk::RayEllipsoidIntersectionImageFilter and >> rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are >> packed in the form of an image stack. The geometry of the projections is >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the >> images' metrics are described by the image stack itself (spacing, size and >> ORIGIN). >> > >> > How should I interpret the origin? As far as I could find out by minor >> modifications of the example, the origin of the projeciton image stack plays >> a role (if I change it to 0,0,0, and retain constantImageSource2's origin >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does >> the origin of the image stack matter? Isn't the origin of a single >> projection fully defined by the corresponding entry in the >> rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the >> offset from the detector central axis crossing point)? Am I right that the >> effective origin of a single projection image emerges basically from the >> detector (x/y of origin of image stack) and from consecutive application of >> the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, >> e.g. caused by gravity, wouldn't be simulatable. >> > >> > Morever, which point exactly does the image origin (x/y components) of >> the projection stack describe? Is it the outer corner of the projection or >> the center of the first voxel (as in DICOM). The size of a projection in the >> example is 256.0x256.0 units. However, the stack's origin is at >> -127.0,-127.0. If the origin should refer to the center of the first projection >> pixel, it should be essentially -127.5,-127.5, right? >> > >> > Sorry for the detailed questions, I just would like to understand how >> RTK is working. >> > >> > Thanks a lot! >> > >> > LF >> > _______________________________________________ >> > Rtk-users mailing list >> > Rtk-users at openrtk.org >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:55:04 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:55:04 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: <20121016085504.78840@gmx.net> Hi, thanks!! Yep, I would be very interested in the script since I would like to try first whether my geometry is generally a no go for the FDK-based approaches in RTK (which I cannot exclude at the moment), before shaping the code and implementing C++-based converters. Lars -------- Original-Nachricht -------- > Datum: Tue, 16 Oct 2012 10:23:17 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > I agree, geometry is irritating! I'm sorry my comments were part of > this irritation... It seemed obvious to me that the origin and the > direction in itk::Image has to be accounted for but I'll add a comment > in the header to make it clearer. Bear in mind that this on-going work > so feel free to suggest improvements and clarifications. > > Regarding geometry conversion, we had done a work with my colleagues > from the Universit? Catholique de Louvain to convert their geometry > parameterization to RTK parameterization using Maxima. That allowed us > to spare some hours spent on deriving the correct formulas... Would > you be interested in the script file? > > Simon > > On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars > wrote: > > Hi Simon, > > > > thanks for your reply! > > > > I read the geometry-doc and played around with > rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > > Basically, the first sentence in section 6 of the doc > > "This class is meant to define a set of 2D projection images, acquired > with a at panel along a circular trajectory, around a 3D tomography." > > along with another sentence in this section > > "9 parameters are used per projection to define the position of the > source and the detector relatively to the fixed coordinate system." > > irritated me a bit. I thought that the 3DCircGeom's task is, in addition > to defining the source position, to define the position and orientation of > the 2D projection images, and the 3DCircGeom is defined in the IEC WCS > (relates to it). I did not expect essential projection image metrics except > dimension (pixel size) and spacing (because image size in physical units is > not part of 3DCircGeom) having any influence on the position and orientation > of it, since this is already defined with the 3DCircGeom object. > > > > My issue at the moment is simply that I have source position, detector > position and detector row/column vectors defined in IEC WCS for each > projection, and have to convert it somehow into your projection geometry format + > (and that's news for me) adjust the image origin of the projection stack. > Unfortunately, my geometry is not really a standard circular one (as in case > of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > > > Thanks so far! > > > > LF > > > > -------- Original-Nachricht -------- > >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 > >> Von: Simon Rit > >> An: Lars Friedrich Lars > >> CC: rtk-users at openrtk.org > >> Betreff: Re: [Rtk-users] FirstReconstruction example > > > >> Hi Lars, > >> The geometry is described in the document geometry.tex, I have added > >> links at the end of the user's wiki page > >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > >> coordinates 0,0,0 of your volume is the isocenter, the point with > >> coordinate 0,0 in projection images is the intersection of your flat > >> panel with the line going through the x-ray source and the isocenter. > >> The image origin is defined by ITK as the center of the pixel with > >> index 0 in memory (first pixel in memory). > >> I hope this helps, > >> Simon > >> > >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > >> wrote: > >> > Hello, > >> > > >> > I have questions concerning the FirstReconstruction example: > >> > Using the rtk::RayEllipsoidIntersectionImageFilter and > >> rtk::ConstantImageSource artificial projections of an ellipsoid are > generated which are > >> packed in the form of an image stack. The geometry of the projections > is > >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, > the > >> images' metrics are described by the image stack itself (spacing, size > and > >> ORIGIN). > >> > > >> > How should I interpret the origin? As far as I could find out by > minor > >> modifications of the example, the origin of the projeciton image stack > plays > >> a role (if I change it to 0,0,0, and retain constantImageSource2's > origin > >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why > does > >> the origin of the image stack matter? Isn't the origin of a single > >> projection fully defined by the corresponding entry in the > >> rtk::ThreeDCircularProjectionGeometry object (I thought the > projOffsetX,projOffsetY args define the > >> offset from the detector central axis crossing point)? Am I right that > the > >> effective origin of a single projection image emerges basically from > the > >> detector (x/y of origin of image stack) and from consecutive > application of > >> the projOffsetX,projOffsetY args? Otherwise, deviating detector > positions, > >> e.g. caused by gravity, wouldn't be simulatable. > >> > > >> > Morever, which point exactly does the image origin (x/y components) > of > >> the projection stack describe? Is it the outer corner of the projection > or > >> the center of the first voxel (as in DICOM). The size of a projection > in the > >> example is 256.0x256.0 units. However, the stack's origin is at > >> -127.0,-127.0. If the origin should refer to the center of the first > projection > >> pixel, it should be essentially -127.5,-127.5, right? > >> > > >> > Sorry for the detailed questions, I just would like to understand how > >> RTK is working. > >> > > >> > Thanks a lot! > >> > > >> > LF > >> > _______________________________________________ > >> > Rtk-users mailing list > >> > Rtk-users at openrtk.org > >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Wed Oct 17 08:56:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 14:56:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> Message-ID: Hi Marta, Yes still ITK 3.20, see instructions here: http://wiki.openrtk.org/index.php/RTK/Users. I fixed the linux error, a commit of 2 days ago was causing it. I don't, however, understand some of your windows errors. It seems that it does not understand the ggo files with enum variables although this has been working on Windows and Linux so far. A potential explanation would be that you have installed an old version of gengetopt on your computer? Maybe you can send me your CMakeCache.txt to help me fixing it? You mentioned a problem with getopt.h in your first email but I did not see it in the log. There is also a linking problem with Cuda that your CMakeCache.txt might help me to understand. Thanks, Simon On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni wrote: > Hi! > sorry that it took soo long to answer. > For windows: > compiler is Visual Studio Express 2008 and we are using Windows 7 (see > log_windows attached) > > For Linux: > I downloaded the latest version from here: https://github.com/SimonRit/RTK > and tried to compile against ITK 3.20 (should I try with ITK4?) > Got over the usual nvcc error, but still could not compile unfortunately > (see log_linux attached) > > thanks a lot > Marta > > On 12 October 2012 11:19, Simon Rit wrote: >> >> Hi Marta, >> Thanks for the feedback. Yes, we would be interested in knowing what >> are the problems with getopt.h. Could you send us more information >> (logs, Windows version, compiler, ...)? >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> merge the latest version of Plastimatch cmake files with rtk. Could >> you update your RTK repository and give it another try? >> A simple Shepp Logan reconstruction example is available here >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> Good luck, >> Simon >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> wrote: >> > Dear Simon and David, >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> > into >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a >> > look >> > at IRTK. >> > >> > Now, problem is that we were not able to compile it neither on windows >> > nor >> > linux (arch distrib). >> > >> > For windows, main issues were related to the windows version of getopt >> > which >> > generate syntax error (Marco can provide you a log file, if you'd like). >> > >> > For linux, I had cuda problem. In particular, although correctly >> > configured, >> > I am stuck with this: >> > [ 7%] Building NVCC (Device) object >> > >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> > surface, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:100: error: there are no arguments to >> > '__surf1Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadc1' must be available >> > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', >> > G++ >> > will accept your code, but allowing the use of an undeclared name is >> > deprecated) >> > /usr/include/surface_functions.h:101: error: there are no arguments to >> > '__surf1Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreads1' must be available >> > /usr/include/surface_functions.h:102: error: there are no arguments to >> > '__surf1Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu1' must be available >> > /usr/include/surface_functions.h:103: error: there are no arguments to >> > '__surf1Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu2' must be available >> > /usr/include/surface_functions.h:104: error: there are no arguments to >> > '__surf1Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu4' must be available >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:460: error: there are no arguments to >> > '__surf2Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadc1' must be available >> > /usr/include/surface_functions.h:461: error: there are no arguments to >> > '__surf2Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreads1' must be available >> > /usr/include/surface_functions.h:462: error: there are no arguments to >> > '__surf2Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu1' must be available >> > /usr/include/surface_functions.h:463: error: there are no arguments to >> > '__surf2Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu2' must be available >> > /usr/include/surface_functions.h:464: error: there are no arguments to >> > '__surf2Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu4' must be available >> > CMake Error at >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> > (message): >> > Error generating file >> > >> > >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > >> > >> > make[2]: *** >> > >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> > Error 1 >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> > make: *** [all] Error 2 >> > >> > I remember having the same issue in plastimatch some time ago (it is due >> > to >> > cuda version) and James added some -fpermissive to fix the issue. >> > >> > But anyhow, can you please guide us through a compilation to make it >> > work >> > and test it on the new projections? >> > >> > thanks a lot >> > Best Regards, >> > Marta Peroni >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:18:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:18:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> Message-ID: The other linux compile errors have been fixed, they were caused by the recent gcc that you seem to be using. Sorry for this hassle, we do not have tested all possible combinations of gccs yet... >From your CMakeCache.txt, it seems that you have gengetopt installed here: C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe A way to solve this would be to remove it from the Windows path so that cmake doesn't use it because gengetopt code has been copied in RTK and will be compiled automatically if it's not in the path. In the future, we should check on gengetopt version and compile it automatically if the system version is too old. I have opened a bug: http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 This should fix the gengetopt enum errors but I still have to figure out the linking problem if it's still here. It's strange that it does not show up on my windows box... Simon On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni wrote: > Hi Simon! > that fixed the error thanks :) But I am afraid I have another one.... > (log_linux attached hed). > I also send you the CMakeCache.txt, but I am afraid your intuition might be > right... > For windows, where do you get the gengeopt? just to make sure we are > up-to-date > thanks a lot > Marta > > > On 17 October 2012 14:56, Simon Rit wrote: >> >> Hi Marta, >> >> Yes still ITK 3.20, see instructions here: >> http://wiki.openrtk.org/index.php/RTK/Users. >> I fixed the linux error, a commit of 2 days ago was causing it. >> I don't, however, understand some of your windows errors. It seems >> that it does not understand the ggo files with enum variables although >> this has been working on Windows and Linux so far. A potential >> explanation would be that you have installed an old version of >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> to help me fixing it? You mentioned a problem with getopt.h in your >> first email but I did not see it in the log. >> There is also a linking problem with Cuda that your CMakeCache.txt >> might help me to understand. >> Thanks, >> Simon >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> wrote: >> > Hi! >> > sorry that it took soo long to answer. >> > For windows: >> > compiler is Visual Studio Express 2008 and we are using Windows 7 (see >> > log_windows attached) >> > >> > For Linux: >> > I downloaded the latest version from here: >> > https://github.com/SimonRit/RTK >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> > Got over the usual nvcc error, but still could not compile unfortunately >> > (see log_linux attached) >> > >> > thanks a lot >> > Marta >> > >> > On 12 October 2012 11:19, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> are the problems with getopt.h. Could you send us more information >> >> (logs, Windows version, compiler, ...)? >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> you update your RTK repository and give it another try? >> >> A simple Shepp Logan reconstruction example is available here >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> Good luck, >> >> Simon >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> wrote: >> >> > Dear Simon and David, >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> >> > into >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had >> >> > a >> >> > look >> >> > at IRTK. >> >> > >> >> > Now, problem is that we were not able to compile it neither on >> >> > windows >> >> > nor >> >> > linux (arch distrib). >> >> > >> >> > For windows, main issues were related to the windows version of >> >> > getopt >> >> > which >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> > like). >> >> > >> >> > For linux, I had cuda problem. In particular, although correctly >> >> > configured, >> >> > I am stuck with this: >> >> > [ 7%] Building NVCC (Device) object >> >> > >> >> > >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:100: error: there are no arguments >> >> > to >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadc1' must be available >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> > '-fpermissive', >> >> > G++ >> >> > will accept your code, but allowing the use of an undeclared name is >> >> > deprecated) >> >> > /usr/include/surface_functions.h:101: error: there are no arguments >> >> > to >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreads1' must be available >> >> > /usr/include/surface_functions.h:102: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu1' must be available >> >> > /usr/include/surface_functions.h:103: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu2' must be available >> >> > /usr/include/surface_functions.h:104: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu4' must be available >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:460: error: there are no arguments >> >> > to >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadc1' must be available >> >> > /usr/include/surface_functions.h:461: error: there are no arguments >> >> > to >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreads1' must be available >> >> > /usr/include/surface_functions.h:462: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu1' must be available >> >> > /usr/include/surface_functions.h:463: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu2' must be available >> >> > /usr/include/surface_functions.h:464: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu4' must be available >> >> > CMake Error at >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> > (message): >> >> > Error generating file >> >> > >> >> > >> >> > >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > >> >> > >> >> > make[2]: *** >> >> > >> >> > >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> > Error 1 >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> > make: *** [all] Error 2 >> >> > >> >> > I remember having the same issue in plastimatch some time ago (it is >> >> > due >> >> > to >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> > >> >> > But anyhow, can you please guide us through a compilation to make it >> >> > work >> >> > and test it on the new projections? >> >> > >> >> > thanks a lot >> >> > Best Regards, >> >> > Marta Peroni >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Wed Oct 17 10:25:52 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Wed, 17 Oct 2012 16:25:52 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... Message-ID: <20121017142552.78880@gmx.net> Hi Simon, we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? Thank you. p From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:44:08 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:44:08 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... In-Reply-To: <20121017142552.78880@gmx.net> References: <20121017142552.78880@gmx.net> Message-ID: Hi, Yes, this is intentional. FDK requires more than matrices to compute, e.g., the angular gaps (http://www.openrtk.org/Doxygen/classrtk_1_1ThreeDCircularProjectionGeometry.html#ae821fb8a5d01b6dd947fc5f8e54cd676). Just search in the code for where the geometry object is used and you'll understand. What you describe is a rtk::ThreeDCircularProjectionGeometry so you are going to lose more time doing a new geometry file than learning how to use rtk::ThreeDCircularProjectionGeometry. If you give us some details and/or an example, we can help you doing the conversion. The parameters should be very intuitive. Simon On Wed, Oct 17, 2012 at 4:25 PM, Lars Friedrich Lars wrote: > Hi Simon, > > we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? > > Thank you. > > p > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Thu Oct 18 05:45:23 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 18 Oct 2012 11:45:23 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> <9115_1350483574_q9HEJWrs014386_CAF0oig0JumNrvzkF28RBGqCi0hRfZuG4OBDTMyyHZptNOZL5dQ@mail.gmail.com> Message-ID: Marta, Sorry, while we were working on compiling RTK for you there has been some other commits that may have caused the problem. Could you give it another try now? It should be fixed according to the dashboard: http://my.cdash.org/index.php?project=RTK Simon On Wed, Oct 17, 2012 at 4:37 PM, Marta Peroni wrote: > Hi Simon! > don't worry, I'm glad I can be useful for testing... > yet another gcc issue I believe: > [ 73%] Building C object > applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/rtkbackprojections_ggo.c.o > Linking CXX executable ../../bin/rtkbackprojections > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaFDKBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaFDKBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaFDKBackProjectionImageFilter::CudaFDKBackProjectionImageFilter()' > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaBackProjectionImageFilter::CudaBackProjectionImageFilter()' > collect2: error: ld returned 1 exit status > make[2]: *** [bin/rtkbackprojections] Error 1 > make[1]: *** > [applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/all] > Error 2 > > make: *** [all] Error 2 > > > I'll let you know very soon about the windows thing...I remember that we > tried to compile without installing gengetopt and it was not compiling it > automatically. Let me give it another shot... > Marta > > On 17 October 2012 16:18, Simon Rit wrote: >> >> The other linux compile errors have been fixed, they were caused by >> the recent gcc that you seem to be using. Sorry for this hassle, we do >> not have tested all possible combinations of gccs yet... >> >> From your CMakeCache.txt, it seems that you have gengetopt installed here: >> C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe >> A way to solve this would be to remove it from the Windows path so >> that cmake doesn't use it because gengetopt code has been copied in >> RTK and will be compiled automatically if it's not in the path. In the >> future, we should check on gengetopt version and compile it >> automatically if the system version is too old. I have opened a bug: >> http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 >> This should fix the gengetopt enum errors but I still have to figure >> out the linking problem if it's still here. It's strange that it does >> not show up on my windows box... >> >> Simon >> >> On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni >> wrote: >> > Hi Simon! >> > that fixed the error thanks :) But I am afraid I have another one.... >> > (log_linux attached hed). >> > I also send you the CMakeCache.txt, but I am afraid your intuition might >> > be >> > right... >> > For windows, where do you get the gengeopt? just to make sure we are >> > up-to-date >> > thanks a lot >> > Marta >> > >> > >> > On 17 October 2012 14:56, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> >> >> Yes still ITK 3.20, see instructions here: >> >> http://wiki.openrtk.org/index.php/RTK/Users. >> >> I fixed the linux error, a commit of 2 days ago was causing it. >> >> I don't, however, understand some of your windows errors. It seems >> >> that it does not understand the ggo files with enum variables although >> >> this has been working on Windows and Linux so far. A potential >> >> explanation would be that you have installed an old version of >> >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> >> to help me fixing it? You mentioned a problem with getopt.h in your >> >> first email but I did not see it in the log. >> >> There is also a linking problem with Cuda that your CMakeCache.txt >> >> might help me to understand. >> >> Thanks, >> >> Simon >> >> >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> >> >> wrote: >> >> > Hi! >> >> > sorry that it took soo long to answer. >> >> > For windows: >> >> > compiler is Visual Studio Express 2008 and we are using Windows 7 >> >> > (see >> >> > log_windows attached) >> >> > >> >> > For Linux: >> >> > I downloaded the latest version from here: >> >> > https://github.com/SimonRit/RTK >> >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> >> > Got over the usual nvcc error, but still could not compile >> >> > unfortunately >> >> > (see log_linux attached) >> >> > >> >> > thanks a lot >> >> > Marta >> >> > >> >> > On 12 October 2012 11:19, Simon Rit >> >> > wrote: >> >> >> >> >> >> Hi Marta, >> >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> >> are the problems with getopt.h. Could you send us more information >> >> >> (logs, Windows version, compiler, ...)? >> >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> >> you update your RTK repository and give it another try? >> >> >> A simple Shepp Logan reconstruction example is available here >> >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> >> Good luck, >> >> >> Simon >> >> >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> >> wrote: >> >> >> > Dear Simon and David, >> >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are >> >> >> > looking >> >> >> > into >> >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we >> >> >> > had >> >> >> > a >> >> >> > look >> >> >> > at IRTK. >> >> >> > >> >> >> > Now, problem is that we were not able to compile it neither on >> >> >> > windows >> >> >> > nor >> >> >> > linux (arch distrib). >> >> >> > >> >> >> > For windows, main issues were related to the windows version of >> >> >> > getopt >> >> >> > which >> >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> >> > like). >> >> >> > >> >> >> > For linux, I had cuda problem. In particular, although correctly >> >> >> > configured, >> >> >> > I am stuck with this: >> >> >> > [ 7%] Building NVCC (Device) object >> >> >> > >> >> >> > >> >> >> > >> >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:100: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> >> > '-fpermissive', >> >> >> > G++ >> >> >> > will accept your code, but allowing the use of an undeclared name >> >> >> > is >> >> >> > deprecated) >> >> >> > /usr/include/surface_functions.h:101: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:102: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:103: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:104: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu4' must be available >> >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:460: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:461: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:462: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:463: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:464: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu4' must be available >> >> >> > CMake Error at >> >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> >> > (message): >> >> >> > Error generating file >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > >> >> >> > >> >> >> > make[2]: *** >> >> >> > >> >> >> > >> >> >> > >> >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> >> > Error 1 >> >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> >> > make: *** [all] Error 2 >> >> >> > >> >> >> > I remember having the same issue in plastimatch some time ago (it >> >> >> > is >> >> >> > due >> >> >> > to >> >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> >> > >> >> >> > But anyhow, can you please guide us through a compilation to make >> >> >> > it >> >> >> > work >> >> >> > and test it on the new projections? >> >> >> > >> >> >> > thanks a lot >> >> >> > Best Regards, >> >> >> > Marta Peroni >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > >> >> >> > ******************************************************************* >> >> >> > Marta Peroni, PhD >> >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> >> > >> >> >> > contacts: >> >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> >> > mobile: +393488202136 (IT) >> >> >> > office: +39 02 2399 9022 >> >> >> > >> >> >> > >> >> >> > ******************************************************************** >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From hsieandy at gmail.com Tue Oct 23 08:48:32 2012 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 23 Oct 2012 23:48:32 +1100 Subject: [Rtk-users] RTK calculating attenuation from Varian projection Message-ID: Hi Simon, I was looking at "rtkVarianObiRawImageFilter.h", and realized that the attenuation is calculated from the projection image simply via a negative transformation (1-Intensity/HND_MaxIntensity). Is it usually the way this is done, and is there any reason for doing this? I would have thought attenuation should be calculated from intensity via logarithm (since I=I_0 exp(-mu x)). Thanks!! Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 23 12:16:07 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 23 Oct 2012 18:16:07 +0200 Subject: [Rtk-users] RTK calculating attenuation from Varian projection In-Reply-To: References: Message-ID: Hi Andy, Yes you're right, I have actually noticed recently that but I have not worked a lot on Varian images because we don't have a Varian CBCT in Lyon. I only had a sub-sampled acquisition from Greg of a Catphan that I used to roughly check the geometry. As far as I can remember, when I wrote this piece of code, I tried to use the same code as Plastimatch but I could well have done it wrongly. I'm actually waiting for a new complete Catphan acquisition from Greg to correct for this but if you already have a patch to suggest or a set of images to send, feel free to do it. Thanks, Simon On Tue, Oct 23, 2012 at 2:48 PM, Andy Shieh wrote: > Hi Simon, > > I was looking at "rtkVarianObiRawImageFilter.h", and realized that the > attenuation is calculated from the projection image simply via a negative > transformation (1-Intensity/HND_MaxIntensity). > Is it usually the way this is done, and is there any reason for doing this? > I would have thought attenuation should be calculated from intensity via > logarithm (since I=I_0 exp(-mu x)). > Thanks!! > > Cheers, > Andy > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From croow at yahoo.com Tue Oct 23 19:57:12 2012 From: croow at yahoo.com (M Miller) Date: Tue, 23 Oct 2012 16:57:12 -0700 (PDT) Subject: [Rtk-users] Reconstruct from projections; Starter tips Message-ID: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> I'm new to RTK and I'd like to reconstruct some projections into a volume. So far I've only been able to get an "InvalidRequestedRegionError", but I'd like to describe my steps with the hope that someone can point out what I've done wrong. I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample programs seem to work fine as I can successfully walk through the FDK SheppLogan example. My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, covering 360deg of rotation. The center of rotation is 65.93mm from the xray source, and the detector is 870.86mm from the source. The detector is 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. ? I create a geometry file: "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 --sdd=870.86 --sid=65.93" ? Attempt to reconstruct: "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml --path=d:\ct_projections\test\ --regexp=tif$ --output=d:\ct_projections\rtkfdk.mha --divisions=2" ? Output: >Regular expression matches 3143 file(s) >Reading geometry information from d:\ct_projections\geo.xml... >Reconstructing and writing... ExceptionObject caught with writer->Update() > >itk::InvalidRequestedRegionError (0000000000009FED10) >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) throw(class itk::InvalidRequestedRegionError)" >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx >Line: 397 >Description: Requested region is (at least partially) outside the largest possible region. ? I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( reader->Update() )" with just "reader->Update()", otherwise there is no debug information. The "lowmem" switch is required to keep ITK from crashing, which I think is an unrelated problem. I use "divisions=2" because plastimatch would crash for me without specifying something similar. Setting the "hardware" switch to either cpu or cuda produces the same error. The client machine has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. ? Is there any extra information necessary or anything that needs clarification? How can I use RTK to reconstruct a volume, if possible? ? Thanks Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Oct 24 04:27:13 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 24 Oct 2012 10:27:13 +0200 Subject: [Rtk-users] Reconstruct from projections; Starter tips In-Reply-To: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> References: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> Message-ID: Hi Micah, You did not do a mistake, you have successfully hit a bug. The truth is that I haven't used the divisions option in a very long time... This should now be fixed https://github.com/SimonRit/RTK/commit/10f8e1b0a5f6b69c943d04513135856968e3e62b and I have added an automated test to avoid future inconveniences https://github.com/SimonRit/RTK/commit/0932e38ad73d8e7214adda5103ced38c7b2754d0 Thanks for the report and keep us a posted. By the way, I have not done a lot of work with tif inputs so you might have to modify the tif conversion from raw to attenuation https://github.com/SimonRit/RTK/blob/master/code/rtkTiffLookupTableImageFilter.h Good luck! Simon On Wed, Oct 24, 2012 at 1:57 AM, M Miller wrote: > I'm new to RTK and I'd like to reconstruct some projections into a volume. > So far I've only been able to get an "InvalidRequestedRegionError", but I'd > like to describe my steps with the hope that someone can point out what > I've done wrong. > > I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample > programs seem to work fine as I can successfully walk through the FDK > SheppLogan example. > > My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, > covering 360deg of rotation. The center of rotation is 65.93mm from the > xray source, and the detector is 870.86mm from the source. The detector is > 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. > > I create a geometry file: > "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 > --sdd=870.86 --sid=65.93" > > Attempt to reconstruct: > "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml > --path=d:\ct_projections\test\ --regexp=tif$ > --output=d:\ct_projections\rtkfdk.mha --divisions=2" > > Output: > >Regular expression matches 3143 file(s) > >Reading geometry information from d:\ct_projections\geo.xml... > >Reconstructing and writing... ExceptionObject caught with writer->Update() > > > >itk::InvalidRequestedRegionError (0000000000009FED10) > >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) > throw(class itk::InvalidRequestedRegionError)" > >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx > >Line: 397 > >Description: Requested region is (at least partially) outside the largest > possible region. > > I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( > reader->Update() )" with just "reader->Update()", otherwise there is no > debug information. > > The "lowmem" switch is required to keep ITK from crashing, which I think > is an unrelated problem. I use "divisions=2" because plastimatch would > crash for me without specifying something similar. Setting the "hardware" > switch to either cpu or cuda produces the same error. The client machine > has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. > > Is there any extra information necessary or anything that needs > clarification? > How can I use RTK to reconstruct a volume, if possible? > > Thanks > Micah > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 12 05:19:16 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 12 Oct 2012 11:19:16 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: Message-ID: Hi Marta, Thanks for the feedback. Yes, we would be interested in knowing what are the problems with getopt.h. Could you send us more information (logs, Windows version, compiler, ...)? Regarding Cuda, this is a bit of a weird problem. I have tried to merge the latest version of Plastimatch cmake files with rtk. Could you update your RTK repository and give it another try? A simple Shepp Logan reconstruction example is available here http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are available here http://wiki.openrtk.org/index.php/RTK/Users. Good luck, Simon On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni wrote: > Dear Simon and David, > was a pleasure to meet you at MICCAI. As I mentioned, we are looking into > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a look > at IRTK. > > Now, problem is that we were not able to compile it neither on windows nor > linux (arch distrib). > > For windows, main issues were related to the windows version of getopt which > generate syntax error (Marco can provide you a log file, if you'd like). > > For linux, I had cuda problem. In particular, although correctly configured, > I am stuck with this: > [ 7%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, > surface, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:100: error: there are no arguments to > '__surf1Dreadc1' that depend on a template parameter, so a declaration of > '__surf1Dreadc1' must be available > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', G++ > will accept your code, but allowing the use of an undeclared name is > deprecated) > /usr/include/surface_functions.h:101: error: there are no arguments to > '__surf1Dreads1' that depend on a template parameter, so a declaration of > '__surf1Dreads1' must be available > /usr/include/surface_functions.h:102: error: there are no arguments to > '__surf1Dreadu1' that depend on a template parameter, so a declaration of > '__surf1Dreadu1' must be available > /usr/include/surface_functions.h:103: error: there are no arguments to > '__surf1Dreadu2' that depend on a template parameter, so a declaration of > '__surf1Dreadu2' must be available > /usr/include/surface_functions.h:104: error: there are no arguments to > '__surf1Dreadu4' that depend on a template parameter, so a declaration of > '__surf1Dreadu4' must be available > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, > surface, int, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:460: error: there are no arguments to > '__surf2Dreadc1' that depend on a template parameter, so a declaration of > '__surf2Dreadc1' must be available > /usr/include/surface_functions.h:461: error: there are no arguments to > '__surf2Dreads1' that depend on a template parameter, so a declaration of > '__surf2Dreads1' must be available > /usr/include/surface_functions.h:462: error: there are no arguments to > '__surf2Dreadu1' that depend on a template parameter, so a declaration of > '__surf2Dreadu1' must be available > /usr/include/surface_functions.h:463: error: there are no arguments to > '__surf2Dreadu2' that depend on a template parameter, so a declaration of > '__surf2Dreadu2' must be available > /usr/include/surface_functions.h:464: error: there are no arguments to > '__surf2Dreadu4' that depend on a template parameter, so a declaration of > '__surf2Dreadu4' must be available > CMake Error at > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 (message): > Error generating file > > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > > make[2]: *** > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] > Error 1 > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 > make: *** [all] Error 2 > > I remember having the same issue in plastimatch some time ago (it is due to > cuda version) and James added some -fpermissive to fix the issue. > > But anyhow, can you please guide us through a compilation to make it work > and test it on the new projections? > > thanks a lot > Best Regards, > Marta Peroni > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Mon Oct 15 13:53:13 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Mon, 15 Oct 2012 19:53:13 +0200 Subject: [Rtk-users] FirstReconstruction example Message-ID: <20121015175313.49610@gmx.net> Hello, I have questions concerning the FirstReconstruction example: Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? Sorry for the detailed questions, I just would like to understand how RTK is working. Thanks a lot! LF From simon.rit at creatis.insa-lyon.fr Mon Oct 15 16:17:59 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 15 Oct 2012 22:17:59 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121015175313.49610@gmx.net> References: <20121015175313.49610@gmx.net> Message-ID: Hi Lars, The geometry is described in the document geometry.tex, I have added links at the end of the user's wiki page http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with coordinates 0,0,0 of your volume is the isocenter, the point with coordinate 0,0 in projection images is the intersection of your flat panel with the line going through the x-ray source and the isocenter. The image origin is defined by ITK as the center of the pixel with index 0 in memory (first pixel in memory). I hope this helps, Simon On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars wrote: > Hello, > > I have questions concerning the FirstReconstruction example: > Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). > > How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. > > Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? > > Sorry for the detailed questions, I just would like to understand how RTK is working. > > Thanks a lot! > > LF > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:03:43 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:03:43 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> Message-ID: <20121016080343.49570@gmx.net> Hi Simon, thanks for your reply! I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. Basically, the first sentence in section 6 of the doc "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." along with another sentence in this section "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... Thanks so far! LF -------- Original-Nachricht -------- > Datum: Mon, 15 Oct 2012 22:17:59 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > Hi Lars, > The geometry is described in the document geometry.tex, I have added > links at the end of the user's wiki page > http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > coordinates 0,0,0 of your volume is the isocenter, the point with > coordinate 0,0 in projection images is the intersection of your flat > panel with the line going through the x-ray source and the isocenter. > The image origin is defined by ITK as the center of the pixel with > index 0 in memory (first pixel in memory). > I hope this helps, > Simon > > On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > wrote: > > Hello, > > > > I have questions concerning the FirstReconstruction example: > > Using the rtk::RayEllipsoidIntersectionImageFilter and > rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are > packed in the form of an image stack. The geometry of the projections is > described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the > images' metrics are described by the image stack itself (spacing, size and > ORIGIN). > > > > How should I interpret the origin? As far as I could find out by minor > modifications of the example, the origin of the projeciton image stack plays > a role (if I change it to 0,0,0, and retain constantImageSource2's origin > at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does > the origin of the image stack matter? Isn't the origin of a single > projection fully defined by the corresponding entry in the > rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the > offset from the detector central axis crossing point)? Am I right that the > effective origin of a single projection image emerges basically from the > detector (x/y of origin of image stack) and from consecutive application of > the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, > e.g. caused by gravity, wouldn't be simulatable. > > > > Morever, which point exactly does the image origin (x/y components) of > the projection stack describe? Is it the outer corner of the projection or > the center of the first voxel (as in DICOM). The size of a projection in the > example is 256.0x256.0 units. However, the stack's origin is at > -127.0,-127.0. If the origin should refer to the center of the first projection > pixel, it should be essentially -127.5,-127.5, right? > > > > Sorry for the detailed questions, I just would like to understand how > RTK is working. > > > > Thanks a lot! > > > > LF > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Tue Oct 16 04:23:17 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 16 Oct 2012 10:23:17 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121016080343.49570@gmx.net> References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: I agree, geometry is irritating! I'm sorry my comments were part of this irritation... It seemed obvious to me that the origin and the direction in itk::Image has to be accounted for but I'll add a comment in the header to make it clearer. Bear in mind that this on-going work so feel free to suggest improvements and clarifications. Regarding geometry conversion, we had done a work with my colleagues from the Universit? Catholique de Louvain to convert their geometry parameterization to RTK parameterization using Maxima. That allowed us to spare some hours spent on deriving the correct formulas... Would you be interested in the script file? Simon On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars wrote: > Hi Simon, > > thanks for your reply! > > I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > Basically, the first sentence in section 6 of the doc > "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." > along with another sentence in this section > "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." > irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. > > My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > Thanks so far! > > LF > > -------- Original-Nachricht -------- >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 >> Von: Simon Rit >> An: Lars Friedrich Lars >> CC: rtk-users at openrtk.org >> Betreff: Re: [Rtk-users] FirstReconstruction example > >> Hi Lars, >> The geometry is described in the document geometry.tex, I have added >> links at the end of the user's wiki page >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with >> coordinates 0,0,0 of your volume is the isocenter, the point with >> coordinate 0,0 in projection images is the intersection of your flat >> panel with the line going through the x-ray source and the isocenter. >> The image origin is defined by ITK as the center of the pixel with >> index 0 in memory (first pixel in memory). >> I hope this helps, >> Simon >> >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars >> wrote: >> > Hello, >> > >> > I have questions concerning the FirstReconstruction example: >> > Using the rtk::RayEllipsoidIntersectionImageFilter and >> rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are >> packed in the form of an image stack. The geometry of the projections is >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the >> images' metrics are described by the image stack itself (spacing, size and >> ORIGIN). >> > >> > How should I interpret the origin? As far as I could find out by minor >> modifications of the example, the origin of the projeciton image stack plays >> a role (if I change it to 0,0,0, and retain constantImageSource2's origin >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does >> the origin of the image stack matter? Isn't the origin of a single >> projection fully defined by the corresponding entry in the >> rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the >> offset from the detector central axis crossing point)? Am I right that the >> effective origin of a single projection image emerges basically from the >> detector (x/y of origin of image stack) and from consecutive application of >> the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, >> e.g. caused by gravity, wouldn't be simulatable. >> > >> > Morever, which point exactly does the image origin (x/y components) of >> the projection stack describe? Is it the outer corner of the projection or >> the center of the first voxel (as in DICOM). The size of a projection in the >> example is 256.0x256.0 units. However, the stack's origin is at >> -127.0,-127.0. If the origin should refer to the center of the first projection >> pixel, it should be essentially -127.5,-127.5, right? >> > >> > Sorry for the detailed questions, I just would like to understand how >> RTK is working. >> > >> > Thanks a lot! >> > >> > LF >> > _______________________________________________ >> > Rtk-users mailing list >> > Rtk-users at openrtk.org >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:55:04 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:55:04 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: <20121016085504.78840@gmx.net> Hi, thanks!! Yep, I would be very interested in the script since I would like to try first whether my geometry is generally a no go for the FDK-based approaches in RTK (which I cannot exclude at the moment), before shaping the code and implementing C++-based converters. Lars -------- Original-Nachricht -------- > Datum: Tue, 16 Oct 2012 10:23:17 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > I agree, geometry is irritating! I'm sorry my comments were part of > this irritation... It seemed obvious to me that the origin and the > direction in itk::Image has to be accounted for but I'll add a comment > in the header to make it clearer. Bear in mind that this on-going work > so feel free to suggest improvements and clarifications. > > Regarding geometry conversion, we had done a work with my colleagues > from the Universit? Catholique de Louvain to convert their geometry > parameterization to RTK parameterization using Maxima. That allowed us > to spare some hours spent on deriving the correct formulas... Would > you be interested in the script file? > > Simon > > On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars > wrote: > > Hi Simon, > > > > thanks for your reply! > > > > I read the geometry-doc and played around with > rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > > Basically, the first sentence in section 6 of the doc > > "This class is meant to define a set of 2D projection images, acquired > with a at panel along a circular trajectory, around a 3D tomography." > > along with another sentence in this section > > "9 parameters are used per projection to define the position of the > source and the detector relatively to the fixed coordinate system." > > irritated me a bit. I thought that the 3DCircGeom's task is, in addition > to defining the source position, to define the position and orientation of > the 2D projection images, and the 3DCircGeom is defined in the IEC WCS > (relates to it). I did not expect essential projection image metrics except > dimension (pixel size) and spacing (because image size in physical units is > not part of 3DCircGeom) having any influence on the position and orientation > of it, since this is already defined with the 3DCircGeom object. > > > > My issue at the moment is simply that I have source position, detector > position and detector row/column vectors defined in IEC WCS for each > projection, and have to convert it somehow into your projection geometry format + > (and that's news for me) adjust the image origin of the projection stack. > Unfortunately, my geometry is not really a standard circular one (as in case > of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > > > Thanks so far! > > > > LF > > > > -------- Original-Nachricht -------- > >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 > >> Von: Simon Rit > >> An: Lars Friedrich Lars > >> CC: rtk-users at openrtk.org > >> Betreff: Re: [Rtk-users] FirstReconstruction example > > > >> Hi Lars, > >> The geometry is described in the document geometry.tex, I have added > >> links at the end of the user's wiki page > >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > >> coordinates 0,0,0 of your volume is the isocenter, the point with > >> coordinate 0,0 in projection images is the intersection of your flat > >> panel with the line going through the x-ray source and the isocenter. > >> The image origin is defined by ITK as the center of the pixel with > >> index 0 in memory (first pixel in memory). > >> I hope this helps, > >> Simon > >> > >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > >> wrote: > >> > Hello, > >> > > >> > I have questions concerning the FirstReconstruction example: > >> > Using the rtk::RayEllipsoidIntersectionImageFilter and > >> rtk::ConstantImageSource artificial projections of an ellipsoid are > generated which are > >> packed in the form of an image stack. The geometry of the projections > is > >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, > the > >> images' metrics are described by the image stack itself (spacing, size > and > >> ORIGIN). > >> > > >> > How should I interpret the origin? As far as I could find out by > minor > >> modifications of the example, the origin of the projeciton image stack > plays > >> a role (if I change it to 0,0,0, and retain constantImageSource2's > origin > >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why > does > >> the origin of the image stack matter? Isn't the origin of a single > >> projection fully defined by the corresponding entry in the > >> rtk::ThreeDCircularProjectionGeometry object (I thought the > projOffsetX,projOffsetY args define the > >> offset from the detector central axis crossing point)? Am I right that > the > >> effective origin of a single projection image emerges basically from > the > >> detector (x/y of origin of image stack) and from consecutive > application of > >> the projOffsetX,projOffsetY args? Otherwise, deviating detector > positions, > >> e.g. caused by gravity, wouldn't be simulatable. > >> > > >> > Morever, which point exactly does the image origin (x/y components) > of > >> the projection stack describe? Is it the outer corner of the projection > or > >> the center of the first voxel (as in DICOM). The size of a projection > in the > >> example is 256.0x256.0 units. However, the stack's origin is at > >> -127.0,-127.0. If the origin should refer to the center of the first > projection > >> pixel, it should be essentially -127.5,-127.5, right? > >> > > >> > Sorry for the detailed questions, I just would like to understand how > >> RTK is working. > >> > > >> > Thanks a lot! > >> > > >> > LF > >> > _______________________________________________ > >> > Rtk-users mailing list > >> > Rtk-users at openrtk.org > >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Wed Oct 17 08:56:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 14:56:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> Message-ID: Hi Marta, Yes still ITK 3.20, see instructions here: http://wiki.openrtk.org/index.php/RTK/Users. I fixed the linux error, a commit of 2 days ago was causing it. I don't, however, understand some of your windows errors. It seems that it does not understand the ggo files with enum variables although this has been working on Windows and Linux so far. A potential explanation would be that you have installed an old version of gengetopt on your computer? Maybe you can send me your CMakeCache.txt to help me fixing it? You mentioned a problem with getopt.h in your first email but I did not see it in the log. There is also a linking problem with Cuda that your CMakeCache.txt might help me to understand. Thanks, Simon On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni wrote: > Hi! > sorry that it took soo long to answer. > For windows: > compiler is Visual Studio Express 2008 and we are using Windows 7 (see > log_windows attached) > > For Linux: > I downloaded the latest version from here: https://github.com/SimonRit/RTK > and tried to compile against ITK 3.20 (should I try with ITK4?) > Got over the usual nvcc error, but still could not compile unfortunately > (see log_linux attached) > > thanks a lot > Marta > > On 12 October 2012 11:19, Simon Rit wrote: >> >> Hi Marta, >> Thanks for the feedback. Yes, we would be interested in knowing what >> are the problems with getopt.h. Could you send us more information >> (logs, Windows version, compiler, ...)? >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> merge the latest version of Plastimatch cmake files with rtk. Could >> you update your RTK repository and give it another try? >> A simple Shepp Logan reconstruction example is available here >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> Good luck, >> Simon >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> wrote: >> > Dear Simon and David, >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> > into >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a >> > look >> > at IRTK. >> > >> > Now, problem is that we were not able to compile it neither on windows >> > nor >> > linux (arch distrib). >> > >> > For windows, main issues were related to the windows version of getopt >> > which >> > generate syntax error (Marco can provide you a log file, if you'd like). >> > >> > For linux, I had cuda problem. In particular, although correctly >> > configured, >> > I am stuck with this: >> > [ 7%] Building NVCC (Device) object >> > >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> > surface, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:100: error: there are no arguments to >> > '__surf1Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadc1' must be available >> > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', >> > G++ >> > will accept your code, but allowing the use of an undeclared name is >> > deprecated) >> > /usr/include/surface_functions.h:101: error: there are no arguments to >> > '__surf1Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreads1' must be available >> > /usr/include/surface_functions.h:102: error: there are no arguments to >> > '__surf1Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu1' must be available >> > /usr/include/surface_functions.h:103: error: there are no arguments to >> > '__surf1Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu2' must be available >> > /usr/include/surface_functions.h:104: error: there are no arguments to >> > '__surf1Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu4' must be available >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:460: error: there are no arguments to >> > '__surf2Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadc1' must be available >> > /usr/include/surface_functions.h:461: error: there are no arguments to >> > '__surf2Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreads1' must be available >> > /usr/include/surface_functions.h:462: error: there are no arguments to >> > '__surf2Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu1' must be available >> > /usr/include/surface_functions.h:463: error: there are no arguments to >> > '__surf2Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu2' must be available >> > /usr/include/surface_functions.h:464: error: there are no arguments to >> > '__surf2Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu4' must be available >> > CMake Error at >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> > (message): >> > Error generating file >> > >> > >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > >> > >> > make[2]: *** >> > >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> > Error 1 >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> > make: *** [all] Error 2 >> > >> > I remember having the same issue in plastimatch some time ago (it is due >> > to >> > cuda version) and James added some -fpermissive to fix the issue. >> > >> > But anyhow, can you please guide us through a compilation to make it >> > work >> > and test it on the new projections? >> > >> > thanks a lot >> > Best Regards, >> > Marta Peroni >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:18:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:18:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> Message-ID: The other linux compile errors have been fixed, they were caused by the recent gcc that you seem to be using. Sorry for this hassle, we do not have tested all possible combinations of gccs yet... >From your CMakeCache.txt, it seems that you have gengetopt installed here: C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe A way to solve this would be to remove it from the Windows path so that cmake doesn't use it because gengetopt code has been copied in RTK and will be compiled automatically if it's not in the path. In the future, we should check on gengetopt version and compile it automatically if the system version is too old. I have opened a bug: http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 This should fix the gengetopt enum errors but I still have to figure out the linking problem if it's still here. It's strange that it does not show up on my windows box... Simon On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni wrote: > Hi Simon! > that fixed the error thanks :) But I am afraid I have another one.... > (log_linux attached hed). > I also send you the CMakeCache.txt, but I am afraid your intuition might be > right... > For windows, where do you get the gengeopt? just to make sure we are > up-to-date > thanks a lot > Marta > > > On 17 October 2012 14:56, Simon Rit wrote: >> >> Hi Marta, >> >> Yes still ITK 3.20, see instructions here: >> http://wiki.openrtk.org/index.php/RTK/Users. >> I fixed the linux error, a commit of 2 days ago was causing it. >> I don't, however, understand some of your windows errors. It seems >> that it does not understand the ggo files with enum variables although >> this has been working on Windows and Linux so far. A potential >> explanation would be that you have installed an old version of >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> to help me fixing it? You mentioned a problem with getopt.h in your >> first email but I did not see it in the log. >> There is also a linking problem with Cuda that your CMakeCache.txt >> might help me to understand. >> Thanks, >> Simon >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> wrote: >> > Hi! >> > sorry that it took soo long to answer. >> > For windows: >> > compiler is Visual Studio Express 2008 and we are using Windows 7 (see >> > log_windows attached) >> > >> > For Linux: >> > I downloaded the latest version from here: >> > https://github.com/SimonRit/RTK >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> > Got over the usual nvcc error, but still could not compile unfortunately >> > (see log_linux attached) >> > >> > thanks a lot >> > Marta >> > >> > On 12 October 2012 11:19, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> are the problems with getopt.h. Could you send us more information >> >> (logs, Windows version, compiler, ...)? >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> you update your RTK repository and give it another try? >> >> A simple Shepp Logan reconstruction example is available here >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> Good luck, >> >> Simon >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> wrote: >> >> > Dear Simon and David, >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> >> > into >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had >> >> > a >> >> > look >> >> > at IRTK. >> >> > >> >> > Now, problem is that we were not able to compile it neither on >> >> > windows >> >> > nor >> >> > linux (arch distrib). >> >> > >> >> > For windows, main issues were related to the windows version of >> >> > getopt >> >> > which >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> > like). >> >> > >> >> > For linux, I had cuda problem. In particular, although correctly >> >> > configured, >> >> > I am stuck with this: >> >> > [ 7%] Building NVCC (Device) object >> >> > >> >> > >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:100: error: there are no arguments >> >> > to >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadc1' must be available >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> > '-fpermissive', >> >> > G++ >> >> > will accept your code, but allowing the use of an undeclared name is >> >> > deprecated) >> >> > /usr/include/surface_functions.h:101: error: there are no arguments >> >> > to >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreads1' must be available >> >> > /usr/include/surface_functions.h:102: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu1' must be available >> >> > /usr/include/surface_functions.h:103: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu2' must be available >> >> > /usr/include/surface_functions.h:104: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu4' must be available >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:460: error: there are no arguments >> >> > to >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadc1' must be available >> >> > /usr/include/surface_functions.h:461: error: there are no arguments >> >> > to >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreads1' must be available >> >> > /usr/include/surface_functions.h:462: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu1' must be available >> >> > /usr/include/surface_functions.h:463: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu2' must be available >> >> > /usr/include/surface_functions.h:464: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu4' must be available >> >> > CMake Error at >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> > (message): >> >> > Error generating file >> >> > >> >> > >> >> > >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > >> >> > >> >> > make[2]: *** >> >> > >> >> > >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> > Error 1 >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> > make: *** [all] Error 2 >> >> > >> >> > I remember having the same issue in plastimatch some time ago (it is >> >> > due >> >> > to >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> > >> >> > But anyhow, can you please guide us through a compilation to make it >> >> > work >> >> > and test it on the new projections? >> >> > >> >> > thanks a lot >> >> > Best Regards, >> >> > Marta Peroni >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Wed Oct 17 10:25:52 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Wed, 17 Oct 2012 16:25:52 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... Message-ID: <20121017142552.78880@gmx.net> Hi Simon, we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? Thank you. p From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:44:08 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:44:08 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... In-Reply-To: <20121017142552.78880@gmx.net> References: <20121017142552.78880@gmx.net> Message-ID: Hi, Yes, this is intentional. FDK requires more than matrices to compute, e.g., the angular gaps (http://www.openrtk.org/Doxygen/classrtk_1_1ThreeDCircularProjectionGeometry.html#ae821fb8a5d01b6dd947fc5f8e54cd676). Just search in the code for where the geometry object is used and you'll understand. What you describe is a rtk::ThreeDCircularProjectionGeometry so you are going to lose more time doing a new geometry file than learning how to use rtk::ThreeDCircularProjectionGeometry. If you give us some details and/or an example, we can help you doing the conversion. The parameters should be very intuitive. Simon On Wed, Oct 17, 2012 at 4:25 PM, Lars Friedrich Lars wrote: > Hi Simon, > > we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? > > Thank you. > > p > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Thu Oct 18 05:45:23 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 18 Oct 2012 11:45:23 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> <9115_1350483574_q9HEJWrs014386_CAF0oig0JumNrvzkF28RBGqCi0hRfZuG4OBDTMyyHZptNOZL5dQ@mail.gmail.com> Message-ID: Marta, Sorry, while we were working on compiling RTK for you there has been some other commits that may have caused the problem. Could you give it another try now? It should be fixed according to the dashboard: http://my.cdash.org/index.php?project=RTK Simon On Wed, Oct 17, 2012 at 4:37 PM, Marta Peroni wrote: > Hi Simon! > don't worry, I'm glad I can be useful for testing... > yet another gcc issue I believe: > [ 73%] Building C object > applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/rtkbackprojections_ggo.c.o > Linking CXX executable ../../bin/rtkbackprojections > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaFDKBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaFDKBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaFDKBackProjectionImageFilter::CudaFDKBackProjectionImageFilter()' > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaBackProjectionImageFilter::CudaBackProjectionImageFilter()' > collect2: error: ld returned 1 exit status > make[2]: *** [bin/rtkbackprojections] Error 1 > make[1]: *** > [applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/all] > Error 2 > > make: *** [all] Error 2 > > > I'll let you know very soon about the windows thing...I remember that we > tried to compile without installing gengetopt and it was not compiling it > automatically. Let me give it another shot... > Marta > > On 17 October 2012 16:18, Simon Rit wrote: >> >> The other linux compile errors have been fixed, they were caused by >> the recent gcc that you seem to be using. Sorry for this hassle, we do >> not have tested all possible combinations of gccs yet... >> >> From your CMakeCache.txt, it seems that you have gengetopt installed here: >> C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe >> A way to solve this would be to remove it from the Windows path so >> that cmake doesn't use it because gengetopt code has been copied in >> RTK and will be compiled automatically if it's not in the path. In the >> future, we should check on gengetopt version and compile it >> automatically if the system version is too old. I have opened a bug: >> http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 >> This should fix the gengetopt enum errors but I still have to figure >> out the linking problem if it's still here. It's strange that it does >> not show up on my windows box... >> >> Simon >> >> On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni >> wrote: >> > Hi Simon! >> > that fixed the error thanks :) But I am afraid I have another one.... >> > (log_linux attached hed). >> > I also send you the CMakeCache.txt, but I am afraid your intuition might >> > be >> > right... >> > For windows, where do you get the gengeopt? just to make sure we are >> > up-to-date >> > thanks a lot >> > Marta >> > >> > >> > On 17 October 2012 14:56, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> >> >> Yes still ITK 3.20, see instructions here: >> >> http://wiki.openrtk.org/index.php/RTK/Users. >> >> I fixed the linux error, a commit of 2 days ago was causing it. >> >> I don't, however, understand some of your windows errors. It seems >> >> that it does not understand the ggo files with enum variables although >> >> this has been working on Windows and Linux so far. A potential >> >> explanation would be that you have installed an old version of >> >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> >> to help me fixing it? You mentioned a problem with getopt.h in your >> >> first email but I did not see it in the log. >> >> There is also a linking problem with Cuda that your CMakeCache.txt >> >> might help me to understand. >> >> Thanks, >> >> Simon >> >> >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> >> >> wrote: >> >> > Hi! >> >> > sorry that it took soo long to answer. >> >> > For windows: >> >> > compiler is Visual Studio Express 2008 and we are using Windows 7 >> >> > (see >> >> > log_windows attached) >> >> > >> >> > For Linux: >> >> > I downloaded the latest version from here: >> >> > https://github.com/SimonRit/RTK >> >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> >> > Got over the usual nvcc error, but still could not compile >> >> > unfortunately >> >> > (see log_linux attached) >> >> > >> >> > thanks a lot >> >> > Marta >> >> > >> >> > On 12 October 2012 11:19, Simon Rit >> >> > wrote: >> >> >> >> >> >> Hi Marta, >> >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> >> are the problems with getopt.h. Could you send us more information >> >> >> (logs, Windows version, compiler, ...)? >> >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> >> you update your RTK repository and give it another try? >> >> >> A simple Shepp Logan reconstruction example is available here >> >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> >> Good luck, >> >> >> Simon >> >> >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> >> wrote: >> >> >> > Dear Simon and David, >> >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are >> >> >> > looking >> >> >> > into >> >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we >> >> >> > had >> >> >> > a >> >> >> > look >> >> >> > at IRTK. >> >> >> > >> >> >> > Now, problem is that we were not able to compile it neither on >> >> >> > windows >> >> >> > nor >> >> >> > linux (arch distrib). >> >> >> > >> >> >> > For windows, main issues were related to the windows version of >> >> >> > getopt >> >> >> > which >> >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> >> > like). >> >> >> > >> >> >> > For linux, I had cuda problem. In particular, although correctly >> >> >> > configured, >> >> >> > I am stuck with this: >> >> >> > [ 7%] Building NVCC (Device) object >> >> >> > >> >> >> > >> >> >> > >> >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:100: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> >> > '-fpermissive', >> >> >> > G++ >> >> >> > will accept your code, but allowing the use of an undeclared name >> >> >> > is >> >> >> > deprecated) >> >> >> > /usr/include/surface_functions.h:101: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:102: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:103: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:104: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu4' must be available >> >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:460: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:461: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:462: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:463: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:464: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu4' must be available >> >> >> > CMake Error at >> >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> >> > (message): >> >> >> > Error generating file >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > >> >> >> > >> >> >> > make[2]: *** >> >> >> > >> >> >> > >> >> >> > >> >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> >> > Error 1 >> >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> >> > make: *** [all] Error 2 >> >> >> > >> >> >> > I remember having the same issue in plastimatch some time ago (it >> >> >> > is >> >> >> > due >> >> >> > to >> >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> >> > >> >> >> > But anyhow, can you please guide us through a compilation to make >> >> >> > it >> >> >> > work >> >> >> > and test it on the new projections? >> >> >> > >> >> >> > thanks a lot >> >> >> > Best Regards, >> >> >> > Marta Peroni >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > >> >> >> > ******************************************************************* >> >> >> > Marta Peroni, PhD >> >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> >> > >> >> >> > contacts: >> >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> >> > mobile: +393488202136 (IT) >> >> >> > office: +39 02 2399 9022 >> >> >> > >> >> >> > >> >> >> > ******************************************************************** >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From hsieandy at gmail.com Tue Oct 23 08:48:32 2012 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 23 Oct 2012 23:48:32 +1100 Subject: [Rtk-users] RTK calculating attenuation from Varian projection Message-ID: Hi Simon, I was looking at "rtkVarianObiRawImageFilter.h", and realized that the attenuation is calculated from the projection image simply via a negative transformation (1-Intensity/HND_MaxIntensity). Is it usually the way this is done, and is there any reason for doing this? I would have thought attenuation should be calculated from intensity via logarithm (since I=I_0 exp(-mu x)). Thanks!! Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 23 12:16:07 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 23 Oct 2012 18:16:07 +0200 Subject: [Rtk-users] RTK calculating attenuation from Varian projection In-Reply-To: References: Message-ID: Hi Andy, Yes you're right, I have actually noticed recently that but I have not worked a lot on Varian images because we don't have a Varian CBCT in Lyon. I only had a sub-sampled acquisition from Greg of a Catphan that I used to roughly check the geometry. As far as I can remember, when I wrote this piece of code, I tried to use the same code as Plastimatch but I could well have done it wrongly. I'm actually waiting for a new complete Catphan acquisition from Greg to correct for this but if you already have a patch to suggest or a set of images to send, feel free to do it. Thanks, Simon On Tue, Oct 23, 2012 at 2:48 PM, Andy Shieh wrote: > Hi Simon, > > I was looking at "rtkVarianObiRawImageFilter.h", and realized that the > attenuation is calculated from the projection image simply via a negative > transformation (1-Intensity/HND_MaxIntensity). > Is it usually the way this is done, and is there any reason for doing this? > I would have thought attenuation should be calculated from intensity via > logarithm (since I=I_0 exp(-mu x)). > Thanks!! > > Cheers, > Andy > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From croow at yahoo.com Tue Oct 23 19:57:12 2012 From: croow at yahoo.com (M Miller) Date: Tue, 23 Oct 2012 16:57:12 -0700 (PDT) Subject: [Rtk-users] Reconstruct from projections; Starter tips Message-ID: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> I'm new to RTK and I'd like to reconstruct some projections into a volume. So far I've only been able to get an "InvalidRequestedRegionError", but I'd like to describe my steps with the hope that someone can point out what I've done wrong. I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample programs seem to work fine as I can successfully walk through the FDK SheppLogan example. My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, covering 360deg of rotation. The center of rotation is 65.93mm from the xray source, and the detector is 870.86mm from the source. The detector is 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. ? I create a geometry file: "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 --sdd=870.86 --sid=65.93" ? Attempt to reconstruct: "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml --path=d:\ct_projections\test\ --regexp=tif$ --output=d:\ct_projections\rtkfdk.mha --divisions=2" ? Output: >Regular expression matches 3143 file(s) >Reading geometry information from d:\ct_projections\geo.xml... >Reconstructing and writing... ExceptionObject caught with writer->Update() > >itk::InvalidRequestedRegionError (0000000000009FED10) >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) throw(class itk::InvalidRequestedRegionError)" >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx >Line: 397 >Description: Requested region is (at least partially) outside the largest possible region. ? I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( reader->Update() )" with just "reader->Update()", otherwise there is no debug information. The "lowmem" switch is required to keep ITK from crashing, which I think is an unrelated problem. I use "divisions=2" because plastimatch would crash for me without specifying something similar. Setting the "hardware" switch to either cpu or cuda produces the same error. The client machine has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. ? Is there any extra information necessary or anything that needs clarification? How can I use RTK to reconstruct a volume, if possible? ? Thanks Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Oct 24 04:27:13 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 24 Oct 2012 10:27:13 +0200 Subject: [Rtk-users] Reconstruct from projections; Starter tips In-Reply-To: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> References: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> Message-ID: Hi Micah, You did not do a mistake, you have successfully hit a bug. The truth is that I haven't used the divisions option in a very long time... This should now be fixed https://github.com/SimonRit/RTK/commit/10f8e1b0a5f6b69c943d04513135856968e3e62b and I have added an automated test to avoid future inconveniences https://github.com/SimonRit/RTK/commit/0932e38ad73d8e7214adda5103ced38c7b2754d0 Thanks for the report and keep us a posted. By the way, I have not done a lot of work with tif inputs so you might have to modify the tif conversion from raw to attenuation https://github.com/SimonRit/RTK/blob/master/code/rtkTiffLookupTableImageFilter.h Good luck! Simon On Wed, Oct 24, 2012 at 1:57 AM, M Miller wrote: > I'm new to RTK and I'd like to reconstruct some projections into a volume. > So far I've only been able to get an "InvalidRequestedRegionError", but I'd > like to describe my steps with the hope that someone can point out what > I've done wrong. > > I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample > programs seem to work fine as I can successfully walk through the FDK > SheppLogan example. > > My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, > covering 360deg of rotation. The center of rotation is 65.93mm from the > xray source, and the detector is 870.86mm from the source. The detector is > 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. > > I create a geometry file: > "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 > --sdd=870.86 --sid=65.93" > > Attempt to reconstruct: > "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml > --path=d:\ct_projections\test\ --regexp=tif$ > --output=d:\ct_projections\rtkfdk.mha --divisions=2" > > Output: > >Regular expression matches 3143 file(s) > >Reading geometry information from d:\ct_projections\geo.xml... > >Reconstructing and writing... ExceptionObject caught with writer->Update() > > > >itk::InvalidRequestedRegionError (0000000000009FED10) > >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) > throw(class itk::InvalidRequestedRegionError)" > >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx > >Line: 397 > >Description: Requested region is (at least partially) outside the largest > possible region. > > I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( > reader->Update() )" with just "reader->Update()", otherwise there is no > debug information. > > The "lowmem" switch is required to keep ITK from crashing, which I think > is an unrelated problem. I use "divisions=2" because plastimatch would > crash for me without specifying something similar. Setting the "hardware" > switch to either cpu or cuda produces the same error. The client machine > has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. > > Is there any extra information necessary or anything that needs > clarification? > How can I use RTK to reconstruct a volume, if possible? > > Thanks > Micah > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 12 05:19:16 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 12 Oct 2012 11:19:16 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: Message-ID: Hi Marta, Thanks for the feedback. Yes, we would be interested in knowing what are the problems with getopt.h. Could you send us more information (logs, Windows version, compiler, ...)? Regarding Cuda, this is a bit of a weird problem. I have tried to merge the latest version of Plastimatch cmake files with rtk. Could you update your RTK repository and give it another try? A simple Shepp Logan reconstruction example is available here http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are available here http://wiki.openrtk.org/index.php/RTK/Users. Good luck, Simon On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni wrote: > Dear Simon and David, > was a pleasure to meet you at MICCAI. As I mentioned, we are looking into > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a look > at IRTK. > > Now, problem is that we were not able to compile it neither on windows nor > linux (arch distrib). > > For windows, main issues were related to the windows version of getopt which > generate syntax error (Marco can provide you a log file, if you'd like). > > For linux, I had cuda problem. In particular, although correctly configured, > I am stuck with this: > [ 7%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, > surface, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:100: error: there are no arguments to > '__surf1Dreadc1' that depend on a template parameter, so a declaration of > '__surf1Dreadc1' must be available > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', G++ > will accept your code, but allowing the use of an undeclared name is > deprecated) > /usr/include/surface_functions.h:101: error: there are no arguments to > '__surf1Dreads1' that depend on a template parameter, so a declaration of > '__surf1Dreads1' must be available > /usr/include/surface_functions.h:102: error: there are no arguments to > '__surf1Dreadu1' that depend on a template parameter, so a declaration of > '__surf1Dreadu1' must be available > /usr/include/surface_functions.h:103: error: there are no arguments to > '__surf1Dreadu2' that depend on a template parameter, so a declaration of > '__surf1Dreadu2' must be available > /usr/include/surface_functions.h:104: error: there are no arguments to > '__surf1Dreadu4' that depend on a template parameter, so a declaration of > '__surf1Dreadu4' must be available > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, > surface, int, int, int, cudaSurfaceBoundaryMode)': > /usr/include/surface_functions.h:460: error: there are no arguments to > '__surf2Dreadc1' that depend on a template parameter, so a declaration of > '__surf2Dreadc1' must be available > /usr/include/surface_functions.h:461: error: there are no arguments to > '__surf2Dreads1' that depend on a template parameter, so a declaration of > '__surf2Dreads1' must be available > /usr/include/surface_functions.h:462: error: there are no arguments to > '__surf2Dreadu1' that depend on a template parameter, so a declaration of > '__surf2Dreadu1' must be available > /usr/include/surface_functions.h:463: error: there are no arguments to > '__surf2Dreadu2' that depend on a template parameter, so a declaration of > '__surf2Dreadu2' must be available > /usr/include/surface_functions.h:464: error: there are no arguments to > '__surf2Dreadu4' that depend on a template parameter, so a declaration of > '__surf2Dreadu4' must be available > CMake Error at > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 (message): > Error generating file > > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > > make[2]: *** > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] > Error 1 > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 > make: *** [all] Error 2 > > I remember having the same issue in plastimatch some time ago (it is due to > cuda version) and James added some -fpermissive to fix the issue. > > But anyhow, can you please guide us through a compilation to make it work > and test it on the new projections? > > thanks a lot > Best Regards, > Marta Peroni > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Mon Oct 15 13:53:13 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Mon, 15 Oct 2012 19:53:13 +0200 Subject: [Rtk-users] FirstReconstruction example Message-ID: <20121015175313.49610@gmx.net> Hello, I have questions concerning the FirstReconstruction example: Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? Sorry for the detailed questions, I just would like to understand how RTK is working. Thanks a lot! LF From simon.rit at creatis.insa-lyon.fr Mon Oct 15 16:17:59 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 15 Oct 2012 22:17:59 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121015175313.49610@gmx.net> References: <20121015175313.49610@gmx.net> Message-ID: Hi Lars, The geometry is described in the document geometry.tex, I have added links at the end of the user's wiki page http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with coordinates 0,0,0 of your volume is the isocenter, the point with coordinate 0,0 in projection images is the intersection of your flat panel with the line going through the x-ray source and the isocenter. The image origin is defined by ITK as the center of the pixel with index 0 in memory (first pixel in memory). I hope this helps, Simon On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars wrote: > Hello, > > I have questions concerning the FirstReconstruction example: > Using the rtk::RayEllipsoidIntersectionImageFilter and rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are packed in the form of an image stack. The geometry of the projections is described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the images' metrics are described by the image stack itself (spacing, size and ORIGIN). > > How should I interpret the origin? As far as I could find out by minor modifications of the example, the origin of the projeciton image stack plays a role (if I change it to 0,0,0, and retain constantImageSource2's origin at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does the origin of the image stack matter? Isn't the origin of a single projection fully defined by the corresponding entry in the rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the offset from the detector central axis crossing point)? Am I right that the effective origin of a single projection image emerges basically from the detector (x/y of origin of image stack) and from consecutive application of the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, e.g. caused by gravity, wouldn't be simulatable. > > Morever, which point exactly does the image origin (x/y components) of the projection stack describe? Is it the outer corner of the projection or the center of the first voxel (as in DICOM). The size of a projection in the example is 256.0x256.0 units. However, the stack's origin is at -127.0,-127.0. If the origin should refer to the center of the first projection pixel, it should be essentially -127.5,-127.5, right? > > Sorry for the detailed questions, I just would like to understand how RTK is working. > > Thanks a lot! > > LF > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:03:43 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:03:43 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> Message-ID: <20121016080343.49570@gmx.net> Hi Simon, thanks for your reply! I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. Basically, the first sentence in section 6 of the doc "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." along with another sentence in this section "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... Thanks so far! LF -------- Original-Nachricht -------- > Datum: Mon, 15 Oct 2012 22:17:59 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > Hi Lars, > The geometry is described in the document geometry.tex, I have added > links at the end of the user's wiki page > http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > coordinates 0,0,0 of your volume is the isocenter, the point with > coordinate 0,0 in projection images is the intersection of your flat > panel with the line going through the x-ray source and the isocenter. > The image origin is defined by ITK as the center of the pixel with > index 0 in memory (first pixel in memory). > I hope this helps, > Simon > > On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > wrote: > > Hello, > > > > I have questions concerning the FirstReconstruction example: > > Using the rtk::RayEllipsoidIntersectionImageFilter and > rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are > packed in the form of an image stack. The geometry of the projections is > described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the > images' metrics are described by the image stack itself (spacing, size and > ORIGIN). > > > > How should I interpret the origin? As far as I could find out by minor > modifications of the example, the origin of the projeciton image stack plays > a role (if I change it to 0,0,0, and retain constantImageSource2's origin > at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does > the origin of the image stack matter? Isn't the origin of a single > projection fully defined by the corresponding entry in the > rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the > offset from the detector central axis crossing point)? Am I right that the > effective origin of a single projection image emerges basically from the > detector (x/y of origin of image stack) and from consecutive application of > the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, > e.g. caused by gravity, wouldn't be simulatable. > > > > Morever, which point exactly does the image origin (x/y components) of > the projection stack describe? Is it the outer corner of the projection or > the center of the first voxel (as in DICOM). The size of a projection in the > example is 256.0x256.0 units. However, the stack's origin is at > -127.0,-127.0. If the origin should refer to the center of the first projection > pixel, it should be essentially -127.5,-127.5, right? > > > > Sorry for the detailed questions, I just would like to understand how > RTK is working. > > > > Thanks a lot! > > > > LF > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Tue Oct 16 04:23:17 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 16 Oct 2012 10:23:17 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: <20121016080343.49570@gmx.net> References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: I agree, geometry is irritating! I'm sorry my comments were part of this irritation... It seemed obvious to me that the origin and the direction in itk::Image has to be accounted for but I'll add a comment in the header to make it clearer. Bear in mind that this on-going work so feel free to suggest improvements and clarifications. Regarding geometry conversion, we had done a work with my colleagues from the Universit? Catholique de Louvain to convert their geometry parameterization to RTK parameterization using Maxima. That allowed us to spare some hours spent on deriving the correct formulas... Would you be interested in the script file? Simon On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars wrote: > Hi Simon, > > thanks for your reply! > > I read the geometry-doc and played around with rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > Basically, the first sentence in section 6 of the doc > "This class is meant to define a set of 2D projection images, acquired with a at panel along a circular trajectory, around a 3D tomography." > along with another sentence in this section > "9 parameters are used per projection to define the position of the source and the detector relatively to the fixed coordinate system." > irritated me a bit. I thought that the 3DCircGeom's task is, in addition to defining the source position, to define the position and orientation of the 2D projection images, and the 3DCircGeom is defined in the IEC WCS (relates to it). I did not expect essential projection image metrics except dimension (pixel size) and spacing (because image size in physical units is not part of 3DCircGeom) having any influence on the position and orientation of it, since this is already defined with the 3DCircGeom object. > > My issue at the moment is simply that I have source position, detector position and detector row/column vectors defined in IEC WCS for each projection, and have to convert it somehow into your projection geometry format + (and that's news for me) adjust the image origin of the projection stack. Unfortunately, my geometry is not really a standard circular one (as in case of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > Thanks so far! > > LF > > -------- Original-Nachricht -------- >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 >> Von: Simon Rit >> An: Lars Friedrich Lars >> CC: rtk-users at openrtk.org >> Betreff: Re: [Rtk-users] FirstReconstruction example > >> Hi Lars, >> The geometry is described in the document geometry.tex, I have added >> links at the end of the user's wiki page >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with >> coordinates 0,0,0 of your volume is the isocenter, the point with >> coordinate 0,0 in projection images is the intersection of your flat >> panel with the line going through the x-ray source and the isocenter. >> The image origin is defined by ITK as the center of the pixel with >> index 0 in memory (first pixel in memory). >> I hope this helps, >> Simon >> >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars >> wrote: >> > Hello, >> > >> > I have questions concerning the FirstReconstruction example: >> > Using the rtk::RayEllipsoidIntersectionImageFilter and >> rtk::ConstantImageSource artificial projections of an ellipsoid are generated which are >> packed in the form of an image stack. The geometry of the projections is >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, the >> images' metrics are described by the image stack itself (spacing, size and >> ORIGIN). >> > >> > How should I interpret the origin? As far as I could find out by minor >> modifications of the example, the origin of the projeciton image stack plays >> a role (if I change it to 0,0,0, and retain constantImageSource2's origin >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why does >> the origin of the image stack matter? Isn't the origin of a single >> projection fully defined by the corresponding entry in the >> rtk::ThreeDCircularProjectionGeometry object (I thought the projOffsetX,projOffsetY args define the >> offset from the detector central axis crossing point)? Am I right that the >> effective origin of a single projection image emerges basically from the >> detector (x/y of origin of image stack) and from consecutive application of >> the projOffsetX,projOffsetY args? Otherwise, deviating detector positions, >> e.g. caused by gravity, wouldn't be simulatable. >> > >> > Morever, which point exactly does the image origin (x/y components) of >> the projection stack describe? Is it the outer corner of the projection or >> the center of the first voxel (as in DICOM). The size of a projection in the >> example is 256.0x256.0 units. However, the stack's origin is at >> -127.0,-127.0. If the origin should refer to the center of the first projection >> pixel, it should be essentially -127.5,-127.5, right? >> > >> > Sorry for the detailed questions, I just would like to understand how >> RTK is working. >> > >> > Thanks a lot! >> > >> > LF >> > _______________________________________________ >> > Rtk-users mailing list >> > Rtk-users at openrtk.org >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From lars-friedrich at gmx.net Tue Oct 16 04:55:04 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Tue, 16 Oct 2012 10:55:04 +0200 Subject: [Rtk-users] FirstReconstruction example In-Reply-To: References: <20121015175313.49610@gmx.net> <20121016080343.49570@gmx.net> Message-ID: <20121016085504.78840@gmx.net> Hi, thanks!! Yep, I would be very interested in the script since I would like to try first whether my geometry is generally a no go for the FDK-based approaches in RTK (which I cannot exclude at the moment), before shaping the code and implementing C++-based converters. Lars -------- Original-Nachricht -------- > Datum: Tue, 16 Oct 2012 10:23:17 +0200 > Von: Simon Rit > An: Lars Friedrich Lars > CC: rtk-users at openrtk.org > Betreff: Re: [Rtk-users] FirstReconstruction example > I agree, geometry is irritating! I'm sorry my comments were part of > this irritation... It seemed obvious to me that the origin and the > direction in itk::Image has to be accounted for but I'll add a comment > in the header to make it clearer. Bear in mind that this on-going work > so feel free to suggest improvements and clarifications. > > Regarding geometry conversion, we had done a work with my colleagues > from the Universit? Catholique de Louvain to convert their geometry > parameterization to RTK parameterization using Maxima. That allowed us > to spare some hours spent on deriving the correct formulas... Would > you be interested in the script file? > > Simon > > On Tue, Oct 16, 2012 at 10:03 AM, Lars Friedrich Lars > wrote: > > Hi Simon, > > > > thanks for your reply! > > > > I read the geometry-doc and played around with > rtk::ThreeDCircularProjectionGeometry before I was writing the question in the last mail. > > Basically, the first sentence in section 6 of the doc > > "This class is meant to define a set of 2D projection images, acquired > with a at panel along a circular trajectory, around a 3D tomography." > > along with another sentence in this section > > "9 parameters are used per projection to define the position of the > source and the detector relatively to the fixed coordinate system." > > irritated me a bit. I thought that the 3DCircGeom's task is, in addition > to defining the source position, to define the position and orientation of > the 2D projection images, and the 3DCircGeom is defined in the IEC WCS > (relates to it). I did not expect essential projection image metrics except > dimension (pixel size) and spacing (because image size in physical units is > not part of 3DCircGeom) having any influence on the position and orientation > of it, since this is already defined with the 3DCircGeom object. > > > > My issue at the moment is simply that I have source position, detector > position and detector row/column vectors defined in IEC WCS for each > projection, and have to convert it somehow into your projection geometry format + > (and that's news for me) adjust the image origin of the projection stack. > Unfortunately, my geometry is not really a standard circular one (as in case > of XVI, OBI etc.). Will try to derive an adaptor for conversion ... > > > > Thanks so far! > > > > LF > > > > -------- Original-Nachricht -------- > >> Datum: Mon, 15 Oct 2012 22:17:59 +0200 > >> Von: Simon Rit > >> An: Lars Friedrich Lars > >> CC: rtk-users at openrtk.org > >> Betreff: Re: [Rtk-users] FirstReconstruction example > > > >> Hi Lars, > >> The geometry is described in the document geometry.tex, I have added > >> links at the end of the user's wiki page > >> http://wiki.openrtk.org/index.php/RTK/Users. Briefly, the point with > >> coordinates 0,0,0 of your volume is the isocenter, the point with > >> coordinate 0,0 in projection images is the intersection of your flat > >> panel with the line going through the x-ray source and the isocenter. > >> The image origin is defined by ITK as the center of the pixel with > >> index 0 in memory (first pixel in memory). > >> I hope this helps, > >> Simon > >> > >> On Mon, Oct 15, 2012 at 7:53 PM, Lars Friedrich Lars > >> wrote: > >> > Hello, > >> > > >> > I have questions concerning the FirstReconstruction example: > >> > Using the rtk::RayEllipsoidIntersectionImageFilter and > >> rtk::ConstantImageSource artificial projections of an ellipsoid are > generated which are > >> packed in the form of an image stack. The geometry of the projections > is > >> described by an rtk::ThreeDCircularProjectionGeometry object. Moreover, > the > >> images' metrics are described by the image stack itself (spacing, size > and > >> ORIGIN). > >> > > >> > How should I interpret the origin? As far as I could find out by > minor > >> modifications of the example, the origin of the projeciton image stack > plays > >> a role (if I change it to 0,0,0, and retain constantImageSource2's > origin > >> at -127,-127,-127, just half of the ellipsoid is reconstructed). Why > does > >> the origin of the image stack matter? Isn't the origin of a single > >> projection fully defined by the corresponding entry in the > >> rtk::ThreeDCircularProjectionGeometry object (I thought the > projOffsetX,projOffsetY args define the > >> offset from the detector central axis crossing point)? Am I right that > the > >> effective origin of a single projection image emerges basically from > the > >> detector (x/y of origin of image stack) and from consecutive > application of > >> the projOffsetX,projOffsetY args? Otherwise, deviating detector > positions, > >> e.g. caused by gravity, wouldn't be simulatable. > >> > > >> > Morever, which point exactly does the image origin (x/y components) > of > >> the projection stack describe? Is it the outer corner of the projection > or > >> the center of the first voxel (as in DICOM). The size of a projection > in the > >> example is 256.0x256.0 units. However, the stack's origin is at > >> -127.0,-127.0. If the origin should refer to the center of the first > projection > >> pixel, it should be essentially -127.5,-127.5, right? > >> > > >> > Sorry for the detailed questions, I just would like to understand how > >> RTK is working. > >> > > >> > Thanks a lot! > >> > > >> > LF > >> > _______________________________________________ > >> > Rtk-users mailing list > >> > Rtk-users at openrtk.org > >> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Wed Oct 17 08:56:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 14:56:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> Message-ID: Hi Marta, Yes still ITK 3.20, see instructions here: http://wiki.openrtk.org/index.php/RTK/Users. I fixed the linux error, a commit of 2 days ago was causing it. I don't, however, understand some of your windows errors. It seems that it does not understand the ggo files with enum variables although this has been working on Windows and Linux so far. A potential explanation would be that you have installed an old version of gengetopt on your computer? Maybe you can send me your CMakeCache.txt to help me fixing it? You mentioned a problem with getopt.h in your first email but I did not see it in the log. There is also a linking problem with Cuda that your CMakeCache.txt might help me to understand. Thanks, Simon On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni wrote: > Hi! > sorry that it took soo long to answer. > For windows: > compiler is Visual Studio Express 2008 and we are using Windows 7 (see > log_windows attached) > > For Linux: > I downloaded the latest version from here: https://github.com/SimonRit/RTK > and tried to compile against ITK 3.20 (should I try with ITK4?) > Got over the usual nvcc error, but still could not compile unfortunately > (see log_linux attached) > > thanks a lot > Marta > > On 12 October 2012 11:19, Simon Rit wrote: >> >> Hi Marta, >> Thanks for the feedback. Yes, we would be interested in knowing what >> are the problems with getopt.h. Could you send us more information >> (logs, Windows version, compiler, ...)? >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> merge the latest version of Plastimatch cmake files with rtk. Could >> you update your RTK repository and give it another try? >> A simple Shepp Logan reconstruction example is available here >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> Good luck, >> Simon >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> wrote: >> > Dear Simon and David, >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> > into >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had a >> > look >> > at IRTK. >> > >> > Now, problem is that we were not able to compile it neither on windows >> > nor >> > linux (arch distrib). >> > >> > For windows, main issues were related to the windows version of getopt >> > which >> > generate syntax error (Marco can provide you a log file, if you'd like). >> > >> > For linux, I had cuda problem. In particular, although correctly >> > configured, >> > I am stuck with this: >> > [ 7%] Building NVCC (Device) object >> > >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> > surface, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:100: error: there are no arguments to >> > '__surf1Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadc1' must be available >> > /usr/include/surface_functions.h:100: error: (if you use '-fpermissive', >> > G++ >> > will accept your code, but allowing the use of an undeclared name is >> > deprecated) >> > /usr/include/surface_functions.h:101: error: there are no arguments to >> > '__surf1Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreads1' must be available >> > /usr/include/surface_functions.h:102: error: there are no arguments to >> > '__surf1Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu1' must be available >> > /usr/include/surface_functions.h:103: error: there are no arguments to >> > '__surf1Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu2' must be available >> > /usr/include/surface_functions.h:104: error: there are no arguments to >> > '__surf1Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf1Dreadu4' must be available >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> > /usr/include/surface_functions.h:460: error: there are no arguments to >> > '__surf2Dreadc1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadc1' must be available >> > /usr/include/surface_functions.h:461: error: there are no arguments to >> > '__surf2Dreads1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreads1' must be available >> > /usr/include/surface_functions.h:462: error: there are no arguments to >> > '__surf2Dreadu1' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu1' must be available >> > /usr/include/surface_functions.h:463: error: there are no arguments to >> > '__surf2Dreadu2' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu2' must be available >> > /usr/include/surface_functions.h:464: error: there are no arguments to >> > '__surf2Dreadu4' that depend on a template parameter, so a declaration >> > of >> > '__surf2Dreadu4' must be available >> > CMake Error at >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> > (message): >> > Error generating file >> > >> > >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > >> > >> > make[2]: *** >> > >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> > Error 1 >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> > make: *** [all] Error 2 >> > >> > I remember having the same issue in plastimatch some time ago (it is due >> > to >> > cuda version) and James added some -fpermissive to fix the issue. >> > >> > But anyhow, can you please guide us through a compilation to make it >> > work >> > and test it on the new projections? >> > >> > thanks a lot >> > Best Regards, >> > Marta Peroni >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:18:11 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:18:11 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> Message-ID: The other linux compile errors have been fixed, they were caused by the recent gcc that you seem to be using. Sorry for this hassle, we do not have tested all possible combinations of gccs yet... >From your CMakeCache.txt, it seems that you have gengetopt installed here: C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe A way to solve this would be to remove it from the Windows path so that cmake doesn't use it because gengetopt code has been copied in RTK and will be compiled automatically if it's not in the path. In the future, we should check on gengetopt version and compile it automatically if the system version is too old. I have opened a bug: http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 This should fix the gengetopt enum errors but I still have to figure out the linking problem if it's still here. It's strange that it does not show up on my windows box... Simon On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni wrote: > Hi Simon! > that fixed the error thanks :) But I am afraid I have another one.... > (log_linux attached hed). > I also send you the CMakeCache.txt, but I am afraid your intuition might be > right... > For windows, where do you get the gengeopt? just to make sure we are > up-to-date > thanks a lot > Marta > > > On 17 October 2012 14:56, Simon Rit wrote: >> >> Hi Marta, >> >> Yes still ITK 3.20, see instructions here: >> http://wiki.openrtk.org/index.php/RTK/Users. >> I fixed the linux error, a commit of 2 days ago was causing it. >> I don't, however, understand some of your windows errors. It seems >> that it does not understand the ggo files with enum variables although >> this has been working on Windows and Linux so far. A potential >> explanation would be that you have installed an old version of >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> to help me fixing it? You mentioned a problem with getopt.h in your >> first email but I did not see it in the log. >> There is also a linking problem with Cuda that your CMakeCache.txt >> might help me to understand. >> Thanks, >> Simon >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> wrote: >> > Hi! >> > sorry that it took soo long to answer. >> > For windows: >> > compiler is Visual Studio Express 2008 and we are using Windows 7 (see >> > log_windows attached) >> > >> > For Linux: >> > I downloaded the latest version from here: >> > https://github.com/SimonRit/RTK >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> > Got over the usual nvcc error, but still could not compile unfortunately >> > (see log_linux attached) >> > >> > thanks a lot >> > Marta >> > >> > On 12 October 2012 11:19, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> are the problems with getopt.h. Could you send us more information >> >> (logs, Windows version, compiler, ...)? >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> you update your RTK repository and give it another try? >> >> A simple Shepp Logan reconstruction example is available here >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> Good luck, >> >> Simon >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> wrote: >> >> > Dear Simon and David, >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are looking >> >> > into >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we had >> >> > a >> >> > look >> >> > at IRTK. >> >> > >> >> > Now, problem is that we were not able to compile it neither on >> >> > windows >> >> > nor >> >> > linux (arch distrib). >> >> > >> >> > For windows, main issues were related to the windows version of >> >> > getopt >> >> > which >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> > like). >> >> > >> >> > For linux, I had cuda problem. In particular, although correctly >> >> > configured, >> >> > I am stuck with this: >> >> > [ 7%] Building NVCC (Device) object >> >> > >> >> > >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:100: error: there are no arguments >> >> > to >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadc1' must be available >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> > '-fpermissive', >> >> > G++ >> >> > will accept your code, but allowing the use of an undeclared name is >> >> > deprecated) >> >> > /usr/include/surface_functions.h:101: error: there are no arguments >> >> > to >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreads1' must be available >> >> > /usr/include/surface_functions.h:102: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu1' must be available >> >> > /usr/include/surface_functions.h:103: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu2' must be available >> >> > /usr/include/surface_functions.h:104: error: there are no arguments >> >> > to >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf1Dreadu4' must be available >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> > /usr/include/surface_functions.h:460: error: there are no arguments >> >> > to >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadc1' must be available >> >> > /usr/include/surface_functions.h:461: error: there are no arguments >> >> > to >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreads1' must be available >> >> > /usr/include/surface_functions.h:462: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu1' must be available >> >> > /usr/include/surface_functions.h:463: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu2' must be available >> >> > /usr/include/surface_functions.h:464: error: there are no arguments >> >> > to >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> > declaration >> >> > of >> >> > '__surf2Dreadu4' must be available >> >> > CMake Error at >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> > (message): >> >> > Error generating file >> >> > >> >> > >> >> > >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> > >> >> > >> >> > make[2]: *** >> >> > >> >> > >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> > Error 1 >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> > make: *** [all] Error 2 >> >> > >> >> > I remember having the same issue in plastimatch some time ago (it is >> >> > due >> >> > to >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> > >> >> > But anyhow, can you please guide us through a compilation to make it >> >> > work >> >> > and test it on the new projections? >> >> > >> >> > thanks a lot >> >> > Best Regards, >> >> > Marta Peroni >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From lars-friedrich at gmx.net Wed Oct 17 10:25:52 2012 From: lars-friedrich at gmx.net (Lars Friedrich Lars) Date: Wed, 17 Oct 2012 16:25:52 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... Message-ID: <20121017142552.78880@gmx.net> Hi Simon, we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? Thank you. p From simon.rit at creatis.insa-lyon.fr Wed Oct 17 10:44:08 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 17 Oct 2012 16:44:08 +0200 Subject: [Rtk-users] deriving from rtk::ProjectionGeometry ... In-Reply-To: <20121017142552.78880@gmx.net> References: <20121017142552.78880@gmx.net> Message-ID: Hi, Yes, this is intentional. FDK requires more than matrices to compute, e.g., the angular gaps (http://www.openrtk.org/Doxygen/classrtk_1_1ThreeDCircularProjectionGeometry.html#ae821fb8a5d01b6dd947fc5f8e54cd676). Just search in the code for where the geometry object is used and you'll understand. What you describe is a rtk::ThreeDCircularProjectionGeometry so you are going to lose more time doing a new geometry file than learning how to use rtk::ThreeDCircularProjectionGeometry. If you give us some details and/or an example, we can help you doing the conversion. The parameters should be very intuitive. Simon On Wed, Oct 17, 2012 at 4:25 PM, Lars Friedrich Lars wrote: > Hi Simon, > > we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix? > > Thank you. > > p > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Thu Oct 18 05:45:23 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 18 Oct 2012 11:45:23 +0200 Subject: [Rtk-users] IRTK compiling problems In-Reply-To: References: <8661_1350033604_q9C9K1hf028809_CAF0oig1j6Omqpmhf5dUe7TBhQJ14vHDrOsv6k+2XHK+sXepnnA@mail.gmail.com> <23621_1350478636_q9HCvDOn004289_CAF0oig2FAKSE=W_45roHiC1yA+eSzJuFJgGkfvLKenbYfzv0pQ@mail.gmail.com> <9115_1350483574_q9HEJWrs014386_CAF0oig0JumNrvzkF28RBGqCi0hRfZuG4OBDTMyyHZptNOZL5dQ@mail.gmail.com> Message-ID: Marta, Sorry, while we were working on compiling RTK for you there has been some other commits that may have caused the problem. Could you give it another try now? It should be fixed according to the dashboard: http://my.cdash.org/index.php?project=RTK Simon On Wed, Oct 17, 2012 at 4:37 PM, Marta Peroni wrote: > Hi Simon! > don't worry, I'm glad I can be useful for testing... > yet another gcc issue I believe: > [ 73%] Building C object > applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/rtkbackprojections_ggo.c.o > Linking CXX executable ../../bin/rtkbackprojections > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaFDKBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaFDKBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv[_ZN3rtk32CudaFDKBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaFDKBackProjectionImageFilter::CudaFDKBackProjectionImageFilter()' > CMakeFiles/rtkbackprojections.dir/rtkbackprojections.cxx.o: In function > `rtk::CudaBackProjectionImageFilter::New()': > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0x18): > undefined reference to `typeinfo for rtk::CudaBackProjectionImageFilter' > rtkbackprojections.cxx:(.text._ZN3rtk29CudaBackProjectionImageFilter3NewEv[_ZN3rtk29CudaBackProjectionImageFilter3NewEv]+0xc9): > undefined reference to > `rtk::CudaBackProjectionImageFilter::CudaBackProjectionImageFilter()' > collect2: error: ld returned 1 exit status > make[2]: *** [bin/rtkbackprojections] Error 1 > make[1]: *** > [applications/rtkbackprojections/CMakeFiles/rtkbackprojections.dir/all] > Error 2 > > make: *** [all] Error 2 > > > I'll let you know very soon about the windows thing...I remember that we > tried to compile without installing gengetopt and it was not compiling it > automatically. Let me give it another shot... > Marta > > On 17 October 2012 16:18, Simon Rit wrote: >> >> The other linux compile errors have been fixed, they were caused by >> the recent gcc that you seem to be using. Sorry for this hassle, we do >> not have tested all possible combinations of gccs yet... >> >> From your CMakeCache.txt, it seems that you have gengetopt installed here: >> C:/Program Files (x86)/GnuWin32/bin/gengetopt.exe >> A way to solve this would be to remove it from the Windows path so >> that cmake doesn't use it because gengetopt code has been copied in >> RTK and will be compiled automatically if it's not in the path. In the >> future, we should check on gengetopt version and compile it >> automatically if the system version is too old. I have opened a bug: >> http://kingkong.grid.creatis.insa-lyon.fr:9002/issues/1707 >> This should fix the gengetopt enum errors but I still have to figure >> out the linking problem if it's still here. It's strange that it does >> not show up on my windows box... >> >> Simon >> >> On Wed, Oct 17, 2012 at 3:08 PM, Marta Peroni >> wrote: >> > Hi Simon! >> > that fixed the error thanks :) But I am afraid I have another one.... >> > (log_linux attached hed). >> > I also send you the CMakeCache.txt, but I am afraid your intuition might >> > be >> > right... >> > For windows, where do you get the gengeopt? just to make sure we are >> > up-to-date >> > thanks a lot >> > Marta >> > >> > >> > On 17 October 2012 14:56, Simon Rit >> > wrote: >> >> >> >> Hi Marta, >> >> >> >> Yes still ITK 3.20, see instructions here: >> >> http://wiki.openrtk.org/index.php/RTK/Users. >> >> I fixed the linux error, a commit of 2 days ago was causing it. >> >> I don't, however, understand some of your windows errors. It seems >> >> that it does not understand the ggo files with enum variables although >> >> this has been working on Windows and Linux so far. A potential >> >> explanation would be that you have installed an old version of >> >> gengetopt on your computer? Maybe you can send me your CMakeCache.txt >> >> to help me fixing it? You mentioned a problem with getopt.h in your >> >> first email but I did not see it in the log. >> >> There is also a linking problem with Cuda that your CMakeCache.txt >> >> might help me to understand. >> >> Thanks, >> >> Simon >> >> >> >> On Wed, Oct 17, 2012 at 9:53 AM, Marta Peroni >> >> >> >> wrote: >> >> > Hi! >> >> > sorry that it took soo long to answer. >> >> > For windows: >> >> > compiler is Visual Studio Express 2008 and we are using Windows 7 >> >> > (see >> >> > log_windows attached) >> >> > >> >> > For Linux: >> >> > I downloaded the latest version from here: >> >> > https://github.com/SimonRit/RTK >> >> > and tried to compile against ITK 3.20 (should I try with ITK4?) >> >> > Got over the usual nvcc error, but still could not compile >> >> > unfortunately >> >> > (see log_linux attached) >> >> > >> >> > thanks a lot >> >> > Marta >> >> > >> >> > On 12 October 2012 11:19, Simon Rit >> >> > wrote: >> >> >> >> >> >> Hi Marta, >> >> >> Thanks for the feedback. Yes, we would be interested in knowing what >> >> >> are the problems with getopt.h. Could you send us more information >> >> >> (logs, Windows version, compiler, ...)? >> >> >> Regarding Cuda, this is a bit of a weird problem. I have tried to >> >> >> merge the latest version of Plastimatch cmake files with rtk. Could >> >> >> you update your RTK repository and give it another try? >> >> >> A simple Shepp Logan reconstruction example is available here >> >> >> http://wiki.openrtk.org/index.php/RTK/Scripts/FDK, code examples are >> >> >> available here http://wiki.openrtk.org/index.php/RTK/Users. >> >> >> Good luck, >> >> >> Simon >> >> >> >> >> >> On Fri, Oct 12, 2012 at 1:42 AM, Marta Peroni >> >> >> wrote: >> >> >> > Dear Simon and David, >> >> >> > was a pleasure to meet you at MICCAI. As I mentioned, we are >> >> >> > looking >> >> >> > into >> >> >> > acquiring CBCT on robotic C-arm at CNAO and as you suggested, we >> >> >> > had >> >> >> > a >> >> >> > look >> >> >> > at IRTK. >> >> >> > >> >> >> > Now, problem is that we were not able to compile it neither on >> >> >> > windows >> >> >> > nor >> >> >> > linux (arch distrib). >> >> >> > >> >> >> > For windows, main issues were related to the windows version of >> >> >> > getopt >> >> >> > which >> >> >> > generate syntax error (Marco can provide you a log file, if you'd >> >> >> > like). >> >> >> > >> >> >> > For linux, I had cuda problem. In particular, although correctly >> >> >> > configured, >> >> >> > I am stuck with this: >> >> >> > [ 7%] Building NVCC (Device) object >> >> >> > >> >> >> > >> >> >> > >> >> >> > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > /usr/include/surface_functions.h: In function 'void surf1Dread(T*, >> >> >> > surface, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:100: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:100: error: (if you use >> >> >> > '-fpermissive', >> >> >> > G++ >> >> >> > will accept your code, but allowing the use of an undeclared name >> >> >> > is >> >> >> > deprecated) >> >> >> > /usr/include/surface_functions.h:101: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:102: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:103: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:104: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf1Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf1Dreadu4' must be available >> >> >> > /usr/include/surface_functions.h: In function 'void surf2Dread(T*, >> >> >> > surface, int, int, int, cudaSurfaceBoundaryMode)': >> >> >> > /usr/include/surface_functions.h:460: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadc1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadc1' must be available >> >> >> > /usr/include/surface_functions.h:461: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreads1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreads1' must be available >> >> >> > /usr/include/surface_functions.h:462: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu1' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu1' must be available >> >> >> > /usr/include/surface_functions.h:463: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu2' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu2' must be available >> >> >> > /usr/include/surface_functions.h:464: error: there are no >> >> >> > arguments >> >> >> > to >> >> >> > '__surf2Dreadu4' that depend on a template parameter, so a >> >> >> > declaration >> >> >> > of >> >> >> > '__surf2Dreadu4' must be available >> >> >> > CMake Error at >> >> >> > cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cmake:252 >> >> >> > (message): >> >> >> > Error generating file >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > /home/marta/provaIRTK/build/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> >> >> > >> >> >> > >> >> >> > make[2]: *** >> >> >> > >> >> >> > >> >> >> > >> >> >> > [code/CMakeFiles/cuda_compile.dir/./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o] >> >> >> > Error 1 >> >> >> > make[1]: *** [code/CMakeFiles/rtkcuda.dir/all] Error 2 >> >> >> > make: *** [all] Error 2 >> >> >> > >> >> >> > I remember having the same issue in plastimatch some time ago (it >> >> >> > is >> >> >> > due >> >> >> > to >> >> >> > cuda version) and James added some -fpermissive to fix the issue. >> >> >> > >> >> >> > But anyhow, can you please guide us through a compilation to make >> >> >> > it >> >> >> > work >> >> >> > and test it on the new projections? >> >> >> > >> >> >> > thanks a lot >> >> >> > Best Regards, >> >> >> > Marta Peroni >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > >> >> >> > ******************************************************************* >> >> >> > Marta Peroni, PhD >> >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> >> > >> >> >> > contacts: >> >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> >> > mobile: +393488202136 (IT) >> >> >> > office: +39 02 2399 9022 >> >> >> > >> >> >> > >> >> >> > ******************************************************************** >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > ******************************************************************* >> >> > Marta Peroni, PhD >> >> > Bioengineering department - Politecnico di Milano (IT) >> >> > >> >> > contacts: >> >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> >> > mobile: +393488202136 (IT) >> >> > office: +39 02 2399 9022 >> >> > >> >> > ******************************************************************** >> >> > >> >> >> >> >> > >> > >> > >> > -- >> > ******************************************************************* >> > Marta Peroni, PhD >> > Bioengineering department - Politecnico di Milano (IT) >> > >> > contacts: >> > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com >> > mobile: +393488202136 (IT) >> > office: +39 02 2399 9022 >> > >> > ******************************************************************** >> > >> >> > > > > -- > ******************************************************************* > Marta Peroni, PhD > Bioengineering department - Politecnico di Milano (IT) > > contacts: > mail: marta.peroni at mail.polimi.it , m.peroni at gmail.com > mobile: +393488202136 (IT) > office: +39 02 2399 9022 > > ******************************************************************** > From hsieandy at gmail.com Tue Oct 23 08:48:32 2012 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 23 Oct 2012 23:48:32 +1100 Subject: [Rtk-users] RTK calculating attenuation from Varian projection Message-ID: Hi Simon, I was looking at "rtkVarianObiRawImageFilter.h", and realized that the attenuation is calculated from the projection image simply via a negative transformation (1-Intensity/HND_MaxIntensity). Is it usually the way this is done, and is there any reason for doing this? I would have thought attenuation should be calculated from intensity via logarithm (since I=I_0 exp(-mu x)). Thanks!! Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 23 12:16:07 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 23 Oct 2012 18:16:07 +0200 Subject: [Rtk-users] RTK calculating attenuation from Varian projection In-Reply-To: References: Message-ID: Hi Andy, Yes you're right, I have actually noticed recently that but I have not worked a lot on Varian images because we don't have a Varian CBCT in Lyon. I only had a sub-sampled acquisition from Greg of a Catphan that I used to roughly check the geometry. As far as I can remember, when I wrote this piece of code, I tried to use the same code as Plastimatch but I could well have done it wrongly. I'm actually waiting for a new complete Catphan acquisition from Greg to correct for this but if you already have a patch to suggest or a set of images to send, feel free to do it. Thanks, Simon On Tue, Oct 23, 2012 at 2:48 PM, Andy Shieh wrote: > Hi Simon, > > I was looking at "rtkVarianObiRawImageFilter.h", and realized that the > attenuation is calculated from the projection image simply via a negative > transformation (1-Intensity/HND_MaxIntensity). > Is it usually the way this is done, and is there any reason for doing this? > I would have thought attenuation should be calculated from intensity via > logarithm (since I=I_0 exp(-mu x)). > Thanks!! > > Cheers, > Andy > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From croow at yahoo.com Tue Oct 23 19:57:12 2012 From: croow at yahoo.com (M Miller) Date: Tue, 23 Oct 2012 16:57:12 -0700 (PDT) Subject: [Rtk-users] Reconstruct from projections; Starter tips Message-ID: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> I'm new to RTK and I'd like to reconstruct some projections into a volume. So far I've only been able to get an "InvalidRequestedRegionError", but I'd like to describe my steps with the hope that someone can point out what I've done wrong. I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample programs seem to work fine as I can successfully walk through the FDK SheppLogan example. My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, covering 360deg of rotation. The center of rotation is 65.93mm from the xray source, and the detector is 870.86mm from the source. The detector is 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. ? I create a geometry file: "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 --sdd=870.86 --sid=65.93" ? Attempt to reconstruct: "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml --path=d:\ct_projections\test\ --regexp=tif$ --output=d:\ct_projections\rtkfdk.mha --divisions=2" ? Output: >Regular expression matches 3143 file(s) >Reading geometry information from d:\ct_projections\geo.xml... >Reconstructing and writing... ExceptionObject caught with writer->Update() > >itk::InvalidRequestedRegionError (0000000000009FED10) >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) throw(class itk::InvalidRequestedRegionError)" >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx >Line: 397 >Description: Requested region is (at least partially) outside the largest possible region. ? I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( reader->Update() )" with just "reader->Update()", otherwise there is no debug information. The "lowmem" switch is required to keep ITK from crashing, which I think is an unrelated problem. I use "divisions=2" because plastimatch would crash for me without specifying something similar. Setting the "hardware" switch to either cpu or cuda produces the same error. The client machine has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. ? Is there any extra information necessary or anything that needs clarification? How can I use RTK to reconstruct a volume, if possible? ? Thanks Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Oct 24 04:27:13 2012 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 24 Oct 2012 10:27:13 +0200 Subject: [Rtk-users] Reconstruct from projections; Starter tips In-Reply-To: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> References: <1351036632.99707.YahooMailClassic@web163803.mail.gq1.yahoo.com> Message-ID: Hi Micah, You did not do a mistake, you have successfully hit a bug. The truth is that I haven't used the divisions option in a very long time... This should now be fixed https://github.com/SimonRit/RTK/commit/10f8e1b0a5f6b69c943d04513135856968e3e62b and I have added an automated test to avoid future inconveniences https://github.com/SimonRit/RTK/commit/0932e38ad73d8e7214adda5103ced38c7b2754d0 Thanks for the report and keep us a posted. By the way, I have not done a lot of work with tif inputs so you might have to modify the tif conversion from raw to attenuation https://github.com/SimonRit/RTK/blob/master/code/rtkTiffLookupTableImageFilter.h Good luck! Simon On Wed, Oct 24, 2012 at 1:57 AM, M Miller wrote: > I'm new to RTK and I'd like to reconstruct some projections into a volume. > So far I've only been able to get an "InvalidRequestedRegionError", but I'd > like to describe my steps with the hope that someone can point out what > I've done wrong. > > I built RTK using VS2010 x64, ITK 3.20.1, and CUDA 4.2. The sample > programs seem to work fine as I can successfully walk through the FDK > SheppLogan example. > > My projections are 3143 16-bit tif files, each 2000x2000 pixels in size, > covering 360deg of rotation. The center of rotation is 65.93mm from the > xray source, and the detector is 870.86mm from the source. The detector is > 2000x2000 pixels in size, with each pixel 0.2mmx0.2mm in size. > > I create a geometry file: > "rtksimulatedgeometry.exe --output=geo.xml --nproj=3143 --arc=360 > --sdd=870.86 --sid=65.93" > > Attempt to reconstruct: > "rtkfdk.exe --verbose --lowmem --geometry d:\ct_projections\geo.xml > --path=d:\ct_projections\test\ --regexp=tif$ > --output=d:\ct_projections\rtkfdk.mha --divisions=2" > > Output: > >Regular expression matches 3143 file(s) > >Reading geometry information from d:\ct_projections\geo.xml... > >Reconstructing and writing... ExceptionObject caught with writer->Update() > > > >itk::InvalidRequestedRegionError (0000000000009FED10) > >Location: "void ___cdecl itk::DataObject::PropagateRequestedRegion(void) > throw(class itk::InvalidRequestedRegionError)" > >File: ..\..\..\InsightToolkit-3.20.1\Code\Common\itkDataObject.cxx > >Line: 397 > >Description: Requested region is (at least partially) outside the largest > possible region. > > I have replaced the original macro "TRY_AND_EXIT_ON_ITK_EXCEPTION( > reader->Update() )" with just "reader->Update()", otherwise there is no > debug information. > > The "lowmem" switch is required to keep ITK from crashing, which I think > is an unrelated problem. I use "divisions=2" because plastimatch would > crash for me without specifying something similar. Setting the "hardware" > switch to either cpu or cuda produces the same error. The client machine > has 32 processors, 128GB RAM, Tesla C2070, and is running Win7 x64. > > Is there any extra information necessary or anything that needs > clarification? > How can I use RTK to reconstruct a volume, if possible? > > Thanks > Micah > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: