From simon.rit at creatis.insa-lyon.fr Sun Feb 1 04:41:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 1 Feb 2015 10:41:03 +0100 Subject: [Rtk-users] RTK In-Reply-To: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> References: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> Message-ID: On Fri, Jan 30, 2015 at 10:19 AM, Robert Callie? wrote: > Hello Simon, > > thank you for the fast reply. > > > > ?Joseph's method samples the ray with one pixel per slice in the main > direction but it does not compute the intersection of the ray with each > voxel. Siddon's method does that. In fig 2 of [Xu and Mueller, 2006], Joseph > is referred to "slice interpolated" and Siddon to "box-line-integrated". > OK, thanks for that hint. I think it will maybe also has the same problem > with divergent rays and missing voxels during the reconstruction. Do you For sure. > have a link to a paper or source to this algorithm. So the algorithm may > work > > As following: > > - calculate intersection with the physical bounding volume (entry > exit points) > > - from entrypoint, determine the 4 voxels that surround this > entrypoint and bilinear interpolate the value at this position and sum it up > > - go to next plane (plane that is most ?perpendicular? to the > current center ray (focus to detector center) ? > > - at the end, the sum is normalized by the ray length ? > (length(exitpoint ? entrypoint)) > > Is that right ? Almost. Maybe I misunderstand your last step but it is actually multiplied by each step length. Normalization occurs during backprojection, not during forward projection. > > > > How can Joseph?s method be used for back projection ? If you write the method as a system matrix, simply take the transpose of it. For (S)ART, you will want to divide by the sum of the weights along one ray which is exactly what you mentionned, the ray length. > > > > ?This sounds very interesting, don't hesitate to share the code and/or the > publication! BTW, what is DDA? > > DDA stands for digital differential analyzer. I use this approach for a > voxel-based forward projector. When I started my project I was looking for a > fast and easy forward projector on voxel basis. > > I found an article about raytracing and acceleration structures where these > people used this 3d dda. They actually needed it to traverse the bounding > hierarchy to get to know what geometry > > the ray intersects with. I slightly modified it to get the intersecetion > length of a ray within a voxel by substraction of the current and previous > step width. I?v attached a zip file that contains this > > modification and the original source code. The original source code is from > www.scratchapixel.com and there is also an article about this topic > (http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-12-introduction-to-acceleration-structures/what-else/). Great, thanks. We'll have a look. Do you distribute this under a specific license? In other words, is there a risk that it would conflict with RTK license? (Apache 2, see website). > > If you have a look at my code you?ll maybe miss some matrix calculation > stuff etc. I use a scene based approach where I place the focus, object and > detector in a so called record. Each record represents the scene geometry at > a certain time, when a projection image was taken. > > Before reconstruction starts I calculate all these positions. I thought this > could be a good approach to decouple the actuall reconstruction algorithm > from the scene geometry. We'll let you know when we look at it if we have questions. > > > > > > ?But generally we use matching resolution between pixels and voxels so the > problem is minimal.? > > Do you mean, that you use a volume resolution that fits to the current > geometry setting and the detector?s pixel resolution ? Yes. > > > > ?Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > Not almost the same. What I mean seems to be simplier. Lets assume the > detector has tilted around the x-axis by 0.25 degrees. The object?s center > is at 0,0,0 and rotation axis is 0,1,0. In FDK you usually got a ray from > source to the voxel center and then you calculate > > the intersection of this ray at the detector plane. To avoid ray plane > intersection calculus, we can rotate the whole system by 0.25 degrees. Means > that the detectors normal now is parallel to the z axis.Of course the > rotation axis is not 0,1,0 any longer and the focus (xray source) > > also is a bit rotated. > > > > ?For the backprojection, we typically used voxel-based backprojection using > the center of the voxel which is faster than what you (seem to) use? > > I think here we mixed something up. This type of back projection is used for > FDK. All my questions were related to S-ART. I need to calculate the weights > > of a voxel for the back projection. To speed it up, I project its vertices > on the detector plane, calc the MEB and the send rays from within this MEB > through the > > voxel and caluclate the intersection length so those rays that will make my > weights. Some people argue that you can use the same backprojection as in FDK to speed up computations. See for example http://www.researchgate.net/profile/Gengsheng_Zeng/publication/12301525_Unmatched_projectorbackprojector_pairs_in_an_iterative_reconstruction_algorithm/links/00b495252b15fc4bb9000000.pdf > > > > > > Best regards, > > Robert > > > > > > P.S. Hello to all the other people here in the mailing list. > > > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Donnerstag, 29. Januar 2015 20:58 > An: Robert Callie? > Cc: rtk-users at openrtk.org > Betreff: Re: RTK > > > > Hi, > Thank you for your interest in RTK. Please use the mailing list for > questions that are of interest to anyone using RTK. > > There are many ways to model the direct problem (forward projection). > Without going into too many details (available in the publications of each > method) : > - "As far as I understand the goal of this approach is to calculate the > intersection length of a ray through a voxel, right ?" False. Joseph's > method samples the ray with one pixel per slice in the main direction but it > does not compute the intersection of the ray with each voxel. Siddon's > method does that. In fig 2 of [Xu and Mueller, 2006], Joseph is referred to > "slice interpolated" and Siddon to "box-line-integrated". > - "I can calculate the intersection length of the ray within a voxel by a > simple substraction, this runs very fast." This sounds very interesting, > don't hesitate to share the code and/or the publication! BTW, what is DDA? > > - Small voxels / pixels, "Did you find a way to handle this ? " We don't > handle this in RTK except if you consider that spatial regularisation (e.g., > total variation) will overcome this problem in a way. But generally we use > matching resolution between pixels and voxels so the problem is minimal. For > the backprojection, we typically used voxel-based backprojection using the > center of the voxel which is faster than what you (seem to) use. I think > that if these things are a problem for you, there is a nice solution called > distance driven (back-)projection (by De Man and Basu). I think it will do > exactly what you want. I haven't implemented it in RTK (yet). > > Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > I hope this helps. Let me know if sg is not clear in my answer! > Cheers, > Simon From riblettmj at mymail.vcu.edu Mon Feb 2 12:03:14 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 12:03:14 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF Message-ID: Hello RTK Users, I?m just getting started using RTK as part of my graduate research and was hoping that someone might be able to help me sort out an issue I?ve been having reconstructing a 3D CBCT image dataset while applying a 4D deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF has been generated by transformix (.mhd format). I followed, for the most part, the MCCBCTReconstruction example on the RTK Wiki. While reconstructing, rtkfdk reads in all of the projections to memory, begins the ?Reconstructing and Writing? phase and proceeds for a few seconds before hanging ? it doesn?t exit or fault, just drops to 0% CPU while retaining the projections in memory. By writing some basic debug messages into the source code, I?ve been able to determine that the issue lies somewhere at m_Deformation->Update() [Line 99 of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 makes it past the m_Deformation->SetFrame(iProj) line, but never makes it past the subsequent update. I?m wondering if this has anything to do with the size of the DVF generated by transformix: approximately 4.0GB (512x100x512x10 image, 4-channels, FLOAT). Just to provide a little more background information, I?m running RTK on a 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of memory running Ubuntu 14.04. RTK was built using the default ?Release? make configuration and linked to ITK 4.5.2. Elastix and Transformix are both the latest version, 4.7. Has anyone else run into a similar issue with reconstructing a similar image, or does anyone have any thoughts as to how to resolve this sort of issue? Thanks in advance! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 2 12:19:53 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 2 Feb 2015 18:19:53 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: Hi, You're the first RTK user I know to use it on Sun! Nice! If you've got 64 GB ram, that should be enough... although you could ask elastix to generate a smaller DVF, RTK linearly interpolates between vectors. You could even use B-spline coeffs directly but you'd have to create a new DVF. My guess is that there is a problem with the initialization of m_Deformation since the line you mention is the first time it's ever used in the class. Do you use the rtkfdk app? I would start by checking that the pointer is not null before this line, sg like: std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; If it equals 0, then there is something going with the deformation. You can check it in the main app, rtkfdk.cxx. Simon On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett wrote: > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From riblettmj at mymail.vcu.edu Mon Feb 2 13:44:54 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 13:44:54 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Simon, I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the added debug line you suggested and it doesn?t look like the pointer is null. Running it through gdb, I got the following info: m_Deformation=0x16ff820 (gdb) x 0x16ff820 0x16ff820: 0x011c51d0 (gdb) x 0x011c51d0 0x11c51d0 <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: 0x005fb874 (gdb) x 0x005fb874 0x5fb874 , 3u> >::CreateAnother() const>: 0xe5894855 (gdb) x 0xe5894855 0xe5894855: Cannot access memory at address 0xe5894855 I?m still waiting on the transformix DVF, but I?ll give that a try too when its done. Thanks again! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go ahead and check to see if the pointer is null and let you know. My current check is having transformix to generate a smaller DVF to see if that helps, so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > >> On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> > wrote: >>> Hello RTK Users, >>> >>> I?m just getting started using RTK as part of my graduate research and was >>> hoping that someone might be able to help me sort out an issue I?ve been >>> having reconstructing a 3D CBCT image dataset while applying a 4D >>> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >>> has been generated by transformix (.mhd format). I followed, for the most >>> part, the MCCBCTReconstruction example on the RTK Wiki. >>> >>> While reconstructing, rtkfdk reads in all of the projections to memory, >>> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >>> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >>> retaining the projections in memory. >>> >>> By writing some basic debug messages into the source code, I?ve been able to >>> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >>> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >>> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >>> past the subsequent update. I?m wondering if this has anything to do with >>> the size of the DVF generated by transformix: approximately 4.0GB >>> (512x100x512x10 image, 4-channels, FLOAT). >>> >>> Just to provide a little more background information, I?m running RTK on a >>> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >>> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >>> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >>> latest version, 4.7. >>> >>> Has anyone else run into a similar issue with reconstructing a similar >>> image, or does anyone have any thoughts as to how to resolve this sort of >>> issue? >>> >>> Thanks in advance! >>> >>> ? Matt >>> >>> __ >>> Matthew J. Riblett >>> Virginia Commonwealth University >>> Department of Radiation Oncology >>> Medical Physics Graduate Program >>> >>> Office: Sanger Hall, Room B1-013 >>> 401 College Street | P.O. Box 980058 >>> Richmond, Virginia 23298 >>> >>> VCU Email: riblettmj at vcu.edu >>> MCV Office Phone: +1.804.628.4858 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Feb 3 02:22:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Feb 2015 08:22:54 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: That's weird because SetFrame does nothing else than change the value of the member Frame. Are you sure it's on SetFrame that the crash occurs? On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett wrote: > Simon, > > I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the > added debug line you suggested and it doesn?t look like the pointer is null. > Running it through gdb, I got the following info: > > m_Deformation=0x16ff820 > > (gdb) x 0x16ff820 > 0x16ff820: 0x011c51d0 > (gdb) x 0x011c51d0 > 0x11c51d0 > <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: > 0x005fb874 > (gdb) x 0x005fb874 > 0x5fb874 3u>, 3u> >::CreateAnother() const>: 0xe5894855 > (gdb) x 0xe5894855 > 0xe5894855: Cannot access memory at address 0xe5894855 > > I?m still waiting on the transformix DVF, but I?ll give that a try too when > its done. > > Thanks again! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett > wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go > ahead and check to see if the pointer is null and let you know. My current > check is having transformix to generate a smaller DVF to see if that helps, > so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby > supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: > > Hi, > You're the first RTK user I know to use it on Sun! Nice! > If you've got 64 GB ram, that should be enough... although you could > ask elastix to generate a smaller DVF, RTK linearly interpolates > between vectors. You could even use B-spline coeffs directly but you'd > have to create a new DVF. > My guess is that there is a problem with the initialization of > m_Deformation since the line you mention is the first time it's ever > used in the class. Do you use the rtkfdk app? I would start by > checking that the pointer is not null before this line, sg like: > std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; > If it equals 0, then there is something going with the deformation. > You can check it in the main app, rtkfdk.cxx. > Simon > > On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett > wrote: > > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From riblettmj at mymail.vcu.edu Tue Feb 3 10:36:03 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Tue, 3 Feb 2015 10:36:03 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: <60DCF1BD-5960-4A62-AC13-42897049FDFF@mymail.vcu.edu> Simon, I think that it makes it past SetFrame and crashes on Update. Just to be sure, I put a debug message after SetFrame and it does make it to that point, so its got to be on the Update line. ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 3, 2015, at 2:22 AM, Simon Rit wrote: > > That's weird because SetFrame does nothing else than change the value > of the member Frame. Are you sure it's on SetFrame that the crash > occurs? > > On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett > wrote: >> Simon, >> >> I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the >> added debug line you suggested and it doesn?t look like the pointer is null. >> Running it through gdb, I got the following info: >> >> m_Deformation=0x16ff820 >> >> (gdb) x 0x16ff820 >> 0x16ff820: 0x011c51d0 >> (gdb) x 0x011c51d0 >> 0x11c51d0 >> <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: >> 0x005fb874 >> (gdb) x 0x005fb874 >> 0x5fb874 > 3u>, 3u> >::CreateAnother() const>: 0xe5894855 >> (gdb) x 0xe5894855 >> 0xe5894855: Cannot access memory at address 0xe5894855 >> >> I?m still waiting on the transformix DVF, but I?ll give that a try too when >> its done. >> >> Thanks again! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett >> wrote: >> >> Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go >> ahead and check to see if the pointer is null and let you know. My current >> check is having transformix to generate a smaller DVF to see if that helps, >> so the server is getting that done as we speak. >> >> You might also like to know that I?ve got RTK running on a Cray CX-1 (baby >> supercomputer) sitting next to the aforementioned Sun x4600-M2. :) >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 12:19 PM, Simon Rit >> wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> wrote: >> >> Hello RTK Users, >> >> I?m just getting started using RTK as part of my graduate research and was >> hoping that someone might be able to help me sort out an issue I?ve been >> having reconstructing a 3D CBCT image dataset while applying a 4D >> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >> has been generated by transformix (.mhd format). I followed, for the most >> part, the MCCBCTReconstruction example on the RTK Wiki. >> >> While reconstructing, rtkfdk reads in all of the projections to memory, >> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >> retaining the projections in memory. >> >> By writing some basic debug messages into the source code, I?ve been able to >> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >> past the subsequent update. I?m wondering if this has anything to do with >> the size of the DVF generated by transformix: approximately 4.0GB >> (512x100x512x10 image, 4-channels, FLOAT). >> >> Just to provide a little more background information, I?m running RTK on a >> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >> latest version, 4.7. >> >> Has anyone else run into a similar issue with reconstructing a similar >> image, or does anyone have any thoughts as to how to resolve this sort of >> issue? >> >> Thanks in advance! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Thu Feb 5 06:44:47 2015 From: wuchao04 at gmail.com (Chao Wu) Date: Thu, 5 Feb 2015 12:44:47 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Hi Simon, There is still an issue with gengetopt. The config file cannot be read. The problem seems to be at around line 62 in rtkMacro.h: char *configFile = args_info.config_arg; points configFile to the address storing the config file name, but next cmdline_parser_##ggo_filename##_free(&args_info); frees all string field of args_info, including args_info.config_arg, therefore the content pointed by configFile becomes invalid. Regards, Chao 2014-12-12 14:10 GMT+01:00 Simon Rit : > My fix did not work. Cyril (Mory) reported that multiple options were read > twice. I hope this new fix will work but don't hesitate to report other > issues with gengetopt. > Thanks again for you reports, > Simon > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > wrote: >> >> That makes sense, thanks for the quick usage explanation, and fix. >> (Disabling the override issue makes sense, and I didn't have time to trace >> through gengetopt. I thought I was missing something, as none of the >> non-flag arguments were being reset (to null, or default values, and thus >> thought 'override' meant something else!). >> >> Thanks again, glad the info was helpful. >> >> Steve >> >> >> On 14-12-10 4:01 AM, Simon Rit wrote: >> >> Hi, >> Thanks for the report, very useful information. I could reproduce the bug >> and I hope that I have fixed it. Briefly: >> - I have changed the code because Ben Champion reported memory leaks and I >> noticed that they occured in deprecated functions of gengetopt that I don't >> use anymore, >> - the way the new macro (as well as the previous one) is written is: first >> read the command line to find if a config file is passed, then read the >> config file and finally read the command line again to check that everything >> has been passed. >> - your fix was not perfect because we would not have checked that the >> required options were set, >> - it turns out that disabling the override option did the job. >> Everything sworks fine now but let met know if you notice something wrong >> again. Thanks again, >> Simon >> >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann >> wrote: >>> >>> A recent update to rtkMacro.h seems to have caused the ggo command line >>> processor to ignore command line flags. (i.e. I can't get any verbose output >>> with '-v'). >>> It seems to happen after making a second call to: >>> >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, &args_params) >>> >>> Removing this second call, has resolved the issue for me. >>> I'm not sure, however, what the intended use of the second call was for >>> (it occurs immediately after: >>> >>> args_params.check_required = 1; >>> >>> which I feel could just be moved above the first call, as it happens >>> regardless, but I may be missing something. >>> >>> I've attached my quickly modified rtkMacro.h for comparison to the latest >>> github commit. >>> >>> Anyhow, hopefully this info is useful, and doesn't only affect me. >>> >>> Steve >>> >>> Our system setup: >>> -Ubuntu 14.04 x64 >>> -gcc 4.8.2 >>> -cuda 6.5 >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 5 09:17:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 5 Feb 2015 15:17:34 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Indeed, it looks as if I had not tested it, I thought I had... This patch should fix it. Thanks for the report! Simon On Thu, Feb 5, 2015 at 12:44 PM, Chao Wu wrote: > Hi Simon, > > There is still an issue with gengetopt. The config file cannot be read. > The problem seems to be at around line 62 in rtkMacro.h: > char *configFile = args_info.config_arg; points configFile to the > address storing the config file name, but next > cmdline_parser_##ggo_filename##_free(&args_info); frees all string > field of args_info, including args_info.config_arg, therefore the > content pointed by configFile becomes invalid. > > Regards, > Chao > > 2014-12-12 14:10 GMT+01:00 Simon Rit : > > My fix did not work. Cyril (Mory) reported that multiple options were > read > > twice. I hope this new fix will work but don't hesitate to report other > > issues with gengetopt. > > Thanks again for you reports, > > Simon > > > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > > wrote: > >> > >> That makes sense, thanks for the quick usage explanation, and fix. > >> (Disabling the override issue makes sense, and I didn't have time to > trace > >> through gengetopt. I thought I was missing something, as none of the > >> non-flag arguments were being reset (to null, or default values, and > thus > >> thought 'override' meant something else!). > >> > >> Thanks again, glad the info was helpful. > >> > >> Steve > >> > >> > >> On 14-12-10 4:01 AM, Simon Rit wrote: > >> > >> Hi, > >> Thanks for the report, very useful information. I could reproduce the > bug > >> and I hope that I have fixed it. Briefly: > >> - I have changed the code because Ben Champion reported memory leaks > and I > >> noticed that they occured in deprecated functions of gengetopt that I > don't > >> use anymore, > >> - the way the new macro (as well as the previous one) is written is: > first > >> read the command line to find if a config file is passed, then read the > >> config file and finally read the command line again to check that > everything > >> has been passed. > >> - your fix was not perfect because we would not have checked that the > >> required options were set, > >> - it turns out that disabling the override option did the job. > >> Everything sworks fine now but let met know if you notice something > wrong > >> again. Thanks again, > >> Simon > >> > >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann > >> wrote: > >>> > >>> A recent update to rtkMacro.h seems to have caused the ggo command line > >>> processor to ignore command line flags. (i.e. I can't get any verbose > output > >>> with '-v'). > >>> It seems to happen after making a second call to: > >>> > >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, > &args_params) > >>> > >>> Removing this second call, has resolved the issue for me. > >>> I'm not sure, however, what the intended use of the second call was for > >>> (it occurs immediately after: > >>> > >>> args_params.check_required = 1; > >>> > >>> which I feel could just be moved above the first call, as it happens > >>> regardless, but I may be missing something. > >>> > >>> I've attached my quickly modified rtkMacro.h for comparison to the > latest > >>> github commit. > >>> > >>> Anyhow, hopefully this info is useful, and doesn't only affect me. > >>> > >>> Steve > >>> > >>> Our system setup: > >>> -Ubuntu 14.04 x64 > >>> -gcc 4.8.2 > >>> -cuda 6.5 > >>> > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> > >> > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Fri Feb 6 12:27:13 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Fri, 6 Feb 2015 18:27:13 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont -------------- next part -------------- A non-text attachment was scrubbed... Name: figure1.png Type: image/png Size: 28287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: figure2.png Type: image/png Size: 80102 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SheppLogan.txt URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 9 09:08:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Feb 2015 15:08:12 +0100 Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT wrote: > Hello rtk users, > > I try to use RTK for reconstruction in my lab but I encounter some > problems. > > I try to reconstruct a simulated spheroid. I join my phantom text file > (SheppLogan.txt). > > If I set source_y=0, I get a correct (I guess) reconstruction, see the > joined figure1.png. I use the followind set of commands : > > rtksimulatedgeometry -n 180 --sdd=508.1658133423730 > --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 > --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && > rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha > --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p > /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml > --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" > > But If I set source_y=15, I obtain some strange artefacts as you can see > on figure2.png. Do you know the origin of this pattern (the vertical one) ? > Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this > artefact doesn't exist. > > Thanks in advance and thanks for this nice toolkit. > > regards, > Mathieu Dupont > > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Thu Feb 12 04:25:12 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Thu, 12 Feb 2015 10:25:12 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <681578867.13033470.1423733112438.JavaMail.zimbra@cppm.in2p3.fr> Hi Simon, you are right, it works now. Thanks for your reactivity. ----- Mail original ----- De: "Simon Rit" ?: "Mathieu DUPONT" Cc: rtk-users at public.kitware.com Envoy?: Lundi 9 F?vrier 2015 15:08:12 Objet: Re: [Rtk-users] fdk artefact, sourceOffsetY Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT < mdupont at cppm.in2p3.fr > wrote: Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From lomahu at gmail.com Thu Feb 12 10:04:45 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 10:04:45 -0500 Subject: [Rtk-users] building CUDA Message-ID: HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 10:50:08 2015 From: theday79 at gmail.com (Yang K Park) Date: Thu, 12 Feb 2015 10:50:08 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <000801d046db$94f3eb60$bedbc220$@gmail.com> Hi Howard, Attached is my Cmake capture image for RTK using CUDA6.5. (I?m using the default option of RTK w/o any manual modification). Also, I?m using VS2013 / win7 64. I found your second option ?CUDA_ATTACH_VS_BUILD_RULE_TO_C ? is different from mine (CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE). And why don?t you use the newest version of CUDA (v6.5)? It may work fine regardless of the model of your NVIDIA graphic card (I?ve tested it for multiple computers w/ different graphic card models). CUDA6.5 is convenient to install since a single installation file will be enough which is including the graphic driver, CUDA toolkit, SDK, etc. (not sure this is same as 5.5). Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Howard Sent: Thursday, February 12, 2015 10:05 AM To: rtk-users at openrtk.org Subject: [Rtk-users] building CUDA HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Cuda_RTK_Cmake.PNG Type: image/png Size: 43604 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:16:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:16:17 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: Hi, Cmake automatically checks if you have a cuda compatible GPU. If it cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile applications. So there must be an issue with your graphic card. Check if you can compile and run has_cuda_gpu.c. Simon On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > HI, > > I encountered a problem when building CUDA applications. CUDA 5.5 was > installed on our system. I set the following in ccmake > > CUDA_64_BIT_DEVICE_CODE ON > CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > RTK_USE_CUDA ON > > I could build but no cuda applications were generated. In the bin folder I > saw libITKCudaCommon.a and librtkcuda.a. > > What did I miss? Anybody could shed light on this? Thanks, > > -howard > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From julien.jomier at kitware.com Thu Feb 12 11:23:10 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Thu, 12 Feb 2015 17:23:10 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <54DCD36E.5080903@kitware.com> To follow up, what do you mean by "no cuda applications were generated"? If you have the libraries compiled that means CMake found a working CUDA compatible device. -Julien On 12/02/2015 17:16, Simon Rit wrote: > Hi, > Cmake automatically checks if you have a cuda compatible GPU. If it > cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > applications. So there must be an issue with your graphic card. Check > if you can compile and run has_cuda_gpu.c. > Simon > > On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> HI, >> >> I encountered a problem when building CUDA applications. CUDA 5.5 was >> installed on our system. I set the following in ccmake >> >> CUDA_64_BIT_DEVICE_CODE ON >> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> RTK_USE_CUDA ON >> >> I could build but no cuda applications were generated. In the bin folder I >> saw libITKCudaCommon.a and librtkcuda.a. >> >> What did I miss? Anybody could shed light on this? Thanks, >> >> -howard >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:27:09 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:27:09 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: <54DCD36E.5080903@kitware.com> References: <54DCD36E.5080903@kitware.com> Message-ID: Actually no, librtkcuda is compiled if the cuda library is available but the applications are compiled if the cuda library AND a cuda compatible device are available... That's probably why you observe this. Simon On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier wrote: > To follow up, what do you mean by "no cuda applications were generated"? If > you have the libraries compiled that means CMake found a working CUDA > compatible device. > > -Julien > > > On 12/02/2015 17:16, Simon Rit wrote: >> >> Hi, >> Cmake automatically checks if you have a cuda compatible GPU. If it >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> applications. So there must be an issue with your graphic card. Check >> if you can compile and run has_cuda_gpu.c. >> Simon >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >>> >>> HI, >>> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >>> installed on our system. I set the following in ccmake >>> >>> CUDA_64_BIT_DEVICE_CODE ON >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >>> RTK_USE_CUDA ON >>> >>> I could build but no cuda applications were generated. In the bin folder >>> I >>> saw libITKCudaCommon.a and librtkcuda.a. >>> >>> What did I miss? Anybody could shed light on this? Thanks, >>> >>> -howard >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > From lomahu at gmail.com Thu Feb 12 12:24:12 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 12:24:12 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: Thanks all for your responses to my question. I did not initially set CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: [ 24%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt for reading. [ 25%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt for reading. As I said in my original post, we have CUDA installed on the system (cluster system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the cards would work well although I haven't confirmed that. -howard On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit wrote: > Actually no, librtkcuda is compiled if the cuda library is available > but the applications are compiled if the cuda library AND a cuda > compatible device are available... That's probably why you observe > this. > Simon > > On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > wrote: > > To follow up, what do you mean by "no cuda applications were generated"? > If > > you have the libraries compiled that means CMake found a working CUDA > > compatible device. > > > > -Julien > > > > > > On 12/02/2015 17:16, Simon Rit wrote: > >> > >> Hi, > >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> applications. So there must be an issue with your graphic card. Check > >> if you can compile and run has_cuda_gpu.c. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >>> > >>> HI, > >>> > >>> I encountered a problem when building CUDA applications. CUDA 5.5 was > >>> installed on our system. I set the following in ccmake > >>> > >>> CUDA_64_BIT_DEVICE_CODE ON > >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >>> RTK_USE_CUDA ON > >>> > >>> I could build but no cuda applications were generated. In the bin > folder > >>> I > >>> saw libITKCudaCommon.a and librtkcuda.a. > >>> > >>> What did I miss? Anybody could shed light on this? Thanks, > >>> > >>> -howard > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> _______________________________________________ > >> Rtk-users mailing list > >> Rtk-users at public.kitware.com > >> http://public.kitware.com/mailman/listinfo/rtk-users > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 12:42:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 18:42:15 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: That's more complicated. First, CUDA_HAVE_GPU is normally turned on automatically but maybe it's been turned off due to the problem you're encountering now. The problem you have is probably not specific to RTK, we don't develop FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an option CUDA_BUILD_CUBIN, maybe turn it off? If I were you, I'd try to create a small separate project with has_cuda_gpu.c and check whether it compiles. If it doesn't, try the cmake mailing list. Simon On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > Thanks all for your responses to my question. I did not initially set > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > [ 24%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > for reading. > > > [ 25%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > for reading. > > As I said in my original post, we have CUDA installed on the system (cluster > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > cards would work well although I haven't confirmed that. > > -howard > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit > wrote: >> >> Actually no, librtkcuda is compiled if the cuda library is available >> but the applications are compiled if the cuda library AND a cuda >> compatible device are available... That's probably why you observe >> this. >> Simon >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> wrote: >> > To follow up, what do you mean by "no cuda applications were generated"? >> > If >> > you have the libraries compiled that means CMake found a working CUDA >> > compatible device. >> > >> > -Julien >> > >> > >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> Hi, >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> applications. So there must be an issue with your graphic card. Check >> >> if you can compile and run has_cuda_gpu.c. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >>> >> >>> HI, >> >>> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >> >>> installed on our system. I set the following in ccmake >> >>> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >>> RTK_USE_CUDA ON >> >>> >> >>> I could build but no cuda applications were generated. In the bin >> >>> folder >> >>> I >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >>> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >>> >> >>> -howard >> >>> >> >>> _______________________________________________ >> >>> Rtk-users mailing list >> >>> Rtk-users at public.kitware.com >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >>> >> >> _______________________________________________ >> >> Rtk-users mailing list >> >> Rtk-users at public.kitware.com >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > > > From lomahu at gmail.com Thu Feb 12 13:37:39 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 13:37:39 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: When I did the following: CUDA_HAVE_GPU ON CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) building was successful. I could run rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk using cuda?) with successful reconstruction. It's done in < 15s, wow! A separate question: how to specify cuda for rtksart, rtkadmmwavelets, rtkadmmtotalvariations etc? Thanks, -howard On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit wrote: > That's more complicated. First, CUDA_HAVE_GPU is normally turned on > automatically but maybe it's been turned off due to the problem you're > encountering now. > The problem you have is probably not specific to RTK, we don't develop > FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an > option CUDA_BUILD_CUBIN, maybe turn it off? > If I were you, I'd try to create a small separate project with > has_cuda_gpu.c and check whether it compiles. If it doesn't, try the > cmake mailing list. > Simon > > On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > > Thanks all for your responses to my question. I did not initially set > > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > > > > [ 24%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > > for reading. > > > > > > [ 25%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > > for reading. > > > > As I said in my original post, we have CUDA installed on the system > (cluster > > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > > cards would work well although I haven't confirmed that. > > > > -howard > > > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > wrote: > >> > >> Actually no, librtkcuda is compiled if the cuda library is available > >> but the applications are compiled if the cuda library AND a cuda > >> compatible device are available... That's probably why you observe > >> this. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > >> wrote: > >> > To follow up, what do you mean by "no cuda applications were > generated"? > >> > If > >> > you have the libraries compiled that means CMake found a working CUDA > >> > compatible device. > >> > > >> > -Julien > >> > > >> > > >> > On 12/02/2015 17:16, Simon Rit wrote: > >> >> > >> >> Hi, > >> >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> >> applications. So there must be an issue with your graphic card. Check > >> >> if you can compile and run has_cuda_gpu.c. > >> >> Simon > >> >> > >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >> >>> > >> >>> HI, > >> >>> > >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 > was > >> >>> installed on our system. I set the following in ccmake > >> >>> > >> >>> CUDA_64_BIT_DEVICE_CODE ON > >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >> >>> RTK_USE_CUDA ON > >> >>> > >> >>> I could build but no cuda applications were generated. In the bin > >> >>> folder > >> >>> I > >> >>> saw libITKCudaCommon.a and librtkcuda.a. > >> >>> > >> >>> What did I miss? Anybody could shed light on this? Thanks, > >> >>> > >> >>> -howard > >> >>> > >> >>> _______________________________________________ > >> >>> Rtk-users mailing list > >> >>> Rtk-users at public.kitware.com > >> >>> http://public.kitware.com/mailman/listinfo/rtk-users > >> >>> > >> >> _______________________________________________ > >> >> Rtk-users mailing list > >> >> Rtk-users at public.kitware.com > >> >> http://public.kitware.com/mailman/listinfo/rtk-users > >> >> > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 13:47:54 2015 From: theday79 at gmail.com (Yang-Kyun Park) Date: Thu, 12 Feb 2015 13:47:54 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: hi howard, use following options for fwd and bkward projection --fp CudaRayCast --bp CudaVoxelBased Yang On Feb 12, 2015 1:37 PM, "Howard" wrote: > When I did the following: > > CUDA_HAVE_GPU ON > CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) > CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) > > building was successful. I could run > > rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk > using cuda?) > > with successful reconstruction. It's done in < 15s, wow! > > A separate question: how to specify cuda for rtksart, > rtkadmmwavelets, rtkadmmtotalvariations etc? > > Thanks, > -howard > > > > > > > > > > > On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> wrote: > >> That's more complicated. First, CUDA_HAVE_GPU is normally turned on >> automatically but maybe it's been turned off due to the problem you're >> encountering now. >> The problem you have is probably not specific to RTK, we don't develop >> FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an >> option CUDA_BUILD_CUBIN, maybe turn it off? >> If I were you, I'd try to create a small separate project with >> has_cuda_gpu.c and check whether it compiles. If it doesn't, try the >> cmake mailing list. >> Simon >> >> On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: >> > Thanks all for your responses to my question. I did not initially set >> > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: >> > >> > >> > [ 24%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > >> > [ 25%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > As I said in my original post, we have CUDA installed on the system >> (cluster >> > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are >> > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume >> the >> > cards would work well although I haven't confirmed that. >> > >> > -howard >> > >> > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> > wrote: >> >> >> >> Actually no, librtkcuda is compiled if the cuda library is available >> >> but the applications are compiled if the cuda library AND a cuda >> >> compatible device are available... That's probably why you observe >> >> this. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> >> wrote: >> >> > To follow up, what do you mean by "no cuda applications were >> generated"? >> >> > If >> >> > you have the libraries compiled that means CMake found a working CUDA >> >> > compatible device. >> >> > >> >> > -Julien >> >> > >> >> > >> >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> >> >> Hi, >> >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> >> applications. So there must be an issue with your graphic card. >> Check >> >> >> if you can compile and run has_cuda_gpu.c. >> >> >> Simon >> >> >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >> >>> >> >> >>> HI, >> >> >>> >> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 >> was >> >> >>> installed on our system. I set the following in ccmake >> >> >>> >> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >> >>> RTK_USE_CUDA ON >> >> >>> >> >> >>> I could build but no cuda applications were generated. In the bin >> >> >>> folder >> >> >>> I >> >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >> >>> >> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >> >>> >> >> >>> -howard >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Rtk-users mailing list >> >> >>> Rtk-users at public.kitware.com >> >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >>> >> >> >> _______________________________________________ >> >> >> Rtk-users mailing list >> >> >> Rtk-users at public.kitware.com >> >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> >> >> > >> > >> > >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 13 07:06:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Feb 2015 13:06:34 +0100 Subject: [Rtk-users] ADMMTVReconstruction In-Reply-To: <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> References: <548EA4E1.4090801@creatis.insa-lyon.fr> <54919EE9.3010406@creatis.insa-lyon.fr> <5492A8BB.2030209@creatis.insa-lyon.fr> <000901d02a50$1c14f470$543edd50$@uclouvain.be> <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> Message-ID: Hi, FYI, S?bastien and I have worked on the pipeline that was mentionned in this discussion. The pipeline is now available in the rtkProjectionsReader (see the diagram in the doc ). Every rtk application can use it from command line options. For example, I0 is automatically estimated if the option --i0=0 is used. Don't hesitate to report what is not clear or not working for you. Simon On Thu, Jan 8, 2015 at 4:04 PM, S?bastien Brousmiche < sebastien.brousmiche at uclouvain.be> wrote: > Hi Howard, > > > > Actually there are three values given per projection: I0, a filtered I0 > (RLS) and the FWHM of the background mode. > > You can just use the first value per projection. If ?output? is the buffer > contained in the file (-d) then use I0 = buffer(1:3:end); > > > > Read rtki0estimation.cxx in the application folder for more information. > I?m planning to add more info in the code later. > > > > Best, > > S?bastien > > > > > > *From:* Howard [mailto:lomahu at gmail.com] > *Sent:* jeudi 8 janvier 2015 15:57 > *To:* S?bastien Brousmiche > *Cc:* Simon Rit; rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Hi Sebastien, > > > > Thank you very much for your explanation. I used -d to write I0 > estimations to a file. I found there are >2000 numbers for ~600 > projections. I thought there would be one number for each projection, but > obviously the output numbers are not generated that way. Could you please > describe a bit more on the file format and how to use them? Or simply I > wait for your new mini-pipeline filter? > > > > Regards, > > -howard > > > > On Wed, Jan 7, 2015 at 3:01 AM, S?bastien Brousmiche < > sebastien.brousmiche at uclouvain.be> wrote: > > Hi Howard, > > > > There is an input parameter with the rtki0estimation application (-d) > which allows you to specify the output file with I0 estimates. > > > > The big file you mentioned contains the histograms of each image (65536 > values each) stored consecutively. The first value is the occurrence of > number 0 in your image, second.. 1 and so forth up to 65535. > > > > This application is not particularly interesting to be used in a pipeline. > > > > > Nevertheless, we are developing a mini-pipeline grouping typical > preprocessing filters. It is under validation and I?ll let you know as soon > as it is available for you. > > > > Best, > > S?bastien > > > > > > > > > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Howard > *Sent:* mercredi 7 janvier 2015 00:17 > *To:* Simon Rit > *Cc:* rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Happy New Year, Simon. > > > > Thank you for pointing to me the I0 estimate procedure.I saw an > application rtki0estimation > > under the Applications folder. Is this the tool you meant? I ran it using > all default parameters > > providing with the original projection data. What I obtained was a file: > i0est_histogram.csv. > > From the comments in rtki0estimation.ggo this file is the output with I0 > estimate. For 650 projections > > the file size is around 200MB. I used excel to open the file and found > that the beginning two numbers > > 64408 and 722024 then followed by 0's. In the middle there are some > nonzero numbers. Essentially > > all zeros. > > Since there is not much description of the application, so it is hard to > figure out easily what I am doing. > > I tried to read the source code, but it might be more useful if you can > give some hints on how to > > use it. > > > > Regards, > > -howard > > > > > > On Mon, Jan 5, 2015 at 1:49 AM, Simon Rit > wrote: > > Happy new year Howard, > Normally, this calibration is handled by the flat panel. It uses an > air projection and a dark (no beam) projection to compute the line > integral. However, there might be fluctuations in time of these two > projections. Some people do regular acquisitions of them to capture > the time fluctuations. Otherwise, a constant value might be a good > solution. S?bastien has recently implemented an automated > determination of this constant, maybe you should have a look: > > http://www.openrtk.org/Doxygen/classrtk_1_1I0EstimationProjectionFilter.html > It is already part of the mini-pipeline for ImagX / IBA projections > processing: > > http://www.openrtk.org/Doxygen/classrtk_1_1ImagXRawToAttenuationImageFilter.html > Simon > > > On Fri, Jan 2, 2015 at 10:17 PM, Howard wrote: > > Happy New Year, Cyril. > > > > I realized that our projection data is having some issues with air > > correction. We checked our calibration and it appeared fine. Do you know > by > > any chance whether there is a quick way of correcting that? I searched > > around and found people used a constant air norm image. > > > > Thanks very much, > > -howard > > > > On Thu, Dec 18, 2014 at 5:13 AM, Cyril Mory > > wrote: > >> > >> Hi Howard, > >> > >> I've taken a look at your data. > >> You can apply tv denoising on the out.mha volume and obtain a > >> significantly lower level of noise without blurring structures by using > the > >> following command : > >> rtktotalvariationdenoising -i out.mha -g 0.001 -o > >> tvdenoised/gamma0.001.mha -n 100 > >> > >> I was unable to obtain good results with iterative reconstruction from > the > >> projection data you sent, though. I think the main reason for this is > that > >> your projections have much-higher-than-zero attenuation in air. Your > >> calculation of i0 when converting from intensity to attenuation is > probably > >> not good enough. Try to correct for this effect first. Then you can > start > >> performing SART and Conjugate Gradient reconstructions on your data, and > >> once you get these right, play with ADMM. > >> > >> You might need to remove the table from the projections to be able to > >> restrict the reconstruction volume strictly to the patient, and speed > up the > >> computations. We can provide help for that too. > >> > >> Best regards, > >> Cyril > >> > >> > >> On 12/17/2014 05:02 PM, Howard wrote: > >> > >> Hi Cyril, > >> > >> I've sent you two files via wetransfer.com: one is the sparse > projection > >> set with geometry file and the other is the fdk reconstructed image > based on > >> full projection set. Please let me know if you have trouble receiving > them. > >> > >> Thanks very much for looking into this. > >> > >> -Howard > >> > >> On Wed, Dec 17, 2014 at 10:19 AM, Cyril Mory > >> wrote: > >>> > >>> Hi Howard, > >>> > >>> Thanks for the detailed feedback. > >>> The image getting blurry is typically due to a too high gamma. > Depending > >>> on you data, gamma can have to be set to a very small value (I use > 0.007 in > >>> some reconstructions on clinical data). Can you send over your volume > >>> reconstructed from full projection data, and I'll have a quick look ? > >>> > >>> There is a lot of instinct in the setting of the parameters. With time, > >>> one gets used to finding a correct set of parameters without really > knowing > >>> how. I can also try to reconstruct from your cbct data if you send me > the > >>> projections and the geometry. > >>> > >>> Best regards, > >>> Cyril > >>> > >>> > >>> On 12/17/2014 03:49 PM, Howard wrote: > >>> > >>> Hi Cyril, > >>> > >>> Thanks very much for your detailed and nice description on how to use > the > >>> admmtv reconstruction. I followed your suggestions and re-ran > >>> reconstructions using admmtotalvariation and admmwavelets with cbct > >>> projection data from a thoracic patient. > >>> > >>> I am reporting what I found and hope these will give you information > for > >>> further improvement. > >>> > >>> 1. I repeated admmtotalvariation with 30 iterations. No improvement was > >>> observed. As a matter of fact, the reconstructed image is getting a lot > >>> noiser compared to that using 3 iterations. The contrast is getting > worse as > >>> well. I tried to play around with window & level in case I was fooled > but > >>> apparently more iterations gave worse results. > >>> > >>> 2. Similarly I ran 30 iterations using admmwavelets. Slightly better > >>> reconstruction compared with total variation. > >>> > >>> 3. Then I went ahead to test if TV benefits us anything using the > >>> tvdenoising application on the fdk-reconstructed image reconstructed > from > >>> full projection set. I found that the more iterations, the more blurry > the > >>> image became. For example, with 50 iterations the contrast on the > denoised > >>> image is very low so that the vertebrae and surrounding soft tissue are > >>> hardly distinguishable. Changing gamma's at 0.2, 0.5, 1.0, 10 did not > seem > >>> to make a difference on the image. With 5 iterations the denoising > seems to > >>> work fairly well. Again, changing gamma's didn't make a difference. > >>> I hope I didn't misused the totalvariationdenoising application. The > >>> command I executed was: rtktotalvariationdenoising -i out.mha -o > >>> out_denoising_n50_gamma05 --gamma 0.5 -n 50 > >>> > >>> In summary, tdmmwavelets seems perform better than tdmmtotalvariation > but > >>> neither gave satisfactory results. No sure what we can infer from the > TV > >>> denoising study. I could send my study to you if there is a need. > Please let > >>> me know what tests I could run. Further help on improvement is > definitely > >>> welcome and appreciated. > >>> > >>> -Howard > >>> > >>> On Mon, Dec 15, 2014 at 4:07 AM, Cyril Mory > >>> wrote: > >>>> > >>>> Hello Howard, > >>>> > >>>> Good to hear that you're using RTK :) > >>>> I'll try to answer all your questions, and give you some advice: > >>>> - In general, you can expect some improvement over rtkfdk, but not a > >>>> huge one > >>>> - You can find the calculations in my PhD thesis > >>>> https://tel.archives-ouvertes.fr/tel-00985728 (in English. Only the > >>>> introduction is in French) > >>>> - Adjusting the parameters is, in itself, a research topic (sorry !). > >>>> Alpha controls the amount of regularization and only that (the > higher, the > >>>> more regularization). Beta, theoretically, should only change the > >>>> convergence speed, provided you do an infinite number of iterations > (I know > >>>> it doesn't help, sorry again !). In practice, beta is ubiquitous and > appears > >>>> everywhere in the calculations, therefore it is hard to predict what > effect > >>>> an increase/decrease of beta will give on the images. I would keep it > as is, > >>>> and play on alpha > >>>> - 3 iterations is way too little. I typically used 30 iterations. > Using > >>>> the CUDA forward and back projectors helped a lot maintain the > computation > >>>> time manageable > >>>> - The quality of the results depends a lot on the nature of the image > >>>> you are trying to reconstruct. In a nutshell, the algorithm assumes > that the > >>>> image you are reconstructing has a certain form of regularity, and > discards > >>>> the potential solutions that do not have it. This assumption partly > >>>> compensates for the lack of data. ADMM TV assumes that the image you > are > >>>> reconstructing is piecewise constant, i.e. has large uniform areas > separated > >>>> by sharp borders. If your image is a phantom, it should give good > results. > >>>> If it is a real patient, you should probably change to another > algorithm > >>>> that assumes another form of regularity in the images (try > rtkadmmwavelets) > >>>> - You can find out whether you typical images can benefit from TV > >>>> regularization by reconstructing from all projections with rtkfdk, > then > >>>> applying rtktotalvariationdenoising on the reconstructed volume (try > 50 > >>>> iterations and adjust the gamma parameter: high gamma means high > >>>> regularization). If this denoising implies an unacceptable loss of > quality, > >>>> stay away from TV for these images, and try wavelets > >>>> > >>>> I hope this helps > >>>> > >>>> Looking forward to reading you again, > >>>> Cyril > >>>> > >>>> > >>>> On 12/12/2014 06:42 PM, Howard wrote: > >>>> > >>>> I am testing the ADMM total variation reconstruction with sparse data > >>>> sample. I could reconstruct but the results were not as good as > expected. In > >>>> other words, it didn't show much improvement compared to fdk > reconstruction > >>>> using the same sparse projection data. > >>>> > >>>> The parameters I used in ADMMTV were the following: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --alpha 1 --beta 1000 -n 3 > >>>> > >>>> while the fdk reconstruction parameters are: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --pad 0.1 --hann 0.5 > >>>> > >>>> The dimensions were chosen to include the entire anatomy. 72 > projections > >>>> were selected out of 646 projections for a 360 degree scan for both > >>>> calculations. > >>>> > >>>> What parameters and how can I adjust (like alpha, beta, or > iterations?) > >>>> to improve the ADMMTV reconstruction? There is not much description > of this > >>>> application from the wiki page. > >>>> > >>>> Thanks, > >>>> > >>>> -howard > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Rtk-users mailing list > >>>> Rtk-users at public.kitware.com > >>>> http://public.kitware.com/mailman/listinfo/rtk-users > >>>> > >>>> > >>>> -- > >>>> -- > >>>> Cyril Mory, Post-doc > >>>> CREATIS > >>>> Leon Berard cancer treatment center > >>>> 28 rue La?nnec > >>>> 69373 Lyon cedex 08 FRANCE > >>>> > >>>> Mobile: +33 6 69 46 73 79 > >>> > >>> > >>> -- > >>> -- > >>> Cyril Mory, Post-doc > >>> CREATIS > >>> Leon Berard cancer treatment center > >>> 28 rue La?nnec > >>> 69373 Lyon cedex 08 FRANCE > >>> > >>> Mobile: +33 6 69 46 73 79 > >> > >> > >> -- > >> -- > >> Cyril Mory, Post-doc > >> CREATIS > >> Leon Berard cancer treatment center > >> 28 rue La?nnec > >> 69373 Lyon cedex 08 FRANCE > >> > >> Mobile: +33 6 69 46 73 79 > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > > > > > ------------------------------ > > [image: Image removed by sender.] > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > > > > > > ------------------------------ > > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: not available URL: From Robert.Calliess at gmx.de Tue Feb 24 03:56:15 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 24 Feb 2015 09:56:15 +0100 Subject: [Rtk-users] sart back projection, weighting steps Message-ID: An HTML attachment was scrubbed... URL: From cyril.mory at creatis.insa-lyon.fr Tue Feb 24 04:55:00 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Tue, 24 Feb 2015 10:55:00 +0100 Subject: [Rtk-users] sart back projection, weighting steps In-Reply-To: References: Message-ID: <54EC4A74.2010601@creatis.insa-lyon.fr> Hi Robert, I'm glad to know that most of the explanation text is understandable :) You might want to check this filter: http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html You can use the command line application "rtkbackprojections" with argument --bp to compare "Joseph" and "NormalizedJoseph". When performing a back projection with non-normalized Joseph, the projection values are "splat" (splat is the adjoint operator of interpolation) between the four nearest voxels in each volume plane the ray intersects. Nothing guarantees that every voxel will receive a contribution during this process. How many contributions a voxel receives is determined by the sampling of the projections, which can be much looser or much denser (locally and globally) than what would be required. Dividing by the back projection of an image of ones mitigates this effect. In theory, as long as the forward and back projection operators are the adjoint of one another, it should not be a problem for SART. In practice, it does make a difference. I hope it helps. Please let me know if it is still unclear; Cyril On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward projection, > every pixel is > divided by the intersection length of the ray with the volume. That is > clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This weighting > step is not > performed when using a voxel-based back projection, as the weights > are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all pixels > have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply this > weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate the > pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range from 0 > to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Thu Feb 26 14:35:06 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Thu, 26 Feb 2015 19:35:06 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely,Vahid? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Thu Feb 26 15:18:53 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Thu, 26 Feb 2015 21:18:53 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Message-ID: <00d901d05201$71a49200$54edb600$@gmx.de> Hello Vahid, I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI but with a wider sensor array. I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code. But let?s see what grandmasters of RTK will suggest. Best regards, Robert Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely, Vahid -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Thu Feb 26 16:33:46 2015 From: ghostcz at hotmail.com (louie L) Date: Thu, 26 Feb 2015 22:33:46 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <00d901d05201$71a49200$54edb600$@gmx.de> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work. Best regards, Louie Greetings from my iOS! > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the > resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). > I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around > the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these > seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI > but with a wider sensor array. > > I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it > would be possible to model the helical trajectory by the changing geometry without changing /adding code. > > But let?s see what grandmasters of RTK will suggest. > > Best regards, > Robert > > > Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users > Gesendet: Donnerstag, 26. Februar 2015 20:35 > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK > > Dear RTK users, > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? > I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. > > Sincerely, > Vahid > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From cyril.mory at creatis.insa-lyon.fr Fri Feb 27 03:45:24 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Fri, 27 Feb 2015 09:45:24 +0100 Subject: [Rtk-users] Fwd: Re: Aw: Re: sart back projection, weighting steps In-Reply-To: <54F02E7E.7080000@creatis.insa-lyon.fr> References: <54F02E7E.7080000@creatis.insa-lyon.fr> Message-ID: <54F02EA4.7010006@creatis.insa-lyon.fr> Hi Robert, No problem, glad to help. I think either I have'nt been clear enough, or you're getting confused, though :) Let me try again: In joseph back projection, for each PIXEL, you "draw a line" between the source and the pixel's center, and see which voxels it crosses. Your line crosses each slice of the volume at an intersection point. You determine what the interpolation weights would be if you were to interpolate at this intersection point. And these weights are indeed between 0 and 1. But instead of interpolating, you "splat", that means you update the four nearest voxels by adding (projection's pixel value * interpolationWeight) to each. And you move to the next slice. Once you've considered all rays, you're done. Nothing in this process guarantees that a voxel will receive any contribution. In fact, some receive none, and some too many. The backprojected volume you obtain is "biased". You could think of it as the product of what you really want (the projection's pixel values smeared out along the lines of rays) with a "sampling density map" (the cumulated splat weights each voxel has been updated with). If you back project a projection of ones, then your resulting volume is exactly this sampling density map, and you can divide by it to obtain what you really want. In voxel based back projection, for each voxel, you "draw a line" between the source and the voxel's center, see where it hits the 2D projection, and add the value of that pixel (or interpolated at this position between pixels) into the voxel. And that's it for this voxel, so each voxel gets updated once and only once. And if the projection contains only ones, then your volume gets filled with ones. Dividing by one isn't going to change anything, so you just don't do it. I hope it is clearer. Cyril On 02/26/2015 02:10 PM, "Robert Callie?" wrote: > Hello Cyril, > thank you for the fast reply and thank you for the support. > Indeed I have some more questions. For the normalization step > you on the one hand side create a projection image filled with "1" > and on the other hand side you create an empty (zero) volume and > then back project the image, ok. > >>How many contributions a voxel receives is determined by the > sampling of the projections > Yes, I have the same problems with a voxel-based back projector. But > don't you have > this problem also with joseph's method when you use it for the back > projection of the "1" projection > image ? It's not clear to me how this kind of back projection actually > works (or is calculated). > And if the projection image consists of pixels with value "1" then we > actually don't need it or do we ? > So far I understand, no matter if we perform the forward or back > projtion, the joseph projector calculates > the weightings of the four voxels that are "around" the current plane > intersection point. And this > weights are always between 0 and 1. > Or do I totally misunderstand the concept of this backprojection. > I hope I did not confused you. > best regards, > Robert > *Gesendet:* Dienstag, 24. Februar 2015 um 10:55 Uhr > *Von:* "Cyril Mory" > *An:* "Robert Callie?" , rtk-users at openrtk.org > *Betreff:* Re: [Rtk-users] sart back projection, weighting steps > Hi Robert, > > I'm glad to know that most of the explanation text is understandable :) > You might want to check this filter: > http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html > You can use the command line application "rtkbackprojections" with > argument --bp to compare "Joseph" and "NormalizedJoseph". > > When performing a back projection with non-normalized Joseph, the > projection values are "splat" (splat is the adjoint operator of > interpolation) between the four nearest voxels in each volume plane > the ray intersects. Nothing guarantees that every voxel will receive a > contribution during this process. How many contributions a voxel > receives is determined by the sampling of the projections, which can > be much looser or much denser (locally and globally) than what would > be required. Dividing by the back projection of an image of ones > mitigates this effect. In theory, as long as the forward and back > projection operators are the adjoint of one another, it should not be > a problem for SART. In practice, it does make a difference. > > I hope it helps. Please let me know if it is still unclear; > > Cyril > On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward > projection, every pixel is > divided by the intersection length of the ray with the volume. > That is clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This > weighting step is not > performed when using a voxel-based back projection, as the > weights are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all > pixels have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply > this weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate > the pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range > from 0 to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually > happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 27 04:42:38 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 27 Feb 2015 10:42:38 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry . I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: > Hi, > > You can change the geometry. If changed correctly, most, if not all, the > iterative cone beam reconstruction will work. > > Best regards, > Louie > > Greetings from my iOS! > > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > > I think you need to add a new reconstruction filter for it. For the first > projection the object usually is placed so that the > > resulting projection image covers the upper half of the detector. And you > will need some additional handling (z-increment). > > I guess you could do a little work around with the current rtk. If you > only reconstruct an rectangular roi around > > the detector?s center where the perspective distortion (because of the > cone) is minimal. And then you add these > > seperate volumes to a final volume. This is just an idea. I do not know > how the result will look like. Think of it like a TDI > > but with a wider sensor array. > > > > I do not know the code in detail, but if it were possible to have seperate > geometry settings for every projection image it > > would be possible to model the helical trajectory by the changing geometry > without changing /adding code. > > > > But let?s see what grandmasters of RTK will suggest. > > > > Best regards, > > Robert > > > > > > *Von:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *Im Auftrag von *vahid ettehadi > via Rtk-users > *Gesendet:* Donnerstag, 26. Februar 2015 20:35 > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] Helical cone-beam reconstruction with RTK > > > > Dear RTK users, > > > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT > in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > > I would like to change the current source trajectory from circular to > helical. I was wondering is it possible to use the RTK for helical > reconstruction only with some simple modification? > > I don't know well about reconstruction process and I don't know which type > of modification is necessary to use RTK for a helical cone beam geometry. > So, any suggestion and recommendation would be appreciated. > > > > Sincerely, > > Vahid > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Fri Feb 27 14:24:14 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Fri, 27 Feb 2015 19:24:14 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: Message-ID: <47007992.1342548.1425065054134.JavaMail.yahoo@mail.yahoo.com> Hello,Thank you Robert, Louie and Simon, for your tips and recommendations. I will work on it and I will share the result or potential problems. I found the RTK more accurate and easy to use in compare with other open-source reconstruction tools such as Oscar and NiftyRec.? Thank you RTK team!Vahid On Friday, February 27, 2015 4:42 AM, Simon Rit wrote: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry. I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work.? Best regards,Louie Greetings from my iOS! On 26 Feb 2015, at 21:19, Robert Callie? wrote: Hello Vahid,I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that theresulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment).I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi aroundthe detector?s center where the perspective distortion (because of the cone) is minimal. And then you add theseseperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDIbut with a wider sensor array.?I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code.?But let?s see what grandmasters of RTK will suggest.?Best regards,Robert??????????????? ?Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK?Dear RTK users,??I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated.?Sincerely,Vahid?? _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Sun Feb 1 04:41:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 1 Feb 2015 10:41:03 +0100 Subject: [Rtk-users] RTK In-Reply-To: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> References: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> Message-ID: On Fri, Jan 30, 2015 at 10:19 AM, Robert Callie? wrote: > Hello Simon, > > thank you for the fast reply. > > > > ?Joseph's method samples the ray with one pixel per slice in the main > direction but it does not compute the intersection of the ray with each > voxel. Siddon's method does that. In fig 2 of [Xu and Mueller, 2006], Joseph > is referred to "slice interpolated" and Siddon to "box-line-integrated". > OK, thanks for that hint. I think it will maybe also has the same problem > with divergent rays and missing voxels during the reconstruction. Do you For sure. > have a link to a paper or source to this algorithm. So the algorithm may > work > > As following: > > - calculate intersection with the physical bounding volume (entry > exit points) > > - from entrypoint, determine the 4 voxels that surround this > entrypoint and bilinear interpolate the value at this position and sum it up > > - go to next plane (plane that is most ?perpendicular? to the > current center ray (focus to detector center) ? > > - at the end, the sum is normalized by the ray length ? > (length(exitpoint ? entrypoint)) > > Is that right ? Almost. Maybe I misunderstand your last step but it is actually multiplied by each step length. Normalization occurs during backprojection, not during forward projection. > > > > How can Joseph?s method be used for back projection ? If you write the method as a system matrix, simply take the transpose of it. For (S)ART, you will want to divide by the sum of the weights along one ray which is exactly what you mentionned, the ray length. > > > > ?This sounds very interesting, don't hesitate to share the code and/or the > publication! BTW, what is DDA? > > DDA stands for digital differential analyzer. I use this approach for a > voxel-based forward projector. When I started my project I was looking for a > fast and easy forward projector on voxel basis. > > I found an article about raytracing and acceleration structures where these > people used this 3d dda. They actually needed it to traverse the bounding > hierarchy to get to know what geometry > > the ray intersects with. I slightly modified it to get the intersecetion > length of a ray within a voxel by substraction of the current and previous > step width. I?v attached a zip file that contains this > > modification and the original source code. The original source code is from > www.scratchapixel.com and there is also an article about this topic > (http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-12-introduction-to-acceleration-structures/what-else/). Great, thanks. We'll have a look. Do you distribute this under a specific license? In other words, is there a risk that it would conflict with RTK license? (Apache 2, see website). > > If you have a look at my code you?ll maybe miss some matrix calculation > stuff etc. I use a scene based approach where I place the focus, object and > detector in a so called record. Each record represents the scene geometry at > a certain time, when a projection image was taken. > > Before reconstruction starts I calculate all these positions. I thought this > could be a good approach to decouple the actuall reconstruction algorithm > from the scene geometry. We'll let you know when we look at it if we have questions. > > > > > > ?But generally we use matching resolution between pixels and voxels so the > problem is minimal.? > > Do you mean, that you use a volume resolution that fits to the current > geometry setting and the detector?s pixel resolution ? Yes. > > > > ?Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > Not almost the same. What I mean seems to be simplier. Lets assume the > detector has tilted around the x-axis by 0.25 degrees. The object?s center > is at 0,0,0 and rotation axis is 0,1,0. In FDK you usually got a ray from > source to the voxel center and then you calculate > > the intersection of this ray at the detector plane. To avoid ray plane > intersection calculus, we can rotate the whole system by 0.25 degrees. Means > that the detectors normal now is parallel to the z axis.Of course the > rotation axis is not 0,1,0 any longer and the focus (xray source) > > also is a bit rotated. > > > > ?For the backprojection, we typically used voxel-based backprojection using > the center of the voxel which is faster than what you (seem to) use? > > I think here we mixed something up. This type of back projection is used for > FDK. All my questions were related to S-ART. I need to calculate the weights > > of a voxel for the back projection. To speed it up, I project its vertices > on the detector plane, calc the MEB and the send rays from within this MEB > through the > > voxel and caluclate the intersection length so those rays that will make my > weights. Some people argue that you can use the same backprojection as in FDK to speed up computations. See for example http://www.researchgate.net/profile/Gengsheng_Zeng/publication/12301525_Unmatched_projectorbackprojector_pairs_in_an_iterative_reconstruction_algorithm/links/00b495252b15fc4bb9000000.pdf > > > > > > Best regards, > > Robert > > > > > > P.S. Hello to all the other people here in the mailing list. > > > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Donnerstag, 29. Januar 2015 20:58 > An: Robert Callie? > Cc: rtk-users at openrtk.org > Betreff: Re: RTK > > > > Hi, > Thank you for your interest in RTK. Please use the mailing list for > questions that are of interest to anyone using RTK. > > There are many ways to model the direct problem (forward projection). > Without going into too many details (available in the publications of each > method) : > - "As far as I understand the goal of this approach is to calculate the > intersection length of a ray through a voxel, right ?" False. Joseph's > method samples the ray with one pixel per slice in the main direction but it > does not compute the intersection of the ray with each voxel. Siddon's > method does that. In fig 2 of [Xu and Mueller, 2006], Joseph is referred to > "slice interpolated" and Siddon to "box-line-integrated". > - "I can calculate the intersection length of the ray within a voxel by a > simple substraction, this runs very fast." This sounds very interesting, > don't hesitate to share the code and/or the publication! BTW, what is DDA? > > - Small voxels / pixels, "Did you find a way to handle this ? " We don't > handle this in RTK except if you consider that spatial regularisation (e.g., > total variation) will overcome this problem in a way. But generally we use > matching resolution between pixels and voxels so the problem is minimal. For > the backprojection, we typically used voxel-based backprojection using the > center of the voxel which is faster than what you (seem to) use. I think > that if these things are a problem for you, there is a nice solution called > distance driven (back-)projection (by De Man and Basu). I think it will do > exactly what you want. I haven't implemented it in RTK (yet). > > Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > I hope this helps. Let me know if sg is not clear in my answer! > Cheers, > Simon From riblettmj at mymail.vcu.edu Mon Feb 2 12:03:14 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 12:03:14 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF Message-ID: Hello RTK Users, I?m just getting started using RTK as part of my graduate research and was hoping that someone might be able to help me sort out an issue I?ve been having reconstructing a 3D CBCT image dataset while applying a 4D deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF has been generated by transformix (.mhd format). I followed, for the most part, the MCCBCTReconstruction example on the RTK Wiki. While reconstructing, rtkfdk reads in all of the projections to memory, begins the ?Reconstructing and Writing? phase and proceeds for a few seconds before hanging ? it doesn?t exit or fault, just drops to 0% CPU while retaining the projections in memory. By writing some basic debug messages into the source code, I?ve been able to determine that the issue lies somewhere at m_Deformation->Update() [Line 99 of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 makes it past the m_Deformation->SetFrame(iProj) line, but never makes it past the subsequent update. I?m wondering if this has anything to do with the size of the DVF generated by transformix: approximately 4.0GB (512x100x512x10 image, 4-channels, FLOAT). Just to provide a little more background information, I?m running RTK on a 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of memory running Ubuntu 14.04. RTK was built using the default ?Release? make configuration and linked to ITK 4.5.2. Elastix and Transformix are both the latest version, 4.7. Has anyone else run into a similar issue with reconstructing a similar image, or does anyone have any thoughts as to how to resolve this sort of issue? Thanks in advance! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 2 12:19:53 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 2 Feb 2015 18:19:53 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: Hi, You're the first RTK user I know to use it on Sun! Nice! If you've got 64 GB ram, that should be enough... although you could ask elastix to generate a smaller DVF, RTK linearly interpolates between vectors. You could even use B-spline coeffs directly but you'd have to create a new DVF. My guess is that there is a problem with the initialization of m_Deformation since the line you mention is the first time it's ever used in the class. Do you use the rtkfdk app? I would start by checking that the pointer is not null before this line, sg like: std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; If it equals 0, then there is something going with the deformation. You can check it in the main app, rtkfdk.cxx. Simon On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett wrote: > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From riblettmj at mymail.vcu.edu Mon Feb 2 13:44:54 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 13:44:54 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Simon, I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the added debug line you suggested and it doesn?t look like the pointer is null. Running it through gdb, I got the following info: m_Deformation=0x16ff820 (gdb) x 0x16ff820 0x16ff820: 0x011c51d0 (gdb) x 0x011c51d0 0x11c51d0 <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: 0x005fb874 (gdb) x 0x005fb874 0x5fb874 , 3u> >::CreateAnother() const>: 0xe5894855 (gdb) x 0xe5894855 0xe5894855: Cannot access memory at address 0xe5894855 I?m still waiting on the transformix DVF, but I?ll give that a try too when its done. Thanks again! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go ahead and check to see if the pointer is null and let you know. My current check is having transformix to generate a smaller DVF to see if that helps, so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > >> On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> > wrote: >>> Hello RTK Users, >>> >>> I?m just getting started using RTK as part of my graduate research and was >>> hoping that someone might be able to help me sort out an issue I?ve been >>> having reconstructing a 3D CBCT image dataset while applying a 4D >>> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >>> has been generated by transformix (.mhd format). I followed, for the most >>> part, the MCCBCTReconstruction example on the RTK Wiki. >>> >>> While reconstructing, rtkfdk reads in all of the projections to memory, >>> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >>> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >>> retaining the projections in memory. >>> >>> By writing some basic debug messages into the source code, I?ve been able to >>> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >>> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >>> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >>> past the subsequent update. I?m wondering if this has anything to do with >>> the size of the DVF generated by transformix: approximately 4.0GB >>> (512x100x512x10 image, 4-channels, FLOAT). >>> >>> Just to provide a little more background information, I?m running RTK on a >>> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >>> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >>> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >>> latest version, 4.7. >>> >>> Has anyone else run into a similar issue with reconstructing a similar >>> image, or does anyone have any thoughts as to how to resolve this sort of >>> issue? >>> >>> Thanks in advance! >>> >>> ? Matt >>> >>> __ >>> Matthew J. Riblett >>> Virginia Commonwealth University >>> Department of Radiation Oncology >>> Medical Physics Graduate Program >>> >>> Office: Sanger Hall, Room B1-013 >>> 401 College Street | P.O. Box 980058 >>> Richmond, Virginia 23298 >>> >>> VCU Email: riblettmj at vcu.edu >>> MCV Office Phone: +1.804.628.4858 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Feb 3 02:22:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Feb 2015 08:22:54 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: That's weird because SetFrame does nothing else than change the value of the member Frame. Are you sure it's on SetFrame that the crash occurs? On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett wrote: > Simon, > > I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the > added debug line you suggested and it doesn?t look like the pointer is null. > Running it through gdb, I got the following info: > > m_Deformation=0x16ff820 > > (gdb) x 0x16ff820 > 0x16ff820: 0x011c51d0 > (gdb) x 0x011c51d0 > 0x11c51d0 > <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: > 0x005fb874 > (gdb) x 0x005fb874 > 0x5fb874 3u>, 3u> >::CreateAnother() const>: 0xe5894855 > (gdb) x 0xe5894855 > 0xe5894855: Cannot access memory at address 0xe5894855 > > I?m still waiting on the transformix DVF, but I?ll give that a try too when > its done. > > Thanks again! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett > wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go > ahead and check to see if the pointer is null and let you know. My current > check is having transformix to generate a smaller DVF to see if that helps, > so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby > supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: > > Hi, > You're the first RTK user I know to use it on Sun! Nice! > If you've got 64 GB ram, that should be enough... although you could > ask elastix to generate a smaller DVF, RTK linearly interpolates > between vectors. You could even use B-spline coeffs directly but you'd > have to create a new DVF. > My guess is that there is a problem with the initialization of > m_Deformation since the line you mention is the first time it's ever > used in the class. Do you use the rtkfdk app? I would start by > checking that the pointer is not null before this line, sg like: > std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; > If it equals 0, then there is something going with the deformation. > You can check it in the main app, rtkfdk.cxx. > Simon > > On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett > wrote: > > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From riblettmj at mymail.vcu.edu Tue Feb 3 10:36:03 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Tue, 3 Feb 2015 10:36:03 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: <60DCF1BD-5960-4A62-AC13-42897049FDFF@mymail.vcu.edu> Simon, I think that it makes it past SetFrame and crashes on Update. Just to be sure, I put a debug message after SetFrame and it does make it to that point, so its got to be on the Update line. ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 3, 2015, at 2:22 AM, Simon Rit wrote: > > That's weird because SetFrame does nothing else than change the value > of the member Frame. Are you sure it's on SetFrame that the crash > occurs? > > On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett > wrote: >> Simon, >> >> I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the >> added debug line you suggested and it doesn?t look like the pointer is null. >> Running it through gdb, I got the following info: >> >> m_Deformation=0x16ff820 >> >> (gdb) x 0x16ff820 >> 0x16ff820: 0x011c51d0 >> (gdb) x 0x011c51d0 >> 0x11c51d0 >> <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: >> 0x005fb874 >> (gdb) x 0x005fb874 >> 0x5fb874 > 3u>, 3u> >::CreateAnother() const>: 0xe5894855 >> (gdb) x 0xe5894855 >> 0xe5894855: Cannot access memory at address 0xe5894855 >> >> I?m still waiting on the transformix DVF, but I?ll give that a try too when >> its done. >> >> Thanks again! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett >> wrote: >> >> Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go >> ahead and check to see if the pointer is null and let you know. My current >> check is having transformix to generate a smaller DVF to see if that helps, >> so the server is getting that done as we speak. >> >> You might also like to know that I?ve got RTK running on a Cray CX-1 (baby >> supercomputer) sitting next to the aforementioned Sun x4600-M2. :) >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 12:19 PM, Simon Rit >> wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> wrote: >> >> Hello RTK Users, >> >> I?m just getting started using RTK as part of my graduate research and was >> hoping that someone might be able to help me sort out an issue I?ve been >> having reconstructing a 3D CBCT image dataset while applying a 4D >> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >> has been generated by transformix (.mhd format). I followed, for the most >> part, the MCCBCTReconstruction example on the RTK Wiki. >> >> While reconstructing, rtkfdk reads in all of the projections to memory, >> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >> retaining the projections in memory. >> >> By writing some basic debug messages into the source code, I?ve been able to >> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >> past the subsequent update. I?m wondering if this has anything to do with >> the size of the DVF generated by transformix: approximately 4.0GB >> (512x100x512x10 image, 4-channels, FLOAT). >> >> Just to provide a little more background information, I?m running RTK on a >> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >> latest version, 4.7. >> >> Has anyone else run into a similar issue with reconstructing a similar >> image, or does anyone have any thoughts as to how to resolve this sort of >> issue? >> >> Thanks in advance! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Thu Feb 5 06:44:47 2015 From: wuchao04 at gmail.com (Chao Wu) Date: Thu, 5 Feb 2015 12:44:47 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Hi Simon, There is still an issue with gengetopt. The config file cannot be read. The problem seems to be at around line 62 in rtkMacro.h: char *configFile = args_info.config_arg; points configFile to the address storing the config file name, but next cmdline_parser_##ggo_filename##_free(&args_info); frees all string field of args_info, including args_info.config_arg, therefore the content pointed by configFile becomes invalid. Regards, Chao 2014-12-12 14:10 GMT+01:00 Simon Rit : > My fix did not work. Cyril (Mory) reported that multiple options were read > twice. I hope this new fix will work but don't hesitate to report other > issues with gengetopt. > Thanks again for you reports, > Simon > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > wrote: >> >> That makes sense, thanks for the quick usage explanation, and fix. >> (Disabling the override issue makes sense, and I didn't have time to trace >> through gengetopt. I thought I was missing something, as none of the >> non-flag arguments were being reset (to null, or default values, and thus >> thought 'override' meant something else!). >> >> Thanks again, glad the info was helpful. >> >> Steve >> >> >> On 14-12-10 4:01 AM, Simon Rit wrote: >> >> Hi, >> Thanks for the report, very useful information. I could reproduce the bug >> and I hope that I have fixed it. Briefly: >> - I have changed the code because Ben Champion reported memory leaks and I >> noticed that they occured in deprecated functions of gengetopt that I don't >> use anymore, >> - the way the new macro (as well as the previous one) is written is: first >> read the command line to find if a config file is passed, then read the >> config file and finally read the command line again to check that everything >> has been passed. >> - your fix was not perfect because we would not have checked that the >> required options were set, >> - it turns out that disabling the override option did the job. >> Everything sworks fine now but let met know if you notice something wrong >> again. Thanks again, >> Simon >> >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann >> wrote: >>> >>> A recent update to rtkMacro.h seems to have caused the ggo command line >>> processor to ignore command line flags. (i.e. I can't get any verbose output >>> with '-v'). >>> It seems to happen after making a second call to: >>> >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, &args_params) >>> >>> Removing this second call, has resolved the issue for me. >>> I'm not sure, however, what the intended use of the second call was for >>> (it occurs immediately after: >>> >>> args_params.check_required = 1; >>> >>> which I feel could just be moved above the first call, as it happens >>> regardless, but I may be missing something. >>> >>> I've attached my quickly modified rtkMacro.h for comparison to the latest >>> github commit. >>> >>> Anyhow, hopefully this info is useful, and doesn't only affect me. >>> >>> Steve >>> >>> Our system setup: >>> -Ubuntu 14.04 x64 >>> -gcc 4.8.2 >>> -cuda 6.5 >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 5 09:17:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 5 Feb 2015 15:17:34 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Indeed, it looks as if I had not tested it, I thought I had... This patch should fix it. Thanks for the report! Simon On Thu, Feb 5, 2015 at 12:44 PM, Chao Wu wrote: > Hi Simon, > > There is still an issue with gengetopt. The config file cannot be read. > The problem seems to be at around line 62 in rtkMacro.h: > char *configFile = args_info.config_arg; points configFile to the > address storing the config file name, but next > cmdline_parser_##ggo_filename##_free(&args_info); frees all string > field of args_info, including args_info.config_arg, therefore the > content pointed by configFile becomes invalid. > > Regards, > Chao > > 2014-12-12 14:10 GMT+01:00 Simon Rit : > > My fix did not work. Cyril (Mory) reported that multiple options were > read > > twice. I hope this new fix will work but don't hesitate to report other > > issues with gengetopt. > > Thanks again for you reports, > > Simon > > > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > > wrote: > >> > >> That makes sense, thanks for the quick usage explanation, and fix. > >> (Disabling the override issue makes sense, and I didn't have time to > trace > >> through gengetopt. I thought I was missing something, as none of the > >> non-flag arguments were being reset (to null, or default values, and > thus > >> thought 'override' meant something else!). > >> > >> Thanks again, glad the info was helpful. > >> > >> Steve > >> > >> > >> On 14-12-10 4:01 AM, Simon Rit wrote: > >> > >> Hi, > >> Thanks for the report, very useful information. I could reproduce the > bug > >> and I hope that I have fixed it. Briefly: > >> - I have changed the code because Ben Champion reported memory leaks > and I > >> noticed that they occured in deprecated functions of gengetopt that I > don't > >> use anymore, > >> - the way the new macro (as well as the previous one) is written is: > first > >> read the command line to find if a config file is passed, then read the > >> config file and finally read the command line again to check that > everything > >> has been passed. > >> - your fix was not perfect because we would not have checked that the > >> required options were set, > >> - it turns out that disabling the override option did the job. > >> Everything sworks fine now but let met know if you notice something > wrong > >> again. Thanks again, > >> Simon > >> > >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann > >> wrote: > >>> > >>> A recent update to rtkMacro.h seems to have caused the ggo command line > >>> processor to ignore command line flags. (i.e. I can't get any verbose > output > >>> with '-v'). > >>> It seems to happen after making a second call to: > >>> > >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, > &args_params) > >>> > >>> Removing this second call, has resolved the issue for me. > >>> I'm not sure, however, what the intended use of the second call was for > >>> (it occurs immediately after: > >>> > >>> args_params.check_required = 1; > >>> > >>> which I feel could just be moved above the first call, as it happens > >>> regardless, but I may be missing something. > >>> > >>> I've attached my quickly modified rtkMacro.h for comparison to the > latest > >>> github commit. > >>> > >>> Anyhow, hopefully this info is useful, and doesn't only affect me. > >>> > >>> Steve > >>> > >>> Our system setup: > >>> -Ubuntu 14.04 x64 > >>> -gcc 4.8.2 > >>> -cuda 6.5 > >>> > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> > >> > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Fri Feb 6 12:27:13 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Fri, 6 Feb 2015 18:27:13 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont -------------- next part -------------- A non-text attachment was scrubbed... Name: figure1.png Type: image/png Size: 28287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: figure2.png Type: image/png Size: 80102 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SheppLogan.txt URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 9 09:08:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Feb 2015 15:08:12 +0100 Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT wrote: > Hello rtk users, > > I try to use RTK for reconstruction in my lab but I encounter some > problems. > > I try to reconstruct a simulated spheroid. I join my phantom text file > (SheppLogan.txt). > > If I set source_y=0, I get a correct (I guess) reconstruction, see the > joined figure1.png. I use the followind set of commands : > > rtksimulatedgeometry -n 180 --sdd=508.1658133423730 > --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 > --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && > rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha > --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p > /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml > --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" > > But If I set source_y=15, I obtain some strange artefacts as you can see > on figure2.png. Do you know the origin of this pattern (the vertical one) ? > Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this > artefact doesn't exist. > > Thanks in advance and thanks for this nice toolkit. > > regards, > Mathieu Dupont > > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Thu Feb 12 04:25:12 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Thu, 12 Feb 2015 10:25:12 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <681578867.13033470.1423733112438.JavaMail.zimbra@cppm.in2p3.fr> Hi Simon, you are right, it works now. Thanks for your reactivity. ----- Mail original ----- De: "Simon Rit" ?: "Mathieu DUPONT" Cc: rtk-users at public.kitware.com Envoy?: Lundi 9 F?vrier 2015 15:08:12 Objet: Re: [Rtk-users] fdk artefact, sourceOffsetY Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT < mdupont at cppm.in2p3.fr > wrote: Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From lomahu at gmail.com Thu Feb 12 10:04:45 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 10:04:45 -0500 Subject: [Rtk-users] building CUDA Message-ID: HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 10:50:08 2015 From: theday79 at gmail.com (Yang K Park) Date: Thu, 12 Feb 2015 10:50:08 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <000801d046db$94f3eb60$bedbc220$@gmail.com> Hi Howard, Attached is my Cmake capture image for RTK using CUDA6.5. (I?m using the default option of RTK w/o any manual modification). Also, I?m using VS2013 / win7 64. I found your second option ?CUDA_ATTACH_VS_BUILD_RULE_TO_C ? is different from mine (CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE). And why don?t you use the newest version of CUDA (v6.5)? It may work fine regardless of the model of your NVIDIA graphic card (I?ve tested it for multiple computers w/ different graphic card models). CUDA6.5 is convenient to install since a single installation file will be enough which is including the graphic driver, CUDA toolkit, SDK, etc. (not sure this is same as 5.5). Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Howard Sent: Thursday, February 12, 2015 10:05 AM To: rtk-users at openrtk.org Subject: [Rtk-users] building CUDA HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Cuda_RTK_Cmake.PNG Type: image/png Size: 43604 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:16:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:16:17 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: Hi, Cmake automatically checks if you have a cuda compatible GPU. If it cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile applications. So there must be an issue with your graphic card. Check if you can compile and run has_cuda_gpu.c. Simon On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > HI, > > I encountered a problem when building CUDA applications. CUDA 5.5 was > installed on our system. I set the following in ccmake > > CUDA_64_BIT_DEVICE_CODE ON > CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > RTK_USE_CUDA ON > > I could build but no cuda applications were generated. In the bin folder I > saw libITKCudaCommon.a and librtkcuda.a. > > What did I miss? Anybody could shed light on this? Thanks, > > -howard > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From julien.jomier at kitware.com Thu Feb 12 11:23:10 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Thu, 12 Feb 2015 17:23:10 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <54DCD36E.5080903@kitware.com> To follow up, what do you mean by "no cuda applications were generated"? If you have the libraries compiled that means CMake found a working CUDA compatible device. -Julien On 12/02/2015 17:16, Simon Rit wrote: > Hi, > Cmake automatically checks if you have a cuda compatible GPU. If it > cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > applications. So there must be an issue with your graphic card. Check > if you can compile and run has_cuda_gpu.c. > Simon > > On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> HI, >> >> I encountered a problem when building CUDA applications. CUDA 5.5 was >> installed on our system. I set the following in ccmake >> >> CUDA_64_BIT_DEVICE_CODE ON >> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> RTK_USE_CUDA ON >> >> I could build but no cuda applications were generated. In the bin folder I >> saw libITKCudaCommon.a and librtkcuda.a. >> >> What did I miss? Anybody could shed light on this? Thanks, >> >> -howard >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:27:09 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:27:09 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: <54DCD36E.5080903@kitware.com> References: <54DCD36E.5080903@kitware.com> Message-ID: Actually no, librtkcuda is compiled if the cuda library is available but the applications are compiled if the cuda library AND a cuda compatible device are available... That's probably why you observe this. Simon On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier wrote: > To follow up, what do you mean by "no cuda applications were generated"? If > you have the libraries compiled that means CMake found a working CUDA > compatible device. > > -Julien > > > On 12/02/2015 17:16, Simon Rit wrote: >> >> Hi, >> Cmake automatically checks if you have a cuda compatible GPU. If it >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> applications. So there must be an issue with your graphic card. Check >> if you can compile and run has_cuda_gpu.c. >> Simon >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >>> >>> HI, >>> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >>> installed on our system. I set the following in ccmake >>> >>> CUDA_64_BIT_DEVICE_CODE ON >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >>> RTK_USE_CUDA ON >>> >>> I could build but no cuda applications were generated. In the bin folder >>> I >>> saw libITKCudaCommon.a and librtkcuda.a. >>> >>> What did I miss? Anybody could shed light on this? Thanks, >>> >>> -howard >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > From lomahu at gmail.com Thu Feb 12 12:24:12 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 12:24:12 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: Thanks all for your responses to my question. I did not initially set CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: [ 24%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt for reading. [ 25%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt for reading. As I said in my original post, we have CUDA installed on the system (cluster system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the cards would work well although I haven't confirmed that. -howard On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit wrote: > Actually no, librtkcuda is compiled if the cuda library is available > but the applications are compiled if the cuda library AND a cuda > compatible device are available... That's probably why you observe > this. > Simon > > On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > wrote: > > To follow up, what do you mean by "no cuda applications were generated"? > If > > you have the libraries compiled that means CMake found a working CUDA > > compatible device. > > > > -Julien > > > > > > On 12/02/2015 17:16, Simon Rit wrote: > >> > >> Hi, > >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> applications. So there must be an issue with your graphic card. Check > >> if you can compile and run has_cuda_gpu.c. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >>> > >>> HI, > >>> > >>> I encountered a problem when building CUDA applications. CUDA 5.5 was > >>> installed on our system. I set the following in ccmake > >>> > >>> CUDA_64_BIT_DEVICE_CODE ON > >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >>> RTK_USE_CUDA ON > >>> > >>> I could build but no cuda applications were generated. In the bin > folder > >>> I > >>> saw libITKCudaCommon.a and librtkcuda.a. > >>> > >>> What did I miss? Anybody could shed light on this? Thanks, > >>> > >>> -howard > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> _______________________________________________ > >> Rtk-users mailing list > >> Rtk-users at public.kitware.com > >> http://public.kitware.com/mailman/listinfo/rtk-users > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 12:42:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 18:42:15 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: That's more complicated. First, CUDA_HAVE_GPU is normally turned on automatically but maybe it's been turned off due to the problem you're encountering now. The problem you have is probably not specific to RTK, we don't develop FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an option CUDA_BUILD_CUBIN, maybe turn it off? If I were you, I'd try to create a small separate project with has_cuda_gpu.c and check whether it compiles. If it doesn't, try the cmake mailing list. Simon On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > Thanks all for your responses to my question. I did not initially set > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > [ 24%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > for reading. > > > [ 25%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > for reading. > > As I said in my original post, we have CUDA installed on the system (cluster > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > cards would work well although I haven't confirmed that. > > -howard > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit > wrote: >> >> Actually no, librtkcuda is compiled if the cuda library is available >> but the applications are compiled if the cuda library AND a cuda >> compatible device are available... That's probably why you observe >> this. >> Simon >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> wrote: >> > To follow up, what do you mean by "no cuda applications were generated"? >> > If >> > you have the libraries compiled that means CMake found a working CUDA >> > compatible device. >> > >> > -Julien >> > >> > >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> Hi, >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> applications. So there must be an issue with your graphic card. Check >> >> if you can compile and run has_cuda_gpu.c. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >>> >> >>> HI, >> >>> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >> >>> installed on our system. I set the following in ccmake >> >>> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >>> RTK_USE_CUDA ON >> >>> >> >>> I could build but no cuda applications were generated. In the bin >> >>> folder >> >>> I >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >>> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >>> >> >>> -howard >> >>> >> >>> _______________________________________________ >> >>> Rtk-users mailing list >> >>> Rtk-users at public.kitware.com >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >>> >> >> _______________________________________________ >> >> Rtk-users mailing list >> >> Rtk-users at public.kitware.com >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > > > From lomahu at gmail.com Thu Feb 12 13:37:39 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 13:37:39 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: When I did the following: CUDA_HAVE_GPU ON CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) building was successful. I could run rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk using cuda?) with successful reconstruction. It's done in < 15s, wow! A separate question: how to specify cuda for rtksart, rtkadmmwavelets, rtkadmmtotalvariations etc? Thanks, -howard On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit wrote: > That's more complicated. First, CUDA_HAVE_GPU is normally turned on > automatically but maybe it's been turned off due to the problem you're > encountering now. > The problem you have is probably not specific to RTK, we don't develop > FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an > option CUDA_BUILD_CUBIN, maybe turn it off? > If I were you, I'd try to create a small separate project with > has_cuda_gpu.c and check whether it compiles. If it doesn't, try the > cmake mailing list. > Simon > > On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > > Thanks all for your responses to my question. I did not initially set > > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > > > > [ 24%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > > for reading. > > > > > > [ 25%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > > for reading. > > > > As I said in my original post, we have CUDA installed on the system > (cluster > > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > > cards would work well although I haven't confirmed that. > > > > -howard > > > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > wrote: > >> > >> Actually no, librtkcuda is compiled if the cuda library is available > >> but the applications are compiled if the cuda library AND a cuda > >> compatible device are available... That's probably why you observe > >> this. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > >> wrote: > >> > To follow up, what do you mean by "no cuda applications were > generated"? > >> > If > >> > you have the libraries compiled that means CMake found a working CUDA > >> > compatible device. > >> > > >> > -Julien > >> > > >> > > >> > On 12/02/2015 17:16, Simon Rit wrote: > >> >> > >> >> Hi, > >> >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> >> applications. So there must be an issue with your graphic card. Check > >> >> if you can compile and run has_cuda_gpu.c. > >> >> Simon > >> >> > >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >> >>> > >> >>> HI, > >> >>> > >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 > was > >> >>> installed on our system. I set the following in ccmake > >> >>> > >> >>> CUDA_64_BIT_DEVICE_CODE ON > >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >> >>> RTK_USE_CUDA ON > >> >>> > >> >>> I could build but no cuda applications were generated. In the bin > >> >>> folder > >> >>> I > >> >>> saw libITKCudaCommon.a and librtkcuda.a. > >> >>> > >> >>> What did I miss? Anybody could shed light on this? Thanks, > >> >>> > >> >>> -howard > >> >>> > >> >>> _______________________________________________ > >> >>> Rtk-users mailing list > >> >>> Rtk-users at public.kitware.com > >> >>> http://public.kitware.com/mailman/listinfo/rtk-users > >> >>> > >> >> _______________________________________________ > >> >> Rtk-users mailing list > >> >> Rtk-users at public.kitware.com > >> >> http://public.kitware.com/mailman/listinfo/rtk-users > >> >> > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 13:47:54 2015 From: theday79 at gmail.com (Yang-Kyun Park) Date: Thu, 12 Feb 2015 13:47:54 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: hi howard, use following options for fwd and bkward projection --fp CudaRayCast --bp CudaVoxelBased Yang On Feb 12, 2015 1:37 PM, "Howard" wrote: > When I did the following: > > CUDA_HAVE_GPU ON > CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) > CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) > > building was successful. I could run > > rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk > using cuda?) > > with successful reconstruction. It's done in < 15s, wow! > > A separate question: how to specify cuda for rtksart, > rtkadmmwavelets, rtkadmmtotalvariations etc? > > Thanks, > -howard > > > > > > > > > > > On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> wrote: > >> That's more complicated. First, CUDA_HAVE_GPU is normally turned on >> automatically but maybe it's been turned off due to the problem you're >> encountering now. >> The problem you have is probably not specific to RTK, we don't develop >> FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an >> option CUDA_BUILD_CUBIN, maybe turn it off? >> If I were you, I'd try to create a small separate project with >> has_cuda_gpu.c and check whether it compiles. If it doesn't, try the >> cmake mailing list. >> Simon >> >> On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: >> > Thanks all for your responses to my question. I did not initially set >> > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: >> > >> > >> > [ 24%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > >> > [ 25%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > As I said in my original post, we have CUDA installed on the system >> (cluster >> > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are >> > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume >> the >> > cards would work well although I haven't confirmed that. >> > >> > -howard >> > >> > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> > wrote: >> >> >> >> Actually no, librtkcuda is compiled if the cuda library is available >> >> but the applications are compiled if the cuda library AND a cuda >> >> compatible device are available... That's probably why you observe >> >> this. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> >> wrote: >> >> > To follow up, what do you mean by "no cuda applications were >> generated"? >> >> > If >> >> > you have the libraries compiled that means CMake found a working CUDA >> >> > compatible device. >> >> > >> >> > -Julien >> >> > >> >> > >> >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> >> >> Hi, >> >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> >> applications. So there must be an issue with your graphic card. >> Check >> >> >> if you can compile and run has_cuda_gpu.c. >> >> >> Simon >> >> >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >> >>> >> >> >>> HI, >> >> >>> >> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 >> was >> >> >>> installed on our system. I set the following in ccmake >> >> >>> >> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >> >>> RTK_USE_CUDA ON >> >> >>> >> >> >>> I could build but no cuda applications were generated. In the bin >> >> >>> folder >> >> >>> I >> >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >> >>> >> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >> >>> >> >> >>> -howard >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Rtk-users mailing list >> >> >>> Rtk-users at public.kitware.com >> >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >>> >> >> >> _______________________________________________ >> >> >> Rtk-users mailing list >> >> >> Rtk-users at public.kitware.com >> >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> >> >> > >> > >> > >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 13 07:06:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Feb 2015 13:06:34 +0100 Subject: [Rtk-users] ADMMTVReconstruction In-Reply-To: <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> References: <548EA4E1.4090801@creatis.insa-lyon.fr> <54919EE9.3010406@creatis.insa-lyon.fr> <5492A8BB.2030209@creatis.insa-lyon.fr> <000901d02a50$1c14f470$543edd50$@uclouvain.be> <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> Message-ID: Hi, FYI, S?bastien and I have worked on the pipeline that was mentionned in this discussion. The pipeline is now available in the rtkProjectionsReader (see the diagram in the doc ). Every rtk application can use it from command line options. For example, I0 is automatically estimated if the option --i0=0 is used. Don't hesitate to report what is not clear or not working for you. Simon On Thu, Jan 8, 2015 at 4:04 PM, S?bastien Brousmiche < sebastien.brousmiche at uclouvain.be> wrote: > Hi Howard, > > > > Actually there are three values given per projection: I0, a filtered I0 > (RLS) and the FWHM of the background mode. > > You can just use the first value per projection. If ?output? is the buffer > contained in the file (-d) then use I0 = buffer(1:3:end); > > > > Read rtki0estimation.cxx in the application folder for more information. > I?m planning to add more info in the code later. > > > > Best, > > S?bastien > > > > > > *From:* Howard [mailto:lomahu at gmail.com] > *Sent:* jeudi 8 janvier 2015 15:57 > *To:* S?bastien Brousmiche > *Cc:* Simon Rit; rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Hi Sebastien, > > > > Thank you very much for your explanation. I used -d to write I0 > estimations to a file. I found there are >2000 numbers for ~600 > projections. I thought there would be one number for each projection, but > obviously the output numbers are not generated that way. Could you please > describe a bit more on the file format and how to use them? Or simply I > wait for your new mini-pipeline filter? > > > > Regards, > > -howard > > > > On Wed, Jan 7, 2015 at 3:01 AM, S?bastien Brousmiche < > sebastien.brousmiche at uclouvain.be> wrote: > > Hi Howard, > > > > There is an input parameter with the rtki0estimation application (-d) > which allows you to specify the output file with I0 estimates. > > > > The big file you mentioned contains the histograms of each image (65536 > values each) stored consecutively. The first value is the occurrence of > number 0 in your image, second.. 1 and so forth up to 65535. > > > > This application is not particularly interesting to be used in a pipeline. > > > > > Nevertheless, we are developing a mini-pipeline grouping typical > preprocessing filters. It is under validation and I?ll let you know as soon > as it is available for you. > > > > Best, > > S?bastien > > > > > > > > > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Howard > *Sent:* mercredi 7 janvier 2015 00:17 > *To:* Simon Rit > *Cc:* rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Happy New Year, Simon. > > > > Thank you for pointing to me the I0 estimate procedure.I saw an > application rtki0estimation > > under the Applications folder. Is this the tool you meant? I ran it using > all default parameters > > providing with the original projection data. What I obtained was a file: > i0est_histogram.csv. > > From the comments in rtki0estimation.ggo this file is the output with I0 > estimate. For 650 projections > > the file size is around 200MB. I used excel to open the file and found > that the beginning two numbers > > 64408 and 722024 then followed by 0's. In the middle there are some > nonzero numbers. Essentially > > all zeros. > > Since there is not much description of the application, so it is hard to > figure out easily what I am doing. > > I tried to read the source code, but it might be more useful if you can > give some hints on how to > > use it. > > > > Regards, > > -howard > > > > > > On Mon, Jan 5, 2015 at 1:49 AM, Simon Rit > wrote: > > Happy new year Howard, > Normally, this calibration is handled by the flat panel. It uses an > air projection and a dark (no beam) projection to compute the line > integral. However, there might be fluctuations in time of these two > projections. Some people do regular acquisitions of them to capture > the time fluctuations. Otherwise, a constant value might be a good > solution. S?bastien has recently implemented an automated > determination of this constant, maybe you should have a look: > > http://www.openrtk.org/Doxygen/classrtk_1_1I0EstimationProjectionFilter.html > It is already part of the mini-pipeline for ImagX / IBA projections > processing: > > http://www.openrtk.org/Doxygen/classrtk_1_1ImagXRawToAttenuationImageFilter.html > Simon > > > On Fri, Jan 2, 2015 at 10:17 PM, Howard wrote: > > Happy New Year, Cyril. > > > > I realized that our projection data is having some issues with air > > correction. We checked our calibration and it appeared fine. Do you know > by > > any chance whether there is a quick way of correcting that? I searched > > around and found people used a constant air norm image. > > > > Thanks very much, > > -howard > > > > On Thu, Dec 18, 2014 at 5:13 AM, Cyril Mory > > wrote: > >> > >> Hi Howard, > >> > >> I've taken a look at your data. > >> You can apply tv denoising on the out.mha volume and obtain a > >> significantly lower level of noise without blurring structures by using > the > >> following command : > >> rtktotalvariationdenoising -i out.mha -g 0.001 -o > >> tvdenoised/gamma0.001.mha -n 100 > >> > >> I was unable to obtain good results with iterative reconstruction from > the > >> projection data you sent, though. I think the main reason for this is > that > >> your projections have much-higher-than-zero attenuation in air. Your > >> calculation of i0 when converting from intensity to attenuation is > probably > >> not good enough. Try to correct for this effect first. Then you can > start > >> performing SART and Conjugate Gradient reconstructions on your data, and > >> once you get these right, play with ADMM. > >> > >> You might need to remove the table from the projections to be able to > >> restrict the reconstruction volume strictly to the patient, and speed > up the > >> computations. We can provide help for that too. > >> > >> Best regards, > >> Cyril > >> > >> > >> On 12/17/2014 05:02 PM, Howard wrote: > >> > >> Hi Cyril, > >> > >> I've sent you two files via wetransfer.com: one is the sparse > projection > >> set with geometry file and the other is the fdk reconstructed image > based on > >> full projection set. Please let me know if you have trouble receiving > them. > >> > >> Thanks very much for looking into this. > >> > >> -Howard > >> > >> On Wed, Dec 17, 2014 at 10:19 AM, Cyril Mory > >> wrote: > >>> > >>> Hi Howard, > >>> > >>> Thanks for the detailed feedback. > >>> The image getting blurry is typically due to a too high gamma. > Depending > >>> on you data, gamma can have to be set to a very small value (I use > 0.007 in > >>> some reconstructions on clinical data). Can you send over your volume > >>> reconstructed from full projection data, and I'll have a quick look ? > >>> > >>> There is a lot of instinct in the setting of the parameters. With time, > >>> one gets used to finding a correct set of parameters without really > knowing > >>> how. I can also try to reconstruct from your cbct data if you send me > the > >>> projections and the geometry. > >>> > >>> Best regards, > >>> Cyril > >>> > >>> > >>> On 12/17/2014 03:49 PM, Howard wrote: > >>> > >>> Hi Cyril, > >>> > >>> Thanks very much for your detailed and nice description on how to use > the > >>> admmtv reconstruction. I followed your suggestions and re-ran > >>> reconstructions using admmtotalvariation and admmwavelets with cbct > >>> projection data from a thoracic patient. > >>> > >>> I am reporting what I found and hope these will give you information > for > >>> further improvement. > >>> > >>> 1. I repeated admmtotalvariation with 30 iterations. No improvement was > >>> observed. As a matter of fact, the reconstructed image is getting a lot > >>> noiser compared to that using 3 iterations. The contrast is getting > worse as > >>> well. I tried to play around with window & level in case I was fooled > but > >>> apparently more iterations gave worse results. > >>> > >>> 2. Similarly I ran 30 iterations using admmwavelets. Slightly better > >>> reconstruction compared with total variation. > >>> > >>> 3. Then I went ahead to test if TV benefits us anything using the > >>> tvdenoising application on the fdk-reconstructed image reconstructed > from > >>> full projection set. I found that the more iterations, the more blurry > the > >>> image became. For example, with 50 iterations the contrast on the > denoised > >>> image is very low so that the vertebrae and surrounding soft tissue are > >>> hardly distinguishable. Changing gamma's at 0.2, 0.5, 1.0, 10 did not > seem > >>> to make a difference on the image. With 5 iterations the denoising > seems to > >>> work fairly well. Again, changing gamma's didn't make a difference. > >>> I hope I didn't misused the totalvariationdenoising application. The > >>> command I executed was: rtktotalvariationdenoising -i out.mha -o > >>> out_denoising_n50_gamma05 --gamma 0.5 -n 50 > >>> > >>> In summary, tdmmwavelets seems perform better than tdmmtotalvariation > but > >>> neither gave satisfactory results. No sure what we can infer from the > TV > >>> denoising study. I could send my study to you if there is a need. > Please let > >>> me know what tests I could run. Further help on improvement is > definitely > >>> welcome and appreciated. > >>> > >>> -Howard > >>> > >>> On Mon, Dec 15, 2014 at 4:07 AM, Cyril Mory > >>> wrote: > >>>> > >>>> Hello Howard, > >>>> > >>>> Good to hear that you're using RTK :) > >>>> I'll try to answer all your questions, and give you some advice: > >>>> - In general, you can expect some improvement over rtkfdk, but not a > >>>> huge one > >>>> - You can find the calculations in my PhD thesis > >>>> https://tel.archives-ouvertes.fr/tel-00985728 (in English. Only the > >>>> introduction is in French) > >>>> - Adjusting the parameters is, in itself, a research topic (sorry !). > >>>> Alpha controls the amount of regularization and only that (the > higher, the > >>>> more regularization). Beta, theoretically, should only change the > >>>> convergence speed, provided you do an infinite number of iterations > (I know > >>>> it doesn't help, sorry again !). In practice, beta is ubiquitous and > appears > >>>> everywhere in the calculations, therefore it is hard to predict what > effect > >>>> an increase/decrease of beta will give on the images. I would keep it > as is, > >>>> and play on alpha > >>>> - 3 iterations is way too little. I typically used 30 iterations. > Using > >>>> the CUDA forward and back projectors helped a lot maintain the > computation > >>>> time manageable > >>>> - The quality of the results depends a lot on the nature of the image > >>>> you are trying to reconstruct. In a nutshell, the algorithm assumes > that the > >>>> image you are reconstructing has a certain form of regularity, and > discards > >>>> the potential solutions that do not have it. This assumption partly > >>>> compensates for the lack of data. ADMM TV assumes that the image you > are > >>>> reconstructing is piecewise constant, i.e. has large uniform areas > separated > >>>> by sharp borders. If your image is a phantom, it should give good > results. > >>>> If it is a real patient, you should probably change to another > algorithm > >>>> that assumes another form of regularity in the images (try > rtkadmmwavelets) > >>>> - You can find out whether you typical images can benefit from TV > >>>> regularization by reconstructing from all projections with rtkfdk, > then > >>>> applying rtktotalvariationdenoising on the reconstructed volume (try > 50 > >>>> iterations and adjust the gamma parameter: high gamma means high > >>>> regularization). If this denoising implies an unacceptable loss of > quality, > >>>> stay away from TV for these images, and try wavelets > >>>> > >>>> I hope this helps > >>>> > >>>> Looking forward to reading you again, > >>>> Cyril > >>>> > >>>> > >>>> On 12/12/2014 06:42 PM, Howard wrote: > >>>> > >>>> I am testing the ADMM total variation reconstruction with sparse data > >>>> sample. I could reconstruct but the results were not as good as > expected. In > >>>> other words, it didn't show much improvement compared to fdk > reconstruction > >>>> using the same sparse projection data. > >>>> > >>>> The parameters I used in ADMMTV were the following: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --alpha 1 --beta 1000 -n 3 > >>>> > >>>> while the fdk reconstruction parameters are: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --pad 0.1 --hann 0.5 > >>>> > >>>> The dimensions were chosen to include the entire anatomy. 72 > projections > >>>> were selected out of 646 projections for a 360 degree scan for both > >>>> calculations. > >>>> > >>>> What parameters and how can I adjust (like alpha, beta, or > iterations?) > >>>> to improve the ADMMTV reconstruction? There is not much description > of this > >>>> application from the wiki page. > >>>> > >>>> Thanks, > >>>> > >>>> -howard > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Rtk-users mailing list > >>>> Rtk-users at public.kitware.com > >>>> http://public.kitware.com/mailman/listinfo/rtk-users > >>>> > >>>> > >>>> -- > >>>> -- > >>>> Cyril Mory, Post-doc > >>>> CREATIS > >>>> Leon Berard cancer treatment center > >>>> 28 rue La?nnec > >>>> 69373 Lyon cedex 08 FRANCE > >>>> > >>>> Mobile: +33 6 69 46 73 79 > >>> > >>> > >>> -- > >>> -- > >>> Cyril Mory, Post-doc > >>> CREATIS > >>> Leon Berard cancer treatment center > >>> 28 rue La?nnec > >>> 69373 Lyon cedex 08 FRANCE > >>> > >>> Mobile: +33 6 69 46 73 79 > >> > >> > >> -- > >> -- > >> Cyril Mory, Post-doc > >> CREATIS > >> Leon Berard cancer treatment center > >> 28 rue La?nnec > >> 69373 Lyon cedex 08 FRANCE > >> > >> Mobile: +33 6 69 46 73 79 > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > > > > > ------------------------------ > > [image: Image removed by sender.] > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > > > > > > ------------------------------ > > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: not available URL: From Robert.Calliess at gmx.de Tue Feb 24 03:56:15 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 24 Feb 2015 09:56:15 +0100 Subject: [Rtk-users] sart back projection, weighting steps Message-ID: An HTML attachment was scrubbed... URL: From cyril.mory at creatis.insa-lyon.fr Tue Feb 24 04:55:00 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Tue, 24 Feb 2015 10:55:00 +0100 Subject: [Rtk-users] sart back projection, weighting steps In-Reply-To: References: Message-ID: <54EC4A74.2010601@creatis.insa-lyon.fr> Hi Robert, I'm glad to know that most of the explanation text is understandable :) You might want to check this filter: http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html You can use the command line application "rtkbackprojections" with argument --bp to compare "Joseph" and "NormalizedJoseph". When performing a back projection with non-normalized Joseph, the projection values are "splat" (splat is the adjoint operator of interpolation) between the four nearest voxels in each volume plane the ray intersects. Nothing guarantees that every voxel will receive a contribution during this process. How many contributions a voxel receives is determined by the sampling of the projections, which can be much looser or much denser (locally and globally) than what would be required. Dividing by the back projection of an image of ones mitigates this effect. In theory, as long as the forward and back projection operators are the adjoint of one another, it should not be a problem for SART. In practice, it does make a difference. I hope it helps. Please let me know if it is still unclear; Cyril On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward projection, > every pixel is > divided by the intersection length of the ray with the volume. That is > clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This weighting > step is not > performed when using a voxel-based back projection, as the weights > are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all pixels > have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply this > weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate the > pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range from 0 > to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Thu Feb 26 14:35:06 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Thu, 26 Feb 2015 19:35:06 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely,Vahid? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Thu Feb 26 15:18:53 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Thu, 26 Feb 2015 21:18:53 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Message-ID: <00d901d05201$71a49200$54edb600$@gmx.de> Hello Vahid, I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI but with a wider sensor array. I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code. But let?s see what grandmasters of RTK will suggest. Best regards, Robert Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely, Vahid -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Thu Feb 26 16:33:46 2015 From: ghostcz at hotmail.com (louie L) Date: Thu, 26 Feb 2015 22:33:46 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <00d901d05201$71a49200$54edb600$@gmx.de> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work. Best regards, Louie Greetings from my iOS! > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the > resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). > I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around > the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these > seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI > but with a wider sensor array. > > I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it > would be possible to model the helical trajectory by the changing geometry without changing /adding code. > > But let?s see what grandmasters of RTK will suggest. > > Best regards, > Robert > > > Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users > Gesendet: Donnerstag, 26. Februar 2015 20:35 > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK > > Dear RTK users, > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? > I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. > > Sincerely, > Vahid > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From cyril.mory at creatis.insa-lyon.fr Fri Feb 27 03:45:24 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Fri, 27 Feb 2015 09:45:24 +0100 Subject: [Rtk-users] Fwd: Re: Aw: Re: sart back projection, weighting steps In-Reply-To: <54F02E7E.7080000@creatis.insa-lyon.fr> References: <54F02E7E.7080000@creatis.insa-lyon.fr> Message-ID: <54F02EA4.7010006@creatis.insa-lyon.fr> Hi Robert, No problem, glad to help. I think either I have'nt been clear enough, or you're getting confused, though :) Let me try again: In joseph back projection, for each PIXEL, you "draw a line" between the source and the pixel's center, and see which voxels it crosses. Your line crosses each slice of the volume at an intersection point. You determine what the interpolation weights would be if you were to interpolate at this intersection point. And these weights are indeed between 0 and 1. But instead of interpolating, you "splat", that means you update the four nearest voxels by adding (projection's pixel value * interpolationWeight) to each. And you move to the next slice. Once you've considered all rays, you're done. Nothing in this process guarantees that a voxel will receive any contribution. In fact, some receive none, and some too many. The backprojected volume you obtain is "biased". You could think of it as the product of what you really want (the projection's pixel values smeared out along the lines of rays) with a "sampling density map" (the cumulated splat weights each voxel has been updated with). If you back project a projection of ones, then your resulting volume is exactly this sampling density map, and you can divide by it to obtain what you really want. In voxel based back projection, for each voxel, you "draw a line" between the source and the voxel's center, see where it hits the 2D projection, and add the value of that pixel (or interpolated at this position between pixels) into the voxel. And that's it for this voxel, so each voxel gets updated once and only once. And if the projection contains only ones, then your volume gets filled with ones. Dividing by one isn't going to change anything, so you just don't do it. I hope it is clearer. Cyril On 02/26/2015 02:10 PM, "Robert Callie?" wrote: > Hello Cyril, > thank you for the fast reply and thank you for the support. > Indeed I have some more questions. For the normalization step > you on the one hand side create a projection image filled with "1" > and on the other hand side you create an empty (zero) volume and > then back project the image, ok. > >>How many contributions a voxel receives is determined by the > sampling of the projections > Yes, I have the same problems with a voxel-based back projector. But > don't you have > this problem also with joseph's method when you use it for the back > projection of the "1" projection > image ? It's not clear to me how this kind of back projection actually > works (or is calculated). > And if the projection image consists of pixels with value "1" then we > actually don't need it or do we ? > So far I understand, no matter if we perform the forward or back > projtion, the joseph projector calculates > the weightings of the four voxels that are "around" the current plane > intersection point. And this > weights are always between 0 and 1. > Or do I totally misunderstand the concept of this backprojection. > I hope I did not confused you. > best regards, > Robert > *Gesendet:* Dienstag, 24. Februar 2015 um 10:55 Uhr > *Von:* "Cyril Mory" > *An:* "Robert Callie?" , rtk-users at openrtk.org > *Betreff:* Re: [Rtk-users] sart back projection, weighting steps > Hi Robert, > > I'm glad to know that most of the explanation text is understandable :) > You might want to check this filter: > http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html > You can use the command line application "rtkbackprojections" with > argument --bp to compare "Joseph" and "NormalizedJoseph". > > When performing a back projection with non-normalized Joseph, the > projection values are "splat" (splat is the adjoint operator of > interpolation) between the four nearest voxels in each volume plane > the ray intersects. Nothing guarantees that every voxel will receive a > contribution during this process. How many contributions a voxel > receives is determined by the sampling of the projections, which can > be much looser or much denser (locally and globally) than what would > be required. Dividing by the back projection of an image of ones > mitigates this effect. In theory, as long as the forward and back > projection operators are the adjoint of one another, it should not be > a problem for SART. In practice, it does make a difference. > > I hope it helps. Please let me know if it is still unclear; > > Cyril > On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward > projection, every pixel is > divided by the intersection length of the ray with the volume. > That is clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This > weighting step is not > performed when using a voxel-based back projection, as the > weights are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all > pixels have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply > this weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate > the pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range > from 0 to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually > happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 27 04:42:38 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 27 Feb 2015 10:42:38 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry . I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: > Hi, > > You can change the geometry. If changed correctly, most, if not all, the > iterative cone beam reconstruction will work. > > Best regards, > Louie > > Greetings from my iOS! > > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > > I think you need to add a new reconstruction filter for it. For the first > projection the object usually is placed so that the > > resulting projection image covers the upper half of the detector. And you > will need some additional handling (z-increment). > > I guess you could do a little work around with the current rtk. If you > only reconstruct an rectangular roi around > > the detector?s center where the perspective distortion (because of the > cone) is minimal. And then you add these > > seperate volumes to a final volume. This is just an idea. I do not know > how the result will look like. Think of it like a TDI > > but with a wider sensor array. > > > > I do not know the code in detail, but if it were possible to have seperate > geometry settings for every projection image it > > would be possible to model the helical trajectory by the changing geometry > without changing /adding code. > > > > But let?s see what grandmasters of RTK will suggest. > > > > Best regards, > > Robert > > > > > > *Von:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *Im Auftrag von *vahid ettehadi > via Rtk-users > *Gesendet:* Donnerstag, 26. Februar 2015 20:35 > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] Helical cone-beam reconstruction with RTK > > > > Dear RTK users, > > > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT > in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > > I would like to change the current source trajectory from circular to > helical. I was wondering is it possible to use the RTK for helical > reconstruction only with some simple modification? > > I don't know well about reconstruction process and I don't know which type > of modification is necessary to use RTK for a helical cone beam geometry. > So, any suggestion and recommendation would be appreciated. > > > > Sincerely, > > Vahid > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Fri Feb 27 14:24:14 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Fri, 27 Feb 2015 19:24:14 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: Message-ID: <47007992.1342548.1425065054134.JavaMail.yahoo@mail.yahoo.com> Hello,Thank you Robert, Louie and Simon, for your tips and recommendations. I will work on it and I will share the result or potential problems. I found the RTK more accurate and easy to use in compare with other open-source reconstruction tools such as Oscar and NiftyRec.? Thank you RTK team!Vahid On Friday, February 27, 2015 4:42 AM, Simon Rit wrote: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry. I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work.? Best regards,Louie Greetings from my iOS! On 26 Feb 2015, at 21:19, Robert Callie? wrote: Hello Vahid,I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that theresulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment).I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi aroundthe detector?s center where the perspective distortion (because of the cone) is minimal. And then you add theseseperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDIbut with a wider sensor array.?I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code.?But let?s see what grandmasters of RTK will suggest.?Best regards,Robert??????????????? ?Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK?Dear RTK users,??I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated.?Sincerely,Vahid?? _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Sun Feb 1 04:41:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 1 Feb 2015 10:41:03 +0100 Subject: [Rtk-users] RTK In-Reply-To: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> References: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> Message-ID: On Fri, Jan 30, 2015 at 10:19 AM, Robert Callie? wrote: > Hello Simon, > > thank you for the fast reply. > > > > ?Joseph's method samples the ray with one pixel per slice in the main > direction but it does not compute the intersection of the ray with each > voxel. Siddon's method does that. In fig 2 of [Xu and Mueller, 2006], Joseph > is referred to "slice interpolated" and Siddon to "box-line-integrated". > OK, thanks for that hint. I think it will maybe also has the same problem > with divergent rays and missing voxels during the reconstruction. Do you For sure. > have a link to a paper or source to this algorithm. So the algorithm may > work > > As following: > > - calculate intersection with the physical bounding volume (entry > exit points) > > - from entrypoint, determine the 4 voxels that surround this > entrypoint and bilinear interpolate the value at this position and sum it up > > - go to next plane (plane that is most ?perpendicular? to the > current center ray (focus to detector center) ? > > - at the end, the sum is normalized by the ray length ? > (length(exitpoint ? entrypoint)) > > Is that right ? Almost. Maybe I misunderstand your last step but it is actually multiplied by each step length. Normalization occurs during backprojection, not during forward projection. > > > > How can Joseph?s method be used for back projection ? If you write the method as a system matrix, simply take the transpose of it. For (S)ART, you will want to divide by the sum of the weights along one ray which is exactly what you mentionned, the ray length. > > > > ?This sounds very interesting, don't hesitate to share the code and/or the > publication! BTW, what is DDA? > > DDA stands for digital differential analyzer. I use this approach for a > voxel-based forward projector. When I started my project I was looking for a > fast and easy forward projector on voxel basis. > > I found an article about raytracing and acceleration structures where these > people used this 3d dda. They actually needed it to traverse the bounding > hierarchy to get to know what geometry > > the ray intersects with. I slightly modified it to get the intersecetion > length of a ray within a voxel by substraction of the current and previous > step width. I?v attached a zip file that contains this > > modification and the original source code. The original source code is from > www.scratchapixel.com and there is also an article about this topic > (http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-12-introduction-to-acceleration-structures/what-else/). Great, thanks. We'll have a look. Do you distribute this under a specific license? In other words, is there a risk that it would conflict with RTK license? (Apache 2, see website). > > If you have a look at my code you?ll maybe miss some matrix calculation > stuff etc. I use a scene based approach where I place the focus, object and > detector in a so called record. Each record represents the scene geometry at > a certain time, when a projection image was taken. > > Before reconstruction starts I calculate all these positions. I thought this > could be a good approach to decouple the actuall reconstruction algorithm > from the scene geometry. We'll let you know when we look at it if we have questions. > > > > > > ?But generally we use matching resolution between pixels and voxels so the > problem is minimal.? > > Do you mean, that you use a volume resolution that fits to the current > geometry setting and the detector?s pixel resolution ? Yes. > > > > ?Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > Not almost the same. What I mean seems to be simplier. Lets assume the > detector has tilted around the x-axis by 0.25 degrees. The object?s center > is at 0,0,0 and rotation axis is 0,1,0. In FDK you usually got a ray from > source to the voxel center and then you calculate > > the intersection of this ray at the detector plane. To avoid ray plane > intersection calculus, we can rotate the whole system by 0.25 degrees. Means > that the detectors normal now is parallel to the z axis.Of course the > rotation axis is not 0,1,0 any longer and the focus (xray source) > > also is a bit rotated. > > > > ?For the backprojection, we typically used voxel-based backprojection using > the center of the voxel which is faster than what you (seem to) use? > > I think here we mixed something up. This type of back projection is used for > FDK. All my questions were related to S-ART. I need to calculate the weights > > of a voxel for the back projection. To speed it up, I project its vertices > on the detector plane, calc the MEB and the send rays from within this MEB > through the > > voxel and caluclate the intersection length so those rays that will make my > weights. Some people argue that you can use the same backprojection as in FDK to speed up computations. See for example http://www.researchgate.net/profile/Gengsheng_Zeng/publication/12301525_Unmatched_projectorbackprojector_pairs_in_an_iterative_reconstruction_algorithm/links/00b495252b15fc4bb9000000.pdf > > > > > > Best regards, > > Robert > > > > > > P.S. Hello to all the other people here in the mailing list. > > > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Donnerstag, 29. Januar 2015 20:58 > An: Robert Callie? > Cc: rtk-users at openrtk.org > Betreff: Re: RTK > > > > Hi, > Thank you for your interest in RTK. Please use the mailing list for > questions that are of interest to anyone using RTK. > > There are many ways to model the direct problem (forward projection). > Without going into too many details (available in the publications of each > method) : > - "As far as I understand the goal of this approach is to calculate the > intersection length of a ray through a voxel, right ?" False. Joseph's > method samples the ray with one pixel per slice in the main direction but it > does not compute the intersection of the ray with each voxel. Siddon's > method does that. In fig 2 of [Xu and Mueller, 2006], Joseph is referred to > "slice interpolated" and Siddon to "box-line-integrated". > - "I can calculate the intersection length of the ray within a voxel by a > simple substraction, this runs very fast." This sounds very interesting, > don't hesitate to share the code and/or the publication! BTW, what is DDA? > > - Small voxels / pixels, "Did you find a way to handle this ? " We don't > handle this in RTK except if you consider that spatial regularisation (e.g., > total variation) will overcome this problem in a way. But generally we use > matching resolution between pixels and voxels so the problem is minimal. For > the backprojection, we typically used voxel-based backprojection using the > center of the voxel which is faster than what you (seem to) use. I think > that if these things are a problem for you, there is a nice solution called > distance driven (back-)projection (by De Man and Basu). I think it will do > exactly what you want. I haven't implemented it in RTK (yet). > > Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > I hope this helps. Let me know if sg is not clear in my answer! > Cheers, > Simon From riblettmj at mymail.vcu.edu Mon Feb 2 12:03:14 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 12:03:14 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF Message-ID: Hello RTK Users, I?m just getting started using RTK as part of my graduate research and was hoping that someone might be able to help me sort out an issue I?ve been having reconstructing a 3D CBCT image dataset while applying a 4D deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF has been generated by transformix (.mhd format). I followed, for the most part, the MCCBCTReconstruction example on the RTK Wiki. While reconstructing, rtkfdk reads in all of the projections to memory, begins the ?Reconstructing and Writing? phase and proceeds for a few seconds before hanging ? it doesn?t exit or fault, just drops to 0% CPU while retaining the projections in memory. By writing some basic debug messages into the source code, I?ve been able to determine that the issue lies somewhere at m_Deformation->Update() [Line 99 of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 makes it past the m_Deformation->SetFrame(iProj) line, but never makes it past the subsequent update. I?m wondering if this has anything to do with the size of the DVF generated by transformix: approximately 4.0GB (512x100x512x10 image, 4-channels, FLOAT). Just to provide a little more background information, I?m running RTK on a 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of memory running Ubuntu 14.04. RTK was built using the default ?Release? make configuration and linked to ITK 4.5.2. Elastix and Transformix are both the latest version, 4.7. Has anyone else run into a similar issue with reconstructing a similar image, or does anyone have any thoughts as to how to resolve this sort of issue? Thanks in advance! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 2 12:19:53 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 2 Feb 2015 18:19:53 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: Hi, You're the first RTK user I know to use it on Sun! Nice! If you've got 64 GB ram, that should be enough... although you could ask elastix to generate a smaller DVF, RTK linearly interpolates between vectors. You could even use B-spline coeffs directly but you'd have to create a new DVF. My guess is that there is a problem with the initialization of m_Deformation since the line you mention is the first time it's ever used in the class. Do you use the rtkfdk app? I would start by checking that the pointer is not null before this line, sg like: std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; If it equals 0, then there is something going with the deformation. You can check it in the main app, rtkfdk.cxx. Simon On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett wrote: > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From riblettmj at mymail.vcu.edu Mon Feb 2 13:44:54 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 13:44:54 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Simon, I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the added debug line you suggested and it doesn?t look like the pointer is null. Running it through gdb, I got the following info: m_Deformation=0x16ff820 (gdb) x 0x16ff820 0x16ff820: 0x011c51d0 (gdb) x 0x011c51d0 0x11c51d0 <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: 0x005fb874 (gdb) x 0x005fb874 0x5fb874 , 3u> >::CreateAnother() const>: 0xe5894855 (gdb) x 0xe5894855 0xe5894855: Cannot access memory at address 0xe5894855 I?m still waiting on the transformix DVF, but I?ll give that a try too when its done. Thanks again! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go ahead and check to see if the pointer is null and let you know. My current check is having transformix to generate a smaller DVF to see if that helps, so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > >> On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> > wrote: >>> Hello RTK Users, >>> >>> I?m just getting started using RTK as part of my graduate research and was >>> hoping that someone might be able to help me sort out an issue I?ve been >>> having reconstructing a 3D CBCT image dataset while applying a 4D >>> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >>> has been generated by transformix (.mhd format). I followed, for the most >>> part, the MCCBCTReconstruction example on the RTK Wiki. >>> >>> While reconstructing, rtkfdk reads in all of the projections to memory, >>> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >>> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >>> retaining the projections in memory. >>> >>> By writing some basic debug messages into the source code, I?ve been able to >>> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >>> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >>> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >>> past the subsequent update. I?m wondering if this has anything to do with >>> the size of the DVF generated by transformix: approximately 4.0GB >>> (512x100x512x10 image, 4-channels, FLOAT). >>> >>> Just to provide a little more background information, I?m running RTK on a >>> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >>> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >>> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >>> latest version, 4.7. >>> >>> Has anyone else run into a similar issue with reconstructing a similar >>> image, or does anyone have any thoughts as to how to resolve this sort of >>> issue? >>> >>> Thanks in advance! >>> >>> ? Matt >>> >>> __ >>> Matthew J. Riblett >>> Virginia Commonwealth University >>> Department of Radiation Oncology >>> Medical Physics Graduate Program >>> >>> Office: Sanger Hall, Room B1-013 >>> 401 College Street | P.O. Box 980058 >>> Richmond, Virginia 23298 >>> >>> VCU Email: riblettmj at vcu.edu >>> MCV Office Phone: +1.804.628.4858 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Feb 3 02:22:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Feb 2015 08:22:54 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: That's weird because SetFrame does nothing else than change the value of the member Frame. Are you sure it's on SetFrame that the crash occurs? On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett wrote: > Simon, > > I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the > added debug line you suggested and it doesn?t look like the pointer is null. > Running it through gdb, I got the following info: > > m_Deformation=0x16ff820 > > (gdb) x 0x16ff820 > 0x16ff820: 0x011c51d0 > (gdb) x 0x011c51d0 > 0x11c51d0 > <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: > 0x005fb874 > (gdb) x 0x005fb874 > 0x5fb874 3u>, 3u> >::CreateAnother() const>: 0xe5894855 > (gdb) x 0xe5894855 > 0xe5894855: Cannot access memory at address 0xe5894855 > > I?m still waiting on the transformix DVF, but I?ll give that a try too when > its done. > > Thanks again! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett > wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go > ahead and check to see if the pointer is null and let you know. My current > check is having transformix to generate a smaller DVF to see if that helps, > so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby > supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: > > Hi, > You're the first RTK user I know to use it on Sun! Nice! > If you've got 64 GB ram, that should be enough... although you could > ask elastix to generate a smaller DVF, RTK linearly interpolates > between vectors. You could even use B-spline coeffs directly but you'd > have to create a new DVF. > My guess is that there is a problem with the initialization of > m_Deformation since the line you mention is the first time it's ever > used in the class. Do you use the rtkfdk app? I would start by > checking that the pointer is not null before this line, sg like: > std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; > If it equals 0, then there is something going with the deformation. > You can check it in the main app, rtkfdk.cxx. > Simon > > On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett > wrote: > > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From riblettmj at mymail.vcu.edu Tue Feb 3 10:36:03 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Tue, 3 Feb 2015 10:36:03 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: <60DCF1BD-5960-4A62-AC13-42897049FDFF@mymail.vcu.edu> Simon, I think that it makes it past SetFrame and crashes on Update. Just to be sure, I put a debug message after SetFrame and it does make it to that point, so its got to be on the Update line. ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 3, 2015, at 2:22 AM, Simon Rit wrote: > > That's weird because SetFrame does nothing else than change the value > of the member Frame. Are you sure it's on SetFrame that the crash > occurs? > > On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett > wrote: >> Simon, >> >> I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the >> added debug line you suggested and it doesn?t look like the pointer is null. >> Running it through gdb, I got the following info: >> >> m_Deformation=0x16ff820 >> >> (gdb) x 0x16ff820 >> 0x16ff820: 0x011c51d0 >> (gdb) x 0x011c51d0 >> 0x11c51d0 >> <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: >> 0x005fb874 >> (gdb) x 0x005fb874 >> 0x5fb874 > 3u>, 3u> >::CreateAnother() const>: 0xe5894855 >> (gdb) x 0xe5894855 >> 0xe5894855: Cannot access memory at address 0xe5894855 >> >> I?m still waiting on the transformix DVF, but I?ll give that a try too when >> its done. >> >> Thanks again! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett >> wrote: >> >> Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go >> ahead and check to see if the pointer is null and let you know. My current >> check is having transformix to generate a smaller DVF to see if that helps, >> so the server is getting that done as we speak. >> >> You might also like to know that I?ve got RTK running on a Cray CX-1 (baby >> supercomputer) sitting next to the aforementioned Sun x4600-M2. :) >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 12:19 PM, Simon Rit >> wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> wrote: >> >> Hello RTK Users, >> >> I?m just getting started using RTK as part of my graduate research and was >> hoping that someone might be able to help me sort out an issue I?ve been >> having reconstructing a 3D CBCT image dataset while applying a 4D >> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >> has been generated by transformix (.mhd format). I followed, for the most >> part, the MCCBCTReconstruction example on the RTK Wiki. >> >> While reconstructing, rtkfdk reads in all of the projections to memory, >> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >> retaining the projections in memory. >> >> By writing some basic debug messages into the source code, I?ve been able to >> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >> past the subsequent update. I?m wondering if this has anything to do with >> the size of the DVF generated by transformix: approximately 4.0GB >> (512x100x512x10 image, 4-channels, FLOAT). >> >> Just to provide a little more background information, I?m running RTK on a >> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >> latest version, 4.7. >> >> Has anyone else run into a similar issue with reconstructing a similar >> image, or does anyone have any thoughts as to how to resolve this sort of >> issue? >> >> Thanks in advance! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Thu Feb 5 06:44:47 2015 From: wuchao04 at gmail.com (Chao Wu) Date: Thu, 5 Feb 2015 12:44:47 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Hi Simon, There is still an issue with gengetopt. The config file cannot be read. The problem seems to be at around line 62 in rtkMacro.h: char *configFile = args_info.config_arg; points configFile to the address storing the config file name, but next cmdline_parser_##ggo_filename##_free(&args_info); frees all string field of args_info, including args_info.config_arg, therefore the content pointed by configFile becomes invalid. Regards, Chao 2014-12-12 14:10 GMT+01:00 Simon Rit : > My fix did not work. Cyril (Mory) reported that multiple options were read > twice. I hope this new fix will work but don't hesitate to report other > issues with gengetopt. > Thanks again for you reports, > Simon > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > wrote: >> >> That makes sense, thanks for the quick usage explanation, and fix. >> (Disabling the override issue makes sense, and I didn't have time to trace >> through gengetopt. I thought I was missing something, as none of the >> non-flag arguments were being reset (to null, or default values, and thus >> thought 'override' meant something else!). >> >> Thanks again, glad the info was helpful. >> >> Steve >> >> >> On 14-12-10 4:01 AM, Simon Rit wrote: >> >> Hi, >> Thanks for the report, very useful information. I could reproduce the bug >> and I hope that I have fixed it. Briefly: >> - I have changed the code because Ben Champion reported memory leaks and I >> noticed that they occured in deprecated functions of gengetopt that I don't >> use anymore, >> - the way the new macro (as well as the previous one) is written is: first >> read the command line to find if a config file is passed, then read the >> config file and finally read the command line again to check that everything >> has been passed. >> - your fix was not perfect because we would not have checked that the >> required options were set, >> - it turns out that disabling the override option did the job. >> Everything sworks fine now but let met know if you notice something wrong >> again. Thanks again, >> Simon >> >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann >> wrote: >>> >>> A recent update to rtkMacro.h seems to have caused the ggo command line >>> processor to ignore command line flags. (i.e. I can't get any verbose output >>> with '-v'). >>> It seems to happen after making a second call to: >>> >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, &args_params) >>> >>> Removing this second call, has resolved the issue for me. >>> I'm not sure, however, what the intended use of the second call was for >>> (it occurs immediately after: >>> >>> args_params.check_required = 1; >>> >>> which I feel could just be moved above the first call, as it happens >>> regardless, but I may be missing something. >>> >>> I've attached my quickly modified rtkMacro.h for comparison to the latest >>> github commit. >>> >>> Anyhow, hopefully this info is useful, and doesn't only affect me. >>> >>> Steve >>> >>> Our system setup: >>> -Ubuntu 14.04 x64 >>> -gcc 4.8.2 >>> -cuda 6.5 >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 5 09:17:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 5 Feb 2015 15:17:34 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Indeed, it looks as if I had not tested it, I thought I had... This patch should fix it. Thanks for the report! Simon On Thu, Feb 5, 2015 at 12:44 PM, Chao Wu wrote: > Hi Simon, > > There is still an issue with gengetopt. The config file cannot be read. > The problem seems to be at around line 62 in rtkMacro.h: > char *configFile = args_info.config_arg; points configFile to the > address storing the config file name, but next > cmdline_parser_##ggo_filename##_free(&args_info); frees all string > field of args_info, including args_info.config_arg, therefore the > content pointed by configFile becomes invalid. > > Regards, > Chao > > 2014-12-12 14:10 GMT+01:00 Simon Rit : > > My fix did not work. Cyril (Mory) reported that multiple options were > read > > twice. I hope this new fix will work but don't hesitate to report other > > issues with gengetopt. > > Thanks again for you reports, > > Simon > > > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > > wrote: > >> > >> That makes sense, thanks for the quick usage explanation, and fix. > >> (Disabling the override issue makes sense, and I didn't have time to > trace > >> through gengetopt. I thought I was missing something, as none of the > >> non-flag arguments were being reset (to null, or default values, and > thus > >> thought 'override' meant something else!). > >> > >> Thanks again, glad the info was helpful. > >> > >> Steve > >> > >> > >> On 14-12-10 4:01 AM, Simon Rit wrote: > >> > >> Hi, > >> Thanks for the report, very useful information. I could reproduce the > bug > >> and I hope that I have fixed it. Briefly: > >> - I have changed the code because Ben Champion reported memory leaks > and I > >> noticed that they occured in deprecated functions of gengetopt that I > don't > >> use anymore, > >> - the way the new macro (as well as the previous one) is written is: > first > >> read the command line to find if a config file is passed, then read the > >> config file and finally read the command line again to check that > everything > >> has been passed. > >> - your fix was not perfect because we would not have checked that the > >> required options were set, > >> - it turns out that disabling the override option did the job. > >> Everything sworks fine now but let met know if you notice something > wrong > >> again. Thanks again, > >> Simon > >> > >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann > >> wrote: > >>> > >>> A recent update to rtkMacro.h seems to have caused the ggo command line > >>> processor to ignore command line flags. (i.e. I can't get any verbose > output > >>> with '-v'). > >>> It seems to happen after making a second call to: > >>> > >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, > &args_params) > >>> > >>> Removing this second call, has resolved the issue for me. > >>> I'm not sure, however, what the intended use of the second call was for > >>> (it occurs immediately after: > >>> > >>> args_params.check_required = 1; > >>> > >>> which I feel could just be moved above the first call, as it happens > >>> regardless, but I may be missing something. > >>> > >>> I've attached my quickly modified rtkMacro.h for comparison to the > latest > >>> github commit. > >>> > >>> Anyhow, hopefully this info is useful, and doesn't only affect me. > >>> > >>> Steve > >>> > >>> Our system setup: > >>> -Ubuntu 14.04 x64 > >>> -gcc 4.8.2 > >>> -cuda 6.5 > >>> > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> > >> > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Fri Feb 6 12:27:13 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Fri, 6 Feb 2015 18:27:13 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont -------------- next part -------------- A non-text attachment was scrubbed... Name: figure1.png Type: image/png Size: 28287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: figure2.png Type: image/png Size: 80102 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SheppLogan.txt URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 9 09:08:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Feb 2015 15:08:12 +0100 Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT wrote: > Hello rtk users, > > I try to use RTK for reconstruction in my lab but I encounter some > problems. > > I try to reconstruct a simulated spheroid. I join my phantom text file > (SheppLogan.txt). > > If I set source_y=0, I get a correct (I guess) reconstruction, see the > joined figure1.png. I use the followind set of commands : > > rtksimulatedgeometry -n 180 --sdd=508.1658133423730 > --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 > --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && > rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha > --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p > /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml > --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" > > But If I set source_y=15, I obtain some strange artefacts as you can see > on figure2.png. Do you know the origin of this pattern (the vertical one) ? > Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this > artefact doesn't exist. > > Thanks in advance and thanks for this nice toolkit. > > regards, > Mathieu Dupont > > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Thu Feb 12 04:25:12 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Thu, 12 Feb 2015 10:25:12 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <681578867.13033470.1423733112438.JavaMail.zimbra@cppm.in2p3.fr> Hi Simon, you are right, it works now. Thanks for your reactivity. ----- Mail original ----- De: "Simon Rit" ?: "Mathieu DUPONT" Cc: rtk-users at public.kitware.com Envoy?: Lundi 9 F?vrier 2015 15:08:12 Objet: Re: [Rtk-users] fdk artefact, sourceOffsetY Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT < mdupont at cppm.in2p3.fr > wrote: Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From lomahu at gmail.com Thu Feb 12 10:04:45 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 10:04:45 -0500 Subject: [Rtk-users] building CUDA Message-ID: HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 10:50:08 2015 From: theday79 at gmail.com (Yang K Park) Date: Thu, 12 Feb 2015 10:50:08 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <000801d046db$94f3eb60$bedbc220$@gmail.com> Hi Howard, Attached is my Cmake capture image for RTK using CUDA6.5. (I?m using the default option of RTK w/o any manual modification). Also, I?m using VS2013 / win7 64. I found your second option ?CUDA_ATTACH_VS_BUILD_RULE_TO_C ? is different from mine (CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE). And why don?t you use the newest version of CUDA (v6.5)? It may work fine regardless of the model of your NVIDIA graphic card (I?ve tested it for multiple computers w/ different graphic card models). CUDA6.5 is convenient to install since a single installation file will be enough which is including the graphic driver, CUDA toolkit, SDK, etc. (not sure this is same as 5.5). Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Howard Sent: Thursday, February 12, 2015 10:05 AM To: rtk-users at openrtk.org Subject: [Rtk-users] building CUDA HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Cuda_RTK_Cmake.PNG Type: image/png Size: 43604 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:16:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:16:17 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: Hi, Cmake automatically checks if you have a cuda compatible GPU. If it cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile applications. So there must be an issue with your graphic card. Check if you can compile and run has_cuda_gpu.c. Simon On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > HI, > > I encountered a problem when building CUDA applications. CUDA 5.5 was > installed on our system. I set the following in ccmake > > CUDA_64_BIT_DEVICE_CODE ON > CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > RTK_USE_CUDA ON > > I could build but no cuda applications were generated. In the bin folder I > saw libITKCudaCommon.a and librtkcuda.a. > > What did I miss? Anybody could shed light on this? Thanks, > > -howard > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From julien.jomier at kitware.com Thu Feb 12 11:23:10 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Thu, 12 Feb 2015 17:23:10 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <54DCD36E.5080903@kitware.com> To follow up, what do you mean by "no cuda applications were generated"? If you have the libraries compiled that means CMake found a working CUDA compatible device. -Julien On 12/02/2015 17:16, Simon Rit wrote: > Hi, > Cmake automatically checks if you have a cuda compatible GPU. If it > cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > applications. So there must be an issue with your graphic card. Check > if you can compile and run has_cuda_gpu.c. > Simon > > On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> HI, >> >> I encountered a problem when building CUDA applications. CUDA 5.5 was >> installed on our system. I set the following in ccmake >> >> CUDA_64_BIT_DEVICE_CODE ON >> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> RTK_USE_CUDA ON >> >> I could build but no cuda applications were generated. In the bin folder I >> saw libITKCudaCommon.a and librtkcuda.a. >> >> What did I miss? Anybody could shed light on this? Thanks, >> >> -howard >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:27:09 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:27:09 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: <54DCD36E.5080903@kitware.com> References: <54DCD36E.5080903@kitware.com> Message-ID: Actually no, librtkcuda is compiled if the cuda library is available but the applications are compiled if the cuda library AND a cuda compatible device are available... That's probably why you observe this. Simon On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier wrote: > To follow up, what do you mean by "no cuda applications were generated"? If > you have the libraries compiled that means CMake found a working CUDA > compatible device. > > -Julien > > > On 12/02/2015 17:16, Simon Rit wrote: >> >> Hi, >> Cmake automatically checks if you have a cuda compatible GPU. If it >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> applications. So there must be an issue with your graphic card. Check >> if you can compile and run has_cuda_gpu.c. >> Simon >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >>> >>> HI, >>> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >>> installed on our system. I set the following in ccmake >>> >>> CUDA_64_BIT_DEVICE_CODE ON >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >>> RTK_USE_CUDA ON >>> >>> I could build but no cuda applications were generated. In the bin folder >>> I >>> saw libITKCudaCommon.a and librtkcuda.a. >>> >>> What did I miss? Anybody could shed light on this? Thanks, >>> >>> -howard >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > From lomahu at gmail.com Thu Feb 12 12:24:12 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 12:24:12 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: Thanks all for your responses to my question. I did not initially set CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: [ 24%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt for reading. [ 25%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt for reading. As I said in my original post, we have CUDA installed on the system (cluster system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the cards would work well although I haven't confirmed that. -howard On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit wrote: > Actually no, librtkcuda is compiled if the cuda library is available > but the applications are compiled if the cuda library AND a cuda > compatible device are available... That's probably why you observe > this. > Simon > > On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > wrote: > > To follow up, what do you mean by "no cuda applications were generated"? > If > > you have the libraries compiled that means CMake found a working CUDA > > compatible device. > > > > -Julien > > > > > > On 12/02/2015 17:16, Simon Rit wrote: > >> > >> Hi, > >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> applications. So there must be an issue with your graphic card. Check > >> if you can compile and run has_cuda_gpu.c. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >>> > >>> HI, > >>> > >>> I encountered a problem when building CUDA applications. CUDA 5.5 was > >>> installed on our system. I set the following in ccmake > >>> > >>> CUDA_64_BIT_DEVICE_CODE ON > >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >>> RTK_USE_CUDA ON > >>> > >>> I could build but no cuda applications were generated. In the bin > folder > >>> I > >>> saw libITKCudaCommon.a and librtkcuda.a. > >>> > >>> What did I miss? Anybody could shed light on this? Thanks, > >>> > >>> -howard > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> _______________________________________________ > >> Rtk-users mailing list > >> Rtk-users at public.kitware.com > >> http://public.kitware.com/mailman/listinfo/rtk-users > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 12:42:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 18:42:15 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: That's more complicated. First, CUDA_HAVE_GPU is normally turned on automatically but maybe it's been turned off due to the problem you're encountering now. The problem you have is probably not specific to RTK, we don't develop FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an option CUDA_BUILD_CUBIN, maybe turn it off? If I were you, I'd try to create a small separate project with has_cuda_gpu.c and check whether it compiles. If it doesn't, try the cmake mailing list. Simon On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > Thanks all for your responses to my question. I did not initially set > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > [ 24%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > for reading. > > > [ 25%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > for reading. > > As I said in my original post, we have CUDA installed on the system (cluster > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > cards would work well although I haven't confirmed that. > > -howard > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit > wrote: >> >> Actually no, librtkcuda is compiled if the cuda library is available >> but the applications are compiled if the cuda library AND a cuda >> compatible device are available... That's probably why you observe >> this. >> Simon >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> wrote: >> > To follow up, what do you mean by "no cuda applications were generated"? >> > If >> > you have the libraries compiled that means CMake found a working CUDA >> > compatible device. >> > >> > -Julien >> > >> > >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> Hi, >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> applications. So there must be an issue with your graphic card. Check >> >> if you can compile and run has_cuda_gpu.c. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >>> >> >>> HI, >> >>> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >> >>> installed on our system. I set the following in ccmake >> >>> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >>> RTK_USE_CUDA ON >> >>> >> >>> I could build but no cuda applications were generated. In the bin >> >>> folder >> >>> I >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >>> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >>> >> >>> -howard >> >>> >> >>> _______________________________________________ >> >>> Rtk-users mailing list >> >>> Rtk-users at public.kitware.com >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >>> >> >> _______________________________________________ >> >> Rtk-users mailing list >> >> Rtk-users at public.kitware.com >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > > > From lomahu at gmail.com Thu Feb 12 13:37:39 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 13:37:39 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: When I did the following: CUDA_HAVE_GPU ON CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) building was successful. I could run rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk using cuda?) with successful reconstruction. It's done in < 15s, wow! A separate question: how to specify cuda for rtksart, rtkadmmwavelets, rtkadmmtotalvariations etc? Thanks, -howard On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit wrote: > That's more complicated. First, CUDA_HAVE_GPU is normally turned on > automatically but maybe it's been turned off due to the problem you're > encountering now. > The problem you have is probably not specific to RTK, we don't develop > FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an > option CUDA_BUILD_CUBIN, maybe turn it off? > If I were you, I'd try to create a small separate project with > has_cuda_gpu.c and check whether it compiles. If it doesn't, try the > cmake mailing list. > Simon > > On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > > Thanks all for your responses to my question. I did not initially set > > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > > > > [ 24%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > > for reading. > > > > > > [ 25%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > > for reading. > > > > As I said in my original post, we have CUDA installed on the system > (cluster > > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > > cards would work well although I haven't confirmed that. > > > > -howard > > > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > wrote: > >> > >> Actually no, librtkcuda is compiled if the cuda library is available > >> but the applications are compiled if the cuda library AND a cuda > >> compatible device are available... That's probably why you observe > >> this. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > >> wrote: > >> > To follow up, what do you mean by "no cuda applications were > generated"? > >> > If > >> > you have the libraries compiled that means CMake found a working CUDA > >> > compatible device. > >> > > >> > -Julien > >> > > >> > > >> > On 12/02/2015 17:16, Simon Rit wrote: > >> >> > >> >> Hi, > >> >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> >> applications. So there must be an issue with your graphic card. Check > >> >> if you can compile and run has_cuda_gpu.c. > >> >> Simon > >> >> > >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >> >>> > >> >>> HI, > >> >>> > >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 > was > >> >>> installed on our system. I set the following in ccmake > >> >>> > >> >>> CUDA_64_BIT_DEVICE_CODE ON > >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >> >>> RTK_USE_CUDA ON > >> >>> > >> >>> I could build but no cuda applications were generated. In the bin > >> >>> folder > >> >>> I > >> >>> saw libITKCudaCommon.a and librtkcuda.a. > >> >>> > >> >>> What did I miss? Anybody could shed light on this? Thanks, > >> >>> > >> >>> -howard > >> >>> > >> >>> _______________________________________________ > >> >>> Rtk-users mailing list > >> >>> Rtk-users at public.kitware.com > >> >>> http://public.kitware.com/mailman/listinfo/rtk-users > >> >>> > >> >> _______________________________________________ > >> >> Rtk-users mailing list > >> >> Rtk-users at public.kitware.com > >> >> http://public.kitware.com/mailman/listinfo/rtk-users > >> >> > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 13:47:54 2015 From: theday79 at gmail.com (Yang-Kyun Park) Date: Thu, 12 Feb 2015 13:47:54 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: hi howard, use following options for fwd and bkward projection --fp CudaRayCast --bp CudaVoxelBased Yang On Feb 12, 2015 1:37 PM, "Howard" wrote: > When I did the following: > > CUDA_HAVE_GPU ON > CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) > CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) > > building was successful. I could run > > rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk > using cuda?) > > with successful reconstruction. It's done in < 15s, wow! > > A separate question: how to specify cuda for rtksart, > rtkadmmwavelets, rtkadmmtotalvariations etc? > > Thanks, > -howard > > > > > > > > > > > On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> wrote: > >> That's more complicated. First, CUDA_HAVE_GPU is normally turned on >> automatically but maybe it's been turned off due to the problem you're >> encountering now. >> The problem you have is probably not specific to RTK, we don't develop >> FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an >> option CUDA_BUILD_CUBIN, maybe turn it off? >> If I were you, I'd try to create a small separate project with >> has_cuda_gpu.c and check whether it compiles. If it doesn't, try the >> cmake mailing list. >> Simon >> >> On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: >> > Thanks all for your responses to my question. I did not initially set >> > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: >> > >> > >> > [ 24%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > >> > [ 25%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > As I said in my original post, we have CUDA installed on the system >> (cluster >> > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are >> > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume >> the >> > cards would work well although I haven't confirmed that. >> > >> > -howard >> > >> > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> > wrote: >> >> >> >> Actually no, librtkcuda is compiled if the cuda library is available >> >> but the applications are compiled if the cuda library AND a cuda >> >> compatible device are available... That's probably why you observe >> >> this. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> >> wrote: >> >> > To follow up, what do you mean by "no cuda applications were >> generated"? >> >> > If >> >> > you have the libraries compiled that means CMake found a working CUDA >> >> > compatible device. >> >> > >> >> > -Julien >> >> > >> >> > >> >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> >> >> Hi, >> >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> >> applications. So there must be an issue with your graphic card. >> Check >> >> >> if you can compile and run has_cuda_gpu.c. >> >> >> Simon >> >> >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >> >>> >> >> >>> HI, >> >> >>> >> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 >> was >> >> >>> installed on our system. I set the following in ccmake >> >> >>> >> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >> >>> RTK_USE_CUDA ON >> >> >>> >> >> >>> I could build but no cuda applications were generated. In the bin >> >> >>> folder >> >> >>> I >> >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >> >>> >> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >> >>> >> >> >>> -howard >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Rtk-users mailing list >> >> >>> Rtk-users at public.kitware.com >> >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >>> >> >> >> _______________________________________________ >> >> >> Rtk-users mailing list >> >> >> Rtk-users at public.kitware.com >> >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> >> >> > >> > >> > >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 13 07:06:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Feb 2015 13:06:34 +0100 Subject: [Rtk-users] ADMMTVReconstruction In-Reply-To: <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> References: <548EA4E1.4090801@creatis.insa-lyon.fr> <54919EE9.3010406@creatis.insa-lyon.fr> <5492A8BB.2030209@creatis.insa-lyon.fr> <000901d02a50$1c14f470$543edd50$@uclouvain.be> <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> Message-ID: Hi, FYI, S?bastien and I have worked on the pipeline that was mentionned in this discussion. The pipeline is now available in the rtkProjectionsReader (see the diagram in the doc ). Every rtk application can use it from command line options. For example, I0 is automatically estimated if the option --i0=0 is used. Don't hesitate to report what is not clear or not working for you. Simon On Thu, Jan 8, 2015 at 4:04 PM, S?bastien Brousmiche < sebastien.brousmiche at uclouvain.be> wrote: > Hi Howard, > > > > Actually there are three values given per projection: I0, a filtered I0 > (RLS) and the FWHM of the background mode. > > You can just use the first value per projection. If ?output? is the buffer > contained in the file (-d) then use I0 = buffer(1:3:end); > > > > Read rtki0estimation.cxx in the application folder for more information. > I?m planning to add more info in the code later. > > > > Best, > > S?bastien > > > > > > *From:* Howard [mailto:lomahu at gmail.com] > *Sent:* jeudi 8 janvier 2015 15:57 > *To:* S?bastien Brousmiche > *Cc:* Simon Rit; rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Hi Sebastien, > > > > Thank you very much for your explanation. I used -d to write I0 > estimations to a file. I found there are >2000 numbers for ~600 > projections. I thought there would be one number for each projection, but > obviously the output numbers are not generated that way. Could you please > describe a bit more on the file format and how to use them? Or simply I > wait for your new mini-pipeline filter? > > > > Regards, > > -howard > > > > On Wed, Jan 7, 2015 at 3:01 AM, S?bastien Brousmiche < > sebastien.brousmiche at uclouvain.be> wrote: > > Hi Howard, > > > > There is an input parameter with the rtki0estimation application (-d) > which allows you to specify the output file with I0 estimates. > > > > The big file you mentioned contains the histograms of each image (65536 > values each) stored consecutively. The first value is the occurrence of > number 0 in your image, second.. 1 and so forth up to 65535. > > > > This application is not particularly interesting to be used in a pipeline. > > > > > Nevertheless, we are developing a mini-pipeline grouping typical > preprocessing filters. It is under validation and I?ll let you know as soon > as it is available for you. > > > > Best, > > S?bastien > > > > > > > > > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Howard > *Sent:* mercredi 7 janvier 2015 00:17 > *To:* Simon Rit > *Cc:* rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Happy New Year, Simon. > > > > Thank you for pointing to me the I0 estimate procedure.I saw an > application rtki0estimation > > under the Applications folder. Is this the tool you meant? I ran it using > all default parameters > > providing with the original projection data. What I obtained was a file: > i0est_histogram.csv. > > From the comments in rtki0estimation.ggo this file is the output with I0 > estimate. For 650 projections > > the file size is around 200MB. I used excel to open the file and found > that the beginning two numbers > > 64408 and 722024 then followed by 0's. In the middle there are some > nonzero numbers. Essentially > > all zeros. > > Since there is not much description of the application, so it is hard to > figure out easily what I am doing. > > I tried to read the source code, but it might be more useful if you can > give some hints on how to > > use it. > > > > Regards, > > -howard > > > > > > On Mon, Jan 5, 2015 at 1:49 AM, Simon Rit > wrote: > > Happy new year Howard, > Normally, this calibration is handled by the flat panel. It uses an > air projection and a dark (no beam) projection to compute the line > integral. However, there might be fluctuations in time of these two > projections. Some people do regular acquisitions of them to capture > the time fluctuations. Otherwise, a constant value might be a good > solution. S?bastien has recently implemented an automated > determination of this constant, maybe you should have a look: > > http://www.openrtk.org/Doxygen/classrtk_1_1I0EstimationProjectionFilter.html > It is already part of the mini-pipeline for ImagX / IBA projections > processing: > > http://www.openrtk.org/Doxygen/classrtk_1_1ImagXRawToAttenuationImageFilter.html > Simon > > > On Fri, Jan 2, 2015 at 10:17 PM, Howard wrote: > > Happy New Year, Cyril. > > > > I realized that our projection data is having some issues with air > > correction. We checked our calibration and it appeared fine. Do you know > by > > any chance whether there is a quick way of correcting that? I searched > > around and found people used a constant air norm image. > > > > Thanks very much, > > -howard > > > > On Thu, Dec 18, 2014 at 5:13 AM, Cyril Mory > > wrote: > >> > >> Hi Howard, > >> > >> I've taken a look at your data. > >> You can apply tv denoising on the out.mha volume and obtain a > >> significantly lower level of noise without blurring structures by using > the > >> following command : > >> rtktotalvariationdenoising -i out.mha -g 0.001 -o > >> tvdenoised/gamma0.001.mha -n 100 > >> > >> I was unable to obtain good results with iterative reconstruction from > the > >> projection data you sent, though. I think the main reason for this is > that > >> your projections have much-higher-than-zero attenuation in air. Your > >> calculation of i0 when converting from intensity to attenuation is > probably > >> not good enough. Try to correct for this effect first. Then you can > start > >> performing SART and Conjugate Gradient reconstructions on your data, and > >> once you get these right, play with ADMM. > >> > >> You might need to remove the table from the projections to be able to > >> restrict the reconstruction volume strictly to the patient, and speed > up the > >> computations. We can provide help for that too. > >> > >> Best regards, > >> Cyril > >> > >> > >> On 12/17/2014 05:02 PM, Howard wrote: > >> > >> Hi Cyril, > >> > >> I've sent you two files via wetransfer.com: one is the sparse > projection > >> set with geometry file and the other is the fdk reconstructed image > based on > >> full projection set. Please let me know if you have trouble receiving > them. > >> > >> Thanks very much for looking into this. > >> > >> -Howard > >> > >> On Wed, Dec 17, 2014 at 10:19 AM, Cyril Mory > >> wrote: > >>> > >>> Hi Howard, > >>> > >>> Thanks for the detailed feedback. > >>> The image getting blurry is typically due to a too high gamma. > Depending > >>> on you data, gamma can have to be set to a very small value (I use > 0.007 in > >>> some reconstructions on clinical data). Can you send over your volume > >>> reconstructed from full projection data, and I'll have a quick look ? > >>> > >>> There is a lot of instinct in the setting of the parameters. With time, > >>> one gets used to finding a correct set of parameters without really > knowing > >>> how. I can also try to reconstruct from your cbct data if you send me > the > >>> projections and the geometry. > >>> > >>> Best regards, > >>> Cyril > >>> > >>> > >>> On 12/17/2014 03:49 PM, Howard wrote: > >>> > >>> Hi Cyril, > >>> > >>> Thanks very much for your detailed and nice description on how to use > the > >>> admmtv reconstruction. I followed your suggestions and re-ran > >>> reconstructions using admmtotalvariation and admmwavelets with cbct > >>> projection data from a thoracic patient. > >>> > >>> I am reporting what I found and hope these will give you information > for > >>> further improvement. > >>> > >>> 1. I repeated admmtotalvariation with 30 iterations. No improvement was > >>> observed. As a matter of fact, the reconstructed image is getting a lot > >>> noiser compared to that using 3 iterations. The contrast is getting > worse as > >>> well. I tried to play around with window & level in case I was fooled > but > >>> apparently more iterations gave worse results. > >>> > >>> 2. Similarly I ran 30 iterations using admmwavelets. Slightly better > >>> reconstruction compared with total variation. > >>> > >>> 3. Then I went ahead to test if TV benefits us anything using the > >>> tvdenoising application on the fdk-reconstructed image reconstructed > from > >>> full projection set. I found that the more iterations, the more blurry > the > >>> image became. For example, with 50 iterations the contrast on the > denoised > >>> image is very low so that the vertebrae and surrounding soft tissue are > >>> hardly distinguishable. Changing gamma's at 0.2, 0.5, 1.0, 10 did not > seem > >>> to make a difference on the image. With 5 iterations the denoising > seems to > >>> work fairly well. Again, changing gamma's didn't make a difference. > >>> I hope I didn't misused the totalvariationdenoising application. The > >>> command I executed was: rtktotalvariationdenoising -i out.mha -o > >>> out_denoising_n50_gamma05 --gamma 0.5 -n 50 > >>> > >>> In summary, tdmmwavelets seems perform better than tdmmtotalvariation > but > >>> neither gave satisfactory results. No sure what we can infer from the > TV > >>> denoising study. I could send my study to you if there is a need. > Please let > >>> me know what tests I could run. Further help on improvement is > definitely > >>> welcome and appreciated. > >>> > >>> -Howard > >>> > >>> On Mon, Dec 15, 2014 at 4:07 AM, Cyril Mory > >>> wrote: > >>>> > >>>> Hello Howard, > >>>> > >>>> Good to hear that you're using RTK :) > >>>> I'll try to answer all your questions, and give you some advice: > >>>> - In general, you can expect some improvement over rtkfdk, but not a > >>>> huge one > >>>> - You can find the calculations in my PhD thesis > >>>> https://tel.archives-ouvertes.fr/tel-00985728 (in English. Only the > >>>> introduction is in French) > >>>> - Adjusting the parameters is, in itself, a research topic (sorry !). > >>>> Alpha controls the amount of regularization and only that (the > higher, the > >>>> more regularization). Beta, theoretically, should only change the > >>>> convergence speed, provided you do an infinite number of iterations > (I know > >>>> it doesn't help, sorry again !). In practice, beta is ubiquitous and > appears > >>>> everywhere in the calculations, therefore it is hard to predict what > effect > >>>> an increase/decrease of beta will give on the images. I would keep it > as is, > >>>> and play on alpha > >>>> - 3 iterations is way too little. I typically used 30 iterations. > Using > >>>> the CUDA forward and back projectors helped a lot maintain the > computation > >>>> time manageable > >>>> - The quality of the results depends a lot on the nature of the image > >>>> you are trying to reconstruct. In a nutshell, the algorithm assumes > that the > >>>> image you are reconstructing has a certain form of regularity, and > discards > >>>> the potential solutions that do not have it. This assumption partly > >>>> compensates for the lack of data. ADMM TV assumes that the image you > are > >>>> reconstructing is piecewise constant, i.e. has large uniform areas > separated > >>>> by sharp borders. If your image is a phantom, it should give good > results. > >>>> If it is a real patient, you should probably change to another > algorithm > >>>> that assumes another form of regularity in the images (try > rtkadmmwavelets) > >>>> - You can find out whether you typical images can benefit from TV > >>>> regularization by reconstructing from all projections with rtkfdk, > then > >>>> applying rtktotalvariationdenoising on the reconstructed volume (try > 50 > >>>> iterations and adjust the gamma parameter: high gamma means high > >>>> regularization). If this denoising implies an unacceptable loss of > quality, > >>>> stay away from TV for these images, and try wavelets > >>>> > >>>> I hope this helps > >>>> > >>>> Looking forward to reading you again, > >>>> Cyril > >>>> > >>>> > >>>> On 12/12/2014 06:42 PM, Howard wrote: > >>>> > >>>> I am testing the ADMM total variation reconstruction with sparse data > >>>> sample. I could reconstruct but the results were not as good as > expected. In > >>>> other words, it didn't show much improvement compared to fdk > reconstruction > >>>> using the same sparse projection data. > >>>> > >>>> The parameters I used in ADMMTV were the following: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --alpha 1 --beta 1000 -n 3 > >>>> > >>>> while the fdk reconstruction parameters are: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --pad 0.1 --hann 0.5 > >>>> > >>>> The dimensions were chosen to include the entire anatomy. 72 > projections > >>>> were selected out of 646 projections for a 360 degree scan for both > >>>> calculations. > >>>> > >>>> What parameters and how can I adjust (like alpha, beta, or > iterations?) > >>>> to improve the ADMMTV reconstruction? There is not much description > of this > >>>> application from the wiki page. > >>>> > >>>> Thanks, > >>>> > >>>> -howard > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Rtk-users mailing list > >>>> Rtk-users at public.kitware.com > >>>> http://public.kitware.com/mailman/listinfo/rtk-users > >>>> > >>>> > >>>> -- > >>>> -- > >>>> Cyril Mory, Post-doc > >>>> CREATIS > >>>> Leon Berard cancer treatment center > >>>> 28 rue La?nnec > >>>> 69373 Lyon cedex 08 FRANCE > >>>> > >>>> Mobile: +33 6 69 46 73 79 > >>> > >>> > >>> -- > >>> -- > >>> Cyril Mory, Post-doc > >>> CREATIS > >>> Leon Berard cancer treatment center > >>> 28 rue La?nnec > >>> 69373 Lyon cedex 08 FRANCE > >>> > >>> Mobile: +33 6 69 46 73 79 > >> > >> > >> -- > >> -- > >> Cyril Mory, Post-doc > >> CREATIS > >> Leon Berard cancer treatment center > >> 28 rue La?nnec > >> 69373 Lyon cedex 08 FRANCE > >> > >> Mobile: +33 6 69 46 73 79 > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > > > > > ------------------------------ > > [image: Image removed by sender.] > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > > > > > > ------------------------------ > > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: not available URL: From Robert.Calliess at gmx.de Tue Feb 24 03:56:15 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 24 Feb 2015 09:56:15 +0100 Subject: [Rtk-users] sart back projection, weighting steps Message-ID: An HTML attachment was scrubbed... URL: From cyril.mory at creatis.insa-lyon.fr Tue Feb 24 04:55:00 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Tue, 24 Feb 2015 10:55:00 +0100 Subject: [Rtk-users] sart back projection, weighting steps In-Reply-To: References: Message-ID: <54EC4A74.2010601@creatis.insa-lyon.fr> Hi Robert, I'm glad to know that most of the explanation text is understandable :) You might want to check this filter: http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html You can use the command line application "rtkbackprojections" with argument --bp to compare "Joseph" and "NormalizedJoseph". When performing a back projection with non-normalized Joseph, the projection values are "splat" (splat is the adjoint operator of interpolation) between the four nearest voxels in each volume plane the ray intersects. Nothing guarantees that every voxel will receive a contribution during this process. How many contributions a voxel receives is determined by the sampling of the projections, which can be much looser or much denser (locally and globally) than what would be required. Dividing by the back projection of an image of ones mitigates this effect. In theory, as long as the forward and back projection operators are the adjoint of one another, it should not be a problem for SART. In practice, it does make a difference. I hope it helps. Please let me know if it is still unclear; Cyril On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward projection, > every pixel is > divided by the intersection length of the ray with the volume. That is > clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This weighting > step is not > performed when using a voxel-based back projection, as the weights > are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all pixels > have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply this > weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate the > pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range from 0 > to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Thu Feb 26 14:35:06 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Thu, 26 Feb 2015 19:35:06 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely,Vahid? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Thu Feb 26 15:18:53 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Thu, 26 Feb 2015 21:18:53 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Message-ID: <00d901d05201$71a49200$54edb600$@gmx.de> Hello Vahid, I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI but with a wider sensor array. I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code. But let?s see what grandmasters of RTK will suggest. Best regards, Robert Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely, Vahid -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Thu Feb 26 16:33:46 2015 From: ghostcz at hotmail.com (louie L) Date: Thu, 26 Feb 2015 22:33:46 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <00d901d05201$71a49200$54edb600$@gmx.de> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work. Best regards, Louie Greetings from my iOS! > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the > resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). > I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around > the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these > seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI > but with a wider sensor array. > > I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it > would be possible to model the helical trajectory by the changing geometry without changing /adding code. > > But let?s see what grandmasters of RTK will suggest. > > Best regards, > Robert > > > Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users > Gesendet: Donnerstag, 26. Februar 2015 20:35 > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK > > Dear RTK users, > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? > I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. > > Sincerely, > Vahid > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From cyril.mory at creatis.insa-lyon.fr Fri Feb 27 03:45:24 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Fri, 27 Feb 2015 09:45:24 +0100 Subject: [Rtk-users] Fwd: Re: Aw: Re: sart back projection, weighting steps In-Reply-To: <54F02E7E.7080000@creatis.insa-lyon.fr> References: <54F02E7E.7080000@creatis.insa-lyon.fr> Message-ID: <54F02EA4.7010006@creatis.insa-lyon.fr> Hi Robert, No problem, glad to help. I think either I have'nt been clear enough, or you're getting confused, though :) Let me try again: In joseph back projection, for each PIXEL, you "draw a line" between the source and the pixel's center, and see which voxels it crosses. Your line crosses each slice of the volume at an intersection point. You determine what the interpolation weights would be if you were to interpolate at this intersection point. And these weights are indeed between 0 and 1. But instead of interpolating, you "splat", that means you update the four nearest voxels by adding (projection's pixel value * interpolationWeight) to each. And you move to the next slice. Once you've considered all rays, you're done. Nothing in this process guarantees that a voxel will receive any contribution. In fact, some receive none, and some too many. The backprojected volume you obtain is "biased". You could think of it as the product of what you really want (the projection's pixel values smeared out along the lines of rays) with a "sampling density map" (the cumulated splat weights each voxel has been updated with). If you back project a projection of ones, then your resulting volume is exactly this sampling density map, and you can divide by it to obtain what you really want. In voxel based back projection, for each voxel, you "draw a line" between the source and the voxel's center, see where it hits the 2D projection, and add the value of that pixel (or interpolated at this position between pixels) into the voxel. And that's it for this voxel, so each voxel gets updated once and only once. And if the projection contains only ones, then your volume gets filled with ones. Dividing by one isn't going to change anything, so you just don't do it. I hope it is clearer. Cyril On 02/26/2015 02:10 PM, "Robert Callie?" wrote: > Hello Cyril, > thank you for the fast reply and thank you for the support. > Indeed I have some more questions. For the normalization step > you on the one hand side create a projection image filled with "1" > and on the other hand side you create an empty (zero) volume and > then back project the image, ok. > >>How many contributions a voxel receives is determined by the > sampling of the projections > Yes, I have the same problems with a voxel-based back projector. But > don't you have > this problem also with joseph's method when you use it for the back > projection of the "1" projection > image ? It's not clear to me how this kind of back projection actually > works (or is calculated). > And if the projection image consists of pixels with value "1" then we > actually don't need it or do we ? > So far I understand, no matter if we perform the forward or back > projtion, the joseph projector calculates > the weightings of the four voxels that are "around" the current plane > intersection point. And this > weights are always between 0 and 1. > Or do I totally misunderstand the concept of this backprojection. > I hope I did not confused you. > best regards, > Robert > *Gesendet:* Dienstag, 24. Februar 2015 um 10:55 Uhr > *Von:* "Cyril Mory" > *An:* "Robert Callie?" , rtk-users at openrtk.org > *Betreff:* Re: [Rtk-users] sart back projection, weighting steps > Hi Robert, > > I'm glad to know that most of the explanation text is understandable :) > You might want to check this filter: > http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html > You can use the command line application "rtkbackprojections" with > argument --bp to compare "Joseph" and "NormalizedJoseph". > > When performing a back projection with non-normalized Joseph, the > projection values are "splat" (splat is the adjoint operator of > interpolation) between the four nearest voxels in each volume plane > the ray intersects. Nothing guarantees that every voxel will receive a > contribution during this process. How many contributions a voxel > receives is determined by the sampling of the projections, which can > be much looser or much denser (locally and globally) than what would > be required. Dividing by the back projection of an image of ones > mitigates this effect. In theory, as long as the forward and back > projection operators are the adjoint of one another, it should not be > a problem for SART. In practice, it does make a difference. > > I hope it helps. Please let me know if it is still unclear; > > Cyril > On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward > projection, every pixel is > divided by the intersection length of the ray with the volume. > That is clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This > weighting step is not > performed when using a voxel-based back projection, as the > weights are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all > pixels have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply > this weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate > the pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range > from 0 to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually > happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 27 04:42:38 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 27 Feb 2015 10:42:38 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry . I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: > Hi, > > You can change the geometry. If changed correctly, most, if not all, the > iterative cone beam reconstruction will work. > > Best regards, > Louie > > Greetings from my iOS! > > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > > I think you need to add a new reconstruction filter for it. For the first > projection the object usually is placed so that the > > resulting projection image covers the upper half of the detector. And you > will need some additional handling (z-increment). > > I guess you could do a little work around with the current rtk. If you > only reconstruct an rectangular roi around > > the detector?s center where the perspective distortion (because of the > cone) is minimal. And then you add these > > seperate volumes to a final volume. This is just an idea. I do not know > how the result will look like. Think of it like a TDI > > but with a wider sensor array. > > > > I do not know the code in detail, but if it were possible to have seperate > geometry settings for every projection image it > > would be possible to model the helical trajectory by the changing geometry > without changing /adding code. > > > > But let?s see what grandmasters of RTK will suggest. > > > > Best regards, > > Robert > > > > > > *Von:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *Im Auftrag von *vahid ettehadi > via Rtk-users > *Gesendet:* Donnerstag, 26. Februar 2015 20:35 > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] Helical cone-beam reconstruction with RTK > > > > Dear RTK users, > > > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT > in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > > I would like to change the current source trajectory from circular to > helical. I was wondering is it possible to use the RTK for helical > reconstruction only with some simple modification? > > I don't know well about reconstruction process and I don't know which type > of modification is necessary to use RTK for a helical cone beam geometry. > So, any suggestion and recommendation would be appreciated. > > > > Sincerely, > > Vahid > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Fri Feb 27 14:24:14 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Fri, 27 Feb 2015 19:24:14 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: Message-ID: <47007992.1342548.1425065054134.JavaMail.yahoo@mail.yahoo.com> Hello,Thank you Robert, Louie and Simon, for your tips and recommendations. I will work on it and I will share the result or potential problems. I found the RTK more accurate and easy to use in compare with other open-source reconstruction tools such as Oscar and NiftyRec.? Thank you RTK team!Vahid On Friday, February 27, 2015 4:42 AM, Simon Rit wrote: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry. I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work.? Best regards,Louie Greetings from my iOS! On 26 Feb 2015, at 21:19, Robert Callie? wrote: Hello Vahid,I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that theresulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment).I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi aroundthe detector?s center where the perspective distortion (because of the cone) is minimal. And then you add theseseperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDIbut with a wider sensor array.?I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code.?But let?s see what grandmasters of RTK will suggest.?Best regards,Robert??????????????? ?Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK?Dear RTK users,??I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated.?Sincerely,Vahid?? _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Sun Feb 1 04:41:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 1 Feb 2015 10:41:03 +0100 Subject: [Rtk-users] RTK In-Reply-To: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> References: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> Message-ID: On Fri, Jan 30, 2015 at 10:19 AM, Robert Callie? wrote: > Hello Simon, > > thank you for the fast reply. > > > > ?Joseph's method samples the ray with one pixel per slice in the main > direction but it does not compute the intersection of the ray with each > voxel. Siddon's method does that. In fig 2 of [Xu and Mueller, 2006], Joseph > is referred to "slice interpolated" and Siddon to "box-line-integrated". > OK, thanks for that hint. I think it will maybe also has the same problem > with divergent rays and missing voxels during the reconstruction. Do you For sure. > have a link to a paper or source to this algorithm. So the algorithm may > work > > As following: > > - calculate intersection with the physical bounding volume (entry > exit points) > > - from entrypoint, determine the 4 voxels that surround this > entrypoint and bilinear interpolate the value at this position and sum it up > > - go to next plane (plane that is most ?perpendicular? to the > current center ray (focus to detector center) ? > > - at the end, the sum is normalized by the ray length ? > (length(exitpoint ? entrypoint)) > > Is that right ? Almost. Maybe I misunderstand your last step but it is actually multiplied by each step length. Normalization occurs during backprojection, not during forward projection. > > > > How can Joseph?s method be used for back projection ? If you write the method as a system matrix, simply take the transpose of it. For (S)ART, you will want to divide by the sum of the weights along one ray which is exactly what you mentionned, the ray length. > > > > ?This sounds very interesting, don't hesitate to share the code and/or the > publication! BTW, what is DDA? > > DDA stands for digital differential analyzer. I use this approach for a > voxel-based forward projector. When I started my project I was looking for a > fast and easy forward projector on voxel basis. > > I found an article about raytracing and acceleration structures where these > people used this 3d dda. They actually needed it to traverse the bounding > hierarchy to get to know what geometry > > the ray intersects with. I slightly modified it to get the intersecetion > length of a ray within a voxel by substraction of the current and previous > step width. I?v attached a zip file that contains this > > modification and the original source code. The original source code is from > www.scratchapixel.com and there is also an article about this topic > (http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-12-introduction-to-acceleration-structures/what-else/). Great, thanks. We'll have a look. Do you distribute this under a specific license? In other words, is there a risk that it would conflict with RTK license? (Apache 2, see website). > > If you have a look at my code you?ll maybe miss some matrix calculation > stuff etc. I use a scene based approach where I place the focus, object and > detector in a so called record. Each record represents the scene geometry at > a certain time, when a projection image was taken. > > Before reconstruction starts I calculate all these positions. I thought this > could be a good approach to decouple the actuall reconstruction algorithm > from the scene geometry. We'll let you know when we look at it if we have questions. > > > > > > ?But generally we use matching resolution between pixels and voxels so the > problem is minimal.? > > Do you mean, that you use a volume resolution that fits to the current > geometry setting and the detector?s pixel resolution ? Yes. > > > > ?Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > Not almost the same. What I mean seems to be simplier. Lets assume the > detector has tilted around the x-axis by 0.25 degrees. The object?s center > is at 0,0,0 and rotation axis is 0,1,0. In FDK you usually got a ray from > source to the voxel center and then you calculate > > the intersection of this ray at the detector plane. To avoid ray plane > intersection calculus, we can rotate the whole system by 0.25 degrees. Means > that the detectors normal now is parallel to the z axis.Of course the > rotation axis is not 0,1,0 any longer and the focus (xray source) > > also is a bit rotated. > > > > ?For the backprojection, we typically used voxel-based backprojection using > the center of the voxel which is faster than what you (seem to) use? > > I think here we mixed something up. This type of back projection is used for > FDK. All my questions were related to S-ART. I need to calculate the weights > > of a voxel for the back projection. To speed it up, I project its vertices > on the detector plane, calc the MEB and the send rays from within this MEB > through the > > voxel and caluclate the intersection length so those rays that will make my > weights. Some people argue that you can use the same backprojection as in FDK to speed up computations. See for example http://www.researchgate.net/profile/Gengsheng_Zeng/publication/12301525_Unmatched_projectorbackprojector_pairs_in_an_iterative_reconstruction_algorithm/links/00b495252b15fc4bb9000000.pdf > > > > > > Best regards, > > Robert > > > > > > P.S. Hello to all the other people here in the mailing list. > > > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Donnerstag, 29. Januar 2015 20:58 > An: Robert Callie? > Cc: rtk-users at openrtk.org > Betreff: Re: RTK > > > > Hi, > Thank you for your interest in RTK. Please use the mailing list for > questions that are of interest to anyone using RTK. > > There are many ways to model the direct problem (forward projection). > Without going into too many details (available in the publications of each > method) : > - "As far as I understand the goal of this approach is to calculate the > intersection length of a ray through a voxel, right ?" False. Joseph's > method samples the ray with one pixel per slice in the main direction but it > does not compute the intersection of the ray with each voxel. Siddon's > method does that. In fig 2 of [Xu and Mueller, 2006], Joseph is referred to > "slice interpolated" and Siddon to "box-line-integrated". > - "I can calculate the intersection length of the ray within a voxel by a > simple substraction, this runs very fast." This sounds very interesting, > don't hesitate to share the code and/or the publication! BTW, what is DDA? > > - Small voxels / pixels, "Did you find a way to handle this ? " We don't > handle this in RTK except if you consider that spatial regularisation (e.g., > total variation) will overcome this problem in a way. But generally we use > matching resolution between pixels and voxels so the problem is minimal. For > the backprojection, we typically used voxel-based backprojection using the > center of the voxel which is faster than what you (seem to) use. I think > that if these things are a problem for you, there is a nice solution called > distance driven (back-)projection (by De Man and Basu). I think it will do > exactly what you want. I haven't implemented it in RTK (yet). > > Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > I hope this helps. Let me know if sg is not clear in my answer! > Cheers, > Simon From riblettmj at mymail.vcu.edu Mon Feb 2 12:03:14 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 12:03:14 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF Message-ID: Hello RTK Users, I?m just getting started using RTK as part of my graduate research and was hoping that someone might be able to help me sort out an issue I?ve been having reconstructing a 3D CBCT image dataset while applying a 4D deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF has been generated by transformix (.mhd format). I followed, for the most part, the MCCBCTReconstruction example on the RTK Wiki. While reconstructing, rtkfdk reads in all of the projections to memory, begins the ?Reconstructing and Writing? phase and proceeds for a few seconds before hanging ? it doesn?t exit or fault, just drops to 0% CPU while retaining the projections in memory. By writing some basic debug messages into the source code, I?ve been able to determine that the issue lies somewhere at m_Deformation->Update() [Line 99 of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 makes it past the m_Deformation->SetFrame(iProj) line, but never makes it past the subsequent update. I?m wondering if this has anything to do with the size of the DVF generated by transformix: approximately 4.0GB (512x100x512x10 image, 4-channels, FLOAT). Just to provide a little more background information, I?m running RTK on a 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of memory running Ubuntu 14.04. RTK was built using the default ?Release? make configuration and linked to ITK 4.5.2. Elastix and Transformix are both the latest version, 4.7. Has anyone else run into a similar issue with reconstructing a similar image, or does anyone have any thoughts as to how to resolve this sort of issue? Thanks in advance! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 2 12:19:53 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 2 Feb 2015 18:19:53 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: Hi, You're the first RTK user I know to use it on Sun! Nice! If you've got 64 GB ram, that should be enough... although you could ask elastix to generate a smaller DVF, RTK linearly interpolates between vectors. You could even use B-spline coeffs directly but you'd have to create a new DVF. My guess is that there is a problem with the initialization of m_Deformation since the line you mention is the first time it's ever used in the class. Do you use the rtkfdk app? I would start by checking that the pointer is not null before this line, sg like: std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; If it equals 0, then there is something going with the deformation. You can check it in the main app, rtkfdk.cxx. Simon On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett wrote: > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From riblettmj at mymail.vcu.edu Mon Feb 2 13:44:54 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 13:44:54 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Simon, I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the added debug line you suggested and it doesn?t look like the pointer is null. Running it through gdb, I got the following info: m_Deformation=0x16ff820 (gdb) x 0x16ff820 0x16ff820: 0x011c51d0 (gdb) x 0x011c51d0 0x11c51d0 <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: 0x005fb874 (gdb) x 0x005fb874 0x5fb874 , 3u> >::CreateAnother() const>: 0xe5894855 (gdb) x 0xe5894855 0xe5894855: Cannot access memory at address 0xe5894855 I?m still waiting on the transformix DVF, but I?ll give that a try too when its done. Thanks again! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go ahead and check to see if the pointer is null and let you know. My current check is having transformix to generate a smaller DVF to see if that helps, so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > >> On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> > wrote: >>> Hello RTK Users, >>> >>> I?m just getting started using RTK as part of my graduate research and was >>> hoping that someone might be able to help me sort out an issue I?ve been >>> having reconstructing a 3D CBCT image dataset while applying a 4D >>> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >>> has been generated by transformix (.mhd format). I followed, for the most >>> part, the MCCBCTReconstruction example on the RTK Wiki. >>> >>> While reconstructing, rtkfdk reads in all of the projections to memory, >>> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >>> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >>> retaining the projections in memory. >>> >>> By writing some basic debug messages into the source code, I?ve been able to >>> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >>> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >>> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >>> past the subsequent update. I?m wondering if this has anything to do with >>> the size of the DVF generated by transformix: approximately 4.0GB >>> (512x100x512x10 image, 4-channels, FLOAT). >>> >>> Just to provide a little more background information, I?m running RTK on a >>> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >>> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >>> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >>> latest version, 4.7. >>> >>> Has anyone else run into a similar issue with reconstructing a similar >>> image, or does anyone have any thoughts as to how to resolve this sort of >>> issue? >>> >>> Thanks in advance! >>> >>> ? Matt >>> >>> __ >>> Matthew J. Riblett >>> Virginia Commonwealth University >>> Department of Radiation Oncology >>> Medical Physics Graduate Program >>> >>> Office: Sanger Hall, Room B1-013 >>> 401 College Street | P.O. Box 980058 >>> Richmond, Virginia 23298 >>> >>> VCU Email: riblettmj at vcu.edu >>> MCV Office Phone: +1.804.628.4858 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Feb 3 02:22:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Feb 2015 08:22:54 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: That's weird because SetFrame does nothing else than change the value of the member Frame. Are you sure it's on SetFrame that the crash occurs? On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett wrote: > Simon, > > I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the > added debug line you suggested and it doesn?t look like the pointer is null. > Running it through gdb, I got the following info: > > m_Deformation=0x16ff820 > > (gdb) x 0x16ff820 > 0x16ff820: 0x011c51d0 > (gdb) x 0x011c51d0 > 0x11c51d0 > <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: > 0x005fb874 > (gdb) x 0x005fb874 > 0x5fb874 3u>, 3u> >::CreateAnother() const>: 0xe5894855 > (gdb) x 0xe5894855 > 0xe5894855: Cannot access memory at address 0xe5894855 > > I?m still waiting on the transformix DVF, but I?ll give that a try too when > its done. > > Thanks again! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett > wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go > ahead and check to see if the pointer is null and let you know. My current > check is having transformix to generate a smaller DVF to see if that helps, > so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby > supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: > > Hi, > You're the first RTK user I know to use it on Sun! Nice! > If you've got 64 GB ram, that should be enough... although you could > ask elastix to generate a smaller DVF, RTK linearly interpolates > between vectors. You could even use B-spline coeffs directly but you'd > have to create a new DVF. > My guess is that there is a problem with the initialization of > m_Deformation since the line you mention is the first time it's ever > used in the class. Do you use the rtkfdk app? I would start by > checking that the pointer is not null before this line, sg like: > std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; > If it equals 0, then there is something going with the deformation. > You can check it in the main app, rtkfdk.cxx. > Simon > > On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett > wrote: > > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From riblettmj at mymail.vcu.edu Tue Feb 3 10:36:03 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Tue, 3 Feb 2015 10:36:03 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: <60DCF1BD-5960-4A62-AC13-42897049FDFF@mymail.vcu.edu> Simon, I think that it makes it past SetFrame and crashes on Update. Just to be sure, I put a debug message after SetFrame and it does make it to that point, so its got to be on the Update line. ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 3, 2015, at 2:22 AM, Simon Rit wrote: > > That's weird because SetFrame does nothing else than change the value > of the member Frame. Are you sure it's on SetFrame that the crash > occurs? > > On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett > wrote: >> Simon, >> >> I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the >> added debug line you suggested and it doesn?t look like the pointer is null. >> Running it through gdb, I got the following info: >> >> m_Deformation=0x16ff820 >> >> (gdb) x 0x16ff820 >> 0x16ff820: 0x011c51d0 >> (gdb) x 0x011c51d0 >> 0x11c51d0 >> <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: >> 0x005fb874 >> (gdb) x 0x005fb874 >> 0x5fb874 > 3u>, 3u> >::CreateAnother() const>: 0xe5894855 >> (gdb) x 0xe5894855 >> 0xe5894855: Cannot access memory at address 0xe5894855 >> >> I?m still waiting on the transformix DVF, but I?ll give that a try too when >> its done. >> >> Thanks again! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett >> wrote: >> >> Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go >> ahead and check to see if the pointer is null and let you know. My current >> check is having transformix to generate a smaller DVF to see if that helps, >> so the server is getting that done as we speak. >> >> You might also like to know that I?ve got RTK running on a Cray CX-1 (baby >> supercomputer) sitting next to the aforementioned Sun x4600-M2. :) >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 12:19 PM, Simon Rit >> wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> wrote: >> >> Hello RTK Users, >> >> I?m just getting started using RTK as part of my graduate research and was >> hoping that someone might be able to help me sort out an issue I?ve been >> having reconstructing a 3D CBCT image dataset while applying a 4D >> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >> has been generated by transformix (.mhd format). I followed, for the most >> part, the MCCBCTReconstruction example on the RTK Wiki. >> >> While reconstructing, rtkfdk reads in all of the projections to memory, >> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >> retaining the projections in memory. >> >> By writing some basic debug messages into the source code, I?ve been able to >> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >> past the subsequent update. I?m wondering if this has anything to do with >> the size of the DVF generated by transformix: approximately 4.0GB >> (512x100x512x10 image, 4-channels, FLOAT). >> >> Just to provide a little more background information, I?m running RTK on a >> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >> latest version, 4.7. >> >> Has anyone else run into a similar issue with reconstructing a similar >> image, or does anyone have any thoughts as to how to resolve this sort of >> issue? >> >> Thanks in advance! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Thu Feb 5 06:44:47 2015 From: wuchao04 at gmail.com (Chao Wu) Date: Thu, 5 Feb 2015 12:44:47 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Hi Simon, There is still an issue with gengetopt. The config file cannot be read. The problem seems to be at around line 62 in rtkMacro.h: char *configFile = args_info.config_arg; points configFile to the address storing the config file name, but next cmdline_parser_##ggo_filename##_free(&args_info); frees all string field of args_info, including args_info.config_arg, therefore the content pointed by configFile becomes invalid. Regards, Chao 2014-12-12 14:10 GMT+01:00 Simon Rit : > My fix did not work. Cyril (Mory) reported that multiple options were read > twice. I hope this new fix will work but don't hesitate to report other > issues with gengetopt. > Thanks again for you reports, > Simon > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > wrote: >> >> That makes sense, thanks for the quick usage explanation, and fix. >> (Disabling the override issue makes sense, and I didn't have time to trace >> through gengetopt. I thought I was missing something, as none of the >> non-flag arguments were being reset (to null, or default values, and thus >> thought 'override' meant something else!). >> >> Thanks again, glad the info was helpful. >> >> Steve >> >> >> On 14-12-10 4:01 AM, Simon Rit wrote: >> >> Hi, >> Thanks for the report, very useful information. I could reproduce the bug >> and I hope that I have fixed it. Briefly: >> - I have changed the code because Ben Champion reported memory leaks and I >> noticed that they occured in deprecated functions of gengetopt that I don't >> use anymore, >> - the way the new macro (as well as the previous one) is written is: first >> read the command line to find if a config file is passed, then read the >> config file and finally read the command line again to check that everything >> has been passed. >> - your fix was not perfect because we would not have checked that the >> required options were set, >> - it turns out that disabling the override option did the job. >> Everything sworks fine now but let met know if you notice something wrong >> again. Thanks again, >> Simon >> >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann >> wrote: >>> >>> A recent update to rtkMacro.h seems to have caused the ggo command line >>> processor to ignore command line flags. (i.e. I can't get any verbose output >>> with '-v'). >>> It seems to happen after making a second call to: >>> >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, &args_params) >>> >>> Removing this second call, has resolved the issue for me. >>> I'm not sure, however, what the intended use of the second call was for >>> (it occurs immediately after: >>> >>> args_params.check_required = 1; >>> >>> which I feel could just be moved above the first call, as it happens >>> regardless, but I may be missing something. >>> >>> I've attached my quickly modified rtkMacro.h for comparison to the latest >>> github commit. >>> >>> Anyhow, hopefully this info is useful, and doesn't only affect me. >>> >>> Steve >>> >>> Our system setup: >>> -Ubuntu 14.04 x64 >>> -gcc 4.8.2 >>> -cuda 6.5 >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 5 09:17:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 5 Feb 2015 15:17:34 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Indeed, it looks as if I had not tested it, I thought I had... This patch should fix it. Thanks for the report! Simon On Thu, Feb 5, 2015 at 12:44 PM, Chao Wu wrote: > Hi Simon, > > There is still an issue with gengetopt. The config file cannot be read. > The problem seems to be at around line 62 in rtkMacro.h: > char *configFile = args_info.config_arg; points configFile to the > address storing the config file name, but next > cmdline_parser_##ggo_filename##_free(&args_info); frees all string > field of args_info, including args_info.config_arg, therefore the > content pointed by configFile becomes invalid. > > Regards, > Chao > > 2014-12-12 14:10 GMT+01:00 Simon Rit : > > My fix did not work. Cyril (Mory) reported that multiple options were > read > > twice. I hope this new fix will work but don't hesitate to report other > > issues with gengetopt. > > Thanks again for you reports, > > Simon > > > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > > wrote: > >> > >> That makes sense, thanks for the quick usage explanation, and fix. > >> (Disabling the override issue makes sense, and I didn't have time to > trace > >> through gengetopt. I thought I was missing something, as none of the > >> non-flag arguments were being reset (to null, or default values, and > thus > >> thought 'override' meant something else!). > >> > >> Thanks again, glad the info was helpful. > >> > >> Steve > >> > >> > >> On 14-12-10 4:01 AM, Simon Rit wrote: > >> > >> Hi, > >> Thanks for the report, very useful information. I could reproduce the > bug > >> and I hope that I have fixed it. Briefly: > >> - I have changed the code because Ben Champion reported memory leaks > and I > >> noticed that they occured in deprecated functions of gengetopt that I > don't > >> use anymore, > >> - the way the new macro (as well as the previous one) is written is: > first > >> read the command line to find if a config file is passed, then read the > >> config file and finally read the command line again to check that > everything > >> has been passed. > >> - your fix was not perfect because we would not have checked that the > >> required options were set, > >> - it turns out that disabling the override option did the job. > >> Everything sworks fine now but let met know if you notice something > wrong > >> again. Thanks again, > >> Simon > >> > >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann > >> wrote: > >>> > >>> A recent update to rtkMacro.h seems to have caused the ggo command line > >>> processor to ignore command line flags. (i.e. I can't get any verbose > output > >>> with '-v'). > >>> It seems to happen after making a second call to: > >>> > >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, > &args_params) > >>> > >>> Removing this second call, has resolved the issue for me. > >>> I'm not sure, however, what the intended use of the second call was for > >>> (it occurs immediately after: > >>> > >>> args_params.check_required = 1; > >>> > >>> which I feel could just be moved above the first call, as it happens > >>> regardless, but I may be missing something. > >>> > >>> I've attached my quickly modified rtkMacro.h for comparison to the > latest > >>> github commit. > >>> > >>> Anyhow, hopefully this info is useful, and doesn't only affect me. > >>> > >>> Steve > >>> > >>> Our system setup: > >>> -Ubuntu 14.04 x64 > >>> -gcc 4.8.2 > >>> -cuda 6.5 > >>> > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> > >> > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Fri Feb 6 12:27:13 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Fri, 6 Feb 2015 18:27:13 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont -------------- next part -------------- A non-text attachment was scrubbed... Name: figure1.png Type: image/png Size: 28287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: figure2.png Type: image/png Size: 80102 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SheppLogan.txt URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 9 09:08:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Feb 2015 15:08:12 +0100 Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT wrote: > Hello rtk users, > > I try to use RTK for reconstruction in my lab but I encounter some > problems. > > I try to reconstruct a simulated spheroid. I join my phantom text file > (SheppLogan.txt). > > If I set source_y=0, I get a correct (I guess) reconstruction, see the > joined figure1.png. I use the followind set of commands : > > rtksimulatedgeometry -n 180 --sdd=508.1658133423730 > --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 > --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && > rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha > --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p > /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml > --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" > > But If I set source_y=15, I obtain some strange artefacts as you can see > on figure2.png. Do you know the origin of this pattern (the vertical one) ? > Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this > artefact doesn't exist. > > Thanks in advance and thanks for this nice toolkit. > > regards, > Mathieu Dupont > > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Thu Feb 12 04:25:12 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Thu, 12 Feb 2015 10:25:12 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <681578867.13033470.1423733112438.JavaMail.zimbra@cppm.in2p3.fr> Hi Simon, you are right, it works now. Thanks for your reactivity. ----- Mail original ----- De: "Simon Rit" ?: "Mathieu DUPONT" Cc: rtk-users at public.kitware.com Envoy?: Lundi 9 F?vrier 2015 15:08:12 Objet: Re: [Rtk-users] fdk artefact, sourceOffsetY Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT < mdupont at cppm.in2p3.fr > wrote: Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From lomahu at gmail.com Thu Feb 12 10:04:45 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 10:04:45 -0500 Subject: [Rtk-users] building CUDA Message-ID: HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 10:50:08 2015 From: theday79 at gmail.com (Yang K Park) Date: Thu, 12 Feb 2015 10:50:08 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <000801d046db$94f3eb60$bedbc220$@gmail.com> Hi Howard, Attached is my Cmake capture image for RTK using CUDA6.5. (I?m using the default option of RTK w/o any manual modification). Also, I?m using VS2013 / win7 64. I found your second option ?CUDA_ATTACH_VS_BUILD_RULE_TO_C ? is different from mine (CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE). And why don?t you use the newest version of CUDA (v6.5)? It may work fine regardless of the model of your NVIDIA graphic card (I?ve tested it for multiple computers w/ different graphic card models). CUDA6.5 is convenient to install since a single installation file will be enough which is including the graphic driver, CUDA toolkit, SDK, etc. (not sure this is same as 5.5). Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Howard Sent: Thursday, February 12, 2015 10:05 AM To: rtk-users at openrtk.org Subject: [Rtk-users] building CUDA HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Cuda_RTK_Cmake.PNG Type: image/png Size: 43604 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:16:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:16:17 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: Hi, Cmake automatically checks if you have a cuda compatible GPU. If it cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile applications. So there must be an issue with your graphic card. Check if you can compile and run has_cuda_gpu.c. Simon On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > HI, > > I encountered a problem when building CUDA applications. CUDA 5.5 was > installed on our system. I set the following in ccmake > > CUDA_64_BIT_DEVICE_CODE ON > CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > RTK_USE_CUDA ON > > I could build but no cuda applications were generated. In the bin folder I > saw libITKCudaCommon.a and librtkcuda.a. > > What did I miss? Anybody could shed light on this? Thanks, > > -howard > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From julien.jomier at kitware.com Thu Feb 12 11:23:10 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Thu, 12 Feb 2015 17:23:10 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <54DCD36E.5080903@kitware.com> To follow up, what do you mean by "no cuda applications were generated"? If you have the libraries compiled that means CMake found a working CUDA compatible device. -Julien On 12/02/2015 17:16, Simon Rit wrote: > Hi, > Cmake automatically checks if you have a cuda compatible GPU. If it > cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > applications. So there must be an issue with your graphic card. Check > if you can compile and run has_cuda_gpu.c. > Simon > > On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> HI, >> >> I encountered a problem when building CUDA applications. CUDA 5.5 was >> installed on our system. I set the following in ccmake >> >> CUDA_64_BIT_DEVICE_CODE ON >> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> RTK_USE_CUDA ON >> >> I could build but no cuda applications were generated. In the bin folder I >> saw libITKCudaCommon.a and librtkcuda.a. >> >> What did I miss? Anybody could shed light on this? Thanks, >> >> -howard >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:27:09 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:27:09 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: <54DCD36E.5080903@kitware.com> References: <54DCD36E.5080903@kitware.com> Message-ID: Actually no, librtkcuda is compiled if the cuda library is available but the applications are compiled if the cuda library AND a cuda compatible device are available... That's probably why you observe this. Simon On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier wrote: > To follow up, what do you mean by "no cuda applications were generated"? If > you have the libraries compiled that means CMake found a working CUDA > compatible device. > > -Julien > > > On 12/02/2015 17:16, Simon Rit wrote: >> >> Hi, >> Cmake automatically checks if you have a cuda compatible GPU. If it >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> applications. So there must be an issue with your graphic card. Check >> if you can compile and run has_cuda_gpu.c. >> Simon >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >>> >>> HI, >>> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >>> installed on our system. I set the following in ccmake >>> >>> CUDA_64_BIT_DEVICE_CODE ON >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >>> RTK_USE_CUDA ON >>> >>> I could build but no cuda applications were generated. In the bin folder >>> I >>> saw libITKCudaCommon.a and librtkcuda.a. >>> >>> What did I miss? Anybody could shed light on this? Thanks, >>> >>> -howard >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > From lomahu at gmail.com Thu Feb 12 12:24:12 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 12:24:12 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: Thanks all for your responses to my question. I did not initially set CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: [ 24%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt for reading. [ 25%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt for reading. As I said in my original post, we have CUDA installed on the system (cluster system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the cards would work well although I haven't confirmed that. -howard On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit wrote: > Actually no, librtkcuda is compiled if the cuda library is available > but the applications are compiled if the cuda library AND a cuda > compatible device are available... That's probably why you observe > this. > Simon > > On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > wrote: > > To follow up, what do you mean by "no cuda applications were generated"? > If > > you have the libraries compiled that means CMake found a working CUDA > > compatible device. > > > > -Julien > > > > > > On 12/02/2015 17:16, Simon Rit wrote: > >> > >> Hi, > >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> applications. So there must be an issue with your graphic card. Check > >> if you can compile and run has_cuda_gpu.c. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >>> > >>> HI, > >>> > >>> I encountered a problem when building CUDA applications. CUDA 5.5 was > >>> installed on our system. I set the following in ccmake > >>> > >>> CUDA_64_BIT_DEVICE_CODE ON > >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >>> RTK_USE_CUDA ON > >>> > >>> I could build but no cuda applications were generated. In the bin > folder > >>> I > >>> saw libITKCudaCommon.a and librtkcuda.a. > >>> > >>> What did I miss? Anybody could shed light on this? Thanks, > >>> > >>> -howard > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> _______________________________________________ > >> Rtk-users mailing list > >> Rtk-users at public.kitware.com > >> http://public.kitware.com/mailman/listinfo/rtk-users > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 12:42:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 18:42:15 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: That's more complicated. First, CUDA_HAVE_GPU is normally turned on automatically but maybe it's been turned off due to the problem you're encountering now. The problem you have is probably not specific to RTK, we don't develop FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an option CUDA_BUILD_CUBIN, maybe turn it off? If I were you, I'd try to create a small separate project with has_cuda_gpu.c and check whether it compiles. If it doesn't, try the cmake mailing list. Simon On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > Thanks all for your responses to my question. I did not initially set > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > [ 24%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > for reading. > > > [ 25%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > for reading. > > As I said in my original post, we have CUDA installed on the system (cluster > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > cards would work well although I haven't confirmed that. > > -howard > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit > wrote: >> >> Actually no, librtkcuda is compiled if the cuda library is available >> but the applications are compiled if the cuda library AND a cuda >> compatible device are available... That's probably why you observe >> this. >> Simon >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> wrote: >> > To follow up, what do you mean by "no cuda applications were generated"? >> > If >> > you have the libraries compiled that means CMake found a working CUDA >> > compatible device. >> > >> > -Julien >> > >> > >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> Hi, >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> applications. So there must be an issue with your graphic card. Check >> >> if you can compile and run has_cuda_gpu.c. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >>> >> >>> HI, >> >>> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >> >>> installed on our system. I set the following in ccmake >> >>> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >>> RTK_USE_CUDA ON >> >>> >> >>> I could build but no cuda applications were generated. In the bin >> >>> folder >> >>> I >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >>> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >>> >> >>> -howard >> >>> >> >>> _______________________________________________ >> >>> Rtk-users mailing list >> >>> Rtk-users at public.kitware.com >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >>> >> >> _______________________________________________ >> >> Rtk-users mailing list >> >> Rtk-users at public.kitware.com >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > > > From lomahu at gmail.com Thu Feb 12 13:37:39 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 13:37:39 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: When I did the following: CUDA_HAVE_GPU ON CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) building was successful. I could run rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk using cuda?) with successful reconstruction. It's done in < 15s, wow! A separate question: how to specify cuda for rtksart, rtkadmmwavelets, rtkadmmtotalvariations etc? Thanks, -howard On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit wrote: > That's more complicated. First, CUDA_HAVE_GPU is normally turned on > automatically but maybe it's been turned off due to the problem you're > encountering now. > The problem you have is probably not specific to RTK, we don't develop > FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an > option CUDA_BUILD_CUBIN, maybe turn it off? > If I were you, I'd try to create a small separate project with > has_cuda_gpu.c and check whether it compiles. If it doesn't, try the > cmake mailing list. > Simon > > On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > > Thanks all for your responses to my question. I did not initially set > > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > > > > [ 24%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > > for reading. > > > > > > [ 25%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > > for reading. > > > > As I said in my original post, we have CUDA installed on the system > (cluster > > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > > cards would work well although I haven't confirmed that. > > > > -howard > > > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > wrote: > >> > >> Actually no, librtkcuda is compiled if the cuda library is available > >> but the applications are compiled if the cuda library AND a cuda > >> compatible device are available... That's probably why you observe > >> this. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > >> wrote: > >> > To follow up, what do you mean by "no cuda applications were > generated"? > >> > If > >> > you have the libraries compiled that means CMake found a working CUDA > >> > compatible device. > >> > > >> > -Julien > >> > > >> > > >> > On 12/02/2015 17:16, Simon Rit wrote: > >> >> > >> >> Hi, > >> >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> >> applications. So there must be an issue with your graphic card. Check > >> >> if you can compile and run has_cuda_gpu.c. > >> >> Simon > >> >> > >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >> >>> > >> >>> HI, > >> >>> > >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 > was > >> >>> installed on our system. I set the following in ccmake > >> >>> > >> >>> CUDA_64_BIT_DEVICE_CODE ON > >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >> >>> RTK_USE_CUDA ON > >> >>> > >> >>> I could build but no cuda applications were generated. In the bin > >> >>> folder > >> >>> I > >> >>> saw libITKCudaCommon.a and librtkcuda.a. > >> >>> > >> >>> What did I miss? Anybody could shed light on this? Thanks, > >> >>> > >> >>> -howard > >> >>> > >> >>> _______________________________________________ > >> >>> Rtk-users mailing list > >> >>> Rtk-users at public.kitware.com > >> >>> http://public.kitware.com/mailman/listinfo/rtk-users > >> >>> > >> >> _______________________________________________ > >> >> Rtk-users mailing list > >> >> Rtk-users at public.kitware.com > >> >> http://public.kitware.com/mailman/listinfo/rtk-users > >> >> > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 13:47:54 2015 From: theday79 at gmail.com (Yang-Kyun Park) Date: Thu, 12 Feb 2015 13:47:54 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: hi howard, use following options for fwd and bkward projection --fp CudaRayCast --bp CudaVoxelBased Yang On Feb 12, 2015 1:37 PM, "Howard" wrote: > When I did the following: > > CUDA_HAVE_GPU ON > CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) > CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) > > building was successful. I could run > > rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk > using cuda?) > > with successful reconstruction. It's done in < 15s, wow! > > A separate question: how to specify cuda for rtksart, > rtkadmmwavelets, rtkadmmtotalvariations etc? > > Thanks, > -howard > > > > > > > > > > > On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> wrote: > >> That's more complicated. First, CUDA_HAVE_GPU is normally turned on >> automatically but maybe it's been turned off due to the problem you're >> encountering now. >> The problem you have is probably not specific to RTK, we don't develop >> FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an >> option CUDA_BUILD_CUBIN, maybe turn it off? >> If I were you, I'd try to create a small separate project with >> has_cuda_gpu.c and check whether it compiles. If it doesn't, try the >> cmake mailing list. >> Simon >> >> On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: >> > Thanks all for your responses to my question. I did not initially set >> > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: >> > >> > >> > [ 24%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > >> > [ 25%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > As I said in my original post, we have CUDA installed on the system >> (cluster >> > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are >> > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume >> the >> > cards would work well although I haven't confirmed that. >> > >> > -howard >> > >> > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> > wrote: >> >> >> >> Actually no, librtkcuda is compiled if the cuda library is available >> >> but the applications are compiled if the cuda library AND a cuda >> >> compatible device are available... That's probably why you observe >> >> this. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> >> wrote: >> >> > To follow up, what do you mean by "no cuda applications were >> generated"? >> >> > If >> >> > you have the libraries compiled that means CMake found a working CUDA >> >> > compatible device. >> >> > >> >> > -Julien >> >> > >> >> > >> >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> >> >> Hi, >> >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> >> applications. So there must be an issue with your graphic card. >> Check >> >> >> if you can compile and run has_cuda_gpu.c. >> >> >> Simon >> >> >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >> >>> >> >> >>> HI, >> >> >>> >> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 >> was >> >> >>> installed on our system. I set the following in ccmake >> >> >>> >> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >> >>> RTK_USE_CUDA ON >> >> >>> >> >> >>> I could build but no cuda applications were generated. In the bin >> >> >>> folder >> >> >>> I >> >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >> >>> >> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >> >>> >> >> >>> -howard >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Rtk-users mailing list >> >> >>> Rtk-users at public.kitware.com >> >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >>> >> >> >> _______________________________________________ >> >> >> Rtk-users mailing list >> >> >> Rtk-users at public.kitware.com >> >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> >> >> > >> > >> > >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 13 07:06:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Feb 2015 13:06:34 +0100 Subject: [Rtk-users] ADMMTVReconstruction In-Reply-To: <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> References: <548EA4E1.4090801@creatis.insa-lyon.fr> <54919EE9.3010406@creatis.insa-lyon.fr> <5492A8BB.2030209@creatis.insa-lyon.fr> <000901d02a50$1c14f470$543edd50$@uclouvain.be> <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> Message-ID: Hi, FYI, S?bastien and I have worked on the pipeline that was mentionned in this discussion. The pipeline is now available in the rtkProjectionsReader (see the diagram in the doc ). Every rtk application can use it from command line options. For example, I0 is automatically estimated if the option --i0=0 is used. Don't hesitate to report what is not clear or not working for you. Simon On Thu, Jan 8, 2015 at 4:04 PM, S?bastien Brousmiche < sebastien.brousmiche at uclouvain.be> wrote: > Hi Howard, > > > > Actually there are three values given per projection: I0, a filtered I0 > (RLS) and the FWHM of the background mode. > > You can just use the first value per projection. If ?output? is the buffer > contained in the file (-d) then use I0 = buffer(1:3:end); > > > > Read rtki0estimation.cxx in the application folder for more information. > I?m planning to add more info in the code later. > > > > Best, > > S?bastien > > > > > > *From:* Howard [mailto:lomahu at gmail.com] > *Sent:* jeudi 8 janvier 2015 15:57 > *To:* S?bastien Brousmiche > *Cc:* Simon Rit; rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Hi Sebastien, > > > > Thank you very much for your explanation. I used -d to write I0 > estimations to a file. I found there are >2000 numbers for ~600 > projections. I thought there would be one number for each projection, but > obviously the output numbers are not generated that way. Could you please > describe a bit more on the file format and how to use them? Or simply I > wait for your new mini-pipeline filter? > > > > Regards, > > -howard > > > > On Wed, Jan 7, 2015 at 3:01 AM, S?bastien Brousmiche < > sebastien.brousmiche at uclouvain.be> wrote: > > Hi Howard, > > > > There is an input parameter with the rtki0estimation application (-d) > which allows you to specify the output file with I0 estimates. > > > > The big file you mentioned contains the histograms of each image (65536 > values each) stored consecutively. The first value is the occurrence of > number 0 in your image, second.. 1 and so forth up to 65535. > > > > This application is not particularly interesting to be used in a pipeline. > > > > > Nevertheless, we are developing a mini-pipeline grouping typical > preprocessing filters. It is under validation and I?ll let you know as soon > as it is available for you. > > > > Best, > > S?bastien > > > > > > > > > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Howard > *Sent:* mercredi 7 janvier 2015 00:17 > *To:* Simon Rit > *Cc:* rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Happy New Year, Simon. > > > > Thank you for pointing to me the I0 estimate procedure.I saw an > application rtki0estimation > > under the Applications folder. Is this the tool you meant? I ran it using > all default parameters > > providing with the original projection data. What I obtained was a file: > i0est_histogram.csv. > > From the comments in rtki0estimation.ggo this file is the output with I0 > estimate. For 650 projections > > the file size is around 200MB. I used excel to open the file and found > that the beginning two numbers > > 64408 and 722024 then followed by 0's. In the middle there are some > nonzero numbers. Essentially > > all zeros. > > Since there is not much description of the application, so it is hard to > figure out easily what I am doing. > > I tried to read the source code, but it might be more useful if you can > give some hints on how to > > use it. > > > > Regards, > > -howard > > > > > > On Mon, Jan 5, 2015 at 1:49 AM, Simon Rit > wrote: > > Happy new year Howard, > Normally, this calibration is handled by the flat panel. It uses an > air projection and a dark (no beam) projection to compute the line > integral. However, there might be fluctuations in time of these two > projections. Some people do regular acquisitions of them to capture > the time fluctuations. Otherwise, a constant value might be a good > solution. S?bastien has recently implemented an automated > determination of this constant, maybe you should have a look: > > http://www.openrtk.org/Doxygen/classrtk_1_1I0EstimationProjectionFilter.html > It is already part of the mini-pipeline for ImagX / IBA projections > processing: > > http://www.openrtk.org/Doxygen/classrtk_1_1ImagXRawToAttenuationImageFilter.html > Simon > > > On Fri, Jan 2, 2015 at 10:17 PM, Howard wrote: > > Happy New Year, Cyril. > > > > I realized that our projection data is having some issues with air > > correction. We checked our calibration and it appeared fine. Do you know > by > > any chance whether there is a quick way of correcting that? I searched > > around and found people used a constant air norm image. > > > > Thanks very much, > > -howard > > > > On Thu, Dec 18, 2014 at 5:13 AM, Cyril Mory > > wrote: > >> > >> Hi Howard, > >> > >> I've taken a look at your data. > >> You can apply tv denoising on the out.mha volume and obtain a > >> significantly lower level of noise without blurring structures by using > the > >> following command : > >> rtktotalvariationdenoising -i out.mha -g 0.001 -o > >> tvdenoised/gamma0.001.mha -n 100 > >> > >> I was unable to obtain good results with iterative reconstruction from > the > >> projection data you sent, though. I think the main reason for this is > that > >> your projections have much-higher-than-zero attenuation in air. Your > >> calculation of i0 when converting from intensity to attenuation is > probably > >> not good enough. Try to correct for this effect first. Then you can > start > >> performing SART and Conjugate Gradient reconstructions on your data, and > >> once you get these right, play with ADMM. > >> > >> You might need to remove the table from the projections to be able to > >> restrict the reconstruction volume strictly to the patient, and speed > up the > >> computations. We can provide help for that too. > >> > >> Best regards, > >> Cyril > >> > >> > >> On 12/17/2014 05:02 PM, Howard wrote: > >> > >> Hi Cyril, > >> > >> I've sent you two files via wetransfer.com: one is the sparse > projection > >> set with geometry file and the other is the fdk reconstructed image > based on > >> full projection set. Please let me know if you have trouble receiving > them. > >> > >> Thanks very much for looking into this. > >> > >> -Howard > >> > >> On Wed, Dec 17, 2014 at 10:19 AM, Cyril Mory > >> wrote: > >>> > >>> Hi Howard, > >>> > >>> Thanks for the detailed feedback. > >>> The image getting blurry is typically due to a too high gamma. > Depending > >>> on you data, gamma can have to be set to a very small value (I use > 0.007 in > >>> some reconstructions on clinical data). Can you send over your volume > >>> reconstructed from full projection data, and I'll have a quick look ? > >>> > >>> There is a lot of instinct in the setting of the parameters. With time, > >>> one gets used to finding a correct set of parameters without really > knowing > >>> how. I can also try to reconstruct from your cbct data if you send me > the > >>> projections and the geometry. > >>> > >>> Best regards, > >>> Cyril > >>> > >>> > >>> On 12/17/2014 03:49 PM, Howard wrote: > >>> > >>> Hi Cyril, > >>> > >>> Thanks very much for your detailed and nice description on how to use > the > >>> admmtv reconstruction. I followed your suggestions and re-ran > >>> reconstructions using admmtotalvariation and admmwavelets with cbct > >>> projection data from a thoracic patient. > >>> > >>> I am reporting what I found and hope these will give you information > for > >>> further improvement. > >>> > >>> 1. I repeated admmtotalvariation with 30 iterations. No improvement was > >>> observed. As a matter of fact, the reconstructed image is getting a lot > >>> noiser compared to that using 3 iterations. The contrast is getting > worse as > >>> well. I tried to play around with window & level in case I was fooled > but > >>> apparently more iterations gave worse results. > >>> > >>> 2. Similarly I ran 30 iterations using admmwavelets. Slightly better > >>> reconstruction compared with total variation. > >>> > >>> 3. Then I went ahead to test if TV benefits us anything using the > >>> tvdenoising application on the fdk-reconstructed image reconstructed > from > >>> full projection set. I found that the more iterations, the more blurry > the > >>> image became. For example, with 50 iterations the contrast on the > denoised > >>> image is very low so that the vertebrae and surrounding soft tissue are > >>> hardly distinguishable. Changing gamma's at 0.2, 0.5, 1.0, 10 did not > seem > >>> to make a difference on the image. With 5 iterations the denoising > seems to > >>> work fairly well. Again, changing gamma's didn't make a difference. > >>> I hope I didn't misused the totalvariationdenoising application. The > >>> command I executed was: rtktotalvariationdenoising -i out.mha -o > >>> out_denoising_n50_gamma05 --gamma 0.5 -n 50 > >>> > >>> In summary, tdmmwavelets seems perform better than tdmmtotalvariation > but > >>> neither gave satisfactory results. No sure what we can infer from the > TV > >>> denoising study. I could send my study to you if there is a need. > Please let > >>> me know what tests I could run. Further help on improvement is > definitely > >>> welcome and appreciated. > >>> > >>> -Howard > >>> > >>> On Mon, Dec 15, 2014 at 4:07 AM, Cyril Mory > >>> wrote: > >>>> > >>>> Hello Howard, > >>>> > >>>> Good to hear that you're using RTK :) > >>>> I'll try to answer all your questions, and give you some advice: > >>>> - In general, you can expect some improvement over rtkfdk, but not a > >>>> huge one > >>>> - You can find the calculations in my PhD thesis > >>>> https://tel.archives-ouvertes.fr/tel-00985728 (in English. Only the > >>>> introduction is in French) > >>>> - Adjusting the parameters is, in itself, a research topic (sorry !). > >>>> Alpha controls the amount of regularization and only that (the > higher, the > >>>> more regularization). Beta, theoretically, should only change the > >>>> convergence speed, provided you do an infinite number of iterations > (I know > >>>> it doesn't help, sorry again !). In practice, beta is ubiquitous and > appears > >>>> everywhere in the calculations, therefore it is hard to predict what > effect > >>>> an increase/decrease of beta will give on the images. I would keep it > as is, > >>>> and play on alpha > >>>> - 3 iterations is way too little. I typically used 30 iterations. > Using > >>>> the CUDA forward and back projectors helped a lot maintain the > computation > >>>> time manageable > >>>> - The quality of the results depends a lot on the nature of the image > >>>> you are trying to reconstruct. In a nutshell, the algorithm assumes > that the > >>>> image you are reconstructing has a certain form of regularity, and > discards > >>>> the potential solutions that do not have it. This assumption partly > >>>> compensates for the lack of data. ADMM TV assumes that the image you > are > >>>> reconstructing is piecewise constant, i.e. has large uniform areas > separated > >>>> by sharp borders. If your image is a phantom, it should give good > results. > >>>> If it is a real patient, you should probably change to another > algorithm > >>>> that assumes another form of regularity in the images (try > rtkadmmwavelets) > >>>> - You can find out whether you typical images can benefit from TV > >>>> regularization by reconstructing from all projections with rtkfdk, > then > >>>> applying rtktotalvariationdenoising on the reconstructed volume (try > 50 > >>>> iterations and adjust the gamma parameter: high gamma means high > >>>> regularization). If this denoising implies an unacceptable loss of > quality, > >>>> stay away from TV for these images, and try wavelets > >>>> > >>>> I hope this helps > >>>> > >>>> Looking forward to reading you again, > >>>> Cyril > >>>> > >>>> > >>>> On 12/12/2014 06:42 PM, Howard wrote: > >>>> > >>>> I am testing the ADMM total variation reconstruction with sparse data > >>>> sample. I could reconstruct but the results were not as good as > expected. In > >>>> other words, it didn't show much improvement compared to fdk > reconstruction > >>>> using the same sparse projection data. > >>>> > >>>> The parameters I used in ADMMTV were the following: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --alpha 1 --beta 1000 -n 3 > >>>> > >>>> while the fdk reconstruction parameters are: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --pad 0.1 --hann 0.5 > >>>> > >>>> The dimensions were chosen to include the entire anatomy. 72 > projections > >>>> were selected out of 646 projections for a 360 degree scan for both > >>>> calculations. > >>>> > >>>> What parameters and how can I adjust (like alpha, beta, or > iterations?) > >>>> to improve the ADMMTV reconstruction? There is not much description > of this > >>>> application from the wiki page. > >>>> > >>>> Thanks, > >>>> > >>>> -howard > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Rtk-users mailing list > >>>> Rtk-users at public.kitware.com > >>>> http://public.kitware.com/mailman/listinfo/rtk-users > >>>> > >>>> > >>>> -- > >>>> -- > >>>> Cyril Mory, Post-doc > >>>> CREATIS > >>>> Leon Berard cancer treatment center > >>>> 28 rue La?nnec > >>>> 69373 Lyon cedex 08 FRANCE > >>>> > >>>> Mobile: +33 6 69 46 73 79 > >>> > >>> > >>> -- > >>> -- > >>> Cyril Mory, Post-doc > >>> CREATIS > >>> Leon Berard cancer treatment center > >>> 28 rue La?nnec > >>> 69373 Lyon cedex 08 FRANCE > >>> > >>> Mobile: +33 6 69 46 73 79 > >> > >> > >> -- > >> -- > >> Cyril Mory, Post-doc > >> CREATIS > >> Leon Berard cancer treatment center > >> 28 rue La?nnec > >> 69373 Lyon cedex 08 FRANCE > >> > >> Mobile: +33 6 69 46 73 79 > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > > > > > ------------------------------ > > [image: Image removed by sender.] > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > > > > > > ------------------------------ > > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: not available URL: From Robert.Calliess at gmx.de Tue Feb 24 03:56:15 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 24 Feb 2015 09:56:15 +0100 Subject: [Rtk-users] sart back projection, weighting steps Message-ID: An HTML attachment was scrubbed... URL: From cyril.mory at creatis.insa-lyon.fr Tue Feb 24 04:55:00 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Tue, 24 Feb 2015 10:55:00 +0100 Subject: [Rtk-users] sart back projection, weighting steps In-Reply-To: References: Message-ID: <54EC4A74.2010601@creatis.insa-lyon.fr> Hi Robert, I'm glad to know that most of the explanation text is understandable :) You might want to check this filter: http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html You can use the command line application "rtkbackprojections" with argument --bp to compare "Joseph" and "NormalizedJoseph". When performing a back projection with non-normalized Joseph, the projection values are "splat" (splat is the adjoint operator of interpolation) between the four nearest voxels in each volume plane the ray intersects. Nothing guarantees that every voxel will receive a contribution during this process. How many contributions a voxel receives is determined by the sampling of the projections, which can be much looser or much denser (locally and globally) than what would be required. Dividing by the back projection of an image of ones mitigates this effect. In theory, as long as the forward and back projection operators are the adjoint of one another, it should not be a problem for SART. In practice, it does make a difference. I hope it helps. Please let me know if it is still unclear; Cyril On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward projection, > every pixel is > divided by the intersection length of the ray with the volume. That is > clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This weighting > step is not > performed when using a voxel-based back projection, as the weights > are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all pixels > have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply this > weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate the > pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range from 0 > to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Thu Feb 26 14:35:06 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Thu, 26 Feb 2015 19:35:06 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely,Vahid? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Thu Feb 26 15:18:53 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Thu, 26 Feb 2015 21:18:53 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Message-ID: <00d901d05201$71a49200$54edb600$@gmx.de> Hello Vahid, I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI but with a wider sensor array. I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code. But let?s see what grandmasters of RTK will suggest. Best regards, Robert Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely, Vahid -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Thu Feb 26 16:33:46 2015 From: ghostcz at hotmail.com (louie L) Date: Thu, 26 Feb 2015 22:33:46 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <00d901d05201$71a49200$54edb600$@gmx.de> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work. Best regards, Louie Greetings from my iOS! > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the > resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). > I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around > the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these > seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI > but with a wider sensor array. > > I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it > would be possible to model the helical trajectory by the changing geometry without changing /adding code. > > But let?s see what grandmasters of RTK will suggest. > > Best regards, > Robert > > > Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users > Gesendet: Donnerstag, 26. Februar 2015 20:35 > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK > > Dear RTK users, > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? > I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. > > Sincerely, > Vahid > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From cyril.mory at creatis.insa-lyon.fr Fri Feb 27 03:45:24 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Fri, 27 Feb 2015 09:45:24 +0100 Subject: [Rtk-users] Fwd: Re: Aw: Re: sart back projection, weighting steps In-Reply-To: <54F02E7E.7080000@creatis.insa-lyon.fr> References: <54F02E7E.7080000@creatis.insa-lyon.fr> Message-ID: <54F02EA4.7010006@creatis.insa-lyon.fr> Hi Robert, No problem, glad to help. I think either I have'nt been clear enough, or you're getting confused, though :) Let me try again: In joseph back projection, for each PIXEL, you "draw a line" between the source and the pixel's center, and see which voxels it crosses. Your line crosses each slice of the volume at an intersection point. You determine what the interpolation weights would be if you were to interpolate at this intersection point. And these weights are indeed between 0 and 1. But instead of interpolating, you "splat", that means you update the four nearest voxels by adding (projection's pixel value * interpolationWeight) to each. And you move to the next slice. Once you've considered all rays, you're done. Nothing in this process guarantees that a voxel will receive any contribution. In fact, some receive none, and some too many. The backprojected volume you obtain is "biased". You could think of it as the product of what you really want (the projection's pixel values smeared out along the lines of rays) with a "sampling density map" (the cumulated splat weights each voxel has been updated with). If you back project a projection of ones, then your resulting volume is exactly this sampling density map, and you can divide by it to obtain what you really want. In voxel based back projection, for each voxel, you "draw a line" between the source and the voxel's center, see where it hits the 2D projection, and add the value of that pixel (or interpolated at this position between pixels) into the voxel. And that's it for this voxel, so each voxel gets updated once and only once. And if the projection contains only ones, then your volume gets filled with ones. Dividing by one isn't going to change anything, so you just don't do it. I hope it is clearer. Cyril On 02/26/2015 02:10 PM, "Robert Callie?" wrote: > Hello Cyril, > thank you for the fast reply and thank you for the support. > Indeed I have some more questions. For the normalization step > you on the one hand side create a projection image filled with "1" > and on the other hand side you create an empty (zero) volume and > then back project the image, ok. > >>How many contributions a voxel receives is determined by the > sampling of the projections > Yes, I have the same problems with a voxel-based back projector. But > don't you have > this problem also with joseph's method when you use it for the back > projection of the "1" projection > image ? It's not clear to me how this kind of back projection actually > works (or is calculated). > And if the projection image consists of pixels with value "1" then we > actually don't need it or do we ? > So far I understand, no matter if we perform the forward or back > projtion, the joseph projector calculates > the weightings of the four voxels that are "around" the current plane > intersection point. And this > weights are always between 0 and 1. > Or do I totally misunderstand the concept of this backprojection. > I hope I did not confused you. > best regards, > Robert > *Gesendet:* Dienstag, 24. Februar 2015 um 10:55 Uhr > *Von:* "Cyril Mory" > *An:* "Robert Callie?" , rtk-users at openrtk.org > *Betreff:* Re: [Rtk-users] sart back projection, weighting steps > Hi Robert, > > I'm glad to know that most of the explanation text is understandable :) > You might want to check this filter: > http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html > You can use the command line application "rtkbackprojections" with > argument --bp to compare "Joseph" and "NormalizedJoseph". > > When performing a back projection with non-normalized Joseph, the > projection values are "splat" (splat is the adjoint operator of > interpolation) between the four nearest voxels in each volume plane > the ray intersects. Nothing guarantees that every voxel will receive a > contribution during this process. How many contributions a voxel > receives is determined by the sampling of the projections, which can > be much looser or much denser (locally and globally) than what would > be required. Dividing by the back projection of an image of ones > mitigates this effect. In theory, as long as the forward and back > projection operators are the adjoint of one another, it should not be > a problem for SART. In practice, it does make a difference. > > I hope it helps. Please let me know if it is still unclear; > > Cyril > On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward > projection, every pixel is > divided by the intersection length of the ray with the volume. > That is clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This > weighting step is not > performed when using a voxel-based back projection, as the > weights are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all > pixels have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply > this weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate > the pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range > from 0 to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually > happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 27 04:42:38 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 27 Feb 2015 10:42:38 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry . I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: > Hi, > > You can change the geometry. If changed correctly, most, if not all, the > iterative cone beam reconstruction will work. > > Best regards, > Louie > > Greetings from my iOS! > > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > > I think you need to add a new reconstruction filter for it. For the first > projection the object usually is placed so that the > > resulting projection image covers the upper half of the detector. And you > will need some additional handling (z-increment). > > I guess you could do a little work around with the current rtk. If you > only reconstruct an rectangular roi around > > the detector?s center where the perspective distortion (because of the > cone) is minimal. And then you add these > > seperate volumes to a final volume. This is just an idea. I do not know > how the result will look like. Think of it like a TDI > > but with a wider sensor array. > > > > I do not know the code in detail, but if it were possible to have seperate > geometry settings for every projection image it > > would be possible to model the helical trajectory by the changing geometry > without changing /adding code. > > > > But let?s see what grandmasters of RTK will suggest. > > > > Best regards, > > Robert > > > > > > *Von:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *Im Auftrag von *vahid ettehadi > via Rtk-users > *Gesendet:* Donnerstag, 26. Februar 2015 20:35 > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] Helical cone-beam reconstruction with RTK > > > > Dear RTK users, > > > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT > in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > > I would like to change the current source trajectory from circular to > helical. I was wondering is it possible to use the RTK for helical > reconstruction only with some simple modification? > > I don't know well about reconstruction process and I don't know which type > of modification is necessary to use RTK for a helical cone beam geometry. > So, any suggestion and recommendation would be appreciated. > > > > Sincerely, > > Vahid > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Fri Feb 27 14:24:14 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Fri, 27 Feb 2015 19:24:14 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: Message-ID: <47007992.1342548.1425065054134.JavaMail.yahoo@mail.yahoo.com> Hello,Thank you Robert, Louie and Simon, for your tips and recommendations. I will work on it and I will share the result or potential problems. I found the RTK more accurate and easy to use in compare with other open-source reconstruction tools such as Oscar and NiftyRec.? Thank you RTK team!Vahid On Friday, February 27, 2015 4:42 AM, Simon Rit wrote: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry. I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work.? Best regards,Louie Greetings from my iOS! On 26 Feb 2015, at 21:19, Robert Callie? wrote: Hello Vahid,I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that theresulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment).I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi aroundthe detector?s center where the perspective distortion (because of the cone) is minimal. And then you add theseseperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDIbut with a wider sensor array.?I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code.?But let?s see what grandmasters of RTK will suggest.?Best regards,Robert??????????????? ?Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK?Dear RTK users,??I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated.?Sincerely,Vahid?? _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Sun Feb 1 04:41:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 1 Feb 2015 10:41:03 +0100 Subject: [Rtk-users] RTK In-Reply-To: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> References: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> Message-ID: On Fri, Jan 30, 2015 at 10:19 AM, Robert Callie? wrote: > Hello Simon, > > thank you for the fast reply. > > > > ?Joseph's method samples the ray with one pixel per slice in the main > direction but it does not compute the intersection of the ray with each > voxel. Siddon's method does that. In fig 2 of [Xu and Mueller, 2006], Joseph > is referred to "slice interpolated" and Siddon to "box-line-integrated". > OK, thanks for that hint. I think it will maybe also has the same problem > with divergent rays and missing voxels during the reconstruction. Do you For sure. > have a link to a paper or source to this algorithm. So the algorithm may > work > > As following: > > - calculate intersection with the physical bounding volume (entry > exit points) > > - from entrypoint, determine the 4 voxels that surround this > entrypoint and bilinear interpolate the value at this position and sum it up > > - go to next plane (plane that is most ?perpendicular? to the > current center ray (focus to detector center) ? > > - at the end, the sum is normalized by the ray length ? > (length(exitpoint ? entrypoint)) > > Is that right ? Almost. Maybe I misunderstand your last step but it is actually multiplied by each step length. Normalization occurs during backprojection, not during forward projection. > > > > How can Joseph?s method be used for back projection ? If you write the method as a system matrix, simply take the transpose of it. For (S)ART, you will want to divide by the sum of the weights along one ray which is exactly what you mentionned, the ray length. > > > > ?This sounds very interesting, don't hesitate to share the code and/or the > publication! BTW, what is DDA? > > DDA stands for digital differential analyzer. I use this approach for a > voxel-based forward projector. When I started my project I was looking for a > fast and easy forward projector on voxel basis. > > I found an article about raytracing and acceleration structures where these > people used this 3d dda. They actually needed it to traverse the bounding > hierarchy to get to know what geometry > > the ray intersects with. I slightly modified it to get the intersecetion > length of a ray within a voxel by substraction of the current and previous > step width. I?v attached a zip file that contains this > > modification and the original source code. The original source code is from > www.scratchapixel.com and there is also an article about this topic > (http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-12-introduction-to-acceleration-structures/what-else/). Great, thanks. We'll have a look. Do you distribute this under a specific license? In other words, is there a risk that it would conflict with RTK license? (Apache 2, see website). > > If you have a look at my code you?ll maybe miss some matrix calculation > stuff etc. I use a scene based approach where I place the focus, object and > detector in a so called record. Each record represents the scene geometry at > a certain time, when a projection image was taken. > > Before reconstruction starts I calculate all these positions. I thought this > could be a good approach to decouple the actuall reconstruction algorithm > from the scene geometry. We'll let you know when we look at it if we have questions. > > > > > > ?But generally we use matching resolution between pixels and voxels so the > problem is minimal.? > > Do you mean, that you use a volume resolution that fits to the current > geometry setting and the detector?s pixel resolution ? Yes. > > > > ?Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > Not almost the same. What I mean seems to be simplier. Lets assume the > detector has tilted around the x-axis by 0.25 degrees. The object?s center > is at 0,0,0 and rotation axis is 0,1,0. In FDK you usually got a ray from > source to the voxel center and then you calculate > > the intersection of this ray at the detector plane. To avoid ray plane > intersection calculus, we can rotate the whole system by 0.25 degrees. Means > that the detectors normal now is parallel to the z axis.Of course the > rotation axis is not 0,1,0 any longer and the focus (xray source) > > also is a bit rotated. > > > > ?For the backprojection, we typically used voxel-based backprojection using > the center of the voxel which is faster than what you (seem to) use? > > I think here we mixed something up. This type of back projection is used for > FDK. All my questions were related to S-ART. I need to calculate the weights > > of a voxel for the back projection. To speed it up, I project its vertices > on the detector plane, calc the MEB and the send rays from within this MEB > through the > > voxel and caluclate the intersection length so those rays that will make my > weights. Some people argue that you can use the same backprojection as in FDK to speed up computations. See for example http://www.researchgate.net/profile/Gengsheng_Zeng/publication/12301525_Unmatched_projectorbackprojector_pairs_in_an_iterative_reconstruction_algorithm/links/00b495252b15fc4bb9000000.pdf > > > > > > Best regards, > > Robert > > > > > > P.S. Hello to all the other people here in the mailing list. > > > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Donnerstag, 29. Januar 2015 20:58 > An: Robert Callie? > Cc: rtk-users at openrtk.org > Betreff: Re: RTK > > > > Hi, > Thank you for your interest in RTK. Please use the mailing list for > questions that are of interest to anyone using RTK. > > There are many ways to model the direct problem (forward projection). > Without going into too many details (available in the publications of each > method) : > - "As far as I understand the goal of this approach is to calculate the > intersection length of a ray through a voxel, right ?" False. Joseph's > method samples the ray with one pixel per slice in the main direction but it > does not compute the intersection of the ray with each voxel. Siddon's > method does that. In fig 2 of [Xu and Mueller, 2006], Joseph is referred to > "slice interpolated" and Siddon to "box-line-integrated". > - "I can calculate the intersection length of the ray within a voxel by a > simple substraction, this runs very fast." This sounds very interesting, > don't hesitate to share the code and/or the publication! BTW, what is DDA? > > - Small voxels / pixels, "Did you find a way to handle this ? " We don't > handle this in RTK except if you consider that spatial regularisation (e.g., > total variation) will overcome this problem in a way. But generally we use > matching resolution between pixels and voxels so the problem is minimal. For > the backprojection, we typically used voxel-based backprojection using the > center of the voxel which is faster than what you (seem to) use. I think > that if these things are a problem for you, there is a nice solution called > distance driven (back-)projection (by De Man and Basu). I think it will do > exactly what you want. I haven't implemented it in RTK (yet). > > Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > I hope this helps. Let me know if sg is not clear in my answer! > Cheers, > Simon From riblettmj at mymail.vcu.edu Mon Feb 2 12:03:14 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 12:03:14 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF Message-ID: Hello RTK Users, I?m just getting started using RTK as part of my graduate research and was hoping that someone might be able to help me sort out an issue I?ve been having reconstructing a 3D CBCT image dataset while applying a 4D deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF has been generated by transformix (.mhd format). I followed, for the most part, the MCCBCTReconstruction example on the RTK Wiki. While reconstructing, rtkfdk reads in all of the projections to memory, begins the ?Reconstructing and Writing? phase and proceeds for a few seconds before hanging ? it doesn?t exit or fault, just drops to 0% CPU while retaining the projections in memory. By writing some basic debug messages into the source code, I?ve been able to determine that the issue lies somewhere at m_Deformation->Update() [Line 99 of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 makes it past the m_Deformation->SetFrame(iProj) line, but never makes it past the subsequent update. I?m wondering if this has anything to do with the size of the DVF generated by transformix: approximately 4.0GB (512x100x512x10 image, 4-channels, FLOAT). Just to provide a little more background information, I?m running RTK on a 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of memory running Ubuntu 14.04. RTK was built using the default ?Release? make configuration and linked to ITK 4.5.2. Elastix and Transformix are both the latest version, 4.7. Has anyone else run into a similar issue with reconstructing a similar image, or does anyone have any thoughts as to how to resolve this sort of issue? Thanks in advance! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 2 12:19:53 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 2 Feb 2015 18:19:53 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: Hi, You're the first RTK user I know to use it on Sun! Nice! If you've got 64 GB ram, that should be enough... although you could ask elastix to generate a smaller DVF, RTK linearly interpolates between vectors. You could even use B-spline coeffs directly but you'd have to create a new DVF. My guess is that there is a problem with the initialization of m_Deformation since the line you mention is the first time it's ever used in the class. Do you use the rtkfdk app? I would start by checking that the pointer is not null before this line, sg like: std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; If it equals 0, then there is something going with the deformation. You can check it in the main app, rtkfdk.cxx. Simon On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett wrote: > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From riblettmj at mymail.vcu.edu Mon Feb 2 13:44:54 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 13:44:54 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Simon, I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the added debug line you suggested and it doesn?t look like the pointer is null. Running it through gdb, I got the following info: m_Deformation=0x16ff820 (gdb) x 0x16ff820 0x16ff820: 0x011c51d0 (gdb) x 0x011c51d0 0x11c51d0 <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: 0x005fb874 (gdb) x 0x005fb874 0x5fb874 , 3u> >::CreateAnother() const>: 0xe5894855 (gdb) x 0xe5894855 0xe5894855: Cannot access memory at address 0xe5894855 I?m still waiting on the transformix DVF, but I?ll give that a try too when its done. Thanks again! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go ahead and check to see if the pointer is null and let you know. My current check is having transformix to generate a smaller DVF to see if that helps, so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > >> On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> > wrote: >>> Hello RTK Users, >>> >>> I?m just getting started using RTK as part of my graduate research and was >>> hoping that someone might be able to help me sort out an issue I?ve been >>> having reconstructing a 3D CBCT image dataset while applying a 4D >>> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >>> has been generated by transformix (.mhd format). I followed, for the most >>> part, the MCCBCTReconstruction example on the RTK Wiki. >>> >>> While reconstructing, rtkfdk reads in all of the projections to memory, >>> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >>> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >>> retaining the projections in memory. >>> >>> By writing some basic debug messages into the source code, I?ve been able to >>> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >>> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >>> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >>> past the subsequent update. I?m wondering if this has anything to do with >>> the size of the DVF generated by transformix: approximately 4.0GB >>> (512x100x512x10 image, 4-channels, FLOAT). >>> >>> Just to provide a little more background information, I?m running RTK on a >>> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >>> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >>> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >>> latest version, 4.7. >>> >>> Has anyone else run into a similar issue with reconstructing a similar >>> image, or does anyone have any thoughts as to how to resolve this sort of >>> issue? >>> >>> Thanks in advance! >>> >>> ? Matt >>> >>> __ >>> Matthew J. Riblett >>> Virginia Commonwealth University >>> Department of Radiation Oncology >>> Medical Physics Graduate Program >>> >>> Office: Sanger Hall, Room B1-013 >>> 401 College Street | P.O. Box 980058 >>> Richmond, Virginia 23298 >>> >>> VCU Email: riblettmj at vcu.edu >>> MCV Office Phone: +1.804.628.4858 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Feb 3 02:22:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Feb 2015 08:22:54 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: That's weird because SetFrame does nothing else than change the value of the member Frame. Are you sure it's on SetFrame that the crash occurs? On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett wrote: > Simon, > > I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the > added debug line you suggested and it doesn?t look like the pointer is null. > Running it through gdb, I got the following info: > > m_Deformation=0x16ff820 > > (gdb) x 0x16ff820 > 0x16ff820: 0x011c51d0 > (gdb) x 0x011c51d0 > 0x11c51d0 > <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: > 0x005fb874 > (gdb) x 0x005fb874 > 0x5fb874 3u>, 3u> >::CreateAnother() const>: 0xe5894855 > (gdb) x 0xe5894855 > 0xe5894855: Cannot access memory at address 0xe5894855 > > I?m still waiting on the transformix DVF, but I?ll give that a try too when > its done. > > Thanks again! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett > wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go > ahead and check to see if the pointer is null and let you know. My current > check is having transformix to generate a smaller DVF to see if that helps, > so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby > supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: > > Hi, > You're the first RTK user I know to use it on Sun! Nice! > If you've got 64 GB ram, that should be enough... although you could > ask elastix to generate a smaller DVF, RTK linearly interpolates > between vectors. You could even use B-spline coeffs directly but you'd > have to create a new DVF. > My guess is that there is a problem with the initialization of > m_Deformation since the line you mention is the first time it's ever > used in the class. Do you use the rtkfdk app? I would start by > checking that the pointer is not null before this line, sg like: > std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; > If it equals 0, then there is something going with the deformation. > You can check it in the main app, rtkfdk.cxx. > Simon > > On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett > wrote: > > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From riblettmj at mymail.vcu.edu Tue Feb 3 10:36:03 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Tue, 3 Feb 2015 10:36:03 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: <60DCF1BD-5960-4A62-AC13-42897049FDFF@mymail.vcu.edu> Simon, I think that it makes it past SetFrame and crashes on Update. Just to be sure, I put a debug message after SetFrame and it does make it to that point, so its got to be on the Update line. ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 3, 2015, at 2:22 AM, Simon Rit wrote: > > That's weird because SetFrame does nothing else than change the value > of the member Frame. Are you sure it's on SetFrame that the crash > occurs? > > On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett > wrote: >> Simon, >> >> I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the >> added debug line you suggested and it doesn?t look like the pointer is null. >> Running it through gdb, I got the following info: >> >> m_Deformation=0x16ff820 >> >> (gdb) x 0x16ff820 >> 0x16ff820: 0x011c51d0 >> (gdb) x 0x011c51d0 >> 0x11c51d0 >> <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: >> 0x005fb874 >> (gdb) x 0x005fb874 >> 0x5fb874 > 3u>, 3u> >::CreateAnother() const>: 0xe5894855 >> (gdb) x 0xe5894855 >> 0xe5894855: Cannot access memory at address 0xe5894855 >> >> I?m still waiting on the transformix DVF, but I?ll give that a try too when >> its done. >> >> Thanks again! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett >> wrote: >> >> Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go >> ahead and check to see if the pointer is null and let you know. My current >> check is having transformix to generate a smaller DVF to see if that helps, >> so the server is getting that done as we speak. >> >> You might also like to know that I?ve got RTK running on a Cray CX-1 (baby >> supercomputer) sitting next to the aforementioned Sun x4600-M2. :) >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 12:19 PM, Simon Rit >> wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> wrote: >> >> Hello RTK Users, >> >> I?m just getting started using RTK as part of my graduate research and was >> hoping that someone might be able to help me sort out an issue I?ve been >> having reconstructing a 3D CBCT image dataset while applying a 4D >> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >> has been generated by transformix (.mhd format). I followed, for the most >> part, the MCCBCTReconstruction example on the RTK Wiki. >> >> While reconstructing, rtkfdk reads in all of the projections to memory, >> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >> retaining the projections in memory. >> >> By writing some basic debug messages into the source code, I?ve been able to >> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >> past the subsequent update. I?m wondering if this has anything to do with >> the size of the DVF generated by transformix: approximately 4.0GB >> (512x100x512x10 image, 4-channels, FLOAT). >> >> Just to provide a little more background information, I?m running RTK on a >> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >> latest version, 4.7. >> >> Has anyone else run into a similar issue with reconstructing a similar >> image, or does anyone have any thoughts as to how to resolve this sort of >> issue? >> >> Thanks in advance! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Thu Feb 5 06:44:47 2015 From: wuchao04 at gmail.com (Chao Wu) Date: Thu, 5 Feb 2015 12:44:47 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Hi Simon, There is still an issue with gengetopt. The config file cannot be read. The problem seems to be at around line 62 in rtkMacro.h: char *configFile = args_info.config_arg; points configFile to the address storing the config file name, but next cmdline_parser_##ggo_filename##_free(&args_info); frees all string field of args_info, including args_info.config_arg, therefore the content pointed by configFile becomes invalid. Regards, Chao 2014-12-12 14:10 GMT+01:00 Simon Rit : > My fix did not work. Cyril (Mory) reported that multiple options were read > twice. I hope this new fix will work but don't hesitate to report other > issues with gengetopt. > Thanks again for you reports, > Simon > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > wrote: >> >> That makes sense, thanks for the quick usage explanation, and fix. >> (Disabling the override issue makes sense, and I didn't have time to trace >> through gengetopt. I thought I was missing something, as none of the >> non-flag arguments were being reset (to null, or default values, and thus >> thought 'override' meant something else!). >> >> Thanks again, glad the info was helpful. >> >> Steve >> >> >> On 14-12-10 4:01 AM, Simon Rit wrote: >> >> Hi, >> Thanks for the report, very useful information. I could reproduce the bug >> and I hope that I have fixed it. Briefly: >> - I have changed the code because Ben Champion reported memory leaks and I >> noticed that they occured in deprecated functions of gengetopt that I don't >> use anymore, >> - the way the new macro (as well as the previous one) is written is: first >> read the command line to find if a config file is passed, then read the >> config file and finally read the command line again to check that everything >> has been passed. >> - your fix was not perfect because we would not have checked that the >> required options were set, >> - it turns out that disabling the override option did the job. >> Everything sworks fine now but let met know if you notice something wrong >> again. Thanks again, >> Simon >> >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann >> wrote: >>> >>> A recent update to rtkMacro.h seems to have caused the ggo command line >>> processor to ignore command line flags. (i.e. I can't get any verbose output >>> with '-v'). >>> It seems to happen after making a second call to: >>> >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, &args_params) >>> >>> Removing this second call, has resolved the issue for me. >>> I'm not sure, however, what the intended use of the second call was for >>> (it occurs immediately after: >>> >>> args_params.check_required = 1; >>> >>> which I feel could just be moved above the first call, as it happens >>> regardless, but I may be missing something. >>> >>> I've attached my quickly modified rtkMacro.h for comparison to the latest >>> github commit. >>> >>> Anyhow, hopefully this info is useful, and doesn't only affect me. >>> >>> Steve >>> >>> Our system setup: >>> -Ubuntu 14.04 x64 >>> -gcc 4.8.2 >>> -cuda 6.5 >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 5 09:17:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 5 Feb 2015 15:17:34 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Indeed, it looks as if I had not tested it, I thought I had... This patch should fix it. Thanks for the report! Simon On Thu, Feb 5, 2015 at 12:44 PM, Chao Wu wrote: > Hi Simon, > > There is still an issue with gengetopt. The config file cannot be read. > The problem seems to be at around line 62 in rtkMacro.h: > char *configFile = args_info.config_arg; points configFile to the > address storing the config file name, but next > cmdline_parser_##ggo_filename##_free(&args_info); frees all string > field of args_info, including args_info.config_arg, therefore the > content pointed by configFile becomes invalid. > > Regards, > Chao > > 2014-12-12 14:10 GMT+01:00 Simon Rit : > > My fix did not work. Cyril (Mory) reported that multiple options were > read > > twice. I hope this new fix will work but don't hesitate to report other > > issues with gengetopt. > > Thanks again for you reports, > > Simon > > > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > > wrote: > >> > >> That makes sense, thanks for the quick usage explanation, and fix. > >> (Disabling the override issue makes sense, and I didn't have time to > trace > >> through gengetopt. I thought I was missing something, as none of the > >> non-flag arguments were being reset (to null, or default values, and > thus > >> thought 'override' meant something else!). > >> > >> Thanks again, glad the info was helpful. > >> > >> Steve > >> > >> > >> On 14-12-10 4:01 AM, Simon Rit wrote: > >> > >> Hi, > >> Thanks for the report, very useful information. I could reproduce the > bug > >> and I hope that I have fixed it. Briefly: > >> - I have changed the code because Ben Champion reported memory leaks > and I > >> noticed that they occured in deprecated functions of gengetopt that I > don't > >> use anymore, > >> - the way the new macro (as well as the previous one) is written is: > first > >> read the command line to find if a config file is passed, then read the > >> config file and finally read the command line again to check that > everything > >> has been passed. > >> - your fix was not perfect because we would not have checked that the > >> required options were set, > >> - it turns out that disabling the override option did the job. > >> Everything sworks fine now but let met know if you notice something > wrong > >> again. Thanks again, > >> Simon > >> > >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann > >> wrote: > >>> > >>> A recent update to rtkMacro.h seems to have caused the ggo command line > >>> processor to ignore command line flags. (i.e. I can't get any verbose > output > >>> with '-v'). > >>> It seems to happen after making a second call to: > >>> > >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, > &args_params) > >>> > >>> Removing this second call, has resolved the issue for me. > >>> I'm not sure, however, what the intended use of the second call was for > >>> (it occurs immediately after: > >>> > >>> args_params.check_required = 1; > >>> > >>> which I feel could just be moved above the first call, as it happens > >>> regardless, but I may be missing something. > >>> > >>> I've attached my quickly modified rtkMacro.h for comparison to the > latest > >>> github commit. > >>> > >>> Anyhow, hopefully this info is useful, and doesn't only affect me. > >>> > >>> Steve > >>> > >>> Our system setup: > >>> -Ubuntu 14.04 x64 > >>> -gcc 4.8.2 > >>> -cuda 6.5 > >>> > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> > >> > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Fri Feb 6 12:27:13 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Fri, 6 Feb 2015 18:27:13 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont -------------- next part -------------- A non-text attachment was scrubbed... Name: figure1.png Type: image/png Size: 28287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: figure2.png Type: image/png Size: 80102 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SheppLogan.txt URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 9 09:08:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Feb 2015 15:08:12 +0100 Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT wrote: > Hello rtk users, > > I try to use RTK for reconstruction in my lab but I encounter some > problems. > > I try to reconstruct a simulated spheroid. I join my phantom text file > (SheppLogan.txt). > > If I set source_y=0, I get a correct (I guess) reconstruction, see the > joined figure1.png. I use the followind set of commands : > > rtksimulatedgeometry -n 180 --sdd=508.1658133423730 > --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 > --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && > rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha > --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p > /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml > --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" > > But If I set source_y=15, I obtain some strange artefacts as you can see > on figure2.png. Do you know the origin of this pattern (the vertical one) ? > Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this > artefact doesn't exist. > > Thanks in advance and thanks for this nice toolkit. > > regards, > Mathieu Dupont > > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Thu Feb 12 04:25:12 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Thu, 12 Feb 2015 10:25:12 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <681578867.13033470.1423733112438.JavaMail.zimbra@cppm.in2p3.fr> Hi Simon, you are right, it works now. Thanks for your reactivity. ----- Mail original ----- De: "Simon Rit" ?: "Mathieu DUPONT" Cc: rtk-users at public.kitware.com Envoy?: Lundi 9 F?vrier 2015 15:08:12 Objet: Re: [Rtk-users] fdk artefact, sourceOffsetY Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT < mdupont at cppm.in2p3.fr > wrote: Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From lomahu at gmail.com Thu Feb 12 10:04:45 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 10:04:45 -0500 Subject: [Rtk-users] building CUDA Message-ID: HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 10:50:08 2015 From: theday79 at gmail.com (Yang K Park) Date: Thu, 12 Feb 2015 10:50:08 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <000801d046db$94f3eb60$bedbc220$@gmail.com> Hi Howard, Attached is my Cmake capture image for RTK using CUDA6.5. (I?m using the default option of RTK w/o any manual modification). Also, I?m using VS2013 / win7 64. I found your second option ?CUDA_ATTACH_VS_BUILD_RULE_TO_C ? is different from mine (CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE). And why don?t you use the newest version of CUDA (v6.5)? It may work fine regardless of the model of your NVIDIA graphic card (I?ve tested it for multiple computers w/ different graphic card models). CUDA6.5 is convenient to install since a single installation file will be enough which is including the graphic driver, CUDA toolkit, SDK, etc. (not sure this is same as 5.5). Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Howard Sent: Thursday, February 12, 2015 10:05 AM To: rtk-users at openrtk.org Subject: [Rtk-users] building CUDA HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Cuda_RTK_Cmake.PNG Type: image/png Size: 43604 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:16:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:16:17 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: Hi, Cmake automatically checks if you have a cuda compatible GPU. If it cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile applications. So there must be an issue with your graphic card. Check if you can compile and run has_cuda_gpu.c. Simon On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > HI, > > I encountered a problem when building CUDA applications. CUDA 5.5 was > installed on our system. I set the following in ccmake > > CUDA_64_BIT_DEVICE_CODE ON > CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > RTK_USE_CUDA ON > > I could build but no cuda applications were generated. In the bin folder I > saw libITKCudaCommon.a and librtkcuda.a. > > What did I miss? Anybody could shed light on this? Thanks, > > -howard > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From julien.jomier at kitware.com Thu Feb 12 11:23:10 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Thu, 12 Feb 2015 17:23:10 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <54DCD36E.5080903@kitware.com> To follow up, what do you mean by "no cuda applications were generated"? If you have the libraries compiled that means CMake found a working CUDA compatible device. -Julien On 12/02/2015 17:16, Simon Rit wrote: > Hi, > Cmake automatically checks if you have a cuda compatible GPU. If it > cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > applications. So there must be an issue with your graphic card. Check > if you can compile and run has_cuda_gpu.c. > Simon > > On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> HI, >> >> I encountered a problem when building CUDA applications. CUDA 5.5 was >> installed on our system. I set the following in ccmake >> >> CUDA_64_BIT_DEVICE_CODE ON >> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> RTK_USE_CUDA ON >> >> I could build but no cuda applications were generated. In the bin folder I >> saw libITKCudaCommon.a and librtkcuda.a. >> >> What did I miss? Anybody could shed light on this? Thanks, >> >> -howard >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:27:09 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:27:09 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: <54DCD36E.5080903@kitware.com> References: <54DCD36E.5080903@kitware.com> Message-ID: Actually no, librtkcuda is compiled if the cuda library is available but the applications are compiled if the cuda library AND a cuda compatible device are available... That's probably why you observe this. Simon On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier wrote: > To follow up, what do you mean by "no cuda applications were generated"? If > you have the libraries compiled that means CMake found a working CUDA > compatible device. > > -Julien > > > On 12/02/2015 17:16, Simon Rit wrote: >> >> Hi, >> Cmake automatically checks if you have a cuda compatible GPU. If it >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> applications. So there must be an issue with your graphic card. Check >> if you can compile and run has_cuda_gpu.c. >> Simon >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >>> >>> HI, >>> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >>> installed on our system. I set the following in ccmake >>> >>> CUDA_64_BIT_DEVICE_CODE ON >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >>> RTK_USE_CUDA ON >>> >>> I could build but no cuda applications were generated. In the bin folder >>> I >>> saw libITKCudaCommon.a and librtkcuda.a. >>> >>> What did I miss? Anybody could shed light on this? Thanks, >>> >>> -howard >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > From lomahu at gmail.com Thu Feb 12 12:24:12 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 12:24:12 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: Thanks all for your responses to my question. I did not initially set CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: [ 24%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt for reading. [ 25%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt for reading. As I said in my original post, we have CUDA installed on the system (cluster system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the cards would work well although I haven't confirmed that. -howard On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit wrote: > Actually no, librtkcuda is compiled if the cuda library is available > but the applications are compiled if the cuda library AND a cuda > compatible device are available... That's probably why you observe > this. > Simon > > On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > wrote: > > To follow up, what do you mean by "no cuda applications were generated"? > If > > you have the libraries compiled that means CMake found a working CUDA > > compatible device. > > > > -Julien > > > > > > On 12/02/2015 17:16, Simon Rit wrote: > >> > >> Hi, > >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> applications. So there must be an issue with your graphic card. Check > >> if you can compile and run has_cuda_gpu.c. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >>> > >>> HI, > >>> > >>> I encountered a problem when building CUDA applications. CUDA 5.5 was > >>> installed on our system. I set the following in ccmake > >>> > >>> CUDA_64_BIT_DEVICE_CODE ON > >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >>> RTK_USE_CUDA ON > >>> > >>> I could build but no cuda applications were generated. In the bin > folder > >>> I > >>> saw libITKCudaCommon.a and librtkcuda.a. > >>> > >>> What did I miss? Anybody could shed light on this? Thanks, > >>> > >>> -howard > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> _______________________________________________ > >> Rtk-users mailing list > >> Rtk-users at public.kitware.com > >> http://public.kitware.com/mailman/listinfo/rtk-users > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 12:42:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 18:42:15 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: That's more complicated. First, CUDA_HAVE_GPU is normally turned on automatically but maybe it's been turned off due to the problem you're encountering now. The problem you have is probably not specific to RTK, we don't develop FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an option CUDA_BUILD_CUBIN, maybe turn it off? If I were you, I'd try to create a small separate project with has_cuda_gpu.c and check whether it compiles. If it doesn't, try the cmake mailing list. Simon On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > Thanks all for your responses to my question. I did not initially set > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > [ 24%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > for reading. > > > [ 25%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > for reading. > > As I said in my original post, we have CUDA installed on the system (cluster > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > cards would work well although I haven't confirmed that. > > -howard > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit > wrote: >> >> Actually no, librtkcuda is compiled if the cuda library is available >> but the applications are compiled if the cuda library AND a cuda >> compatible device are available... That's probably why you observe >> this. >> Simon >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> wrote: >> > To follow up, what do you mean by "no cuda applications were generated"? >> > If >> > you have the libraries compiled that means CMake found a working CUDA >> > compatible device. >> > >> > -Julien >> > >> > >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> Hi, >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> applications. So there must be an issue with your graphic card. Check >> >> if you can compile and run has_cuda_gpu.c. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >>> >> >>> HI, >> >>> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >> >>> installed on our system. I set the following in ccmake >> >>> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >>> RTK_USE_CUDA ON >> >>> >> >>> I could build but no cuda applications were generated. In the bin >> >>> folder >> >>> I >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >>> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >>> >> >>> -howard >> >>> >> >>> _______________________________________________ >> >>> Rtk-users mailing list >> >>> Rtk-users at public.kitware.com >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >>> >> >> _______________________________________________ >> >> Rtk-users mailing list >> >> Rtk-users at public.kitware.com >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > > > From lomahu at gmail.com Thu Feb 12 13:37:39 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 13:37:39 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: When I did the following: CUDA_HAVE_GPU ON CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) building was successful. I could run rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk using cuda?) with successful reconstruction. It's done in < 15s, wow! A separate question: how to specify cuda for rtksart, rtkadmmwavelets, rtkadmmtotalvariations etc? Thanks, -howard On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit wrote: > That's more complicated. First, CUDA_HAVE_GPU is normally turned on > automatically but maybe it's been turned off due to the problem you're > encountering now. > The problem you have is probably not specific to RTK, we don't develop > FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an > option CUDA_BUILD_CUBIN, maybe turn it off? > If I were you, I'd try to create a small separate project with > has_cuda_gpu.c and check whether it compiles. If it doesn't, try the > cmake mailing list. > Simon > > On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > > Thanks all for your responses to my question. I did not initially set > > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > > > > [ 24%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > > for reading. > > > > > > [ 25%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > > for reading. > > > > As I said in my original post, we have CUDA installed on the system > (cluster > > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > > cards would work well although I haven't confirmed that. > > > > -howard > > > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > wrote: > >> > >> Actually no, librtkcuda is compiled if the cuda library is available > >> but the applications are compiled if the cuda library AND a cuda > >> compatible device are available... That's probably why you observe > >> this. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > >> wrote: > >> > To follow up, what do you mean by "no cuda applications were > generated"? > >> > If > >> > you have the libraries compiled that means CMake found a working CUDA > >> > compatible device. > >> > > >> > -Julien > >> > > >> > > >> > On 12/02/2015 17:16, Simon Rit wrote: > >> >> > >> >> Hi, > >> >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> >> applications. So there must be an issue with your graphic card. Check > >> >> if you can compile and run has_cuda_gpu.c. > >> >> Simon > >> >> > >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >> >>> > >> >>> HI, > >> >>> > >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 > was > >> >>> installed on our system. I set the following in ccmake > >> >>> > >> >>> CUDA_64_BIT_DEVICE_CODE ON > >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >> >>> RTK_USE_CUDA ON > >> >>> > >> >>> I could build but no cuda applications were generated. In the bin > >> >>> folder > >> >>> I > >> >>> saw libITKCudaCommon.a and librtkcuda.a. > >> >>> > >> >>> What did I miss? Anybody could shed light on this? Thanks, > >> >>> > >> >>> -howard > >> >>> > >> >>> _______________________________________________ > >> >>> Rtk-users mailing list > >> >>> Rtk-users at public.kitware.com > >> >>> http://public.kitware.com/mailman/listinfo/rtk-users > >> >>> > >> >> _______________________________________________ > >> >> Rtk-users mailing list > >> >> Rtk-users at public.kitware.com > >> >> http://public.kitware.com/mailman/listinfo/rtk-users > >> >> > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 13:47:54 2015 From: theday79 at gmail.com (Yang-Kyun Park) Date: Thu, 12 Feb 2015 13:47:54 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: hi howard, use following options for fwd and bkward projection --fp CudaRayCast --bp CudaVoxelBased Yang On Feb 12, 2015 1:37 PM, "Howard" wrote: > When I did the following: > > CUDA_HAVE_GPU ON > CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) > CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) > > building was successful. I could run > > rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk > using cuda?) > > with successful reconstruction. It's done in < 15s, wow! > > A separate question: how to specify cuda for rtksart, > rtkadmmwavelets, rtkadmmtotalvariations etc? > > Thanks, > -howard > > > > > > > > > > > On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> wrote: > >> That's more complicated. First, CUDA_HAVE_GPU is normally turned on >> automatically but maybe it's been turned off due to the problem you're >> encountering now. >> The problem you have is probably not specific to RTK, we don't develop >> FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an >> option CUDA_BUILD_CUBIN, maybe turn it off? >> If I were you, I'd try to create a small separate project with >> has_cuda_gpu.c and check whether it compiles. If it doesn't, try the >> cmake mailing list. >> Simon >> >> On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: >> > Thanks all for your responses to my question. I did not initially set >> > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: >> > >> > >> > [ 24%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > >> > [ 25%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > As I said in my original post, we have CUDA installed on the system >> (cluster >> > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are >> > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume >> the >> > cards would work well although I haven't confirmed that. >> > >> > -howard >> > >> > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> > wrote: >> >> >> >> Actually no, librtkcuda is compiled if the cuda library is available >> >> but the applications are compiled if the cuda library AND a cuda >> >> compatible device are available... That's probably why you observe >> >> this. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> >> wrote: >> >> > To follow up, what do you mean by "no cuda applications were >> generated"? >> >> > If >> >> > you have the libraries compiled that means CMake found a working CUDA >> >> > compatible device. >> >> > >> >> > -Julien >> >> > >> >> > >> >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> >> >> Hi, >> >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> >> applications. So there must be an issue with your graphic card. >> Check >> >> >> if you can compile and run has_cuda_gpu.c. >> >> >> Simon >> >> >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >> >>> >> >> >>> HI, >> >> >>> >> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 >> was >> >> >>> installed on our system. I set the following in ccmake >> >> >>> >> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >> >>> RTK_USE_CUDA ON >> >> >>> >> >> >>> I could build but no cuda applications were generated. In the bin >> >> >>> folder >> >> >>> I >> >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >> >>> >> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >> >>> >> >> >>> -howard >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Rtk-users mailing list >> >> >>> Rtk-users at public.kitware.com >> >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >>> >> >> >> _______________________________________________ >> >> >> Rtk-users mailing list >> >> >> Rtk-users at public.kitware.com >> >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> >> >> > >> > >> > >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 13 07:06:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Feb 2015 13:06:34 +0100 Subject: [Rtk-users] ADMMTVReconstruction In-Reply-To: <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> References: <548EA4E1.4090801@creatis.insa-lyon.fr> <54919EE9.3010406@creatis.insa-lyon.fr> <5492A8BB.2030209@creatis.insa-lyon.fr> <000901d02a50$1c14f470$543edd50$@uclouvain.be> <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> Message-ID: Hi, FYI, S?bastien and I have worked on the pipeline that was mentionned in this discussion. The pipeline is now available in the rtkProjectionsReader (see the diagram in the doc ). Every rtk application can use it from command line options. For example, I0 is automatically estimated if the option --i0=0 is used. Don't hesitate to report what is not clear or not working for you. Simon On Thu, Jan 8, 2015 at 4:04 PM, S?bastien Brousmiche < sebastien.brousmiche at uclouvain.be> wrote: > Hi Howard, > > > > Actually there are three values given per projection: I0, a filtered I0 > (RLS) and the FWHM of the background mode. > > You can just use the first value per projection. If ?output? is the buffer > contained in the file (-d) then use I0 = buffer(1:3:end); > > > > Read rtki0estimation.cxx in the application folder for more information. > I?m planning to add more info in the code later. > > > > Best, > > S?bastien > > > > > > *From:* Howard [mailto:lomahu at gmail.com] > *Sent:* jeudi 8 janvier 2015 15:57 > *To:* S?bastien Brousmiche > *Cc:* Simon Rit; rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Hi Sebastien, > > > > Thank you very much for your explanation. I used -d to write I0 > estimations to a file. I found there are >2000 numbers for ~600 > projections. I thought there would be one number for each projection, but > obviously the output numbers are not generated that way. Could you please > describe a bit more on the file format and how to use them? Or simply I > wait for your new mini-pipeline filter? > > > > Regards, > > -howard > > > > On Wed, Jan 7, 2015 at 3:01 AM, S?bastien Brousmiche < > sebastien.brousmiche at uclouvain.be> wrote: > > Hi Howard, > > > > There is an input parameter with the rtki0estimation application (-d) > which allows you to specify the output file with I0 estimates. > > > > The big file you mentioned contains the histograms of each image (65536 > values each) stored consecutively. The first value is the occurrence of > number 0 in your image, second.. 1 and so forth up to 65535. > > > > This application is not particularly interesting to be used in a pipeline. > > > > > Nevertheless, we are developing a mini-pipeline grouping typical > preprocessing filters. It is under validation and I?ll let you know as soon > as it is available for you. > > > > Best, > > S?bastien > > > > > > > > > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Howard > *Sent:* mercredi 7 janvier 2015 00:17 > *To:* Simon Rit > *Cc:* rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Happy New Year, Simon. > > > > Thank you for pointing to me the I0 estimate procedure.I saw an > application rtki0estimation > > under the Applications folder. Is this the tool you meant? I ran it using > all default parameters > > providing with the original projection data. What I obtained was a file: > i0est_histogram.csv. > > From the comments in rtki0estimation.ggo this file is the output with I0 > estimate. For 650 projections > > the file size is around 200MB. I used excel to open the file and found > that the beginning two numbers > > 64408 and 722024 then followed by 0's. In the middle there are some > nonzero numbers. Essentially > > all zeros. > > Since there is not much description of the application, so it is hard to > figure out easily what I am doing. > > I tried to read the source code, but it might be more useful if you can > give some hints on how to > > use it. > > > > Regards, > > -howard > > > > > > On Mon, Jan 5, 2015 at 1:49 AM, Simon Rit > wrote: > > Happy new year Howard, > Normally, this calibration is handled by the flat panel. It uses an > air projection and a dark (no beam) projection to compute the line > integral. However, there might be fluctuations in time of these two > projections. Some people do regular acquisitions of them to capture > the time fluctuations. Otherwise, a constant value might be a good > solution. S?bastien has recently implemented an automated > determination of this constant, maybe you should have a look: > > http://www.openrtk.org/Doxygen/classrtk_1_1I0EstimationProjectionFilter.html > It is already part of the mini-pipeline for ImagX / IBA projections > processing: > > http://www.openrtk.org/Doxygen/classrtk_1_1ImagXRawToAttenuationImageFilter.html > Simon > > > On Fri, Jan 2, 2015 at 10:17 PM, Howard wrote: > > Happy New Year, Cyril. > > > > I realized that our projection data is having some issues with air > > correction. We checked our calibration and it appeared fine. Do you know > by > > any chance whether there is a quick way of correcting that? I searched > > around and found people used a constant air norm image. > > > > Thanks very much, > > -howard > > > > On Thu, Dec 18, 2014 at 5:13 AM, Cyril Mory > > wrote: > >> > >> Hi Howard, > >> > >> I've taken a look at your data. > >> You can apply tv denoising on the out.mha volume and obtain a > >> significantly lower level of noise without blurring structures by using > the > >> following command : > >> rtktotalvariationdenoising -i out.mha -g 0.001 -o > >> tvdenoised/gamma0.001.mha -n 100 > >> > >> I was unable to obtain good results with iterative reconstruction from > the > >> projection data you sent, though. I think the main reason for this is > that > >> your projections have much-higher-than-zero attenuation in air. Your > >> calculation of i0 when converting from intensity to attenuation is > probably > >> not good enough. Try to correct for this effect first. Then you can > start > >> performing SART and Conjugate Gradient reconstructions on your data, and > >> once you get these right, play with ADMM. > >> > >> You might need to remove the table from the projections to be able to > >> restrict the reconstruction volume strictly to the patient, and speed > up the > >> computations. We can provide help for that too. > >> > >> Best regards, > >> Cyril > >> > >> > >> On 12/17/2014 05:02 PM, Howard wrote: > >> > >> Hi Cyril, > >> > >> I've sent you two files via wetransfer.com: one is the sparse > projection > >> set with geometry file and the other is the fdk reconstructed image > based on > >> full projection set. Please let me know if you have trouble receiving > them. > >> > >> Thanks very much for looking into this. > >> > >> -Howard > >> > >> On Wed, Dec 17, 2014 at 10:19 AM, Cyril Mory > >> wrote: > >>> > >>> Hi Howard, > >>> > >>> Thanks for the detailed feedback. > >>> The image getting blurry is typically due to a too high gamma. > Depending > >>> on you data, gamma can have to be set to a very small value (I use > 0.007 in > >>> some reconstructions on clinical data). Can you send over your volume > >>> reconstructed from full projection data, and I'll have a quick look ? > >>> > >>> There is a lot of instinct in the setting of the parameters. With time, > >>> one gets used to finding a correct set of parameters without really > knowing > >>> how. I can also try to reconstruct from your cbct data if you send me > the > >>> projections and the geometry. > >>> > >>> Best regards, > >>> Cyril > >>> > >>> > >>> On 12/17/2014 03:49 PM, Howard wrote: > >>> > >>> Hi Cyril, > >>> > >>> Thanks very much for your detailed and nice description on how to use > the > >>> admmtv reconstruction. I followed your suggestions and re-ran > >>> reconstructions using admmtotalvariation and admmwavelets with cbct > >>> projection data from a thoracic patient. > >>> > >>> I am reporting what I found and hope these will give you information > for > >>> further improvement. > >>> > >>> 1. I repeated admmtotalvariation with 30 iterations. No improvement was > >>> observed. As a matter of fact, the reconstructed image is getting a lot > >>> noiser compared to that using 3 iterations. The contrast is getting > worse as > >>> well. I tried to play around with window & level in case I was fooled > but > >>> apparently more iterations gave worse results. > >>> > >>> 2. Similarly I ran 30 iterations using admmwavelets. Slightly better > >>> reconstruction compared with total variation. > >>> > >>> 3. Then I went ahead to test if TV benefits us anything using the > >>> tvdenoising application on the fdk-reconstructed image reconstructed > from > >>> full projection set. I found that the more iterations, the more blurry > the > >>> image became. For example, with 50 iterations the contrast on the > denoised > >>> image is very low so that the vertebrae and surrounding soft tissue are > >>> hardly distinguishable. Changing gamma's at 0.2, 0.5, 1.0, 10 did not > seem > >>> to make a difference on the image. With 5 iterations the denoising > seems to > >>> work fairly well. Again, changing gamma's didn't make a difference. > >>> I hope I didn't misused the totalvariationdenoising application. The > >>> command I executed was: rtktotalvariationdenoising -i out.mha -o > >>> out_denoising_n50_gamma05 --gamma 0.5 -n 50 > >>> > >>> In summary, tdmmwavelets seems perform better than tdmmtotalvariation > but > >>> neither gave satisfactory results. No sure what we can infer from the > TV > >>> denoising study. I could send my study to you if there is a need. > Please let > >>> me know what tests I could run. Further help on improvement is > definitely > >>> welcome and appreciated. > >>> > >>> -Howard > >>> > >>> On Mon, Dec 15, 2014 at 4:07 AM, Cyril Mory > >>> wrote: > >>>> > >>>> Hello Howard, > >>>> > >>>> Good to hear that you're using RTK :) > >>>> I'll try to answer all your questions, and give you some advice: > >>>> - In general, you can expect some improvement over rtkfdk, but not a > >>>> huge one > >>>> - You can find the calculations in my PhD thesis > >>>> https://tel.archives-ouvertes.fr/tel-00985728 (in English. Only the > >>>> introduction is in French) > >>>> - Adjusting the parameters is, in itself, a research topic (sorry !). > >>>> Alpha controls the amount of regularization and only that (the > higher, the > >>>> more regularization). Beta, theoretically, should only change the > >>>> convergence speed, provided you do an infinite number of iterations > (I know > >>>> it doesn't help, sorry again !). In practice, beta is ubiquitous and > appears > >>>> everywhere in the calculations, therefore it is hard to predict what > effect > >>>> an increase/decrease of beta will give on the images. I would keep it > as is, > >>>> and play on alpha > >>>> - 3 iterations is way too little. I typically used 30 iterations. > Using > >>>> the CUDA forward and back projectors helped a lot maintain the > computation > >>>> time manageable > >>>> - The quality of the results depends a lot on the nature of the image > >>>> you are trying to reconstruct. In a nutshell, the algorithm assumes > that the > >>>> image you are reconstructing has a certain form of regularity, and > discards > >>>> the potential solutions that do not have it. This assumption partly > >>>> compensates for the lack of data. ADMM TV assumes that the image you > are > >>>> reconstructing is piecewise constant, i.e. has large uniform areas > separated > >>>> by sharp borders. If your image is a phantom, it should give good > results. > >>>> If it is a real patient, you should probably change to another > algorithm > >>>> that assumes another form of regularity in the images (try > rtkadmmwavelets) > >>>> - You can find out whether you typical images can benefit from TV > >>>> regularization by reconstructing from all projections with rtkfdk, > then > >>>> applying rtktotalvariationdenoising on the reconstructed volume (try > 50 > >>>> iterations and adjust the gamma parameter: high gamma means high > >>>> regularization). If this denoising implies an unacceptable loss of > quality, > >>>> stay away from TV for these images, and try wavelets > >>>> > >>>> I hope this helps > >>>> > >>>> Looking forward to reading you again, > >>>> Cyril > >>>> > >>>> > >>>> On 12/12/2014 06:42 PM, Howard wrote: > >>>> > >>>> I am testing the ADMM total variation reconstruction with sparse data > >>>> sample. I could reconstruct but the results were not as good as > expected. In > >>>> other words, it didn't show much improvement compared to fdk > reconstruction > >>>> using the same sparse projection data. > >>>> > >>>> The parameters I used in ADMMTV were the following: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --alpha 1 --beta 1000 -n 3 > >>>> > >>>> while the fdk reconstruction parameters are: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --pad 0.1 --hann 0.5 > >>>> > >>>> The dimensions were chosen to include the entire anatomy. 72 > projections > >>>> were selected out of 646 projections for a 360 degree scan for both > >>>> calculations. > >>>> > >>>> What parameters and how can I adjust (like alpha, beta, or > iterations?) > >>>> to improve the ADMMTV reconstruction? There is not much description > of this > >>>> application from the wiki page. > >>>> > >>>> Thanks, > >>>> > >>>> -howard > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Rtk-users mailing list > >>>> Rtk-users at public.kitware.com > >>>> http://public.kitware.com/mailman/listinfo/rtk-users > >>>> > >>>> > >>>> -- > >>>> -- > >>>> Cyril Mory, Post-doc > >>>> CREATIS > >>>> Leon Berard cancer treatment center > >>>> 28 rue La?nnec > >>>> 69373 Lyon cedex 08 FRANCE > >>>> > >>>> Mobile: +33 6 69 46 73 79 > >>> > >>> > >>> -- > >>> -- > >>> Cyril Mory, Post-doc > >>> CREATIS > >>> Leon Berard cancer treatment center > >>> 28 rue La?nnec > >>> 69373 Lyon cedex 08 FRANCE > >>> > >>> Mobile: +33 6 69 46 73 79 > >> > >> > >> -- > >> -- > >> Cyril Mory, Post-doc > >> CREATIS > >> Leon Berard cancer treatment center > >> 28 rue La?nnec > >> 69373 Lyon cedex 08 FRANCE > >> > >> Mobile: +33 6 69 46 73 79 > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > > > > > ------------------------------ > > [image: Image removed by sender.] > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > > > > > > ------------------------------ > > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: not available URL: From Robert.Calliess at gmx.de Tue Feb 24 03:56:15 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 24 Feb 2015 09:56:15 +0100 Subject: [Rtk-users] sart back projection, weighting steps Message-ID: An HTML attachment was scrubbed... URL: From cyril.mory at creatis.insa-lyon.fr Tue Feb 24 04:55:00 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Tue, 24 Feb 2015 10:55:00 +0100 Subject: [Rtk-users] sart back projection, weighting steps In-Reply-To: References: Message-ID: <54EC4A74.2010601@creatis.insa-lyon.fr> Hi Robert, I'm glad to know that most of the explanation text is understandable :) You might want to check this filter: http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html You can use the command line application "rtkbackprojections" with argument --bp to compare "Joseph" and "NormalizedJoseph". When performing a back projection with non-normalized Joseph, the projection values are "splat" (splat is the adjoint operator of interpolation) between the four nearest voxels in each volume plane the ray intersects. Nothing guarantees that every voxel will receive a contribution during this process. How many contributions a voxel receives is determined by the sampling of the projections, which can be much looser or much denser (locally and globally) than what would be required. Dividing by the back projection of an image of ones mitigates this effect. In theory, as long as the forward and back projection operators are the adjoint of one another, it should not be a problem for SART. In practice, it does make a difference. I hope it helps. Please let me know if it is still unclear; Cyril On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward projection, > every pixel is > divided by the intersection length of the ray with the volume. That is > clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This weighting > step is not > performed when using a voxel-based back projection, as the weights > are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all pixels > have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply this > weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate the > pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range from 0 > to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Thu Feb 26 14:35:06 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Thu, 26 Feb 2015 19:35:06 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely,Vahid? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Thu Feb 26 15:18:53 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Thu, 26 Feb 2015 21:18:53 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Message-ID: <00d901d05201$71a49200$54edb600$@gmx.de> Hello Vahid, I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI but with a wider sensor array. I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code. But let?s see what grandmasters of RTK will suggest. Best regards, Robert Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely, Vahid -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Thu Feb 26 16:33:46 2015 From: ghostcz at hotmail.com (louie L) Date: Thu, 26 Feb 2015 22:33:46 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <00d901d05201$71a49200$54edb600$@gmx.de> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work. Best regards, Louie Greetings from my iOS! > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the > resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). > I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around > the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these > seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI > but with a wider sensor array. > > I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it > would be possible to model the helical trajectory by the changing geometry without changing /adding code. > > But let?s see what grandmasters of RTK will suggest. > > Best regards, > Robert > > > Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users > Gesendet: Donnerstag, 26. Februar 2015 20:35 > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK > > Dear RTK users, > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? > I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. > > Sincerely, > Vahid > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From cyril.mory at creatis.insa-lyon.fr Fri Feb 27 03:45:24 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Fri, 27 Feb 2015 09:45:24 +0100 Subject: [Rtk-users] Fwd: Re: Aw: Re: sart back projection, weighting steps In-Reply-To: <54F02E7E.7080000@creatis.insa-lyon.fr> References: <54F02E7E.7080000@creatis.insa-lyon.fr> Message-ID: <54F02EA4.7010006@creatis.insa-lyon.fr> Hi Robert, No problem, glad to help. I think either I have'nt been clear enough, or you're getting confused, though :) Let me try again: In joseph back projection, for each PIXEL, you "draw a line" between the source and the pixel's center, and see which voxels it crosses. Your line crosses each slice of the volume at an intersection point. You determine what the interpolation weights would be if you were to interpolate at this intersection point. And these weights are indeed between 0 and 1. But instead of interpolating, you "splat", that means you update the four nearest voxels by adding (projection's pixel value * interpolationWeight) to each. And you move to the next slice. Once you've considered all rays, you're done. Nothing in this process guarantees that a voxel will receive any contribution. In fact, some receive none, and some too many. The backprojected volume you obtain is "biased". You could think of it as the product of what you really want (the projection's pixel values smeared out along the lines of rays) with a "sampling density map" (the cumulated splat weights each voxel has been updated with). If you back project a projection of ones, then your resulting volume is exactly this sampling density map, and you can divide by it to obtain what you really want. In voxel based back projection, for each voxel, you "draw a line" between the source and the voxel's center, see where it hits the 2D projection, and add the value of that pixel (or interpolated at this position between pixels) into the voxel. And that's it for this voxel, so each voxel gets updated once and only once. And if the projection contains only ones, then your volume gets filled with ones. Dividing by one isn't going to change anything, so you just don't do it. I hope it is clearer. Cyril On 02/26/2015 02:10 PM, "Robert Callie?" wrote: > Hello Cyril, > thank you for the fast reply and thank you for the support. > Indeed I have some more questions. For the normalization step > you on the one hand side create a projection image filled with "1" > and on the other hand side you create an empty (zero) volume and > then back project the image, ok. > >>How many contributions a voxel receives is determined by the > sampling of the projections > Yes, I have the same problems with a voxel-based back projector. But > don't you have > this problem also with joseph's method when you use it for the back > projection of the "1" projection > image ? It's not clear to me how this kind of back projection actually > works (or is calculated). > And if the projection image consists of pixels with value "1" then we > actually don't need it or do we ? > So far I understand, no matter if we perform the forward or back > projtion, the joseph projector calculates > the weightings of the four voxels that are "around" the current plane > intersection point. And this > weights are always between 0 and 1. > Or do I totally misunderstand the concept of this backprojection. > I hope I did not confused you. > best regards, > Robert > *Gesendet:* Dienstag, 24. Februar 2015 um 10:55 Uhr > *Von:* "Cyril Mory" > *An:* "Robert Callie?" , rtk-users at openrtk.org > *Betreff:* Re: [Rtk-users] sart back projection, weighting steps > Hi Robert, > > I'm glad to know that most of the explanation text is understandable :) > You might want to check this filter: > http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html > You can use the command line application "rtkbackprojections" with > argument --bp to compare "Joseph" and "NormalizedJoseph". > > When performing a back projection with non-normalized Joseph, the > projection values are "splat" (splat is the adjoint operator of > interpolation) between the four nearest voxels in each volume plane > the ray intersects. Nothing guarantees that every voxel will receive a > contribution during this process. How many contributions a voxel > receives is determined by the sampling of the projections, which can > be much looser or much denser (locally and globally) than what would > be required. Dividing by the back projection of an image of ones > mitigates this effect. In theory, as long as the forward and back > projection operators are the adjoint of one another, it should not be > a problem for SART. In practice, it does make a difference. > > I hope it helps. Please let me know if it is still unclear; > > Cyril > On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward > projection, every pixel is > divided by the intersection length of the ray with the volume. > That is clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This > weighting step is not > performed when using a voxel-based back projection, as the > weights are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all > pixels have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply > this weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate > the pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range > from 0 to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually > happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 27 04:42:38 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 27 Feb 2015 10:42:38 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry . I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: > Hi, > > You can change the geometry. If changed correctly, most, if not all, the > iterative cone beam reconstruction will work. > > Best regards, > Louie > > Greetings from my iOS! > > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > > I think you need to add a new reconstruction filter for it. For the first > projection the object usually is placed so that the > > resulting projection image covers the upper half of the detector. And you > will need some additional handling (z-increment). > > I guess you could do a little work around with the current rtk. If you > only reconstruct an rectangular roi around > > the detector?s center where the perspective distortion (because of the > cone) is minimal. And then you add these > > seperate volumes to a final volume. This is just an idea. I do not know > how the result will look like. Think of it like a TDI > > but with a wider sensor array. > > > > I do not know the code in detail, but if it were possible to have seperate > geometry settings for every projection image it > > would be possible to model the helical trajectory by the changing geometry > without changing /adding code. > > > > But let?s see what grandmasters of RTK will suggest. > > > > Best regards, > > Robert > > > > > > *Von:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *Im Auftrag von *vahid ettehadi > via Rtk-users > *Gesendet:* Donnerstag, 26. Februar 2015 20:35 > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] Helical cone-beam reconstruction with RTK > > > > Dear RTK users, > > > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT > in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > > I would like to change the current source trajectory from circular to > helical. I was wondering is it possible to use the RTK for helical > reconstruction only with some simple modification? > > I don't know well about reconstruction process and I don't know which type > of modification is necessary to use RTK for a helical cone beam geometry. > So, any suggestion and recommendation would be appreciated. > > > > Sincerely, > > Vahid > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Fri Feb 27 14:24:14 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Fri, 27 Feb 2015 19:24:14 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: Message-ID: <47007992.1342548.1425065054134.JavaMail.yahoo@mail.yahoo.com> Hello,Thank you Robert, Louie and Simon, for your tips and recommendations. I will work on it and I will share the result or potential problems. I found the RTK more accurate and easy to use in compare with other open-source reconstruction tools such as Oscar and NiftyRec.? Thank you RTK team!Vahid On Friday, February 27, 2015 4:42 AM, Simon Rit wrote: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry. I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work.? Best regards,Louie Greetings from my iOS! On 26 Feb 2015, at 21:19, Robert Callie? wrote: Hello Vahid,I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that theresulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment).I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi aroundthe detector?s center where the perspective distortion (because of the cone) is minimal. And then you add theseseperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDIbut with a wider sensor array.?I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code.?But let?s see what grandmasters of RTK will suggest.?Best regards,Robert??????????????? ?Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK?Dear RTK users,??I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated.?Sincerely,Vahid?? _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Sun Feb 1 04:41:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 1 Feb 2015 10:41:03 +0100 Subject: [Rtk-users] RTK In-Reply-To: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> References: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> Message-ID: On Fri, Jan 30, 2015 at 10:19 AM, Robert Callie? wrote: > Hello Simon, > > thank you for the fast reply. > > > > ?Joseph's method samples the ray with one pixel per slice in the main > direction but it does not compute the intersection of the ray with each > voxel. Siddon's method does that. In fig 2 of [Xu and Mueller, 2006], Joseph > is referred to "slice interpolated" and Siddon to "box-line-integrated". > OK, thanks for that hint. I think it will maybe also has the same problem > with divergent rays and missing voxels during the reconstruction. Do you For sure. > have a link to a paper or source to this algorithm. So the algorithm may > work > > As following: > > - calculate intersection with the physical bounding volume (entry > exit points) > > - from entrypoint, determine the 4 voxels that surround this > entrypoint and bilinear interpolate the value at this position and sum it up > > - go to next plane (plane that is most ?perpendicular? to the > current center ray (focus to detector center) ? > > - at the end, the sum is normalized by the ray length ? > (length(exitpoint ? entrypoint)) > > Is that right ? Almost. Maybe I misunderstand your last step but it is actually multiplied by each step length. Normalization occurs during backprojection, not during forward projection. > > > > How can Joseph?s method be used for back projection ? If you write the method as a system matrix, simply take the transpose of it. For (S)ART, you will want to divide by the sum of the weights along one ray which is exactly what you mentionned, the ray length. > > > > ?This sounds very interesting, don't hesitate to share the code and/or the > publication! BTW, what is DDA? > > DDA stands for digital differential analyzer. I use this approach for a > voxel-based forward projector. When I started my project I was looking for a > fast and easy forward projector on voxel basis. > > I found an article about raytracing and acceleration structures where these > people used this 3d dda. They actually needed it to traverse the bounding > hierarchy to get to know what geometry > > the ray intersects with. I slightly modified it to get the intersecetion > length of a ray within a voxel by substraction of the current and previous > step width. I?v attached a zip file that contains this > > modification and the original source code. The original source code is from > www.scratchapixel.com and there is also an article about this topic > (http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-12-introduction-to-acceleration-structures/what-else/). Great, thanks. We'll have a look. Do you distribute this under a specific license? In other words, is there a risk that it would conflict with RTK license? (Apache 2, see website). > > If you have a look at my code you?ll maybe miss some matrix calculation > stuff etc. I use a scene based approach where I place the focus, object and > detector in a so called record. Each record represents the scene geometry at > a certain time, when a projection image was taken. > > Before reconstruction starts I calculate all these positions. I thought this > could be a good approach to decouple the actuall reconstruction algorithm > from the scene geometry. We'll let you know when we look at it if we have questions. > > > > > > ?But generally we use matching resolution between pixels and voxels so the > problem is minimal.? > > Do you mean, that you use a volume resolution that fits to the current > geometry setting and the detector?s pixel resolution ? Yes. > > > > ?Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > Not almost the same. What I mean seems to be simplier. Lets assume the > detector has tilted around the x-axis by 0.25 degrees. The object?s center > is at 0,0,0 and rotation axis is 0,1,0. In FDK you usually got a ray from > source to the voxel center and then you calculate > > the intersection of this ray at the detector plane. To avoid ray plane > intersection calculus, we can rotate the whole system by 0.25 degrees. Means > that the detectors normal now is parallel to the z axis.Of course the > rotation axis is not 0,1,0 any longer and the focus (xray source) > > also is a bit rotated. > > > > ?For the backprojection, we typically used voxel-based backprojection using > the center of the voxel which is faster than what you (seem to) use? > > I think here we mixed something up. This type of back projection is used for > FDK. All my questions were related to S-ART. I need to calculate the weights > > of a voxel for the back projection. To speed it up, I project its vertices > on the detector plane, calc the MEB and the send rays from within this MEB > through the > > voxel and caluclate the intersection length so those rays that will make my > weights. Some people argue that you can use the same backprojection as in FDK to speed up computations. See for example http://www.researchgate.net/profile/Gengsheng_Zeng/publication/12301525_Unmatched_projectorbackprojector_pairs_in_an_iterative_reconstruction_algorithm/links/00b495252b15fc4bb9000000.pdf > > > > > > Best regards, > > Robert > > > > > > P.S. Hello to all the other people here in the mailing list. > > > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Donnerstag, 29. Januar 2015 20:58 > An: Robert Callie? > Cc: rtk-users at openrtk.org > Betreff: Re: RTK > > > > Hi, > Thank you for your interest in RTK. Please use the mailing list for > questions that are of interest to anyone using RTK. > > There are many ways to model the direct problem (forward projection). > Without going into too many details (available in the publications of each > method) : > - "As far as I understand the goal of this approach is to calculate the > intersection length of a ray through a voxel, right ?" False. Joseph's > method samples the ray with one pixel per slice in the main direction but it > does not compute the intersection of the ray with each voxel. Siddon's > method does that. In fig 2 of [Xu and Mueller, 2006], Joseph is referred to > "slice interpolated" and Siddon to "box-line-integrated". > - "I can calculate the intersection length of the ray within a voxel by a > simple substraction, this runs very fast." This sounds very interesting, > don't hesitate to share the code and/or the publication! BTW, what is DDA? > > - Small voxels / pixels, "Did you find a way to handle this ? " We don't > handle this in RTK except if you consider that spatial regularisation (e.g., > total variation) will overcome this problem in a way. But generally we use > matching resolution between pixels and voxels so the problem is minimal. For > the backprojection, we typically used voxel-based backprojection using the > center of the voxel which is faster than what you (seem to) use. I think > that if these things are a problem for you, there is a nice solution called > distance driven (back-)projection (by De Man and Basu). I think it will do > exactly what you want. I haven't implemented it in RTK (yet). > > Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > I hope this helps. Let me know if sg is not clear in my answer! > Cheers, > Simon From riblettmj at mymail.vcu.edu Mon Feb 2 12:03:14 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 12:03:14 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF Message-ID: Hello RTK Users, I?m just getting started using RTK as part of my graduate research and was hoping that someone might be able to help me sort out an issue I?ve been having reconstructing a 3D CBCT image dataset while applying a 4D deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF has been generated by transformix (.mhd format). I followed, for the most part, the MCCBCTReconstruction example on the RTK Wiki. While reconstructing, rtkfdk reads in all of the projections to memory, begins the ?Reconstructing and Writing? phase and proceeds for a few seconds before hanging ? it doesn?t exit or fault, just drops to 0% CPU while retaining the projections in memory. By writing some basic debug messages into the source code, I?ve been able to determine that the issue lies somewhere at m_Deformation->Update() [Line 99 of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 makes it past the m_Deformation->SetFrame(iProj) line, but never makes it past the subsequent update. I?m wondering if this has anything to do with the size of the DVF generated by transformix: approximately 4.0GB (512x100x512x10 image, 4-channels, FLOAT). Just to provide a little more background information, I?m running RTK on a 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of memory running Ubuntu 14.04. RTK was built using the default ?Release? make configuration and linked to ITK 4.5.2. Elastix and Transformix are both the latest version, 4.7. Has anyone else run into a similar issue with reconstructing a similar image, or does anyone have any thoughts as to how to resolve this sort of issue? Thanks in advance! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 2 12:19:53 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 2 Feb 2015 18:19:53 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: Hi, You're the first RTK user I know to use it on Sun! Nice! If you've got 64 GB ram, that should be enough... although you could ask elastix to generate a smaller DVF, RTK linearly interpolates between vectors. You could even use B-spline coeffs directly but you'd have to create a new DVF. My guess is that there is a problem with the initialization of m_Deformation since the line you mention is the first time it's ever used in the class. Do you use the rtkfdk app? I would start by checking that the pointer is not null before this line, sg like: std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; If it equals 0, then there is something going with the deformation. You can check it in the main app, rtkfdk.cxx. Simon On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett wrote: > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From riblettmj at mymail.vcu.edu Mon Feb 2 13:44:54 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 13:44:54 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Simon, I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the added debug line you suggested and it doesn?t look like the pointer is null. Running it through gdb, I got the following info: m_Deformation=0x16ff820 (gdb) x 0x16ff820 0x16ff820: 0x011c51d0 (gdb) x 0x011c51d0 0x11c51d0 <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: 0x005fb874 (gdb) x 0x005fb874 0x5fb874 , 3u> >::CreateAnother() const>: 0xe5894855 (gdb) x 0xe5894855 0xe5894855: Cannot access memory at address 0xe5894855 I?m still waiting on the transformix DVF, but I?ll give that a try too when its done. Thanks again! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go ahead and check to see if the pointer is null and let you know. My current check is having transformix to generate a smaller DVF to see if that helps, so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > >> On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> > wrote: >>> Hello RTK Users, >>> >>> I?m just getting started using RTK as part of my graduate research and was >>> hoping that someone might be able to help me sort out an issue I?ve been >>> having reconstructing a 3D CBCT image dataset while applying a 4D >>> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >>> has been generated by transformix (.mhd format). I followed, for the most >>> part, the MCCBCTReconstruction example on the RTK Wiki. >>> >>> While reconstructing, rtkfdk reads in all of the projections to memory, >>> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >>> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >>> retaining the projections in memory. >>> >>> By writing some basic debug messages into the source code, I?ve been able to >>> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >>> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >>> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >>> past the subsequent update. I?m wondering if this has anything to do with >>> the size of the DVF generated by transformix: approximately 4.0GB >>> (512x100x512x10 image, 4-channels, FLOAT). >>> >>> Just to provide a little more background information, I?m running RTK on a >>> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >>> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >>> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >>> latest version, 4.7. >>> >>> Has anyone else run into a similar issue with reconstructing a similar >>> image, or does anyone have any thoughts as to how to resolve this sort of >>> issue? >>> >>> Thanks in advance! >>> >>> ? Matt >>> >>> __ >>> Matthew J. Riblett >>> Virginia Commonwealth University >>> Department of Radiation Oncology >>> Medical Physics Graduate Program >>> >>> Office: Sanger Hall, Room B1-013 >>> 401 College Street | P.O. Box 980058 >>> Richmond, Virginia 23298 >>> >>> VCU Email: riblettmj at vcu.edu >>> MCV Office Phone: +1.804.628.4858 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Feb 3 02:22:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Feb 2015 08:22:54 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: That's weird because SetFrame does nothing else than change the value of the member Frame. Are you sure it's on SetFrame that the crash occurs? On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett wrote: > Simon, > > I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the > added debug line you suggested and it doesn?t look like the pointer is null. > Running it through gdb, I got the following info: > > m_Deformation=0x16ff820 > > (gdb) x 0x16ff820 > 0x16ff820: 0x011c51d0 > (gdb) x 0x011c51d0 > 0x11c51d0 > <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: > 0x005fb874 > (gdb) x 0x005fb874 > 0x5fb874 3u>, 3u> >::CreateAnother() const>: 0xe5894855 > (gdb) x 0xe5894855 > 0xe5894855: Cannot access memory at address 0xe5894855 > > I?m still waiting on the transformix DVF, but I?ll give that a try too when > its done. > > Thanks again! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett > wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go > ahead and check to see if the pointer is null and let you know. My current > check is having transformix to generate a smaller DVF to see if that helps, > so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby > supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: > > Hi, > You're the first RTK user I know to use it on Sun! Nice! > If you've got 64 GB ram, that should be enough... although you could > ask elastix to generate a smaller DVF, RTK linearly interpolates > between vectors. You could even use B-spline coeffs directly but you'd > have to create a new DVF. > My guess is that there is a problem with the initialization of > m_Deformation since the line you mention is the first time it's ever > used in the class. Do you use the rtkfdk app? I would start by > checking that the pointer is not null before this line, sg like: > std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; > If it equals 0, then there is something going with the deformation. > You can check it in the main app, rtkfdk.cxx. > Simon > > On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett > wrote: > > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From riblettmj at mymail.vcu.edu Tue Feb 3 10:36:03 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Tue, 3 Feb 2015 10:36:03 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: <60DCF1BD-5960-4A62-AC13-42897049FDFF@mymail.vcu.edu> Simon, I think that it makes it past SetFrame and crashes on Update. Just to be sure, I put a debug message after SetFrame and it does make it to that point, so its got to be on the Update line. ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 3, 2015, at 2:22 AM, Simon Rit wrote: > > That's weird because SetFrame does nothing else than change the value > of the member Frame. Are you sure it's on SetFrame that the crash > occurs? > > On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett > wrote: >> Simon, >> >> I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the >> added debug line you suggested and it doesn?t look like the pointer is null. >> Running it through gdb, I got the following info: >> >> m_Deformation=0x16ff820 >> >> (gdb) x 0x16ff820 >> 0x16ff820: 0x011c51d0 >> (gdb) x 0x011c51d0 >> 0x11c51d0 >> <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: >> 0x005fb874 >> (gdb) x 0x005fb874 >> 0x5fb874 > 3u>, 3u> >::CreateAnother() const>: 0xe5894855 >> (gdb) x 0xe5894855 >> 0xe5894855: Cannot access memory at address 0xe5894855 >> >> I?m still waiting on the transformix DVF, but I?ll give that a try too when >> its done. >> >> Thanks again! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett >> wrote: >> >> Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go >> ahead and check to see if the pointer is null and let you know. My current >> check is having transformix to generate a smaller DVF to see if that helps, >> so the server is getting that done as we speak. >> >> You might also like to know that I?ve got RTK running on a Cray CX-1 (baby >> supercomputer) sitting next to the aforementioned Sun x4600-M2. :) >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 12:19 PM, Simon Rit >> wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> wrote: >> >> Hello RTK Users, >> >> I?m just getting started using RTK as part of my graduate research and was >> hoping that someone might be able to help me sort out an issue I?ve been >> having reconstructing a 3D CBCT image dataset while applying a 4D >> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >> has been generated by transformix (.mhd format). I followed, for the most >> part, the MCCBCTReconstruction example on the RTK Wiki. >> >> While reconstructing, rtkfdk reads in all of the projections to memory, >> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >> retaining the projections in memory. >> >> By writing some basic debug messages into the source code, I?ve been able to >> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >> past the subsequent update. I?m wondering if this has anything to do with >> the size of the DVF generated by transformix: approximately 4.0GB >> (512x100x512x10 image, 4-channels, FLOAT). >> >> Just to provide a little more background information, I?m running RTK on a >> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >> latest version, 4.7. >> >> Has anyone else run into a similar issue with reconstructing a similar >> image, or does anyone have any thoughts as to how to resolve this sort of >> issue? >> >> Thanks in advance! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Thu Feb 5 06:44:47 2015 From: wuchao04 at gmail.com (Chao Wu) Date: Thu, 5 Feb 2015 12:44:47 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Hi Simon, There is still an issue with gengetopt. The config file cannot be read. The problem seems to be at around line 62 in rtkMacro.h: char *configFile = args_info.config_arg; points configFile to the address storing the config file name, but next cmdline_parser_##ggo_filename##_free(&args_info); frees all string field of args_info, including args_info.config_arg, therefore the content pointed by configFile becomes invalid. Regards, Chao 2014-12-12 14:10 GMT+01:00 Simon Rit : > My fix did not work. Cyril (Mory) reported that multiple options were read > twice. I hope this new fix will work but don't hesitate to report other > issues with gengetopt. > Thanks again for you reports, > Simon > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > wrote: >> >> That makes sense, thanks for the quick usage explanation, and fix. >> (Disabling the override issue makes sense, and I didn't have time to trace >> through gengetopt. I thought I was missing something, as none of the >> non-flag arguments were being reset (to null, or default values, and thus >> thought 'override' meant something else!). >> >> Thanks again, glad the info was helpful. >> >> Steve >> >> >> On 14-12-10 4:01 AM, Simon Rit wrote: >> >> Hi, >> Thanks for the report, very useful information. I could reproduce the bug >> and I hope that I have fixed it. Briefly: >> - I have changed the code because Ben Champion reported memory leaks and I >> noticed that they occured in deprecated functions of gengetopt that I don't >> use anymore, >> - the way the new macro (as well as the previous one) is written is: first >> read the command line to find if a config file is passed, then read the >> config file and finally read the command line again to check that everything >> has been passed. >> - your fix was not perfect because we would not have checked that the >> required options were set, >> - it turns out that disabling the override option did the job. >> Everything sworks fine now but let met know if you notice something wrong >> again. Thanks again, >> Simon >> >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann >> wrote: >>> >>> A recent update to rtkMacro.h seems to have caused the ggo command line >>> processor to ignore command line flags. (i.e. I can't get any verbose output >>> with '-v'). >>> It seems to happen after making a second call to: >>> >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, &args_params) >>> >>> Removing this second call, has resolved the issue for me. >>> I'm not sure, however, what the intended use of the second call was for >>> (it occurs immediately after: >>> >>> args_params.check_required = 1; >>> >>> which I feel could just be moved above the first call, as it happens >>> regardless, but I may be missing something. >>> >>> I've attached my quickly modified rtkMacro.h for comparison to the latest >>> github commit. >>> >>> Anyhow, hopefully this info is useful, and doesn't only affect me. >>> >>> Steve >>> >>> Our system setup: >>> -Ubuntu 14.04 x64 >>> -gcc 4.8.2 >>> -cuda 6.5 >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 5 09:17:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 5 Feb 2015 15:17:34 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Indeed, it looks as if I had not tested it, I thought I had... This patch should fix it. Thanks for the report! Simon On Thu, Feb 5, 2015 at 12:44 PM, Chao Wu wrote: > Hi Simon, > > There is still an issue with gengetopt. The config file cannot be read. > The problem seems to be at around line 62 in rtkMacro.h: > char *configFile = args_info.config_arg; points configFile to the > address storing the config file name, but next > cmdline_parser_##ggo_filename##_free(&args_info); frees all string > field of args_info, including args_info.config_arg, therefore the > content pointed by configFile becomes invalid. > > Regards, > Chao > > 2014-12-12 14:10 GMT+01:00 Simon Rit : > > My fix did not work. Cyril (Mory) reported that multiple options were > read > > twice. I hope this new fix will work but don't hesitate to report other > > issues with gengetopt. > > Thanks again for you reports, > > Simon > > > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > > wrote: > >> > >> That makes sense, thanks for the quick usage explanation, and fix. > >> (Disabling the override issue makes sense, and I didn't have time to > trace > >> through gengetopt. I thought I was missing something, as none of the > >> non-flag arguments were being reset (to null, or default values, and > thus > >> thought 'override' meant something else!). > >> > >> Thanks again, glad the info was helpful. > >> > >> Steve > >> > >> > >> On 14-12-10 4:01 AM, Simon Rit wrote: > >> > >> Hi, > >> Thanks for the report, very useful information. I could reproduce the > bug > >> and I hope that I have fixed it. Briefly: > >> - I have changed the code because Ben Champion reported memory leaks > and I > >> noticed that they occured in deprecated functions of gengetopt that I > don't > >> use anymore, > >> - the way the new macro (as well as the previous one) is written is: > first > >> read the command line to find if a config file is passed, then read the > >> config file and finally read the command line again to check that > everything > >> has been passed. > >> - your fix was not perfect because we would not have checked that the > >> required options were set, > >> - it turns out that disabling the override option did the job. > >> Everything sworks fine now but let met know if you notice something > wrong > >> again. Thanks again, > >> Simon > >> > >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann > >> wrote: > >>> > >>> A recent update to rtkMacro.h seems to have caused the ggo command line > >>> processor to ignore command line flags. (i.e. I can't get any verbose > output > >>> with '-v'). > >>> It seems to happen after making a second call to: > >>> > >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, > &args_params) > >>> > >>> Removing this second call, has resolved the issue for me. > >>> I'm not sure, however, what the intended use of the second call was for > >>> (it occurs immediately after: > >>> > >>> args_params.check_required = 1; > >>> > >>> which I feel could just be moved above the first call, as it happens > >>> regardless, but I may be missing something. > >>> > >>> I've attached my quickly modified rtkMacro.h for comparison to the > latest > >>> github commit. > >>> > >>> Anyhow, hopefully this info is useful, and doesn't only affect me. > >>> > >>> Steve > >>> > >>> Our system setup: > >>> -Ubuntu 14.04 x64 > >>> -gcc 4.8.2 > >>> -cuda 6.5 > >>> > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> > >> > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Fri Feb 6 12:27:13 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Fri, 6 Feb 2015 18:27:13 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont -------------- next part -------------- A non-text attachment was scrubbed... Name: figure1.png Type: image/png Size: 28287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: figure2.png Type: image/png Size: 80102 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SheppLogan.txt URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 9 09:08:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Feb 2015 15:08:12 +0100 Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT wrote: > Hello rtk users, > > I try to use RTK for reconstruction in my lab but I encounter some > problems. > > I try to reconstruct a simulated spheroid. I join my phantom text file > (SheppLogan.txt). > > If I set source_y=0, I get a correct (I guess) reconstruction, see the > joined figure1.png. I use the followind set of commands : > > rtksimulatedgeometry -n 180 --sdd=508.1658133423730 > --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 > --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && > rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha > --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p > /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml > --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" > > But If I set source_y=15, I obtain some strange artefacts as you can see > on figure2.png. Do you know the origin of this pattern (the vertical one) ? > Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this > artefact doesn't exist. > > Thanks in advance and thanks for this nice toolkit. > > regards, > Mathieu Dupont > > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Thu Feb 12 04:25:12 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Thu, 12 Feb 2015 10:25:12 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <681578867.13033470.1423733112438.JavaMail.zimbra@cppm.in2p3.fr> Hi Simon, you are right, it works now. Thanks for your reactivity. ----- Mail original ----- De: "Simon Rit" ?: "Mathieu DUPONT" Cc: rtk-users at public.kitware.com Envoy?: Lundi 9 F?vrier 2015 15:08:12 Objet: Re: [Rtk-users] fdk artefact, sourceOffsetY Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT < mdupont at cppm.in2p3.fr > wrote: Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From lomahu at gmail.com Thu Feb 12 10:04:45 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 10:04:45 -0500 Subject: [Rtk-users] building CUDA Message-ID: HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 10:50:08 2015 From: theday79 at gmail.com (Yang K Park) Date: Thu, 12 Feb 2015 10:50:08 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <000801d046db$94f3eb60$bedbc220$@gmail.com> Hi Howard, Attached is my Cmake capture image for RTK using CUDA6.5. (I?m using the default option of RTK w/o any manual modification). Also, I?m using VS2013 / win7 64. I found your second option ?CUDA_ATTACH_VS_BUILD_RULE_TO_C ? is different from mine (CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE). And why don?t you use the newest version of CUDA (v6.5)? It may work fine regardless of the model of your NVIDIA graphic card (I?ve tested it for multiple computers w/ different graphic card models). CUDA6.5 is convenient to install since a single installation file will be enough which is including the graphic driver, CUDA toolkit, SDK, etc. (not sure this is same as 5.5). Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Howard Sent: Thursday, February 12, 2015 10:05 AM To: rtk-users at openrtk.org Subject: [Rtk-users] building CUDA HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Cuda_RTK_Cmake.PNG Type: image/png Size: 43604 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:16:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:16:17 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: Hi, Cmake automatically checks if you have a cuda compatible GPU. If it cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile applications. So there must be an issue with your graphic card. Check if you can compile and run has_cuda_gpu.c. Simon On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > HI, > > I encountered a problem when building CUDA applications. CUDA 5.5 was > installed on our system. I set the following in ccmake > > CUDA_64_BIT_DEVICE_CODE ON > CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > RTK_USE_CUDA ON > > I could build but no cuda applications were generated. In the bin folder I > saw libITKCudaCommon.a and librtkcuda.a. > > What did I miss? Anybody could shed light on this? Thanks, > > -howard > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From julien.jomier at kitware.com Thu Feb 12 11:23:10 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Thu, 12 Feb 2015 17:23:10 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <54DCD36E.5080903@kitware.com> To follow up, what do you mean by "no cuda applications were generated"? If you have the libraries compiled that means CMake found a working CUDA compatible device. -Julien On 12/02/2015 17:16, Simon Rit wrote: > Hi, > Cmake automatically checks if you have a cuda compatible GPU. If it > cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > applications. So there must be an issue with your graphic card. Check > if you can compile and run has_cuda_gpu.c. > Simon > > On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> HI, >> >> I encountered a problem when building CUDA applications. CUDA 5.5 was >> installed on our system. I set the following in ccmake >> >> CUDA_64_BIT_DEVICE_CODE ON >> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> RTK_USE_CUDA ON >> >> I could build but no cuda applications were generated. In the bin folder I >> saw libITKCudaCommon.a and librtkcuda.a. >> >> What did I miss? Anybody could shed light on this? Thanks, >> >> -howard >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:27:09 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:27:09 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: <54DCD36E.5080903@kitware.com> References: <54DCD36E.5080903@kitware.com> Message-ID: Actually no, librtkcuda is compiled if the cuda library is available but the applications are compiled if the cuda library AND a cuda compatible device are available... That's probably why you observe this. Simon On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier wrote: > To follow up, what do you mean by "no cuda applications were generated"? If > you have the libraries compiled that means CMake found a working CUDA > compatible device. > > -Julien > > > On 12/02/2015 17:16, Simon Rit wrote: >> >> Hi, >> Cmake automatically checks if you have a cuda compatible GPU. If it >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> applications. So there must be an issue with your graphic card. Check >> if you can compile and run has_cuda_gpu.c. >> Simon >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >>> >>> HI, >>> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >>> installed on our system. I set the following in ccmake >>> >>> CUDA_64_BIT_DEVICE_CODE ON >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >>> RTK_USE_CUDA ON >>> >>> I could build but no cuda applications were generated. In the bin folder >>> I >>> saw libITKCudaCommon.a and librtkcuda.a. >>> >>> What did I miss? Anybody could shed light on this? Thanks, >>> >>> -howard >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > From lomahu at gmail.com Thu Feb 12 12:24:12 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 12:24:12 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: Thanks all for your responses to my question. I did not initially set CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: [ 24%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt for reading. [ 25%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt for reading. As I said in my original post, we have CUDA installed on the system (cluster system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the cards would work well although I haven't confirmed that. -howard On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit wrote: > Actually no, librtkcuda is compiled if the cuda library is available > but the applications are compiled if the cuda library AND a cuda > compatible device are available... That's probably why you observe > this. > Simon > > On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > wrote: > > To follow up, what do you mean by "no cuda applications were generated"? > If > > you have the libraries compiled that means CMake found a working CUDA > > compatible device. > > > > -Julien > > > > > > On 12/02/2015 17:16, Simon Rit wrote: > >> > >> Hi, > >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> applications. So there must be an issue with your graphic card. Check > >> if you can compile and run has_cuda_gpu.c. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >>> > >>> HI, > >>> > >>> I encountered a problem when building CUDA applications. CUDA 5.5 was > >>> installed on our system. I set the following in ccmake > >>> > >>> CUDA_64_BIT_DEVICE_CODE ON > >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >>> RTK_USE_CUDA ON > >>> > >>> I could build but no cuda applications were generated. In the bin > folder > >>> I > >>> saw libITKCudaCommon.a and librtkcuda.a. > >>> > >>> What did I miss? Anybody could shed light on this? Thanks, > >>> > >>> -howard > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> _______________________________________________ > >> Rtk-users mailing list > >> Rtk-users at public.kitware.com > >> http://public.kitware.com/mailman/listinfo/rtk-users > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 12:42:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 18:42:15 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: That's more complicated. First, CUDA_HAVE_GPU is normally turned on automatically but maybe it's been turned off due to the problem you're encountering now. The problem you have is probably not specific to RTK, we don't develop FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an option CUDA_BUILD_CUBIN, maybe turn it off? If I were you, I'd try to create a small separate project with has_cuda_gpu.c and check whether it compiles. If it doesn't, try the cmake mailing list. Simon On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > Thanks all for your responses to my question. I did not initially set > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > [ 24%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > for reading. > > > [ 25%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > for reading. > > As I said in my original post, we have CUDA installed on the system (cluster > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > cards would work well although I haven't confirmed that. > > -howard > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit > wrote: >> >> Actually no, librtkcuda is compiled if the cuda library is available >> but the applications are compiled if the cuda library AND a cuda >> compatible device are available... That's probably why you observe >> this. >> Simon >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> wrote: >> > To follow up, what do you mean by "no cuda applications were generated"? >> > If >> > you have the libraries compiled that means CMake found a working CUDA >> > compatible device. >> > >> > -Julien >> > >> > >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> Hi, >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> applications. So there must be an issue with your graphic card. Check >> >> if you can compile and run has_cuda_gpu.c. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >>> >> >>> HI, >> >>> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >> >>> installed on our system. I set the following in ccmake >> >>> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >>> RTK_USE_CUDA ON >> >>> >> >>> I could build but no cuda applications were generated. In the bin >> >>> folder >> >>> I >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >>> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >>> >> >>> -howard >> >>> >> >>> _______________________________________________ >> >>> Rtk-users mailing list >> >>> Rtk-users at public.kitware.com >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >>> >> >> _______________________________________________ >> >> Rtk-users mailing list >> >> Rtk-users at public.kitware.com >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > > > From lomahu at gmail.com Thu Feb 12 13:37:39 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 13:37:39 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: When I did the following: CUDA_HAVE_GPU ON CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) building was successful. I could run rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk using cuda?) with successful reconstruction. It's done in < 15s, wow! A separate question: how to specify cuda for rtksart, rtkadmmwavelets, rtkadmmtotalvariations etc? Thanks, -howard On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit wrote: > That's more complicated. First, CUDA_HAVE_GPU is normally turned on > automatically but maybe it's been turned off due to the problem you're > encountering now. > The problem you have is probably not specific to RTK, we don't develop > FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an > option CUDA_BUILD_CUBIN, maybe turn it off? > If I were you, I'd try to create a small separate project with > has_cuda_gpu.c and check whether it compiles. If it doesn't, try the > cmake mailing list. > Simon > > On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > > Thanks all for your responses to my question. I did not initially set > > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > > > > [ 24%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > > for reading. > > > > > > [ 25%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > > for reading. > > > > As I said in my original post, we have CUDA installed on the system > (cluster > > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > > cards would work well although I haven't confirmed that. > > > > -howard > > > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > wrote: > >> > >> Actually no, librtkcuda is compiled if the cuda library is available > >> but the applications are compiled if the cuda library AND a cuda > >> compatible device are available... That's probably why you observe > >> this. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > >> wrote: > >> > To follow up, what do you mean by "no cuda applications were > generated"? > >> > If > >> > you have the libraries compiled that means CMake found a working CUDA > >> > compatible device. > >> > > >> > -Julien > >> > > >> > > >> > On 12/02/2015 17:16, Simon Rit wrote: > >> >> > >> >> Hi, > >> >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> >> applications. So there must be an issue with your graphic card. Check > >> >> if you can compile and run has_cuda_gpu.c. > >> >> Simon > >> >> > >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >> >>> > >> >>> HI, > >> >>> > >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 > was > >> >>> installed on our system. I set the following in ccmake > >> >>> > >> >>> CUDA_64_BIT_DEVICE_CODE ON > >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >> >>> RTK_USE_CUDA ON > >> >>> > >> >>> I could build but no cuda applications were generated. In the bin > >> >>> folder > >> >>> I > >> >>> saw libITKCudaCommon.a and librtkcuda.a. > >> >>> > >> >>> What did I miss? Anybody could shed light on this? Thanks, > >> >>> > >> >>> -howard > >> >>> > >> >>> _______________________________________________ > >> >>> Rtk-users mailing list > >> >>> Rtk-users at public.kitware.com > >> >>> http://public.kitware.com/mailman/listinfo/rtk-users > >> >>> > >> >> _______________________________________________ > >> >> Rtk-users mailing list > >> >> Rtk-users at public.kitware.com > >> >> http://public.kitware.com/mailman/listinfo/rtk-users > >> >> > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 13:47:54 2015 From: theday79 at gmail.com (Yang-Kyun Park) Date: Thu, 12 Feb 2015 13:47:54 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: hi howard, use following options for fwd and bkward projection --fp CudaRayCast --bp CudaVoxelBased Yang On Feb 12, 2015 1:37 PM, "Howard" wrote: > When I did the following: > > CUDA_HAVE_GPU ON > CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) > CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) > > building was successful. I could run > > rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk > using cuda?) > > with successful reconstruction. It's done in < 15s, wow! > > A separate question: how to specify cuda for rtksart, > rtkadmmwavelets, rtkadmmtotalvariations etc? > > Thanks, > -howard > > > > > > > > > > > On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> wrote: > >> That's more complicated. First, CUDA_HAVE_GPU is normally turned on >> automatically but maybe it's been turned off due to the problem you're >> encountering now. >> The problem you have is probably not specific to RTK, we don't develop >> FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an >> option CUDA_BUILD_CUBIN, maybe turn it off? >> If I were you, I'd try to create a small separate project with >> has_cuda_gpu.c and check whether it compiles. If it doesn't, try the >> cmake mailing list. >> Simon >> >> On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: >> > Thanks all for your responses to my question. I did not initially set >> > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: >> > >> > >> > [ 24%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > >> > [ 25%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > As I said in my original post, we have CUDA installed on the system >> (cluster >> > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are >> > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume >> the >> > cards would work well although I haven't confirmed that. >> > >> > -howard >> > >> > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> > wrote: >> >> >> >> Actually no, librtkcuda is compiled if the cuda library is available >> >> but the applications are compiled if the cuda library AND a cuda >> >> compatible device are available... That's probably why you observe >> >> this. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> >> wrote: >> >> > To follow up, what do you mean by "no cuda applications were >> generated"? >> >> > If >> >> > you have the libraries compiled that means CMake found a working CUDA >> >> > compatible device. >> >> > >> >> > -Julien >> >> > >> >> > >> >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> >> >> Hi, >> >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> >> applications. So there must be an issue with your graphic card. >> Check >> >> >> if you can compile and run has_cuda_gpu.c. >> >> >> Simon >> >> >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >> >>> >> >> >>> HI, >> >> >>> >> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 >> was >> >> >>> installed on our system. I set the following in ccmake >> >> >>> >> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >> >>> RTK_USE_CUDA ON >> >> >>> >> >> >>> I could build but no cuda applications were generated. In the bin >> >> >>> folder >> >> >>> I >> >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >> >>> >> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >> >>> >> >> >>> -howard >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Rtk-users mailing list >> >> >>> Rtk-users at public.kitware.com >> >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >>> >> >> >> _______________________________________________ >> >> >> Rtk-users mailing list >> >> >> Rtk-users at public.kitware.com >> >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> >> >> > >> > >> > >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 13 07:06:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Feb 2015 13:06:34 +0100 Subject: [Rtk-users] ADMMTVReconstruction In-Reply-To: <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> References: <548EA4E1.4090801@creatis.insa-lyon.fr> <54919EE9.3010406@creatis.insa-lyon.fr> <5492A8BB.2030209@creatis.insa-lyon.fr> <000901d02a50$1c14f470$543edd50$@uclouvain.be> <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> Message-ID: Hi, FYI, S?bastien and I have worked on the pipeline that was mentionned in this discussion. The pipeline is now available in the rtkProjectionsReader (see the diagram in the doc ). Every rtk application can use it from command line options. For example, I0 is automatically estimated if the option --i0=0 is used. Don't hesitate to report what is not clear or not working for you. Simon On Thu, Jan 8, 2015 at 4:04 PM, S?bastien Brousmiche < sebastien.brousmiche at uclouvain.be> wrote: > Hi Howard, > > > > Actually there are three values given per projection: I0, a filtered I0 > (RLS) and the FWHM of the background mode. > > You can just use the first value per projection. If ?output? is the buffer > contained in the file (-d) then use I0 = buffer(1:3:end); > > > > Read rtki0estimation.cxx in the application folder for more information. > I?m planning to add more info in the code later. > > > > Best, > > S?bastien > > > > > > *From:* Howard [mailto:lomahu at gmail.com] > *Sent:* jeudi 8 janvier 2015 15:57 > *To:* S?bastien Brousmiche > *Cc:* Simon Rit; rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Hi Sebastien, > > > > Thank you very much for your explanation. I used -d to write I0 > estimations to a file. I found there are >2000 numbers for ~600 > projections. I thought there would be one number for each projection, but > obviously the output numbers are not generated that way. Could you please > describe a bit more on the file format and how to use them? Or simply I > wait for your new mini-pipeline filter? > > > > Regards, > > -howard > > > > On Wed, Jan 7, 2015 at 3:01 AM, S?bastien Brousmiche < > sebastien.brousmiche at uclouvain.be> wrote: > > Hi Howard, > > > > There is an input parameter with the rtki0estimation application (-d) > which allows you to specify the output file with I0 estimates. > > > > The big file you mentioned contains the histograms of each image (65536 > values each) stored consecutively. The first value is the occurrence of > number 0 in your image, second.. 1 and so forth up to 65535. > > > > This application is not particularly interesting to be used in a pipeline. > > > > > Nevertheless, we are developing a mini-pipeline grouping typical > preprocessing filters. It is under validation and I?ll let you know as soon > as it is available for you. > > > > Best, > > S?bastien > > > > > > > > > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Howard > *Sent:* mercredi 7 janvier 2015 00:17 > *To:* Simon Rit > *Cc:* rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Happy New Year, Simon. > > > > Thank you for pointing to me the I0 estimate procedure.I saw an > application rtki0estimation > > under the Applications folder. Is this the tool you meant? I ran it using > all default parameters > > providing with the original projection data. What I obtained was a file: > i0est_histogram.csv. > > From the comments in rtki0estimation.ggo this file is the output with I0 > estimate. For 650 projections > > the file size is around 200MB. I used excel to open the file and found > that the beginning two numbers > > 64408 and 722024 then followed by 0's. In the middle there are some > nonzero numbers. Essentially > > all zeros. > > Since there is not much description of the application, so it is hard to > figure out easily what I am doing. > > I tried to read the source code, but it might be more useful if you can > give some hints on how to > > use it. > > > > Regards, > > -howard > > > > > > On Mon, Jan 5, 2015 at 1:49 AM, Simon Rit > wrote: > > Happy new year Howard, > Normally, this calibration is handled by the flat panel. It uses an > air projection and a dark (no beam) projection to compute the line > integral. However, there might be fluctuations in time of these two > projections. Some people do regular acquisitions of them to capture > the time fluctuations. Otherwise, a constant value might be a good > solution. S?bastien has recently implemented an automated > determination of this constant, maybe you should have a look: > > http://www.openrtk.org/Doxygen/classrtk_1_1I0EstimationProjectionFilter.html > It is already part of the mini-pipeline for ImagX / IBA projections > processing: > > http://www.openrtk.org/Doxygen/classrtk_1_1ImagXRawToAttenuationImageFilter.html > Simon > > > On Fri, Jan 2, 2015 at 10:17 PM, Howard wrote: > > Happy New Year, Cyril. > > > > I realized that our projection data is having some issues with air > > correction. We checked our calibration and it appeared fine. Do you know > by > > any chance whether there is a quick way of correcting that? I searched > > around and found people used a constant air norm image. > > > > Thanks very much, > > -howard > > > > On Thu, Dec 18, 2014 at 5:13 AM, Cyril Mory > > wrote: > >> > >> Hi Howard, > >> > >> I've taken a look at your data. > >> You can apply tv denoising on the out.mha volume and obtain a > >> significantly lower level of noise without blurring structures by using > the > >> following command : > >> rtktotalvariationdenoising -i out.mha -g 0.001 -o > >> tvdenoised/gamma0.001.mha -n 100 > >> > >> I was unable to obtain good results with iterative reconstruction from > the > >> projection data you sent, though. I think the main reason for this is > that > >> your projections have much-higher-than-zero attenuation in air. Your > >> calculation of i0 when converting from intensity to attenuation is > probably > >> not good enough. Try to correct for this effect first. Then you can > start > >> performing SART and Conjugate Gradient reconstructions on your data, and > >> once you get these right, play with ADMM. > >> > >> You might need to remove the table from the projections to be able to > >> restrict the reconstruction volume strictly to the patient, and speed > up the > >> computations. We can provide help for that too. > >> > >> Best regards, > >> Cyril > >> > >> > >> On 12/17/2014 05:02 PM, Howard wrote: > >> > >> Hi Cyril, > >> > >> I've sent you two files via wetransfer.com: one is the sparse > projection > >> set with geometry file and the other is the fdk reconstructed image > based on > >> full projection set. Please let me know if you have trouble receiving > them. > >> > >> Thanks very much for looking into this. > >> > >> -Howard > >> > >> On Wed, Dec 17, 2014 at 10:19 AM, Cyril Mory > >> wrote: > >>> > >>> Hi Howard, > >>> > >>> Thanks for the detailed feedback. > >>> The image getting blurry is typically due to a too high gamma. > Depending > >>> on you data, gamma can have to be set to a very small value (I use > 0.007 in > >>> some reconstructions on clinical data). Can you send over your volume > >>> reconstructed from full projection data, and I'll have a quick look ? > >>> > >>> There is a lot of instinct in the setting of the parameters. With time, > >>> one gets used to finding a correct set of parameters without really > knowing > >>> how. I can also try to reconstruct from your cbct data if you send me > the > >>> projections and the geometry. > >>> > >>> Best regards, > >>> Cyril > >>> > >>> > >>> On 12/17/2014 03:49 PM, Howard wrote: > >>> > >>> Hi Cyril, > >>> > >>> Thanks very much for your detailed and nice description on how to use > the > >>> admmtv reconstruction. I followed your suggestions and re-ran > >>> reconstructions using admmtotalvariation and admmwavelets with cbct > >>> projection data from a thoracic patient. > >>> > >>> I am reporting what I found and hope these will give you information > for > >>> further improvement. > >>> > >>> 1. I repeated admmtotalvariation with 30 iterations. No improvement was > >>> observed. As a matter of fact, the reconstructed image is getting a lot > >>> noiser compared to that using 3 iterations. The contrast is getting > worse as > >>> well. I tried to play around with window & level in case I was fooled > but > >>> apparently more iterations gave worse results. > >>> > >>> 2. Similarly I ran 30 iterations using admmwavelets. Slightly better > >>> reconstruction compared with total variation. > >>> > >>> 3. Then I went ahead to test if TV benefits us anything using the > >>> tvdenoising application on the fdk-reconstructed image reconstructed > from > >>> full projection set. I found that the more iterations, the more blurry > the > >>> image became. For example, with 50 iterations the contrast on the > denoised > >>> image is very low so that the vertebrae and surrounding soft tissue are > >>> hardly distinguishable. Changing gamma's at 0.2, 0.5, 1.0, 10 did not > seem > >>> to make a difference on the image. With 5 iterations the denoising > seems to > >>> work fairly well. Again, changing gamma's didn't make a difference. > >>> I hope I didn't misused the totalvariationdenoising application. The > >>> command I executed was: rtktotalvariationdenoising -i out.mha -o > >>> out_denoising_n50_gamma05 --gamma 0.5 -n 50 > >>> > >>> In summary, tdmmwavelets seems perform better than tdmmtotalvariation > but > >>> neither gave satisfactory results. No sure what we can infer from the > TV > >>> denoising study. I could send my study to you if there is a need. > Please let > >>> me know what tests I could run. Further help on improvement is > definitely > >>> welcome and appreciated. > >>> > >>> -Howard > >>> > >>> On Mon, Dec 15, 2014 at 4:07 AM, Cyril Mory > >>> wrote: > >>>> > >>>> Hello Howard, > >>>> > >>>> Good to hear that you're using RTK :) > >>>> I'll try to answer all your questions, and give you some advice: > >>>> - In general, you can expect some improvement over rtkfdk, but not a > >>>> huge one > >>>> - You can find the calculations in my PhD thesis > >>>> https://tel.archives-ouvertes.fr/tel-00985728 (in English. Only the > >>>> introduction is in French) > >>>> - Adjusting the parameters is, in itself, a research topic (sorry !). > >>>> Alpha controls the amount of regularization and only that (the > higher, the > >>>> more regularization). Beta, theoretically, should only change the > >>>> convergence speed, provided you do an infinite number of iterations > (I know > >>>> it doesn't help, sorry again !). In practice, beta is ubiquitous and > appears > >>>> everywhere in the calculations, therefore it is hard to predict what > effect > >>>> an increase/decrease of beta will give on the images. I would keep it > as is, > >>>> and play on alpha > >>>> - 3 iterations is way too little. I typically used 30 iterations. > Using > >>>> the CUDA forward and back projectors helped a lot maintain the > computation > >>>> time manageable > >>>> - The quality of the results depends a lot on the nature of the image > >>>> you are trying to reconstruct. In a nutshell, the algorithm assumes > that the > >>>> image you are reconstructing has a certain form of regularity, and > discards > >>>> the potential solutions that do not have it. This assumption partly > >>>> compensates for the lack of data. ADMM TV assumes that the image you > are > >>>> reconstructing is piecewise constant, i.e. has large uniform areas > separated > >>>> by sharp borders. If your image is a phantom, it should give good > results. > >>>> If it is a real patient, you should probably change to another > algorithm > >>>> that assumes another form of regularity in the images (try > rtkadmmwavelets) > >>>> - You can find out whether you typical images can benefit from TV > >>>> regularization by reconstructing from all projections with rtkfdk, > then > >>>> applying rtktotalvariationdenoising on the reconstructed volume (try > 50 > >>>> iterations and adjust the gamma parameter: high gamma means high > >>>> regularization). If this denoising implies an unacceptable loss of > quality, > >>>> stay away from TV for these images, and try wavelets > >>>> > >>>> I hope this helps > >>>> > >>>> Looking forward to reading you again, > >>>> Cyril > >>>> > >>>> > >>>> On 12/12/2014 06:42 PM, Howard wrote: > >>>> > >>>> I am testing the ADMM total variation reconstruction with sparse data > >>>> sample. I could reconstruct but the results were not as good as > expected. In > >>>> other words, it didn't show much improvement compared to fdk > reconstruction > >>>> using the same sparse projection data. > >>>> > >>>> The parameters I used in ADMMTV were the following: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --alpha 1 --beta 1000 -n 3 > >>>> > >>>> while the fdk reconstruction parameters are: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --pad 0.1 --hann 0.5 > >>>> > >>>> The dimensions were chosen to include the entire anatomy. 72 > projections > >>>> were selected out of 646 projections for a 360 degree scan for both > >>>> calculations. > >>>> > >>>> What parameters and how can I adjust (like alpha, beta, or > iterations?) > >>>> to improve the ADMMTV reconstruction? There is not much description > of this > >>>> application from the wiki page. > >>>> > >>>> Thanks, > >>>> > >>>> -howard > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Rtk-users mailing list > >>>> Rtk-users at public.kitware.com > >>>> http://public.kitware.com/mailman/listinfo/rtk-users > >>>> > >>>> > >>>> -- > >>>> -- > >>>> Cyril Mory, Post-doc > >>>> CREATIS > >>>> Leon Berard cancer treatment center > >>>> 28 rue La?nnec > >>>> 69373 Lyon cedex 08 FRANCE > >>>> > >>>> Mobile: +33 6 69 46 73 79 > >>> > >>> > >>> -- > >>> -- > >>> Cyril Mory, Post-doc > >>> CREATIS > >>> Leon Berard cancer treatment center > >>> 28 rue La?nnec > >>> 69373 Lyon cedex 08 FRANCE > >>> > >>> Mobile: +33 6 69 46 73 79 > >> > >> > >> -- > >> -- > >> Cyril Mory, Post-doc > >> CREATIS > >> Leon Berard cancer treatment center > >> 28 rue La?nnec > >> 69373 Lyon cedex 08 FRANCE > >> > >> Mobile: +33 6 69 46 73 79 > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > > > > > ------------------------------ > > [image: Image removed by sender.] > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > > > > > > ------------------------------ > > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: not available URL: From Robert.Calliess at gmx.de Tue Feb 24 03:56:15 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 24 Feb 2015 09:56:15 +0100 Subject: [Rtk-users] sart back projection, weighting steps Message-ID: An HTML attachment was scrubbed... URL: From cyril.mory at creatis.insa-lyon.fr Tue Feb 24 04:55:00 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Tue, 24 Feb 2015 10:55:00 +0100 Subject: [Rtk-users] sart back projection, weighting steps In-Reply-To: References: Message-ID: <54EC4A74.2010601@creatis.insa-lyon.fr> Hi Robert, I'm glad to know that most of the explanation text is understandable :) You might want to check this filter: http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html You can use the command line application "rtkbackprojections" with argument --bp to compare "Joseph" and "NormalizedJoseph". When performing a back projection with non-normalized Joseph, the projection values are "splat" (splat is the adjoint operator of interpolation) between the four nearest voxels in each volume plane the ray intersects. Nothing guarantees that every voxel will receive a contribution during this process. How many contributions a voxel receives is determined by the sampling of the projections, which can be much looser or much denser (locally and globally) than what would be required. Dividing by the back projection of an image of ones mitigates this effect. In theory, as long as the forward and back projection operators are the adjoint of one another, it should not be a problem for SART. In practice, it does make a difference. I hope it helps. Please let me know if it is still unclear; Cyril On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward projection, > every pixel is > divided by the intersection length of the ray with the volume. That is > clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This weighting > step is not > performed when using a voxel-based back projection, as the weights > are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all pixels > have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply this > weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate the > pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range from 0 > to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Thu Feb 26 14:35:06 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Thu, 26 Feb 2015 19:35:06 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely,Vahid? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Thu Feb 26 15:18:53 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Thu, 26 Feb 2015 21:18:53 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Message-ID: <00d901d05201$71a49200$54edb600$@gmx.de> Hello Vahid, I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI but with a wider sensor array. I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code. But let?s see what grandmasters of RTK will suggest. Best regards, Robert Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely, Vahid -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Thu Feb 26 16:33:46 2015 From: ghostcz at hotmail.com (louie L) Date: Thu, 26 Feb 2015 22:33:46 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <00d901d05201$71a49200$54edb600$@gmx.de> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work. Best regards, Louie Greetings from my iOS! > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the > resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). > I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around > the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these > seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI > but with a wider sensor array. > > I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it > would be possible to model the helical trajectory by the changing geometry without changing /adding code. > > But let?s see what grandmasters of RTK will suggest. > > Best regards, > Robert > > > Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users > Gesendet: Donnerstag, 26. Februar 2015 20:35 > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK > > Dear RTK users, > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? > I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. > > Sincerely, > Vahid > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From cyril.mory at creatis.insa-lyon.fr Fri Feb 27 03:45:24 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Fri, 27 Feb 2015 09:45:24 +0100 Subject: [Rtk-users] Fwd: Re: Aw: Re: sart back projection, weighting steps In-Reply-To: <54F02E7E.7080000@creatis.insa-lyon.fr> References: <54F02E7E.7080000@creatis.insa-lyon.fr> Message-ID: <54F02EA4.7010006@creatis.insa-lyon.fr> Hi Robert, No problem, glad to help. I think either I have'nt been clear enough, or you're getting confused, though :) Let me try again: In joseph back projection, for each PIXEL, you "draw a line" between the source and the pixel's center, and see which voxels it crosses. Your line crosses each slice of the volume at an intersection point. You determine what the interpolation weights would be if you were to interpolate at this intersection point. And these weights are indeed between 0 and 1. But instead of interpolating, you "splat", that means you update the four nearest voxels by adding (projection's pixel value * interpolationWeight) to each. And you move to the next slice. Once you've considered all rays, you're done. Nothing in this process guarantees that a voxel will receive any contribution. In fact, some receive none, and some too many. The backprojected volume you obtain is "biased". You could think of it as the product of what you really want (the projection's pixel values smeared out along the lines of rays) with a "sampling density map" (the cumulated splat weights each voxel has been updated with). If you back project a projection of ones, then your resulting volume is exactly this sampling density map, and you can divide by it to obtain what you really want. In voxel based back projection, for each voxel, you "draw a line" between the source and the voxel's center, see where it hits the 2D projection, and add the value of that pixel (or interpolated at this position between pixels) into the voxel. And that's it for this voxel, so each voxel gets updated once and only once. And if the projection contains only ones, then your volume gets filled with ones. Dividing by one isn't going to change anything, so you just don't do it. I hope it is clearer. Cyril On 02/26/2015 02:10 PM, "Robert Callie?" wrote: > Hello Cyril, > thank you for the fast reply and thank you for the support. > Indeed I have some more questions. For the normalization step > you on the one hand side create a projection image filled with "1" > and on the other hand side you create an empty (zero) volume and > then back project the image, ok. > >>How many contributions a voxel receives is determined by the > sampling of the projections > Yes, I have the same problems with a voxel-based back projector. But > don't you have > this problem also with joseph's method when you use it for the back > projection of the "1" projection > image ? It's not clear to me how this kind of back projection actually > works (or is calculated). > And if the projection image consists of pixels with value "1" then we > actually don't need it or do we ? > So far I understand, no matter if we perform the forward or back > projtion, the joseph projector calculates > the weightings of the four voxels that are "around" the current plane > intersection point. And this > weights are always between 0 and 1. > Or do I totally misunderstand the concept of this backprojection. > I hope I did not confused you. > best regards, > Robert > *Gesendet:* Dienstag, 24. Februar 2015 um 10:55 Uhr > *Von:* "Cyril Mory" > *An:* "Robert Callie?" , rtk-users at openrtk.org > *Betreff:* Re: [Rtk-users] sart back projection, weighting steps > Hi Robert, > > I'm glad to know that most of the explanation text is understandable :) > You might want to check this filter: > http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html > You can use the command line application "rtkbackprojections" with > argument --bp to compare "Joseph" and "NormalizedJoseph". > > When performing a back projection with non-normalized Joseph, the > projection values are "splat" (splat is the adjoint operator of > interpolation) between the four nearest voxels in each volume plane > the ray intersects. Nothing guarantees that every voxel will receive a > contribution during this process. How many contributions a voxel > receives is determined by the sampling of the projections, which can > be much looser or much denser (locally and globally) than what would > be required. Dividing by the back projection of an image of ones > mitigates this effect. In theory, as long as the forward and back > projection operators are the adjoint of one another, it should not be > a problem for SART. In practice, it does make a difference. > > I hope it helps. Please let me know if it is still unclear; > > Cyril > On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward > projection, every pixel is > divided by the intersection length of the ray with the volume. > That is clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This > weighting step is not > performed when using a voxel-based back projection, as the > weights are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all > pixels have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply > this weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate > the pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range > from 0 to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually > happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 27 04:42:38 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 27 Feb 2015 10:42:38 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry . I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: > Hi, > > You can change the geometry. If changed correctly, most, if not all, the > iterative cone beam reconstruction will work. > > Best regards, > Louie > > Greetings from my iOS! > > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > > I think you need to add a new reconstruction filter for it. For the first > projection the object usually is placed so that the > > resulting projection image covers the upper half of the detector. And you > will need some additional handling (z-increment). > > I guess you could do a little work around with the current rtk. If you > only reconstruct an rectangular roi around > > the detector?s center where the perspective distortion (because of the > cone) is minimal. And then you add these > > seperate volumes to a final volume. This is just an idea. I do not know > how the result will look like. Think of it like a TDI > > but with a wider sensor array. > > > > I do not know the code in detail, but if it were possible to have seperate > geometry settings for every projection image it > > would be possible to model the helical trajectory by the changing geometry > without changing /adding code. > > > > But let?s see what grandmasters of RTK will suggest. > > > > Best regards, > > Robert > > > > > > *Von:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *Im Auftrag von *vahid ettehadi > via Rtk-users > *Gesendet:* Donnerstag, 26. Februar 2015 20:35 > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] Helical cone-beam reconstruction with RTK > > > > Dear RTK users, > > > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT > in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > > I would like to change the current source trajectory from circular to > helical. I was wondering is it possible to use the RTK for helical > reconstruction only with some simple modification? > > I don't know well about reconstruction process and I don't know which type > of modification is necessary to use RTK for a helical cone beam geometry. > So, any suggestion and recommendation would be appreciated. > > > > Sincerely, > > Vahid > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Fri Feb 27 14:24:14 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Fri, 27 Feb 2015 19:24:14 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: Message-ID: <47007992.1342548.1425065054134.JavaMail.yahoo@mail.yahoo.com> Hello,Thank you Robert, Louie and Simon, for your tips and recommendations. I will work on it and I will share the result or potential problems. I found the RTK more accurate and easy to use in compare with other open-source reconstruction tools such as Oscar and NiftyRec.? Thank you RTK team!Vahid On Friday, February 27, 2015 4:42 AM, Simon Rit wrote: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry. I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work.? Best regards,Louie Greetings from my iOS! On 26 Feb 2015, at 21:19, Robert Callie? wrote: Hello Vahid,I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that theresulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment).I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi aroundthe detector?s center where the perspective distortion (because of the cone) is minimal. And then you add theseseperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDIbut with a wider sensor array.?I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code.?But let?s see what grandmasters of RTK will suggest.?Best regards,Robert??????????????? ?Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK?Dear RTK users,??I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated.?Sincerely,Vahid?? _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Sun Feb 1 04:41:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 1 Feb 2015 10:41:03 +0100 Subject: [Rtk-users] RTK In-Reply-To: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> References: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> Message-ID: On Fri, Jan 30, 2015 at 10:19 AM, Robert Callie? wrote: > Hello Simon, > > thank you for the fast reply. > > > > ?Joseph's method samples the ray with one pixel per slice in the main > direction but it does not compute the intersection of the ray with each > voxel. Siddon's method does that. In fig 2 of [Xu and Mueller, 2006], Joseph > is referred to "slice interpolated" and Siddon to "box-line-integrated". > OK, thanks for that hint. I think it will maybe also has the same problem > with divergent rays and missing voxels during the reconstruction. Do you For sure. > have a link to a paper or source to this algorithm. So the algorithm may > work > > As following: > > - calculate intersection with the physical bounding volume (entry > exit points) > > - from entrypoint, determine the 4 voxels that surround this > entrypoint and bilinear interpolate the value at this position and sum it up > > - go to next plane (plane that is most ?perpendicular? to the > current center ray (focus to detector center) ? > > - at the end, the sum is normalized by the ray length ? > (length(exitpoint ? entrypoint)) > > Is that right ? Almost. Maybe I misunderstand your last step but it is actually multiplied by each step length. Normalization occurs during backprojection, not during forward projection. > > > > How can Joseph?s method be used for back projection ? If you write the method as a system matrix, simply take the transpose of it. For (S)ART, you will want to divide by the sum of the weights along one ray which is exactly what you mentionned, the ray length. > > > > ?This sounds very interesting, don't hesitate to share the code and/or the > publication! BTW, what is DDA? > > DDA stands for digital differential analyzer. I use this approach for a > voxel-based forward projector. When I started my project I was looking for a > fast and easy forward projector on voxel basis. > > I found an article about raytracing and acceleration structures where these > people used this 3d dda. They actually needed it to traverse the bounding > hierarchy to get to know what geometry > > the ray intersects with. I slightly modified it to get the intersecetion > length of a ray within a voxel by substraction of the current and previous > step width. I?v attached a zip file that contains this > > modification and the original source code. The original source code is from > www.scratchapixel.com and there is also an article about this topic > (http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-12-introduction-to-acceleration-structures/what-else/). Great, thanks. We'll have a look. Do you distribute this under a specific license? In other words, is there a risk that it would conflict with RTK license? (Apache 2, see website). > > If you have a look at my code you?ll maybe miss some matrix calculation > stuff etc. I use a scene based approach where I place the focus, object and > detector in a so called record. Each record represents the scene geometry at > a certain time, when a projection image was taken. > > Before reconstruction starts I calculate all these positions. I thought this > could be a good approach to decouple the actuall reconstruction algorithm > from the scene geometry. We'll let you know when we look at it if we have questions. > > > > > > ?But generally we use matching resolution between pixels and voxels so the > problem is minimal.? > > Do you mean, that you use a volume resolution that fits to the current > geometry setting and the detector?s pixel resolution ? Yes. > > > > ?Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > Not almost the same. What I mean seems to be simplier. Lets assume the > detector has tilted around the x-axis by 0.25 degrees. The object?s center > is at 0,0,0 and rotation axis is 0,1,0. In FDK you usually got a ray from > source to the voxel center and then you calculate > > the intersection of this ray at the detector plane. To avoid ray plane > intersection calculus, we can rotate the whole system by 0.25 degrees. Means > that the detectors normal now is parallel to the z axis.Of course the > rotation axis is not 0,1,0 any longer and the focus (xray source) > > also is a bit rotated. > > > > ?For the backprojection, we typically used voxel-based backprojection using > the center of the voxel which is faster than what you (seem to) use? > > I think here we mixed something up. This type of back projection is used for > FDK. All my questions were related to S-ART. I need to calculate the weights > > of a voxel for the back projection. To speed it up, I project its vertices > on the detector plane, calc the MEB and the send rays from within this MEB > through the > > voxel and caluclate the intersection length so those rays that will make my > weights. Some people argue that you can use the same backprojection as in FDK to speed up computations. See for example http://www.researchgate.net/profile/Gengsheng_Zeng/publication/12301525_Unmatched_projectorbackprojector_pairs_in_an_iterative_reconstruction_algorithm/links/00b495252b15fc4bb9000000.pdf > > > > > > Best regards, > > Robert > > > > > > P.S. Hello to all the other people here in the mailing list. > > > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Donnerstag, 29. Januar 2015 20:58 > An: Robert Callie? > Cc: rtk-users at openrtk.org > Betreff: Re: RTK > > > > Hi, > Thank you for your interest in RTK. Please use the mailing list for > questions that are of interest to anyone using RTK. > > There are many ways to model the direct problem (forward projection). > Without going into too many details (available in the publications of each > method) : > - "As far as I understand the goal of this approach is to calculate the > intersection length of a ray through a voxel, right ?" False. Joseph's > method samples the ray with one pixel per slice in the main direction but it > does not compute the intersection of the ray with each voxel. Siddon's > method does that. In fig 2 of [Xu and Mueller, 2006], Joseph is referred to > "slice interpolated" and Siddon to "box-line-integrated". > - "I can calculate the intersection length of the ray within a voxel by a > simple substraction, this runs very fast." This sounds very interesting, > don't hesitate to share the code and/or the publication! BTW, what is DDA? > > - Small voxels / pixels, "Did you find a way to handle this ? " We don't > handle this in RTK except if you consider that spatial regularisation (e.g., > total variation) will overcome this problem in a way. But generally we use > matching resolution between pixels and voxels so the problem is minimal. For > the backprojection, we typically used voxel-based backprojection using the > center of the voxel which is faster than what you (seem to) use. I think > that if these things are a problem for you, there is a nice solution called > distance driven (back-)projection (by De Man and Basu). I think it will do > exactly what you want. I haven't implemented it in RTK (yet). > > Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > I hope this helps. Let me know if sg is not clear in my answer! > Cheers, > Simon From riblettmj at mymail.vcu.edu Mon Feb 2 12:03:14 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 12:03:14 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF Message-ID: Hello RTK Users, I?m just getting started using RTK as part of my graduate research and was hoping that someone might be able to help me sort out an issue I?ve been having reconstructing a 3D CBCT image dataset while applying a 4D deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF has been generated by transformix (.mhd format). I followed, for the most part, the MCCBCTReconstruction example on the RTK Wiki. While reconstructing, rtkfdk reads in all of the projections to memory, begins the ?Reconstructing and Writing? phase and proceeds for a few seconds before hanging ? it doesn?t exit or fault, just drops to 0% CPU while retaining the projections in memory. By writing some basic debug messages into the source code, I?ve been able to determine that the issue lies somewhere at m_Deformation->Update() [Line 99 of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 makes it past the m_Deformation->SetFrame(iProj) line, but never makes it past the subsequent update. I?m wondering if this has anything to do with the size of the DVF generated by transformix: approximately 4.0GB (512x100x512x10 image, 4-channels, FLOAT). Just to provide a little more background information, I?m running RTK on a 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of memory running Ubuntu 14.04. RTK was built using the default ?Release? make configuration and linked to ITK 4.5.2. Elastix and Transformix are both the latest version, 4.7. Has anyone else run into a similar issue with reconstructing a similar image, or does anyone have any thoughts as to how to resolve this sort of issue? Thanks in advance! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 2 12:19:53 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 2 Feb 2015 18:19:53 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: Hi, You're the first RTK user I know to use it on Sun! Nice! If you've got 64 GB ram, that should be enough... although you could ask elastix to generate a smaller DVF, RTK linearly interpolates between vectors. You could even use B-spline coeffs directly but you'd have to create a new DVF. My guess is that there is a problem with the initialization of m_Deformation since the line you mention is the first time it's ever used in the class. Do you use the rtkfdk app? I would start by checking that the pointer is not null before this line, sg like: std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; If it equals 0, then there is something going with the deformation. You can check it in the main app, rtkfdk.cxx. Simon On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett wrote: > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From riblettmj at mymail.vcu.edu Mon Feb 2 13:44:54 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 13:44:54 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Simon, I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the added debug line you suggested and it doesn?t look like the pointer is null. Running it through gdb, I got the following info: m_Deformation=0x16ff820 (gdb) x 0x16ff820 0x16ff820: 0x011c51d0 (gdb) x 0x011c51d0 0x11c51d0 <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: 0x005fb874 (gdb) x 0x005fb874 0x5fb874 , 3u> >::CreateAnother() const>: 0xe5894855 (gdb) x 0xe5894855 0xe5894855: Cannot access memory at address 0xe5894855 I?m still waiting on the transformix DVF, but I?ll give that a try too when its done. Thanks again! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go ahead and check to see if the pointer is null and let you know. My current check is having transformix to generate a smaller DVF to see if that helps, so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > >> On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> > wrote: >>> Hello RTK Users, >>> >>> I?m just getting started using RTK as part of my graduate research and was >>> hoping that someone might be able to help me sort out an issue I?ve been >>> having reconstructing a 3D CBCT image dataset while applying a 4D >>> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >>> has been generated by transformix (.mhd format). I followed, for the most >>> part, the MCCBCTReconstruction example on the RTK Wiki. >>> >>> While reconstructing, rtkfdk reads in all of the projections to memory, >>> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >>> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >>> retaining the projections in memory. >>> >>> By writing some basic debug messages into the source code, I?ve been able to >>> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >>> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >>> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >>> past the subsequent update. I?m wondering if this has anything to do with >>> the size of the DVF generated by transformix: approximately 4.0GB >>> (512x100x512x10 image, 4-channels, FLOAT). >>> >>> Just to provide a little more background information, I?m running RTK on a >>> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >>> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >>> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >>> latest version, 4.7. >>> >>> Has anyone else run into a similar issue with reconstructing a similar >>> image, or does anyone have any thoughts as to how to resolve this sort of >>> issue? >>> >>> Thanks in advance! >>> >>> ? Matt >>> >>> __ >>> Matthew J. Riblett >>> Virginia Commonwealth University >>> Department of Radiation Oncology >>> Medical Physics Graduate Program >>> >>> Office: Sanger Hall, Room B1-013 >>> 401 College Street | P.O. Box 980058 >>> Richmond, Virginia 23298 >>> >>> VCU Email: riblettmj at vcu.edu >>> MCV Office Phone: +1.804.628.4858 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Feb 3 02:22:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Feb 2015 08:22:54 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: That's weird because SetFrame does nothing else than change the value of the member Frame. Are you sure it's on SetFrame that the crash occurs? On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett wrote: > Simon, > > I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the > added debug line you suggested and it doesn?t look like the pointer is null. > Running it through gdb, I got the following info: > > m_Deformation=0x16ff820 > > (gdb) x 0x16ff820 > 0x16ff820: 0x011c51d0 > (gdb) x 0x011c51d0 > 0x11c51d0 > <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: > 0x005fb874 > (gdb) x 0x005fb874 > 0x5fb874 3u>, 3u> >::CreateAnother() const>: 0xe5894855 > (gdb) x 0xe5894855 > 0xe5894855: Cannot access memory at address 0xe5894855 > > I?m still waiting on the transformix DVF, but I?ll give that a try too when > its done. > > Thanks again! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett > wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go > ahead and check to see if the pointer is null and let you know. My current > check is having transformix to generate a smaller DVF to see if that helps, > so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby > supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: > > Hi, > You're the first RTK user I know to use it on Sun! Nice! > If you've got 64 GB ram, that should be enough... although you could > ask elastix to generate a smaller DVF, RTK linearly interpolates > between vectors. You could even use B-spline coeffs directly but you'd > have to create a new DVF. > My guess is that there is a problem with the initialization of > m_Deformation since the line you mention is the first time it's ever > used in the class. Do you use the rtkfdk app? I would start by > checking that the pointer is not null before this line, sg like: > std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; > If it equals 0, then there is something going with the deformation. > You can check it in the main app, rtkfdk.cxx. > Simon > > On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett > wrote: > > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From riblettmj at mymail.vcu.edu Tue Feb 3 10:36:03 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Tue, 3 Feb 2015 10:36:03 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: <60DCF1BD-5960-4A62-AC13-42897049FDFF@mymail.vcu.edu> Simon, I think that it makes it past SetFrame and crashes on Update. Just to be sure, I put a debug message after SetFrame and it does make it to that point, so its got to be on the Update line. ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 3, 2015, at 2:22 AM, Simon Rit wrote: > > That's weird because SetFrame does nothing else than change the value > of the member Frame. Are you sure it's on SetFrame that the crash > occurs? > > On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett > wrote: >> Simon, >> >> I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the >> added debug line you suggested and it doesn?t look like the pointer is null. >> Running it through gdb, I got the following info: >> >> m_Deformation=0x16ff820 >> >> (gdb) x 0x16ff820 >> 0x16ff820: 0x011c51d0 >> (gdb) x 0x011c51d0 >> 0x11c51d0 >> <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: >> 0x005fb874 >> (gdb) x 0x005fb874 >> 0x5fb874 > 3u>, 3u> >::CreateAnother() const>: 0xe5894855 >> (gdb) x 0xe5894855 >> 0xe5894855: Cannot access memory at address 0xe5894855 >> >> I?m still waiting on the transformix DVF, but I?ll give that a try too when >> its done. >> >> Thanks again! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett >> wrote: >> >> Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go >> ahead and check to see if the pointer is null and let you know. My current >> check is having transformix to generate a smaller DVF to see if that helps, >> so the server is getting that done as we speak. >> >> You might also like to know that I?ve got RTK running on a Cray CX-1 (baby >> supercomputer) sitting next to the aforementioned Sun x4600-M2. :) >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 12:19 PM, Simon Rit >> wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> wrote: >> >> Hello RTK Users, >> >> I?m just getting started using RTK as part of my graduate research and was >> hoping that someone might be able to help me sort out an issue I?ve been >> having reconstructing a 3D CBCT image dataset while applying a 4D >> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >> has been generated by transformix (.mhd format). I followed, for the most >> part, the MCCBCTReconstruction example on the RTK Wiki. >> >> While reconstructing, rtkfdk reads in all of the projections to memory, >> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >> retaining the projections in memory. >> >> By writing some basic debug messages into the source code, I?ve been able to >> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >> past the subsequent update. I?m wondering if this has anything to do with >> the size of the DVF generated by transformix: approximately 4.0GB >> (512x100x512x10 image, 4-channels, FLOAT). >> >> Just to provide a little more background information, I?m running RTK on a >> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >> latest version, 4.7. >> >> Has anyone else run into a similar issue with reconstructing a similar >> image, or does anyone have any thoughts as to how to resolve this sort of >> issue? >> >> Thanks in advance! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Thu Feb 5 06:44:47 2015 From: wuchao04 at gmail.com (Chao Wu) Date: Thu, 5 Feb 2015 12:44:47 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Hi Simon, There is still an issue with gengetopt. The config file cannot be read. The problem seems to be at around line 62 in rtkMacro.h: char *configFile = args_info.config_arg; points configFile to the address storing the config file name, but next cmdline_parser_##ggo_filename##_free(&args_info); frees all string field of args_info, including args_info.config_arg, therefore the content pointed by configFile becomes invalid. Regards, Chao 2014-12-12 14:10 GMT+01:00 Simon Rit : > My fix did not work. Cyril (Mory) reported that multiple options were read > twice. I hope this new fix will work but don't hesitate to report other > issues with gengetopt. > Thanks again for you reports, > Simon > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > wrote: >> >> That makes sense, thanks for the quick usage explanation, and fix. >> (Disabling the override issue makes sense, and I didn't have time to trace >> through gengetopt. I thought I was missing something, as none of the >> non-flag arguments were being reset (to null, or default values, and thus >> thought 'override' meant something else!). >> >> Thanks again, glad the info was helpful. >> >> Steve >> >> >> On 14-12-10 4:01 AM, Simon Rit wrote: >> >> Hi, >> Thanks for the report, very useful information. I could reproduce the bug >> and I hope that I have fixed it. Briefly: >> - I have changed the code because Ben Champion reported memory leaks and I >> noticed that they occured in deprecated functions of gengetopt that I don't >> use anymore, >> - the way the new macro (as well as the previous one) is written is: first >> read the command line to find if a config file is passed, then read the >> config file and finally read the command line again to check that everything >> has been passed. >> - your fix was not perfect because we would not have checked that the >> required options were set, >> - it turns out that disabling the override option did the job. >> Everything sworks fine now but let met know if you notice something wrong >> again. Thanks again, >> Simon >> >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann >> wrote: >>> >>> A recent update to rtkMacro.h seems to have caused the ggo command line >>> processor to ignore command line flags. (i.e. I can't get any verbose output >>> with '-v'). >>> It seems to happen after making a second call to: >>> >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, &args_params) >>> >>> Removing this second call, has resolved the issue for me. >>> I'm not sure, however, what the intended use of the second call was for >>> (it occurs immediately after: >>> >>> args_params.check_required = 1; >>> >>> which I feel could just be moved above the first call, as it happens >>> regardless, but I may be missing something. >>> >>> I've attached my quickly modified rtkMacro.h for comparison to the latest >>> github commit. >>> >>> Anyhow, hopefully this info is useful, and doesn't only affect me. >>> >>> Steve >>> >>> Our system setup: >>> -Ubuntu 14.04 x64 >>> -gcc 4.8.2 >>> -cuda 6.5 >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 5 09:17:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 5 Feb 2015 15:17:34 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Indeed, it looks as if I had not tested it, I thought I had... This patch should fix it. Thanks for the report! Simon On Thu, Feb 5, 2015 at 12:44 PM, Chao Wu wrote: > Hi Simon, > > There is still an issue with gengetopt. The config file cannot be read. > The problem seems to be at around line 62 in rtkMacro.h: > char *configFile = args_info.config_arg; points configFile to the > address storing the config file name, but next > cmdline_parser_##ggo_filename##_free(&args_info); frees all string > field of args_info, including args_info.config_arg, therefore the > content pointed by configFile becomes invalid. > > Regards, > Chao > > 2014-12-12 14:10 GMT+01:00 Simon Rit : > > My fix did not work. Cyril (Mory) reported that multiple options were > read > > twice. I hope this new fix will work but don't hesitate to report other > > issues with gengetopt. > > Thanks again for you reports, > > Simon > > > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > > wrote: > >> > >> That makes sense, thanks for the quick usage explanation, and fix. > >> (Disabling the override issue makes sense, and I didn't have time to > trace > >> through gengetopt. I thought I was missing something, as none of the > >> non-flag arguments were being reset (to null, or default values, and > thus > >> thought 'override' meant something else!). > >> > >> Thanks again, glad the info was helpful. > >> > >> Steve > >> > >> > >> On 14-12-10 4:01 AM, Simon Rit wrote: > >> > >> Hi, > >> Thanks for the report, very useful information. I could reproduce the > bug > >> and I hope that I have fixed it. Briefly: > >> - I have changed the code because Ben Champion reported memory leaks > and I > >> noticed that they occured in deprecated functions of gengetopt that I > don't > >> use anymore, > >> - the way the new macro (as well as the previous one) is written is: > first > >> read the command line to find if a config file is passed, then read the > >> config file and finally read the command line again to check that > everything > >> has been passed. > >> - your fix was not perfect because we would not have checked that the > >> required options were set, > >> - it turns out that disabling the override option did the job. > >> Everything sworks fine now but let met know if you notice something > wrong > >> again. Thanks again, > >> Simon > >> > >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann > >> wrote: > >>> > >>> A recent update to rtkMacro.h seems to have caused the ggo command line > >>> processor to ignore command line flags. (i.e. I can't get any verbose > output > >>> with '-v'). > >>> It seems to happen after making a second call to: > >>> > >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, > &args_params) > >>> > >>> Removing this second call, has resolved the issue for me. > >>> I'm not sure, however, what the intended use of the second call was for > >>> (it occurs immediately after: > >>> > >>> args_params.check_required = 1; > >>> > >>> which I feel could just be moved above the first call, as it happens > >>> regardless, but I may be missing something. > >>> > >>> I've attached my quickly modified rtkMacro.h for comparison to the > latest > >>> github commit. > >>> > >>> Anyhow, hopefully this info is useful, and doesn't only affect me. > >>> > >>> Steve > >>> > >>> Our system setup: > >>> -Ubuntu 14.04 x64 > >>> -gcc 4.8.2 > >>> -cuda 6.5 > >>> > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> > >> > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Fri Feb 6 12:27:13 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Fri, 6 Feb 2015 18:27:13 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont -------------- next part -------------- A non-text attachment was scrubbed... Name: figure1.png Type: image/png Size: 28287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: figure2.png Type: image/png Size: 80102 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SheppLogan.txt URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 9 09:08:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Feb 2015 15:08:12 +0100 Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT wrote: > Hello rtk users, > > I try to use RTK for reconstruction in my lab but I encounter some > problems. > > I try to reconstruct a simulated spheroid. I join my phantom text file > (SheppLogan.txt). > > If I set source_y=0, I get a correct (I guess) reconstruction, see the > joined figure1.png. I use the followind set of commands : > > rtksimulatedgeometry -n 180 --sdd=508.1658133423730 > --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 > --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && > rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha > --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p > /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml > --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" > > But If I set source_y=15, I obtain some strange artefacts as you can see > on figure2.png. Do you know the origin of this pattern (the vertical one) ? > Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this > artefact doesn't exist. > > Thanks in advance and thanks for this nice toolkit. > > regards, > Mathieu Dupont > > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Thu Feb 12 04:25:12 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Thu, 12 Feb 2015 10:25:12 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <681578867.13033470.1423733112438.JavaMail.zimbra@cppm.in2p3.fr> Hi Simon, you are right, it works now. Thanks for your reactivity. ----- Mail original ----- De: "Simon Rit" ?: "Mathieu DUPONT" Cc: rtk-users at public.kitware.com Envoy?: Lundi 9 F?vrier 2015 15:08:12 Objet: Re: [Rtk-users] fdk artefact, sourceOffsetY Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT < mdupont at cppm.in2p3.fr > wrote: Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From lomahu at gmail.com Thu Feb 12 10:04:45 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 10:04:45 -0500 Subject: [Rtk-users] building CUDA Message-ID: HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 10:50:08 2015 From: theday79 at gmail.com (Yang K Park) Date: Thu, 12 Feb 2015 10:50:08 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <000801d046db$94f3eb60$bedbc220$@gmail.com> Hi Howard, Attached is my Cmake capture image for RTK using CUDA6.5. (I?m using the default option of RTK w/o any manual modification). Also, I?m using VS2013 / win7 64. I found your second option ?CUDA_ATTACH_VS_BUILD_RULE_TO_C ? is different from mine (CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE). And why don?t you use the newest version of CUDA (v6.5)? It may work fine regardless of the model of your NVIDIA graphic card (I?ve tested it for multiple computers w/ different graphic card models). CUDA6.5 is convenient to install since a single installation file will be enough which is including the graphic driver, CUDA toolkit, SDK, etc. (not sure this is same as 5.5). Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Howard Sent: Thursday, February 12, 2015 10:05 AM To: rtk-users at openrtk.org Subject: [Rtk-users] building CUDA HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Cuda_RTK_Cmake.PNG Type: image/png Size: 43604 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:16:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:16:17 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: Hi, Cmake automatically checks if you have a cuda compatible GPU. If it cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile applications. So there must be an issue with your graphic card. Check if you can compile and run has_cuda_gpu.c. Simon On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > HI, > > I encountered a problem when building CUDA applications. CUDA 5.5 was > installed on our system. I set the following in ccmake > > CUDA_64_BIT_DEVICE_CODE ON > CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > RTK_USE_CUDA ON > > I could build but no cuda applications were generated. In the bin folder I > saw libITKCudaCommon.a and librtkcuda.a. > > What did I miss? Anybody could shed light on this? Thanks, > > -howard > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From julien.jomier at kitware.com Thu Feb 12 11:23:10 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Thu, 12 Feb 2015 17:23:10 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <54DCD36E.5080903@kitware.com> To follow up, what do you mean by "no cuda applications were generated"? If you have the libraries compiled that means CMake found a working CUDA compatible device. -Julien On 12/02/2015 17:16, Simon Rit wrote: > Hi, > Cmake automatically checks if you have a cuda compatible GPU. If it > cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > applications. So there must be an issue with your graphic card. Check > if you can compile and run has_cuda_gpu.c. > Simon > > On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> HI, >> >> I encountered a problem when building CUDA applications. CUDA 5.5 was >> installed on our system. I set the following in ccmake >> >> CUDA_64_BIT_DEVICE_CODE ON >> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> RTK_USE_CUDA ON >> >> I could build but no cuda applications were generated. In the bin folder I >> saw libITKCudaCommon.a and librtkcuda.a. >> >> What did I miss? Anybody could shed light on this? Thanks, >> >> -howard >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:27:09 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:27:09 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: <54DCD36E.5080903@kitware.com> References: <54DCD36E.5080903@kitware.com> Message-ID: Actually no, librtkcuda is compiled if the cuda library is available but the applications are compiled if the cuda library AND a cuda compatible device are available... That's probably why you observe this. Simon On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier wrote: > To follow up, what do you mean by "no cuda applications were generated"? If > you have the libraries compiled that means CMake found a working CUDA > compatible device. > > -Julien > > > On 12/02/2015 17:16, Simon Rit wrote: >> >> Hi, >> Cmake automatically checks if you have a cuda compatible GPU. If it >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> applications. So there must be an issue with your graphic card. Check >> if you can compile and run has_cuda_gpu.c. >> Simon >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >>> >>> HI, >>> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >>> installed on our system. I set the following in ccmake >>> >>> CUDA_64_BIT_DEVICE_CODE ON >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >>> RTK_USE_CUDA ON >>> >>> I could build but no cuda applications were generated. In the bin folder >>> I >>> saw libITKCudaCommon.a and librtkcuda.a. >>> >>> What did I miss? Anybody could shed light on this? Thanks, >>> >>> -howard >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > From lomahu at gmail.com Thu Feb 12 12:24:12 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 12:24:12 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: Thanks all for your responses to my question. I did not initially set CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: [ 24%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt for reading. [ 25%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt for reading. As I said in my original post, we have CUDA installed on the system (cluster system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the cards would work well although I haven't confirmed that. -howard On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit wrote: > Actually no, librtkcuda is compiled if the cuda library is available > but the applications are compiled if the cuda library AND a cuda > compatible device are available... That's probably why you observe > this. > Simon > > On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > wrote: > > To follow up, what do you mean by "no cuda applications were generated"? > If > > you have the libraries compiled that means CMake found a working CUDA > > compatible device. > > > > -Julien > > > > > > On 12/02/2015 17:16, Simon Rit wrote: > >> > >> Hi, > >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> applications. So there must be an issue with your graphic card. Check > >> if you can compile and run has_cuda_gpu.c. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >>> > >>> HI, > >>> > >>> I encountered a problem when building CUDA applications. CUDA 5.5 was > >>> installed on our system. I set the following in ccmake > >>> > >>> CUDA_64_BIT_DEVICE_CODE ON > >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >>> RTK_USE_CUDA ON > >>> > >>> I could build but no cuda applications were generated. In the bin > folder > >>> I > >>> saw libITKCudaCommon.a and librtkcuda.a. > >>> > >>> What did I miss? Anybody could shed light on this? Thanks, > >>> > >>> -howard > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> _______________________________________________ > >> Rtk-users mailing list > >> Rtk-users at public.kitware.com > >> http://public.kitware.com/mailman/listinfo/rtk-users > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 12:42:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 18:42:15 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: That's more complicated. First, CUDA_HAVE_GPU is normally turned on automatically but maybe it's been turned off due to the problem you're encountering now. The problem you have is probably not specific to RTK, we don't develop FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an option CUDA_BUILD_CUBIN, maybe turn it off? If I were you, I'd try to create a small separate project with has_cuda_gpu.c and check whether it compiles. If it doesn't, try the cmake mailing list. Simon On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > Thanks all for your responses to my question. I did not initially set > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > [ 24%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > for reading. > > > [ 25%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > for reading. > > As I said in my original post, we have CUDA installed on the system (cluster > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > cards would work well although I haven't confirmed that. > > -howard > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit > wrote: >> >> Actually no, librtkcuda is compiled if the cuda library is available >> but the applications are compiled if the cuda library AND a cuda >> compatible device are available... That's probably why you observe >> this. >> Simon >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> wrote: >> > To follow up, what do you mean by "no cuda applications were generated"? >> > If >> > you have the libraries compiled that means CMake found a working CUDA >> > compatible device. >> > >> > -Julien >> > >> > >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> Hi, >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> applications. So there must be an issue with your graphic card. Check >> >> if you can compile and run has_cuda_gpu.c. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >>> >> >>> HI, >> >>> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >> >>> installed on our system. I set the following in ccmake >> >>> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >>> RTK_USE_CUDA ON >> >>> >> >>> I could build but no cuda applications were generated. In the bin >> >>> folder >> >>> I >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >>> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >>> >> >>> -howard >> >>> >> >>> _______________________________________________ >> >>> Rtk-users mailing list >> >>> Rtk-users at public.kitware.com >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >>> >> >> _______________________________________________ >> >> Rtk-users mailing list >> >> Rtk-users at public.kitware.com >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > > > From lomahu at gmail.com Thu Feb 12 13:37:39 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 13:37:39 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: When I did the following: CUDA_HAVE_GPU ON CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) building was successful. I could run rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk using cuda?) with successful reconstruction. It's done in < 15s, wow! A separate question: how to specify cuda for rtksart, rtkadmmwavelets, rtkadmmtotalvariations etc? Thanks, -howard On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit wrote: > That's more complicated. First, CUDA_HAVE_GPU is normally turned on > automatically but maybe it's been turned off due to the problem you're > encountering now. > The problem you have is probably not specific to RTK, we don't develop > FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an > option CUDA_BUILD_CUBIN, maybe turn it off? > If I were you, I'd try to create a small separate project with > has_cuda_gpu.c and check whether it compiles. If it doesn't, try the > cmake mailing list. > Simon > > On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > > Thanks all for your responses to my question. I did not initially set > > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > > > > [ 24%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > > for reading. > > > > > > [ 25%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > > for reading. > > > > As I said in my original post, we have CUDA installed on the system > (cluster > > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > > cards would work well although I haven't confirmed that. > > > > -howard > > > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > wrote: > >> > >> Actually no, librtkcuda is compiled if the cuda library is available > >> but the applications are compiled if the cuda library AND a cuda > >> compatible device are available... That's probably why you observe > >> this. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > >> wrote: > >> > To follow up, what do you mean by "no cuda applications were > generated"? > >> > If > >> > you have the libraries compiled that means CMake found a working CUDA > >> > compatible device. > >> > > >> > -Julien > >> > > >> > > >> > On 12/02/2015 17:16, Simon Rit wrote: > >> >> > >> >> Hi, > >> >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> >> applications. So there must be an issue with your graphic card. Check > >> >> if you can compile and run has_cuda_gpu.c. > >> >> Simon > >> >> > >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >> >>> > >> >>> HI, > >> >>> > >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 > was > >> >>> installed on our system. I set the following in ccmake > >> >>> > >> >>> CUDA_64_BIT_DEVICE_CODE ON > >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >> >>> RTK_USE_CUDA ON > >> >>> > >> >>> I could build but no cuda applications were generated. In the bin > >> >>> folder > >> >>> I > >> >>> saw libITKCudaCommon.a and librtkcuda.a. > >> >>> > >> >>> What did I miss? Anybody could shed light on this? Thanks, > >> >>> > >> >>> -howard > >> >>> > >> >>> _______________________________________________ > >> >>> Rtk-users mailing list > >> >>> Rtk-users at public.kitware.com > >> >>> http://public.kitware.com/mailman/listinfo/rtk-users > >> >>> > >> >> _______________________________________________ > >> >> Rtk-users mailing list > >> >> Rtk-users at public.kitware.com > >> >> http://public.kitware.com/mailman/listinfo/rtk-users > >> >> > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 13:47:54 2015 From: theday79 at gmail.com (Yang-Kyun Park) Date: Thu, 12 Feb 2015 13:47:54 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: hi howard, use following options for fwd and bkward projection --fp CudaRayCast --bp CudaVoxelBased Yang On Feb 12, 2015 1:37 PM, "Howard" wrote: > When I did the following: > > CUDA_HAVE_GPU ON > CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) > CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) > > building was successful. I could run > > rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk > using cuda?) > > with successful reconstruction. It's done in < 15s, wow! > > A separate question: how to specify cuda for rtksart, > rtkadmmwavelets, rtkadmmtotalvariations etc? > > Thanks, > -howard > > > > > > > > > > > On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> wrote: > >> That's more complicated. First, CUDA_HAVE_GPU is normally turned on >> automatically but maybe it's been turned off due to the problem you're >> encountering now. >> The problem you have is probably not specific to RTK, we don't develop >> FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an >> option CUDA_BUILD_CUBIN, maybe turn it off? >> If I were you, I'd try to create a small separate project with >> has_cuda_gpu.c and check whether it compiles. If it doesn't, try the >> cmake mailing list. >> Simon >> >> On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: >> > Thanks all for your responses to my question. I did not initially set >> > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: >> > >> > >> > [ 24%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > >> > [ 25%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > As I said in my original post, we have CUDA installed on the system >> (cluster >> > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are >> > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume >> the >> > cards would work well although I haven't confirmed that. >> > >> > -howard >> > >> > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> > wrote: >> >> >> >> Actually no, librtkcuda is compiled if the cuda library is available >> >> but the applications are compiled if the cuda library AND a cuda >> >> compatible device are available... That's probably why you observe >> >> this. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> >> wrote: >> >> > To follow up, what do you mean by "no cuda applications were >> generated"? >> >> > If >> >> > you have the libraries compiled that means CMake found a working CUDA >> >> > compatible device. >> >> > >> >> > -Julien >> >> > >> >> > >> >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> >> >> Hi, >> >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> >> applications. So there must be an issue with your graphic card. >> Check >> >> >> if you can compile and run has_cuda_gpu.c. >> >> >> Simon >> >> >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >> >>> >> >> >>> HI, >> >> >>> >> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 >> was >> >> >>> installed on our system. I set the following in ccmake >> >> >>> >> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >> >>> RTK_USE_CUDA ON >> >> >>> >> >> >>> I could build but no cuda applications were generated. In the bin >> >> >>> folder >> >> >>> I >> >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >> >>> >> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >> >>> >> >> >>> -howard >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Rtk-users mailing list >> >> >>> Rtk-users at public.kitware.com >> >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >>> >> >> >> _______________________________________________ >> >> >> Rtk-users mailing list >> >> >> Rtk-users at public.kitware.com >> >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> >> >> > >> > >> > >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 13 07:06:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Feb 2015 13:06:34 +0100 Subject: [Rtk-users] ADMMTVReconstruction In-Reply-To: <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> References: <548EA4E1.4090801@creatis.insa-lyon.fr> <54919EE9.3010406@creatis.insa-lyon.fr> <5492A8BB.2030209@creatis.insa-lyon.fr> <000901d02a50$1c14f470$543edd50$@uclouvain.be> <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> Message-ID: Hi, FYI, S?bastien and I have worked on the pipeline that was mentionned in this discussion. The pipeline is now available in the rtkProjectionsReader (see the diagram in the doc ). Every rtk application can use it from command line options. For example, I0 is automatically estimated if the option --i0=0 is used. Don't hesitate to report what is not clear or not working for you. Simon On Thu, Jan 8, 2015 at 4:04 PM, S?bastien Brousmiche < sebastien.brousmiche at uclouvain.be> wrote: > Hi Howard, > > > > Actually there are three values given per projection: I0, a filtered I0 > (RLS) and the FWHM of the background mode. > > You can just use the first value per projection. If ?output? is the buffer > contained in the file (-d) then use I0 = buffer(1:3:end); > > > > Read rtki0estimation.cxx in the application folder for more information. > I?m planning to add more info in the code later. > > > > Best, > > S?bastien > > > > > > *From:* Howard [mailto:lomahu at gmail.com] > *Sent:* jeudi 8 janvier 2015 15:57 > *To:* S?bastien Brousmiche > *Cc:* Simon Rit; rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Hi Sebastien, > > > > Thank you very much for your explanation. I used -d to write I0 > estimations to a file. I found there are >2000 numbers for ~600 > projections. I thought there would be one number for each projection, but > obviously the output numbers are not generated that way. Could you please > describe a bit more on the file format and how to use them? Or simply I > wait for your new mini-pipeline filter? > > > > Regards, > > -howard > > > > On Wed, Jan 7, 2015 at 3:01 AM, S?bastien Brousmiche < > sebastien.brousmiche at uclouvain.be> wrote: > > Hi Howard, > > > > There is an input parameter with the rtki0estimation application (-d) > which allows you to specify the output file with I0 estimates. > > > > The big file you mentioned contains the histograms of each image (65536 > values each) stored consecutively. The first value is the occurrence of > number 0 in your image, second.. 1 and so forth up to 65535. > > > > This application is not particularly interesting to be used in a pipeline. > > > > > Nevertheless, we are developing a mini-pipeline grouping typical > preprocessing filters. It is under validation and I?ll let you know as soon > as it is available for you. > > > > Best, > > S?bastien > > > > > > > > > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Howard > *Sent:* mercredi 7 janvier 2015 00:17 > *To:* Simon Rit > *Cc:* rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Happy New Year, Simon. > > > > Thank you for pointing to me the I0 estimate procedure.I saw an > application rtki0estimation > > under the Applications folder. Is this the tool you meant? I ran it using > all default parameters > > providing with the original projection data. What I obtained was a file: > i0est_histogram.csv. > > From the comments in rtki0estimation.ggo this file is the output with I0 > estimate. For 650 projections > > the file size is around 200MB. I used excel to open the file and found > that the beginning two numbers > > 64408 and 722024 then followed by 0's. In the middle there are some > nonzero numbers. Essentially > > all zeros. > > Since there is not much description of the application, so it is hard to > figure out easily what I am doing. > > I tried to read the source code, but it might be more useful if you can > give some hints on how to > > use it. > > > > Regards, > > -howard > > > > > > On Mon, Jan 5, 2015 at 1:49 AM, Simon Rit > wrote: > > Happy new year Howard, > Normally, this calibration is handled by the flat panel. It uses an > air projection and a dark (no beam) projection to compute the line > integral. However, there might be fluctuations in time of these two > projections. Some people do regular acquisitions of them to capture > the time fluctuations. Otherwise, a constant value might be a good > solution. S?bastien has recently implemented an automated > determination of this constant, maybe you should have a look: > > http://www.openrtk.org/Doxygen/classrtk_1_1I0EstimationProjectionFilter.html > It is already part of the mini-pipeline for ImagX / IBA projections > processing: > > http://www.openrtk.org/Doxygen/classrtk_1_1ImagXRawToAttenuationImageFilter.html > Simon > > > On Fri, Jan 2, 2015 at 10:17 PM, Howard wrote: > > Happy New Year, Cyril. > > > > I realized that our projection data is having some issues with air > > correction. We checked our calibration and it appeared fine. Do you know > by > > any chance whether there is a quick way of correcting that? I searched > > around and found people used a constant air norm image. > > > > Thanks very much, > > -howard > > > > On Thu, Dec 18, 2014 at 5:13 AM, Cyril Mory > > wrote: > >> > >> Hi Howard, > >> > >> I've taken a look at your data. > >> You can apply tv denoising on the out.mha volume and obtain a > >> significantly lower level of noise without blurring structures by using > the > >> following command : > >> rtktotalvariationdenoising -i out.mha -g 0.001 -o > >> tvdenoised/gamma0.001.mha -n 100 > >> > >> I was unable to obtain good results with iterative reconstruction from > the > >> projection data you sent, though. I think the main reason for this is > that > >> your projections have much-higher-than-zero attenuation in air. Your > >> calculation of i0 when converting from intensity to attenuation is > probably > >> not good enough. Try to correct for this effect first. Then you can > start > >> performing SART and Conjugate Gradient reconstructions on your data, and > >> once you get these right, play with ADMM. > >> > >> You might need to remove the table from the projections to be able to > >> restrict the reconstruction volume strictly to the patient, and speed > up the > >> computations. We can provide help for that too. > >> > >> Best regards, > >> Cyril > >> > >> > >> On 12/17/2014 05:02 PM, Howard wrote: > >> > >> Hi Cyril, > >> > >> I've sent you two files via wetransfer.com: one is the sparse > projection > >> set with geometry file and the other is the fdk reconstructed image > based on > >> full projection set. Please let me know if you have trouble receiving > them. > >> > >> Thanks very much for looking into this. > >> > >> -Howard > >> > >> On Wed, Dec 17, 2014 at 10:19 AM, Cyril Mory > >> wrote: > >>> > >>> Hi Howard, > >>> > >>> Thanks for the detailed feedback. > >>> The image getting blurry is typically due to a too high gamma. > Depending > >>> on you data, gamma can have to be set to a very small value (I use > 0.007 in > >>> some reconstructions on clinical data). Can you send over your volume > >>> reconstructed from full projection data, and I'll have a quick look ? > >>> > >>> There is a lot of instinct in the setting of the parameters. With time, > >>> one gets used to finding a correct set of parameters without really > knowing > >>> how. I can also try to reconstruct from your cbct data if you send me > the > >>> projections and the geometry. > >>> > >>> Best regards, > >>> Cyril > >>> > >>> > >>> On 12/17/2014 03:49 PM, Howard wrote: > >>> > >>> Hi Cyril, > >>> > >>> Thanks very much for your detailed and nice description on how to use > the > >>> admmtv reconstruction. I followed your suggestions and re-ran > >>> reconstructions using admmtotalvariation and admmwavelets with cbct > >>> projection data from a thoracic patient. > >>> > >>> I am reporting what I found and hope these will give you information > for > >>> further improvement. > >>> > >>> 1. I repeated admmtotalvariation with 30 iterations. No improvement was > >>> observed. As a matter of fact, the reconstructed image is getting a lot > >>> noiser compared to that using 3 iterations. The contrast is getting > worse as > >>> well. I tried to play around with window & level in case I was fooled > but > >>> apparently more iterations gave worse results. > >>> > >>> 2. Similarly I ran 30 iterations using admmwavelets. Slightly better > >>> reconstruction compared with total variation. > >>> > >>> 3. Then I went ahead to test if TV benefits us anything using the > >>> tvdenoising application on the fdk-reconstructed image reconstructed > from > >>> full projection set. I found that the more iterations, the more blurry > the > >>> image became. For example, with 50 iterations the contrast on the > denoised > >>> image is very low so that the vertebrae and surrounding soft tissue are > >>> hardly distinguishable. Changing gamma's at 0.2, 0.5, 1.0, 10 did not > seem > >>> to make a difference on the image. With 5 iterations the denoising > seems to > >>> work fairly well. Again, changing gamma's didn't make a difference. > >>> I hope I didn't misused the totalvariationdenoising application. The > >>> command I executed was: rtktotalvariationdenoising -i out.mha -o > >>> out_denoising_n50_gamma05 --gamma 0.5 -n 50 > >>> > >>> In summary, tdmmwavelets seems perform better than tdmmtotalvariation > but > >>> neither gave satisfactory results. No sure what we can infer from the > TV > >>> denoising study. I could send my study to you if there is a need. > Please let > >>> me know what tests I could run. Further help on improvement is > definitely > >>> welcome and appreciated. > >>> > >>> -Howard > >>> > >>> On Mon, Dec 15, 2014 at 4:07 AM, Cyril Mory > >>> wrote: > >>>> > >>>> Hello Howard, > >>>> > >>>> Good to hear that you're using RTK :) > >>>> I'll try to answer all your questions, and give you some advice: > >>>> - In general, you can expect some improvement over rtkfdk, but not a > >>>> huge one > >>>> - You can find the calculations in my PhD thesis > >>>> https://tel.archives-ouvertes.fr/tel-00985728 (in English. Only the > >>>> introduction is in French) > >>>> - Adjusting the parameters is, in itself, a research topic (sorry !). > >>>> Alpha controls the amount of regularization and only that (the > higher, the > >>>> more regularization). Beta, theoretically, should only change the > >>>> convergence speed, provided you do an infinite number of iterations > (I know > >>>> it doesn't help, sorry again !). In practice, beta is ubiquitous and > appears > >>>> everywhere in the calculations, therefore it is hard to predict what > effect > >>>> an increase/decrease of beta will give on the images. I would keep it > as is, > >>>> and play on alpha > >>>> - 3 iterations is way too little. I typically used 30 iterations. > Using > >>>> the CUDA forward and back projectors helped a lot maintain the > computation > >>>> time manageable > >>>> - The quality of the results depends a lot on the nature of the image > >>>> you are trying to reconstruct. In a nutshell, the algorithm assumes > that the > >>>> image you are reconstructing has a certain form of regularity, and > discards > >>>> the potential solutions that do not have it. This assumption partly > >>>> compensates for the lack of data. ADMM TV assumes that the image you > are > >>>> reconstructing is piecewise constant, i.e. has large uniform areas > separated > >>>> by sharp borders. If your image is a phantom, it should give good > results. > >>>> If it is a real patient, you should probably change to another > algorithm > >>>> that assumes another form of regularity in the images (try > rtkadmmwavelets) > >>>> - You can find out whether you typical images can benefit from TV > >>>> regularization by reconstructing from all projections with rtkfdk, > then > >>>> applying rtktotalvariationdenoising on the reconstructed volume (try > 50 > >>>> iterations and adjust the gamma parameter: high gamma means high > >>>> regularization). If this denoising implies an unacceptable loss of > quality, > >>>> stay away from TV for these images, and try wavelets > >>>> > >>>> I hope this helps > >>>> > >>>> Looking forward to reading you again, > >>>> Cyril > >>>> > >>>> > >>>> On 12/12/2014 06:42 PM, Howard wrote: > >>>> > >>>> I am testing the ADMM total variation reconstruction with sparse data > >>>> sample. I could reconstruct but the results were not as good as > expected. In > >>>> other words, it didn't show much improvement compared to fdk > reconstruction > >>>> using the same sparse projection data. > >>>> > >>>> The parameters I used in ADMMTV were the following: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --alpha 1 --beta 1000 -n 3 > >>>> > >>>> while the fdk reconstruction parameters are: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --pad 0.1 --hann 0.5 > >>>> > >>>> The dimensions were chosen to include the entire anatomy. 72 > projections > >>>> were selected out of 646 projections for a 360 degree scan for both > >>>> calculations. > >>>> > >>>> What parameters and how can I adjust (like alpha, beta, or > iterations?) > >>>> to improve the ADMMTV reconstruction? There is not much description > of this > >>>> application from the wiki page. > >>>> > >>>> Thanks, > >>>> > >>>> -howard > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Rtk-users mailing list > >>>> Rtk-users at public.kitware.com > >>>> http://public.kitware.com/mailman/listinfo/rtk-users > >>>> > >>>> > >>>> -- > >>>> -- > >>>> Cyril Mory, Post-doc > >>>> CREATIS > >>>> Leon Berard cancer treatment center > >>>> 28 rue La?nnec > >>>> 69373 Lyon cedex 08 FRANCE > >>>> > >>>> Mobile: +33 6 69 46 73 79 > >>> > >>> > >>> -- > >>> -- > >>> Cyril Mory, Post-doc > >>> CREATIS > >>> Leon Berard cancer treatment center > >>> 28 rue La?nnec > >>> 69373 Lyon cedex 08 FRANCE > >>> > >>> Mobile: +33 6 69 46 73 79 > >> > >> > >> -- > >> -- > >> Cyril Mory, Post-doc > >> CREATIS > >> Leon Berard cancer treatment center > >> 28 rue La?nnec > >> 69373 Lyon cedex 08 FRANCE > >> > >> Mobile: +33 6 69 46 73 79 > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > > > > > ------------------------------ > > [image: Image removed by sender.] > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > > > > > > ------------------------------ > > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: not available URL: From Robert.Calliess at gmx.de Tue Feb 24 03:56:15 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 24 Feb 2015 09:56:15 +0100 Subject: [Rtk-users] sart back projection, weighting steps Message-ID: An HTML attachment was scrubbed... URL: From cyril.mory at creatis.insa-lyon.fr Tue Feb 24 04:55:00 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Tue, 24 Feb 2015 10:55:00 +0100 Subject: [Rtk-users] sart back projection, weighting steps In-Reply-To: References: Message-ID: <54EC4A74.2010601@creatis.insa-lyon.fr> Hi Robert, I'm glad to know that most of the explanation text is understandable :) You might want to check this filter: http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html You can use the command line application "rtkbackprojections" with argument --bp to compare "Joseph" and "NormalizedJoseph". When performing a back projection with non-normalized Joseph, the projection values are "splat" (splat is the adjoint operator of interpolation) between the four nearest voxels in each volume plane the ray intersects. Nothing guarantees that every voxel will receive a contribution during this process. How many contributions a voxel receives is determined by the sampling of the projections, which can be much looser or much denser (locally and globally) than what would be required. Dividing by the back projection of an image of ones mitigates this effect. In theory, as long as the forward and back projection operators are the adjoint of one another, it should not be a problem for SART. In practice, it does make a difference. I hope it helps. Please let me know if it is still unclear; Cyril On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward projection, > every pixel is > divided by the intersection length of the ray with the volume. That is > clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This weighting > step is not > performed when using a voxel-based back projection, as the weights > are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all pixels > have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply this > weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate the > pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range from 0 > to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Thu Feb 26 14:35:06 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Thu, 26 Feb 2015 19:35:06 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely,Vahid? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Thu Feb 26 15:18:53 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Thu, 26 Feb 2015 21:18:53 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Message-ID: <00d901d05201$71a49200$54edb600$@gmx.de> Hello Vahid, I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI but with a wider sensor array. I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code. But let?s see what grandmasters of RTK will suggest. Best regards, Robert Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely, Vahid -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Thu Feb 26 16:33:46 2015 From: ghostcz at hotmail.com (louie L) Date: Thu, 26 Feb 2015 22:33:46 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <00d901d05201$71a49200$54edb600$@gmx.de> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work. Best regards, Louie Greetings from my iOS! > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the > resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). > I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around > the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these > seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI > but with a wider sensor array. > > I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it > would be possible to model the helical trajectory by the changing geometry without changing /adding code. > > But let?s see what grandmasters of RTK will suggest. > > Best regards, > Robert > > > Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users > Gesendet: Donnerstag, 26. Februar 2015 20:35 > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK > > Dear RTK users, > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? > I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. > > Sincerely, > Vahid > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From cyril.mory at creatis.insa-lyon.fr Fri Feb 27 03:45:24 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Fri, 27 Feb 2015 09:45:24 +0100 Subject: [Rtk-users] Fwd: Re: Aw: Re: sart back projection, weighting steps In-Reply-To: <54F02E7E.7080000@creatis.insa-lyon.fr> References: <54F02E7E.7080000@creatis.insa-lyon.fr> Message-ID: <54F02EA4.7010006@creatis.insa-lyon.fr> Hi Robert, No problem, glad to help. I think either I have'nt been clear enough, or you're getting confused, though :) Let me try again: In joseph back projection, for each PIXEL, you "draw a line" between the source and the pixel's center, and see which voxels it crosses. Your line crosses each slice of the volume at an intersection point. You determine what the interpolation weights would be if you were to interpolate at this intersection point. And these weights are indeed between 0 and 1. But instead of interpolating, you "splat", that means you update the four nearest voxels by adding (projection's pixel value * interpolationWeight) to each. And you move to the next slice. Once you've considered all rays, you're done. Nothing in this process guarantees that a voxel will receive any contribution. In fact, some receive none, and some too many. The backprojected volume you obtain is "biased". You could think of it as the product of what you really want (the projection's pixel values smeared out along the lines of rays) with a "sampling density map" (the cumulated splat weights each voxel has been updated with). If you back project a projection of ones, then your resulting volume is exactly this sampling density map, and you can divide by it to obtain what you really want. In voxel based back projection, for each voxel, you "draw a line" between the source and the voxel's center, see where it hits the 2D projection, and add the value of that pixel (or interpolated at this position between pixels) into the voxel. And that's it for this voxel, so each voxel gets updated once and only once. And if the projection contains only ones, then your volume gets filled with ones. Dividing by one isn't going to change anything, so you just don't do it. I hope it is clearer. Cyril On 02/26/2015 02:10 PM, "Robert Callie?" wrote: > Hello Cyril, > thank you for the fast reply and thank you for the support. > Indeed I have some more questions. For the normalization step > you on the one hand side create a projection image filled with "1" > and on the other hand side you create an empty (zero) volume and > then back project the image, ok. > >>How many contributions a voxel receives is determined by the > sampling of the projections > Yes, I have the same problems with a voxel-based back projector. But > don't you have > this problem also with joseph's method when you use it for the back > projection of the "1" projection > image ? It's not clear to me how this kind of back projection actually > works (or is calculated). > And if the projection image consists of pixels with value "1" then we > actually don't need it or do we ? > So far I understand, no matter if we perform the forward or back > projtion, the joseph projector calculates > the weightings of the four voxels that are "around" the current plane > intersection point. And this > weights are always between 0 and 1. > Or do I totally misunderstand the concept of this backprojection. > I hope I did not confused you. > best regards, > Robert > *Gesendet:* Dienstag, 24. Februar 2015 um 10:55 Uhr > *Von:* "Cyril Mory" > *An:* "Robert Callie?" , rtk-users at openrtk.org > *Betreff:* Re: [Rtk-users] sart back projection, weighting steps > Hi Robert, > > I'm glad to know that most of the explanation text is understandable :) > You might want to check this filter: > http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html > You can use the command line application "rtkbackprojections" with > argument --bp to compare "Joseph" and "NormalizedJoseph". > > When performing a back projection with non-normalized Joseph, the > projection values are "splat" (splat is the adjoint operator of > interpolation) between the four nearest voxels in each volume plane > the ray intersects. Nothing guarantees that every voxel will receive a > contribution during this process. How many contributions a voxel > receives is determined by the sampling of the projections, which can > be much looser or much denser (locally and globally) than what would > be required. Dividing by the back projection of an image of ones > mitigates this effect. In theory, as long as the forward and back > projection operators are the adjoint of one another, it should not be > a problem for SART. In practice, it does make a difference. > > I hope it helps. Please let me know if it is still unclear; > > Cyril > On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward > projection, every pixel is > divided by the intersection length of the ray with the volume. > That is clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This > weighting step is not > performed when using a voxel-based back projection, as the > weights are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all > pixels have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply > this weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate > the pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range > from 0 to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually > happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 27 04:42:38 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 27 Feb 2015 10:42:38 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry . I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: > Hi, > > You can change the geometry. If changed correctly, most, if not all, the > iterative cone beam reconstruction will work. > > Best regards, > Louie > > Greetings from my iOS! > > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > > I think you need to add a new reconstruction filter for it. For the first > projection the object usually is placed so that the > > resulting projection image covers the upper half of the detector. And you > will need some additional handling (z-increment). > > I guess you could do a little work around with the current rtk. If you > only reconstruct an rectangular roi around > > the detector?s center where the perspective distortion (because of the > cone) is minimal. And then you add these > > seperate volumes to a final volume. This is just an idea. I do not know > how the result will look like. Think of it like a TDI > > but with a wider sensor array. > > > > I do not know the code in detail, but if it were possible to have seperate > geometry settings for every projection image it > > would be possible to model the helical trajectory by the changing geometry > without changing /adding code. > > > > But let?s see what grandmasters of RTK will suggest. > > > > Best regards, > > Robert > > > > > > *Von:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *Im Auftrag von *vahid ettehadi > via Rtk-users > *Gesendet:* Donnerstag, 26. Februar 2015 20:35 > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] Helical cone-beam reconstruction with RTK > > > > Dear RTK users, > > > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT > in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > > I would like to change the current source trajectory from circular to > helical. I was wondering is it possible to use the RTK for helical > reconstruction only with some simple modification? > > I don't know well about reconstruction process and I don't know which type > of modification is necessary to use RTK for a helical cone beam geometry. > So, any suggestion and recommendation would be appreciated. > > > > Sincerely, > > Vahid > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Fri Feb 27 14:24:14 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Fri, 27 Feb 2015 19:24:14 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: Message-ID: <47007992.1342548.1425065054134.JavaMail.yahoo@mail.yahoo.com> Hello,Thank you Robert, Louie and Simon, for your tips and recommendations. I will work on it and I will share the result or potential problems. I found the RTK more accurate and easy to use in compare with other open-source reconstruction tools such as Oscar and NiftyRec.? Thank you RTK team!Vahid On Friday, February 27, 2015 4:42 AM, Simon Rit wrote: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry. I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work.? Best regards,Louie Greetings from my iOS! On 26 Feb 2015, at 21:19, Robert Callie? wrote: Hello Vahid,I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that theresulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment).I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi aroundthe detector?s center where the perspective distortion (because of the cone) is minimal. And then you add theseseperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDIbut with a wider sensor array.?I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code.?But let?s see what grandmasters of RTK will suggest.?Best regards,Robert??????????????? ?Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK?Dear RTK users,??I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated.?Sincerely,Vahid?? _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Sun Feb 1 04:41:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 1 Feb 2015 10:41:03 +0100 Subject: [Rtk-users] RTK In-Reply-To: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> References: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> Message-ID: On Fri, Jan 30, 2015 at 10:19 AM, Robert Callie? wrote: > Hello Simon, > > thank you for the fast reply. > > > > ?Joseph's method samples the ray with one pixel per slice in the main > direction but it does not compute the intersection of the ray with each > voxel. Siddon's method does that. In fig 2 of [Xu and Mueller, 2006], Joseph > is referred to "slice interpolated" and Siddon to "box-line-integrated". > OK, thanks for that hint. I think it will maybe also has the same problem > with divergent rays and missing voxels during the reconstruction. Do you For sure. > have a link to a paper or source to this algorithm. So the algorithm may > work > > As following: > > - calculate intersection with the physical bounding volume (entry > exit points) > > - from entrypoint, determine the 4 voxels that surround this > entrypoint and bilinear interpolate the value at this position and sum it up > > - go to next plane (plane that is most ?perpendicular? to the > current center ray (focus to detector center) ? > > - at the end, the sum is normalized by the ray length ? > (length(exitpoint ? entrypoint)) > > Is that right ? Almost. Maybe I misunderstand your last step but it is actually multiplied by each step length. Normalization occurs during backprojection, not during forward projection. > > > > How can Joseph?s method be used for back projection ? If you write the method as a system matrix, simply take the transpose of it. For (S)ART, you will want to divide by the sum of the weights along one ray which is exactly what you mentionned, the ray length. > > > > ?This sounds very interesting, don't hesitate to share the code and/or the > publication! BTW, what is DDA? > > DDA stands for digital differential analyzer. I use this approach for a > voxel-based forward projector. When I started my project I was looking for a > fast and easy forward projector on voxel basis. > > I found an article about raytracing and acceleration structures where these > people used this 3d dda. They actually needed it to traverse the bounding > hierarchy to get to know what geometry > > the ray intersects with. I slightly modified it to get the intersecetion > length of a ray within a voxel by substraction of the current and previous > step width. I?v attached a zip file that contains this > > modification and the original source code. The original source code is from > www.scratchapixel.com and there is also an article about this topic > (http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-12-introduction-to-acceleration-structures/what-else/). Great, thanks. We'll have a look. Do you distribute this under a specific license? In other words, is there a risk that it would conflict with RTK license? (Apache 2, see website). > > If you have a look at my code you?ll maybe miss some matrix calculation > stuff etc. I use a scene based approach where I place the focus, object and > detector in a so called record. Each record represents the scene geometry at > a certain time, when a projection image was taken. > > Before reconstruction starts I calculate all these positions. I thought this > could be a good approach to decouple the actuall reconstruction algorithm > from the scene geometry. We'll let you know when we look at it if we have questions. > > > > > > ?But generally we use matching resolution between pixels and voxels so the > problem is minimal.? > > Do you mean, that you use a volume resolution that fits to the current > geometry setting and the detector?s pixel resolution ? Yes. > > > > ?Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > Not almost the same. What I mean seems to be simplier. Lets assume the > detector has tilted around the x-axis by 0.25 degrees. The object?s center > is at 0,0,0 and rotation axis is 0,1,0. In FDK you usually got a ray from > source to the voxel center and then you calculate > > the intersection of this ray at the detector plane. To avoid ray plane > intersection calculus, we can rotate the whole system by 0.25 degrees. Means > that the detectors normal now is parallel to the z axis.Of course the > rotation axis is not 0,1,0 any longer and the focus (xray source) > > also is a bit rotated. > > > > ?For the backprojection, we typically used voxel-based backprojection using > the center of the voxel which is faster than what you (seem to) use? > > I think here we mixed something up. This type of back projection is used for > FDK. All my questions were related to S-ART. I need to calculate the weights > > of a voxel for the back projection. To speed it up, I project its vertices > on the detector plane, calc the MEB and the send rays from within this MEB > through the > > voxel and caluclate the intersection length so those rays that will make my > weights. Some people argue that you can use the same backprojection as in FDK to speed up computations. See for example http://www.researchgate.net/profile/Gengsheng_Zeng/publication/12301525_Unmatched_projectorbackprojector_pairs_in_an_iterative_reconstruction_algorithm/links/00b495252b15fc4bb9000000.pdf > > > > > > Best regards, > > Robert > > > > > > P.S. Hello to all the other people here in the mailing list. > > > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Donnerstag, 29. Januar 2015 20:58 > An: Robert Callie? > Cc: rtk-users at openrtk.org > Betreff: Re: RTK > > > > Hi, > Thank you for your interest in RTK. Please use the mailing list for > questions that are of interest to anyone using RTK. > > There are many ways to model the direct problem (forward projection). > Without going into too many details (available in the publications of each > method) : > - "As far as I understand the goal of this approach is to calculate the > intersection length of a ray through a voxel, right ?" False. Joseph's > method samples the ray with one pixel per slice in the main direction but it > does not compute the intersection of the ray with each voxel. Siddon's > method does that. In fig 2 of [Xu and Mueller, 2006], Joseph is referred to > "slice interpolated" and Siddon to "box-line-integrated". > - "I can calculate the intersection length of the ray within a voxel by a > simple substraction, this runs very fast." This sounds very interesting, > don't hesitate to share the code and/or the publication! BTW, what is DDA? > > - Small voxels / pixels, "Did you find a way to handle this ? " We don't > handle this in RTK except if you consider that spatial regularisation (e.g., > total variation) will overcome this problem in a way. But generally we use > matching resolution between pixels and voxels so the problem is minimal. For > the backprojection, we typically used voxel-based backprojection using the > center of the voxel which is faster than what you (seem to) use. I think > that if these things are a problem for you, there is a nice solution called > distance driven (back-)projection (by De Man and Basu). I think it will do > exactly what you want. I haven't implemented it in RTK (yet). > > Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > I hope this helps. Let me know if sg is not clear in my answer! > Cheers, > Simon From riblettmj at mymail.vcu.edu Mon Feb 2 12:03:14 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 12:03:14 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF Message-ID: Hello RTK Users, I?m just getting started using RTK as part of my graduate research and was hoping that someone might be able to help me sort out an issue I?ve been having reconstructing a 3D CBCT image dataset while applying a 4D deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF has been generated by transformix (.mhd format). I followed, for the most part, the MCCBCTReconstruction example on the RTK Wiki. While reconstructing, rtkfdk reads in all of the projections to memory, begins the ?Reconstructing and Writing? phase and proceeds for a few seconds before hanging ? it doesn?t exit or fault, just drops to 0% CPU while retaining the projections in memory. By writing some basic debug messages into the source code, I?ve been able to determine that the issue lies somewhere at m_Deformation->Update() [Line 99 of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 makes it past the m_Deformation->SetFrame(iProj) line, but never makes it past the subsequent update. I?m wondering if this has anything to do with the size of the DVF generated by transformix: approximately 4.0GB (512x100x512x10 image, 4-channels, FLOAT). Just to provide a little more background information, I?m running RTK on a 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of memory running Ubuntu 14.04. RTK was built using the default ?Release? make configuration and linked to ITK 4.5.2. Elastix and Transformix are both the latest version, 4.7. Has anyone else run into a similar issue with reconstructing a similar image, or does anyone have any thoughts as to how to resolve this sort of issue? Thanks in advance! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 2 12:19:53 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 2 Feb 2015 18:19:53 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: Hi, You're the first RTK user I know to use it on Sun! Nice! If you've got 64 GB ram, that should be enough... although you could ask elastix to generate a smaller DVF, RTK linearly interpolates between vectors. You could even use B-spline coeffs directly but you'd have to create a new DVF. My guess is that there is a problem with the initialization of m_Deformation since the line you mention is the first time it's ever used in the class. Do you use the rtkfdk app? I would start by checking that the pointer is not null before this line, sg like: std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; If it equals 0, then there is something going with the deformation. You can check it in the main app, rtkfdk.cxx. Simon On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett wrote: > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From riblettmj at mymail.vcu.edu Mon Feb 2 13:44:54 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 13:44:54 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Simon, I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the added debug line you suggested and it doesn?t look like the pointer is null. Running it through gdb, I got the following info: m_Deformation=0x16ff820 (gdb) x 0x16ff820 0x16ff820: 0x011c51d0 (gdb) x 0x011c51d0 0x11c51d0 <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: 0x005fb874 (gdb) x 0x005fb874 0x5fb874 , 3u> >::CreateAnother() const>: 0xe5894855 (gdb) x 0xe5894855 0xe5894855: Cannot access memory at address 0xe5894855 I?m still waiting on the transformix DVF, but I?ll give that a try too when its done. Thanks again! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go ahead and check to see if the pointer is null and let you know. My current check is having transformix to generate a smaller DVF to see if that helps, so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > >> On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> > wrote: >>> Hello RTK Users, >>> >>> I?m just getting started using RTK as part of my graduate research and was >>> hoping that someone might be able to help me sort out an issue I?ve been >>> having reconstructing a 3D CBCT image dataset while applying a 4D >>> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >>> has been generated by transformix (.mhd format). I followed, for the most >>> part, the MCCBCTReconstruction example on the RTK Wiki. >>> >>> While reconstructing, rtkfdk reads in all of the projections to memory, >>> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >>> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >>> retaining the projections in memory. >>> >>> By writing some basic debug messages into the source code, I?ve been able to >>> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >>> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >>> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >>> past the subsequent update. I?m wondering if this has anything to do with >>> the size of the DVF generated by transformix: approximately 4.0GB >>> (512x100x512x10 image, 4-channels, FLOAT). >>> >>> Just to provide a little more background information, I?m running RTK on a >>> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >>> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >>> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >>> latest version, 4.7. >>> >>> Has anyone else run into a similar issue with reconstructing a similar >>> image, or does anyone have any thoughts as to how to resolve this sort of >>> issue? >>> >>> Thanks in advance! >>> >>> ? Matt >>> >>> __ >>> Matthew J. Riblett >>> Virginia Commonwealth University >>> Department of Radiation Oncology >>> Medical Physics Graduate Program >>> >>> Office: Sanger Hall, Room B1-013 >>> 401 College Street | P.O. Box 980058 >>> Richmond, Virginia 23298 >>> >>> VCU Email: riblettmj at vcu.edu >>> MCV Office Phone: +1.804.628.4858 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Feb 3 02:22:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Feb 2015 08:22:54 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: That's weird because SetFrame does nothing else than change the value of the member Frame. Are you sure it's on SetFrame that the crash occurs? On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett wrote: > Simon, > > I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the > added debug line you suggested and it doesn?t look like the pointer is null. > Running it through gdb, I got the following info: > > m_Deformation=0x16ff820 > > (gdb) x 0x16ff820 > 0x16ff820: 0x011c51d0 > (gdb) x 0x011c51d0 > 0x11c51d0 > <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: > 0x005fb874 > (gdb) x 0x005fb874 > 0x5fb874 3u>, 3u> >::CreateAnother() const>: 0xe5894855 > (gdb) x 0xe5894855 > 0xe5894855: Cannot access memory at address 0xe5894855 > > I?m still waiting on the transformix DVF, but I?ll give that a try too when > its done. > > Thanks again! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett > wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go > ahead and check to see if the pointer is null and let you know. My current > check is having transformix to generate a smaller DVF to see if that helps, > so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby > supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: > > Hi, > You're the first RTK user I know to use it on Sun! Nice! > If you've got 64 GB ram, that should be enough... although you could > ask elastix to generate a smaller DVF, RTK linearly interpolates > between vectors. You could even use B-spline coeffs directly but you'd > have to create a new DVF. > My guess is that there is a problem with the initialization of > m_Deformation since the line you mention is the first time it's ever > used in the class. Do you use the rtkfdk app? I would start by > checking that the pointer is not null before this line, sg like: > std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; > If it equals 0, then there is something going with the deformation. > You can check it in the main app, rtkfdk.cxx. > Simon > > On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett > wrote: > > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From riblettmj at mymail.vcu.edu Tue Feb 3 10:36:03 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Tue, 3 Feb 2015 10:36:03 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: <60DCF1BD-5960-4A62-AC13-42897049FDFF@mymail.vcu.edu> Simon, I think that it makes it past SetFrame and crashes on Update. Just to be sure, I put a debug message after SetFrame and it does make it to that point, so its got to be on the Update line. ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 3, 2015, at 2:22 AM, Simon Rit wrote: > > That's weird because SetFrame does nothing else than change the value > of the member Frame. Are you sure it's on SetFrame that the crash > occurs? > > On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett > wrote: >> Simon, >> >> I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the >> added debug line you suggested and it doesn?t look like the pointer is null. >> Running it through gdb, I got the following info: >> >> m_Deformation=0x16ff820 >> >> (gdb) x 0x16ff820 >> 0x16ff820: 0x011c51d0 >> (gdb) x 0x011c51d0 >> 0x11c51d0 >> <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: >> 0x005fb874 >> (gdb) x 0x005fb874 >> 0x5fb874 > 3u>, 3u> >::CreateAnother() const>: 0xe5894855 >> (gdb) x 0xe5894855 >> 0xe5894855: Cannot access memory at address 0xe5894855 >> >> I?m still waiting on the transformix DVF, but I?ll give that a try too when >> its done. >> >> Thanks again! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett >> wrote: >> >> Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go >> ahead and check to see if the pointer is null and let you know. My current >> check is having transformix to generate a smaller DVF to see if that helps, >> so the server is getting that done as we speak. >> >> You might also like to know that I?ve got RTK running on a Cray CX-1 (baby >> supercomputer) sitting next to the aforementioned Sun x4600-M2. :) >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 12:19 PM, Simon Rit >> wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> wrote: >> >> Hello RTK Users, >> >> I?m just getting started using RTK as part of my graduate research and was >> hoping that someone might be able to help me sort out an issue I?ve been >> having reconstructing a 3D CBCT image dataset while applying a 4D >> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >> has been generated by transformix (.mhd format). I followed, for the most >> part, the MCCBCTReconstruction example on the RTK Wiki. >> >> While reconstructing, rtkfdk reads in all of the projections to memory, >> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >> retaining the projections in memory. >> >> By writing some basic debug messages into the source code, I?ve been able to >> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >> past the subsequent update. I?m wondering if this has anything to do with >> the size of the DVF generated by transformix: approximately 4.0GB >> (512x100x512x10 image, 4-channels, FLOAT). >> >> Just to provide a little more background information, I?m running RTK on a >> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >> latest version, 4.7. >> >> Has anyone else run into a similar issue with reconstructing a similar >> image, or does anyone have any thoughts as to how to resolve this sort of >> issue? >> >> Thanks in advance! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Thu Feb 5 06:44:47 2015 From: wuchao04 at gmail.com (Chao Wu) Date: Thu, 5 Feb 2015 12:44:47 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Hi Simon, There is still an issue with gengetopt. The config file cannot be read. The problem seems to be at around line 62 in rtkMacro.h: char *configFile = args_info.config_arg; points configFile to the address storing the config file name, but next cmdline_parser_##ggo_filename##_free(&args_info); frees all string field of args_info, including args_info.config_arg, therefore the content pointed by configFile becomes invalid. Regards, Chao 2014-12-12 14:10 GMT+01:00 Simon Rit : > My fix did not work. Cyril (Mory) reported that multiple options were read > twice. I hope this new fix will work but don't hesitate to report other > issues with gengetopt. > Thanks again for you reports, > Simon > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > wrote: >> >> That makes sense, thanks for the quick usage explanation, and fix. >> (Disabling the override issue makes sense, and I didn't have time to trace >> through gengetopt. I thought I was missing something, as none of the >> non-flag arguments were being reset (to null, or default values, and thus >> thought 'override' meant something else!). >> >> Thanks again, glad the info was helpful. >> >> Steve >> >> >> On 14-12-10 4:01 AM, Simon Rit wrote: >> >> Hi, >> Thanks for the report, very useful information. I could reproduce the bug >> and I hope that I have fixed it. Briefly: >> - I have changed the code because Ben Champion reported memory leaks and I >> noticed that they occured in deprecated functions of gengetopt that I don't >> use anymore, >> - the way the new macro (as well as the previous one) is written is: first >> read the command line to find if a config file is passed, then read the >> config file and finally read the command line again to check that everything >> has been passed. >> - your fix was not perfect because we would not have checked that the >> required options were set, >> - it turns out that disabling the override option did the job. >> Everything sworks fine now but let met know if you notice something wrong >> again. Thanks again, >> Simon >> >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann >> wrote: >>> >>> A recent update to rtkMacro.h seems to have caused the ggo command line >>> processor to ignore command line flags. (i.e. I can't get any verbose output >>> with '-v'). >>> It seems to happen after making a second call to: >>> >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, &args_params) >>> >>> Removing this second call, has resolved the issue for me. >>> I'm not sure, however, what the intended use of the second call was for >>> (it occurs immediately after: >>> >>> args_params.check_required = 1; >>> >>> which I feel could just be moved above the first call, as it happens >>> regardless, but I may be missing something. >>> >>> I've attached my quickly modified rtkMacro.h for comparison to the latest >>> github commit. >>> >>> Anyhow, hopefully this info is useful, and doesn't only affect me. >>> >>> Steve >>> >>> Our system setup: >>> -Ubuntu 14.04 x64 >>> -gcc 4.8.2 >>> -cuda 6.5 >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 5 09:17:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 5 Feb 2015 15:17:34 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Indeed, it looks as if I had not tested it, I thought I had... This patch should fix it. Thanks for the report! Simon On Thu, Feb 5, 2015 at 12:44 PM, Chao Wu wrote: > Hi Simon, > > There is still an issue with gengetopt. The config file cannot be read. > The problem seems to be at around line 62 in rtkMacro.h: > char *configFile = args_info.config_arg; points configFile to the > address storing the config file name, but next > cmdline_parser_##ggo_filename##_free(&args_info); frees all string > field of args_info, including args_info.config_arg, therefore the > content pointed by configFile becomes invalid. > > Regards, > Chao > > 2014-12-12 14:10 GMT+01:00 Simon Rit : > > My fix did not work. Cyril (Mory) reported that multiple options were > read > > twice. I hope this new fix will work but don't hesitate to report other > > issues with gengetopt. > > Thanks again for you reports, > > Simon > > > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > > wrote: > >> > >> That makes sense, thanks for the quick usage explanation, and fix. > >> (Disabling the override issue makes sense, and I didn't have time to > trace > >> through gengetopt. I thought I was missing something, as none of the > >> non-flag arguments were being reset (to null, or default values, and > thus > >> thought 'override' meant something else!). > >> > >> Thanks again, glad the info was helpful. > >> > >> Steve > >> > >> > >> On 14-12-10 4:01 AM, Simon Rit wrote: > >> > >> Hi, > >> Thanks for the report, very useful information. I could reproduce the > bug > >> and I hope that I have fixed it. Briefly: > >> - I have changed the code because Ben Champion reported memory leaks > and I > >> noticed that they occured in deprecated functions of gengetopt that I > don't > >> use anymore, > >> - the way the new macro (as well as the previous one) is written is: > first > >> read the command line to find if a config file is passed, then read the > >> config file and finally read the command line again to check that > everything > >> has been passed. > >> - your fix was not perfect because we would not have checked that the > >> required options were set, > >> - it turns out that disabling the override option did the job. > >> Everything sworks fine now but let met know if you notice something > wrong > >> again. Thanks again, > >> Simon > >> > >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann > >> wrote: > >>> > >>> A recent update to rtkMacro.h seems to have caused the ggo command line > >>> processor to ignore command line flags. (i.e. I can't get any verbose > output > >>> with '-v'). > >>> It seems to happen after making a second call to: > >>> > >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, > &args_params) > >>> > >>> Removing this second call, has resolved the issue for me. > >>> I'm not sure, however, what the intended use of the second call was for > >>> (it occurs immediately after: > >>> > >>> args_params.check_required = 1; > >>> > >>> which I feel could just be moved above the first call, as it happens > >>> regardless, but I may be missing something. > >>> > >>> I've attached my quickly modified rtkMacro.h for comparison to the > latest > >>> github commit. > >>> > >>> Anyhow, hopefully this info is useful, and doesn't only affect me. > >>> > >>> Steve > >>> > >>> Our system setup: > >>> -Ubuntu 14.04 x64 > >>> -gcc 4.8.2 > >>> -cuda 6.5 > >>> > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> > >> > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Fri Feb 6 12:27:13 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Fri, 6 Feb 2015 18:27:13 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont -------------- next part -------------- A non-text attachment was scrubbed... Name: figure1.png Type: image/png Size: 28287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: figure2.png Type: image/png Size: 80102 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SheppLogan.txt URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 9 09:08:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Feb 2015 15:08:12 +0100 Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT wrote: > Hello rtk users, > > I try to use RTK for reconstruction in my lab but I encounter some > problems. > > I try to reconstruct a simulated spheroid. I join my phantom text file > (SheppLogan.txt). > > If I set source_y=0, I get a correct (I guess) reconstruction, see the > joined figure1.png. I use the followind set of commands : > > rtksimulatedgeometry -n 180 --sdd=508.1658133423730 > --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 > --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && > rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha > --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p > /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml > --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" > > But If I set source_y=15, I obtain some strange artefacts as you can see > on figure2.png. Do you know the origin of this pattern (the vertical one) ? > Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this > artefact doesn't exist. > > Thanks in advance and thanks for this nice toolkit. > > regards, > Mathieu Dupont > > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Thu Feb 12 04:25:12 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Thu, 12 Feb 2015 10:25:12 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <681578867.13033470.1423733112438.JavaMail.zimbra@cppm.in2p3.fr> Hi Simon, you are right, it works now. Thanks for your reactivity. ----- Mail original ----- De: "Simon Rit" ?: "Mathieu DUPONT" Cc: rtk-users at public.kitware.com Envoy?: Lundi 9 F?vrier 2015 15:08:12 Objet: Re: [Rtk-users] fdk artefact, sourceOffsetY Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT < mdupont at cppm.in2p3.fr > wrote: Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From lomahu at gmail.com Thu Feb 12 10:04:45 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 10:04:45 -0500 Subject: [Rtk-users] building CUDA Message-ID: HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 10:50:08 2015 From: theday79 at gmail.com (Yang K Park) Date: Thu, 12 Feb 2015 10:50:08 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <000801d046db$94f3eb60$bedbc220$@gmail.com> Hi Howard, Attached is my Cmake capture image for RTK using CUDA6.5. (I?m using the default option of RTK w/o any manual modification). Also, I?m using VS2013 / win7 64. I found your second option ?CUDA_ATTACH_VS_BUILD_RULE_TO_C ? is different from mine (CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE). And why don?t you use the newest version of CUDA (v6.5)? It may work fine regardless of the model of your NVIDIA graphic card (I?ve tested it for multiple computers w/ different graphic card models). CUDA6.5 is convenient to install since a single installation file will be enough which is including the graphic driver, CUDA toolkit, SDK, etc. (not sure this is same as 5.5). Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Howard Sent: Thursday, February 12, 2015 10:05 AM To: rtk-users at openrtk.org Subject: [Rtk-users] building CUDA HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Cuda_RTK_Cmake.PNG Type: image/png Size: 43604 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:16:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:16:17 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: Hi, Cmake automatically checks if you have a cuda compatible GPU. If it cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile applications. So there must be an issue with your graphic card. Check if you can compile and run has_cuda_gpu.c. Simon On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > HI, > > I encountered a problem when building CUDA applications. CUDA 5.5 was > installed on our system. I set the following in ccmake > > CUDA_64_BIT_DEVICE_CODE ON > CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > RTK_USE_CUDA ON > > I could build but no cuda applications were generated. In the bin folder I > saw libITKCudaCommon.a and librtkcuda.a. > > What did I miss? Anybody could shed light on this? Thanks, > > -howard > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From julien.jomier at kitware.com Thu Feb 12 11:23:10 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Thu, 12 Feb 2015 17:23:10 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <54DCD36E.5080903@kitware.com> To follow up, what do you mean by "no cuda applications were generated"? If you have the libraries compiled that means CMake found a working CUDA compatible device. -Julien On 12/02/2015 17:16, Simon Rit wrote: > Hi, > Cmake automatically checks if you have a cuda compatible GPU. If it > cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > applications. So there must be an issue with your graphic card. Check > if you can compile and run has_cuda_gpu.c. > Simon > > On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> HI, >> >> I encountered a problem when building CUDA applications. CUDA 5.5 was >> installed on our system. I set the following in ccmake >> >> CUDA_64_BIT_DEVICE_CODE ON >> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> RTK_USE_CUDA ON >> >> I could build but no cuda applications were generated. In the bin folder I >> saw libITKCudaCommon.a and librtkcuda.a. >> >> What did I miss? Anybody could shed light on this? Thanks, >> >> -howard >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:27:09 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:27:09 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: <54DCD36E.5080903@kitware.com> References: <54DCD36E.5080903@kitware.com> Message-ID: Actually no, librtkcuda is compiled if the cuda library is available but the applications are compiled if the cuda library AND a cuda compatible device are available... That's probably why you observe this. Simon On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier wrote: > To follow up, what do you mean by "no cuda applications were generated"? If > you have the libraries compiled that means CMake found a working CUDA > compatible device. > > -Julien > > > On 12/02/2015 17:16, Simon Rit wrote: >> >> Hi, >> Cmake automatically checks if you have a cuda compatible GPU. If it >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> applications. So there must be an issue with your graphic card. Check >> if you can compile and run has_cuda_gpu.c. >> Simon >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >>> >>> HI, >>> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >>> installed on our system. I set the following in ccmake >>> >>> CUDA_64_BIT_DEVICE_CODE ON >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >>> RTK_USE_CUDA ON >>> >>> I could build but no cuda applications were generated. In the bin folder >>> I >>> saw libITKCudaCommon.a and librtkcuda.a. >>> >>> What did I miss? Anybody could shed light on this? Thanks, >>> >>> -howard >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > From lomahu at gmail.com Thu Feb 12 12:24:12 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 12:24:12 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: Thanks all for your responses to my question. I did not initially set CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: [ 24%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt for reading. [ 25%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt for reading. As I said in my original post, we have CUDA installed on the system (cluster system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the cards would work well although I haven't confirmed that. -howard On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit wrote: > Actually no, librtkcuda is compiled if the cuda library is available > but the applications are compiled if the cuda library AND a cuda > compatible device are available... That's probably why you observe > this. > Simon > > On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > wrote: > > To follow up, what do you mean by "no cuda applications were generated"? > If > > you have the libraries compiled that means CMake found a working CUDA > > compatible device. > > > > -Julien > > > > > > On 12/02/2015 17:16, Simon Rit wrote: > >> > >> Hi, > >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> applications. So there must be an issue with your graphic card. Check > >> if you can compile and run has_cuda_gpu.c. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >>> > >>> HI, > >>> > >>> I encountered a problem when building CUDA applications. CUDA 5.5 was > >>> installed on our system. I set the following in ccmake > >>> > >>> CUDA_64_BIT_DEVICE_CODE ON > >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >>> RTK_USE_CUDA ON > >>> > >>> I could build but no cuda applications were generated. In the bin > folder > >>> I > >>> saw libITKCudaCommon.a and librtkcuda.a. > >>> > >>> What did I miss? Anybody could shed light on this? Thanks, > >>> > >>> -howard > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> _______________________________________________ > >> Rtk-users mailing list > >> Rtk-users at public.kitware.com > >> http://public.kitware.com/mailman/listinfo/rtk-users > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 12:42:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 18:42:15 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: That's more complicated. First, CUDA_HAVE_GPU is normally turned on automatically but maybe it's been turned off due to the problem you're encountering now. The problem you have is probably not specific to RTK, we don't develop FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an option CUDA_BUILD_CUBIN, maybe turn it off? If I were you, I'd try to create a small separate project with has_cuda_gpu.c and check whether it compiles. If it doesn't, try the cmake mailing list. Simon On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > Thanks all for your responses to my question. I did not initially set > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > [ 24%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > for reading. > > > [ 25%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > for reading. > > As I said in my original post, we have CUDA installed on the system (cluster > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > cards would work well although I haven't confirmed that. > > -howard > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit > wrote: >> >> Actually no, librtkcuda is compiled if the cuda library is available >> but the applications are compiled if the cuda library AND a cuda >> compatible device are available... That's probably why you observe >> this. >> Simon >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> wrote: >> > To follow up, what do you mean by "no cuda applications were generated"? >> > If >> > you have the libraries compiled that means CMake found a working CUDA >> > compatible device. >> > >> > -Julien >> > >> > >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> Hi, >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> applications. So there must be an issue with your graphic card. Check >> >> if you can compile and run has_cuda_gpu.c. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >>> >> >>> HI, >> >>> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >> >>> installed on our system. I set the following in ccmake >> >>> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >>> RTK_USE_CUDA ON >> >>> >> >>> I could build but no cuda applications were generated. In the bin >> >>> folder >> >>> I >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >>> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >>> >> >>> -howard >> >>> >> >>> _______________________________________________ >> >>> Rtk-users mailing list >> >>> Rtk-users at public.kitware.com >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >>> >> >> _______________________________________________ >> >> Rtk-users mailing list >> >> Rtk-users at public.kitware.com >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > > > From lomahu at gmail.com Thu Feb 12 13:37:39 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 13:37:39 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: When I did the following: CUDA_HAVE_GPU ON CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) building was successful. I could run rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk using cuda?) with successful reconstruction. It's done in < 15s, wow! A separate question: how to specify cuda for rtksart, rtkadmmwavelets, rtkadmmtotalvariations etc? Thanks, -howard On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit wrote: > That's more complicated. First, CUDA_HAVE_GPU is normally turned on > automatically but maybe it's been turned off due to the problem you're > encountering now. > The problem you have is probably not specific to RTK, we don't develop > FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an > option CUDA_BUILD_CUBIN, maybe turn it off? > If I were you, I'd try to create a small separate project with > has_cuda_gpu.c and check whether it compiles. If it doesn't, try the > cmake mailing list. > Simon > > On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > > Thanks all for your responses to my question. I did not initially set > > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > > > > [ 24%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > > for reading. > > > > > > [ 25%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > > for reading. > > > > As I said in my original post, we have CUDA installed on the system > (cluster > > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > > cards would work well although I haven't confirmed that. > > > > -howard > > > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > wrote: > >> > >> Actually no, librtkcuda is compiled if the cuda library is available > >> but the applications are compiled if the cuda library AND a cuda > >> compatible device are available... That's probably why you observe > >> this. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > >> wrote: > >> > To follow up, what do you mean by "no cuda applications were > generated"? > >> > If > >> > you have the libraries compiled that means CMake found a working CUDA > >> > compatible device. > >> > > >> > -Julien > >> > > >> > > >> > On 12/02/2015 17:16, Simon Rit wrote: > >> >> > >> >> Hi, > >> >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> >> applications. So there must be an issue with your graphic card. Check > >> >> if you can compile and run has_cuda_gpu.c. > >> >> Simon > >> >> > >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >> >>> > >> >>> HI, > >> >>> > >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 > was > >> >>> installed on our system. I set the following in ccmake > >> >>> > >> >>> CUDA_64_BIT_DEVICE_CODE ON > >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >> >>> RTK_USE_CUDA ON > >> >>> > >> >>> I could build but no cuda applications were generated. In the bin > >> >>> folder > >> >>> I > >> >>> saw libITKCudaCommon.a and librtkcuda.a. > >> >>> > >> >>> What did I miss? Anybody could shed light on this? Thanks, > >> >>> > >> >>> -howard > >> >>> > >> >>> _______________________________________________ > >> >>> Rtk-users mailing list > >> >>> Rtk-users at public.kitware.com > >> >>> http://public.kitware.com/mailman/listinfo/rtk-users > >> >>> > >> >> _______________________________________________ > >> >> Rtk-users mailing list > >> >> Rtk-users at public.kitware.com > >> >> http://public.kitware.com/mailman/listinfo/rtk-users > >> >> > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 13:47:54 2015 From: theday79 at gmail.com (Yang-Kyun Park) Date: Thu, 12 Feb 2015 13:47:54 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: hi howard, use following options for fwd and bkward projection --fp CudaRayCast --bp CudaVoxelBased Yang On Feb 12, 2015 1:37 PM, "Howard" wrote: > When I did the following: > > CUDA_HAVE_GPU ON > CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) > CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) > > building was successful. I could run > > rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk > using cuda?) > > with successful reconstruction. It's done in < 15s, wow! > > A separate question: how to specify cuda for rtksart, > rtkadmmwavelets, rtkadmmtotalvariations etc? > > Thanks, > -howard > > > > > > > > > > > On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> wrote: > >> That's more complicated. First, CUDA_HAVE_GPU is normally turned on >> automatically but maybe it's been turned off due to the problem you're >> encountering now. >> The problem you have is probably not specific to RTK, we don't develop >> FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an >> option CUDA_BUILD_CUBIN, maybe turn it off? >> If I were you, I'd try to create a small separate project with >> has_cuda_gpu.c and check whether it compiles. If it doesn't, try the >> cmake mailing list. >> Simon >> >> On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: >> > Thanks all for your responses to my question. I did not initially set >> > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: >> > >> > >> > [ 24%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > >> > [ 25%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > As I said in my original post, we have CUDA installed on the system >> (cluster >> > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are >> > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume >> the >> > cards would work well although I haven't confirmed that. >> > >> > -howard >> > >> > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> > wrote: >> >> >> >> Actually no, librtkcuda is compiled if the cuda library is available >> >> but the applications are compiled if the cuda library AND a cuda >> >> compatible device are available... That's probably why you observe >> >> this. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> >> wrote: >> >> > To follow up, what do you mean by "no cuda applications were >> generated"? >> >> > If >> >> > you have the libraries compiled that means CMake found a working CUDA >> >> > compatible device. >> >> > >> >> > -Julien >> >> > >> >> > >> >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> >> >> Hi, >> >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> >> applications. So there must be an issue with your graphic card. >> Check >> >> >> if you can compile and run has_cuda_gpu.c. >> >> >> Simon >> >> >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >> >>> >> >> >>> HI, >> >> >>> >> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 >> was >> >> >>> installed on our system. I set the following in ccmake >> >> >>> >> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >> >>> RTK_USE_CUDA ON >> >> >>> >> >> >>> I could build but no cuda applications were generated. In the bin >> >> >>> folder >> >> >>> I >> >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >> >>> >> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >> >>> >> >> >>> -howard >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Rtk-users mailing list >> >> >>> Rtk-users at public.kitware.com >> >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >>> >> >> >> _______________________________________________ >> >> >> Rtk-users mailing list >> >> >> Rtk-users at public.kitware.com >> >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> >> >> > >> > >> > >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 13 07:06:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Feb 2015 13:06:34 +0100 Subject: [Rtk-users] ADMMTVReconstruction In-Reply-To: <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> References: <548EA4E1.4090801@creatis.insa-lyon.fr> <54919EE9.3010406@creatis.insa-lyon.fr> <5492A8BB.2030209@creatis.insa-lyon.fr> <000901d02a50$1c14f470$543edd50$@uclouvain.be> <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> Message-ID: Hi, FYI, S?bastien and I have worked on the pipeline that was mentionned in this discussion. The pipeline is now available in the rtkProjectionsReader (see the diagram in the doc ). Every rtk application can use it from command line options. For example, I0 is automatically estimated if the option --i0=0 is used. Don't hesitate to report what is not clear or not working for you. Simon On Thu, Jan 8, 2015 at 4:04 PM, S?bastien Brousmiche < sebastien.brousmiche at uclouvain.be> wrote: > Hi Howard, > > > > Actually there are three values given per projection: I0, a filtered I0 > (RLS) and the FWHM of the background mode. > > You can just use the first value per projection. If ?output? is the buffer > contained in the file (-d) then use I0 = buffer(1:3:end); > > > > Read rtki0estimation.cxx in the application folder for more information. > I?m planning to add more info in the code later. > > > > Best, > > S?bastien > > > > > > *From:* Howard [mailto:lomahu at gmail.com] > *Sent:* jeudi 8 janvier 2015 15:57 > *To:* S?bastien Brousmiche > *Cc:* Simon Rit; rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Hi Sebastien, > > > > Thank you very much for your explanation. I used -d to write I0 > estimations to a file. I found there are >2000 numbers for ~600 > projections. I thought there would be one number for each projection, but > obviously the output numbers are not generated that way. Could you please > describe a bit more on the file format and how to use them? Or simply I > wait for your new mini-pipeline filter? > > > > Regards, > > -howard > > > > On Wed, Jan 7, 2015 at 3:01 AM, S?bastien Brousmiche < > sebastien.brousmiche at uclouvain.be> wrote: > > Hi Howard, > > > > There is an input parameter with the rtki0estimation application (-d) > which allows you to specify the output file with I0 estimates. > > > > The big file you mentioned contains the histograms of each image (65536 > values each) stored consecutively. The first value is the occurrence of > number 0 in your image, second.. 1 and so forth up to 65535. > > > > This application is not particularly interesting to be used in a pipeline. > > > > > Nevertheless, we are developing a mini-pipeline grouping typical > preprocessing filters. It is under validation and I?ll let you know as soon > as it is available for you. > > > > Best, > > S?bastien > > > > > > > > > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Howard > *Sent:* mercredi 7 janvier 2015 00:17 > *To:* Simon Rit > *Cc:* rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Happy New Year, Simon. > > > > Thank you for pointing to me the I0 estimate procedure.I saw an > application rtki0estimation > > under the Applications folder. Is this the tool you meant? I ran it using > all default parameters > > providing with the original projection data. What I obtained was a file: > i0est_histogram.csv. > > From the comments in rtki0estimation.ggo this file is the output with I0 > estimate. For 650 projections > > the file size is around 200MB. I used excel to open the file and found > that the beginning two numbers > > 64408 and 722024 then followed by 0's. In the middle there are some > nonzero numbers. Essentially > > all zeros. > > Since there is not much description of the application, so it is hard to > figure out easily what I am doing. > > I tried to read the source code, but it might be more useful if you can > give some hints on how to > > use it. > > > > Regards, > > -howard > > > > > > On Mon, Jan 5, 2015 at 1:49 AM, Simon Rit > wrote: > > Happy new year Howard, > Normally, this calibration is handled by the flat panel. It uses an > air projection and a dark (no beam) projection to compute the line > integral. However, there might be fluctuations in time of these two > projections. Some people do regular acquisitions of them to capture > the time fluctuations. Otherwise, a constant value might be a good > solution. S?bastien has recently implemented an automated > determination of this constant, maybe you should have a look: > > http://www.openrtk.org/Doxygen/classrtk_1_1I0EstimationProjectionFilter.html > It is already part of the mini-pipeline for ImagX / IBA projections > processing: > > http://www.openrtk.org/Doxygen/classrtk_1_1ImagXRawToAttenuationImageFilter.html > Simon > > > On Fri, Jan 2, 2015 at 10:17 PM, Howard wrote: > > Happy New Year, Cyril. > > > > I realized that our projection data is having some issues with air > > correction. We checked our calibration and it appeared fine. Do you know > by > > any chance whether there is a quick way of correcting that? I searched > > around and found people used a constant air norm image. > > > > Thanks very much, > > -howard > > > > On Thu, Dec 18, 2014 at 5:13 AM, Cyril Mory > > wrote: > >> > >> Hi Howard, > >> > >> I've taken a look at your data. > >> You can apply tv denoising on the out.mha volume and obtain a > >> significantly lower level of noise without blurring structures by using > the > >> following command : > >> rtktotalvariationdenoising -i out.mha -g 0.001 -o > >> tvdenoised/gamma0.001.mha -n 100 > >> > >> I was unable to obtain good results with iterative reconstruction from > the > >> projection data you sent, though. I think the main reason for this is > that > >> your projections have much-higher-than-zero attenuation in air. Your > >> calculation of i0 when converting from intensity to attenuation is > probably > >> not good enough. Try to correct for this effect first. Then you can > start > >> performing SART and Conjugate Gradient reconstructions on your data, and > >> once you get these right, play with ADMM. > >> > >> You might need to remove the table from the projections to be able to > >> restrict the reconstruction volume strictly to the patient, and speed > up the > >> computations. We can provide help for that too. > >> > >> Best regards, > >> Cyril > >> > >> > >> On 12/17/2014 05:02 PM, Howard wrote: > >> > >> Hi Cyril, > >> > >> I've sent you two files via wetransfer.com: one is the sparse > projection > >> set with geometry file and the other is the fdk reconstructed image > based on > >> full projection set. Please let me know if you have trouble receiving > them. > >> > >> Thanks very much for looking into this. > >> > >> -Howard > >> > >> On Wed, Dec 17, 2014 at 10:19 AM, Cyril Mory > >> wrote: > >>> > >>> Hi Howard, > >>> > >>> Thanks for the detailed feedback. > >>> The image getting blurry is typically due to a too high gamma. > Depending > >>> on you data, gamma can have to be set to a very small value (I use > 0.007 in > >>> some reconstructions on clinical data). Can you send over your volume > >>> reconstructed from full projection data, and I'll have a quick look ? > >>> > >>> There is a lot of instinct in the setting of the parameters. With time, > >>> one gets used to finding a correct set of parameters without really > knowing > >>> how. I can also try to reconstruct from your cbct data if you send me > the > >>> projections and the geometry. > >>> > >>> Best regards, > >>> Cyril > >>> > >>> > >>> On 12/17/2014 03:49 PM, Howard wrote: > >>> > >>> Hi Cyril, > >>> > >>> Thanks very much for your detailed and nice description on how to use > the > >>> admmtv reconstruction. I followed your suggestions and re-ran > >>> reconstructions using admmtotalvariation and admmwavelets with cbct > >>> projection data from a thoracic patient. > >>> > >>> I am reporting what I found and hope these will give you information > for > >>> further improvement. > >>> > >>> 1. I repeated admmtotalvariation with 30 iterations. No improvement was > >>> observed. As a matter of fact, the reconstructed image is getting a lot > >>> noiser compared to that using 3 iterations. The contrast is getting > worse as > >>> well. I tried to play around with window & level in case I was fooled > but > >>> apparently more iterations gave worse results. > >>> > >>> 2. Similarly I ran 30 iterations using admmwavelets. Slightly better > >>> reconstruction compared with total variation. > >>> > >>> 3. Then I went ahead to test if TV benefits us anything using the > >>> tvdenoising application on the fdk-reconstructed image reconstructed > from > >>> full projection set. I found that the more iterations, the more blurry > the > >>> image became. For example, with 50 iterations the contrast on the > denoised > >>> image is very low so that the vertebrae and surrounding soft tissue are > >>> hardly distinguishable. Changing gamma's at 0.2, 0.5, 1.0, 10 did not > seem > >>> to make a difference on the image. With 5 iterations the denoising > seems to > >>> work fairly well. Again, changing gamma's didn't make a difference. > >>> I hope I didn't misused the totalvariationdenoising application. The > >>> command I executed was: rtktotalvariationdenoising -i out.mha -o > >>> out_denoising_n50_gamma05 --gamma 0.5 -n 50 > >>> > >>> In summary, tdmmwavelets seems perform better than tdmmtotalvariation > but > >>> neither gave satisfactory results. No sure what we can infer from the > TV > >>> denoising study. I could send my study to you if there is a need. > Please let > >>> me know what tests I could run. Further help on improvement is > definitely > >>> welcome and appreciated. > >>> > >>> -Howard > >>> > >>> On Mon, Dec 15, 2014 at 4:07 AM, Cyril Mory > >>> wrote: > >>>> > >>>> Hello Howard, > >>>> > >>>> Good to hear that you're using RTK :) > >>>> I'll try to answer all your questions, and give you some advice: > >>>> - In general, you can expect some improvement over rtkfdk, but not a > >>>> huge one > >>>> - You can find the calculations in my PhD thesis > >>>> https://tel.archives-ouvertes.fr/tel-00985728 (in English. Only the > >>>> introduction is in French) > >>>> - Adjusting the parameters is, in itself, a research topic (sorry !). > >>>> Alpha controls the amount of regularization and only that (the > higher, the > >>>> more regularization). Beta, theoretically, should only change the > >>>> convergence speed, provided you do an infinite number of iterations > (I know > >>>> it doesn't help, sorry again !). In practice, beta is ubiquitous and > appears > >>>> everywhere in the calculations, therefore it is hard to predict what > effect > >>>> an increase/decrease of beta will give on the images. I would keep it > as is, > >>>> and play on alpha > >>>> - 3 iterations is way too little. I typically used 30 iterations. > Using > >>>> the CUDA forward and back projectors helped a lot maintain the > computation > >>>> time manageable > >>>> - The quality of the results depends a lot on the nature of the image > >>>> you are trying to reconstruct. In a nutshell, the algorithm assumes > that the > >>>> image you are reconstructing has a certain form of regularity, and > discards > >>>> the potential solutions that do not have it. This assumption partly > >>>> compensates for the lack of data. ADMM TV assumes that the image you > are > >>>> reconstructing is piecewise constant, i.e. has large uniform areas > separated > >>>> by sharp borders. If your image is a phantom, it should give good > results. > >>>> If it is a real patient, you should probably change to another > algorithm > >>>> that assumes another form of regularity in the images (try > rtkadmmwavelets) > >>>> - You can find out whether you typical images can benefit from TV > >>>> regularization by reconstructing from all projections with rtkfdk, > then > >>>> applying rtktotalvariationdenoising on the reconstructed volume (try > 50 > >>>> iterations and adjust the gamma parameter: high gamma means high > >>>> regularization). If this denoising implies an unacceptable loss of > quality, > >>>> stay away from TV for these images, and try wavelets > >>>> > >>>> I hope this helps > >>>> > >>>> Looking forward to reading you again, > >>>> Cyril > >>>> > >>>> > >>>> On 12/12/2014 06:42 PM, Howard wrote: > >>>> > >>>> I am testing the ADMM total variation reconstruction with sparse data > >>>> sample. I could reconstruct but the results were not as good as > expected. In > >>>> other words, it didn't show much improvement compared to fdk > reconstruction > >>>> using the same sparse projection data. > >>>> > >>>> The parameters I used in ADMMTV were the following: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --alpha 1 --beta 1000 -n 3 > >>>> > >>>> while the fdk reconstruction parameters are: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --pad 0.1 --hann 0.5 > >>>> > >>>> The dimensions were chosen to include the entire anatomy. 72 > projections > >>>> were selected out of 646 projections for a 360 degree scan for both > >>>> calculations. > >>>> > >>>> What parameters and how can I adjust (like alpha, beta, or > iterations?) > >>>> to improve the ADMMTV reconstruction? There is not much description > of this > >>>> application from the wiki page. > >>>> > >>>> Thanks, > >>>> > >>>> -howard > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Rtk-users mailing list > >>>> Rtk-users at public.kitware.com > >>>> http://public.kitware.com/mailman/listinfo/rtk-users > >>>> > >>>> > >>>> -- > >>>> -- > >>>> Cyril Mory, Post-doc > >>>> CREATIS > >>>> Leon Berard cancer treatment center > >>>> 28 rue La?nnec > >>>> 69373 Lyon cedex 08 FRANCE > >>>> > >>>> Mobile: +33 6 69 46 73 79 > >>> > >>> > >>> -- > >>> -- > >>> Cyril Mory, Post-doc > >>> CREATIS > >>> Leon Berard cancer treatment center > >>> 28 rue La?nnec > >>> 69373 Lyon cedex 08 FRANCE > >>> > >>> Mobile: +33 6 69 46 73 79 > >> > >> > >> -- > >> -- > >> Cyril Mory, Post-doc > >> CREATIS > >> Leon Berard cancer treatment center > >> 28 rue La?nnec > >> 69373 Lyon cedex 08 FRANCE > >> > >> Mobile: +33 6 69 46 73 79 > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > > > > > ------------------------------ > > [image: Image removed by sender.] > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > > > > > > ------------------------------ > > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: not available URL: From Robert.Calliess at gmx.de Tue Feb 24 03:56:15 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 24 Feb 2015 09:56:15 +0100 Subject: [Rtk-users] sart back projection, weighting steps Message-ID: An HTML attachment was scrubbed... URL: From cyril.mory at creatis.insa-lyon.fr Tue Feb 24 04:55:00 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Tue, 24 Feb 2015 10:55:00 +0100 Subject: [Rtk-users] sart back projection, weighting steps In-Reply-To: References: Message-ID: <54EC4A74.2010601@creatis.insa-lyon.fr> Hi Robert, I'm glad to know that most of the explanation text is understandable :) You might want to check this filter: http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html You can use the command line application "rtkbackprojections" with argument --bp to compare "Joseph" and "NormalizedJoseph". When performing a back projection with non-normalized Joseph, the projection values are "splat" (splat is the adjoint operator of interpolation) between the four nearest voxels in each volume plane the ray intersects. Nothing guarantees that every voxel will receive a contribution during this process. How many contributions a voxel receives is determined by the sampling of the projections, which can be much looser or much denser (locally and globally) than what would be required. Dividing by the back projection of an image of ones mitigates this effect. In theory, as long as the forward and back projection operators are the adjoint of one another, it should not be a problem for SART. In practice, it does make a difference. I hope it helps. Please let me know if it is still unclear; Cyril On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward projection, > every pixel is > divided by the intersection length of the ray with the volume. That is > clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This weighting > step is not > performed when using a voxel-based back projection, as the weights > are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all pixels > have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply this > weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate the > pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range from 0 > to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Thu Feb 26 14:35:06 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Thu, 26 Feb 2015 19:35:06 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely,Vahid? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Thu Feb 26 15:18:53 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Thu, 26 Feb 2015 21:18:53 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Message-ID: <00d901d05201$71a49200$54edb600$@gmx.de> Hello Vahid, I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI but with a wider sensor array. I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code. But let?s see what grandmasters of RTK will suggest. Best regards, Robert Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely, Vahid -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Thu Feb 26 16:33:46 2015 From: ghostcz at hotmail.com (louie L) Date: Thu, 26 Feb 2015 22:33:46 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <00d901d05201$71a49200$54edb600$@gmx.de> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work. Best regards, Louie Greetings from my iOS! > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the > resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). > I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around > the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these > seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI > but with a wider sensor array. > > I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it > would be possible to model the helical trajectory by the changing geometry without changing /adding code. > > But let?s see what grandmasters of RTK will suggest. > > Best regards, > Robert > > > Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users > Gesendet: Donnerstag, 26. Februar 2015 20:35 > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK > > Dear RTK users, > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? > I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. > > Sincerely, > Vahid > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From cyril.mory at creatis.insa-lyon.fr Fri Feb 27 03:45:24 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Fri, 27 Feb 2015 09:45:24 +0100 Subject: [Rtk-users] Fwd: Re: Aw: Re: sart back projection, weighting steps In-Reply-To: <54F02E7E.7080000@creatis.insa-lyon.fr> References: <54F02E7E.7080000@creatis.insa-lyon.fr> Message-ID: <54F02EA4.7010006@creatis.insa-lyon.fr> Hi Robert, No problem, glad to help. I think either I have'nt been clear enough, or you're getting confused, though :) Let me try again: In joseph back projection, for each PIXEL, you "draw a line" between the source and the pixel's center, and see which voxels it crosses. Your line crosses each slice of the volume at an intersection point. You determine what the interpolation weights would be if you were to interpolate at this intersection point. And these weights are indeed between 0 and 1. But instead of interpolating, you "splat", that means you update the four nearest voxels by adding (projection's pixel value * interpolationWeight) to each. And you move to the next slice. Once you've considered all rays, you're done. Nothing in this process guarantees that a voxel will receive any contribution. In fact, some receive none, and some too many. The backprojected volume you obtain is "biased". You could think of it as the product of what you really want (the projection's pixel values smeared out along the lines of rays) with a "sampling density map" (the cumulated splat weights each voxel has been updated with). If you back project a projection of ones, then your resulting volume is exactly this sampling density map, and you can divide by it to obtain what you really want. In voxel based back projection, for each voxel, you "draw a line" between the source and the voxel's center, see where it hits the 2D projection, and add the value of that pixel (or interpolated at this position between pixels) into the voxel. And that's it for this voxel, so each voxel gets updated once and only once. And if the projection contains only ones, then your volume gets filled with ones. Dividing by one isn't going to change anything, so you just don't do it. I hope it is clearer. Cyril On 02/26/2015 02:10 PM, "Robert Callie?" wrote: > Hello Cyril, > thank you for the fast reply and thank you for the support. > Indeed I have some more questions. For the normalization step > you on the one hand side create a projection image filled with "1" > and on the other hand side you create an empty (zero) volume and > then back project the image, ok. > >>How many contributions a voxel receives is determined by the > sampling of the projections > Yes, I have the same problems with a voxel-based back projector. But > don't you have > this problem also with joseph's method when you use it for the back > projection of the "1" projection > image ? It's not clear to me how this kind of back projection actually > works (or is calculated). > And if the projection image consists of pixels with value "1" then we > actually don't need it or do we ? > So far I understand, no matter if we perform the forward or back > projtion, the joseph projector calculates > the weightings of the four voxels that are "around" the current plane > intersection point. And this > weights are always between 0 and 1. > Or do I totally misunderstand the concept of this backprojection. > I hope I did not confused you. > best regards, > Robert > *Gesendet:* Dienstag, 24. Februar 2015 um 10:55 Uhr > *Von:* "Cyril Mory" > *An:* "Robert Callie?" , rtk-users at openrtk.org > *Betreff:* Re: [Rtk-users] sart back projection, weighting steps > Hi Robert, > > I'm glad to know that most of the explanation text is understandable :) > You might want to check this filter: > http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html > You can use the command line application "rtkbackprojections" with > argument --bp to compare "Joseph" and "NormalizedJoseph". > > When performing a back projection with non-normalized Joseph, the > projection values are "splat" (splat is the adjoint operator of > interpolation) between the four nearest voxels in each volume plane > the ray intersects. Nothing guarantees that every voxel will receive a > contribution during this process. How many contributions a voxel > receives is determined by the sampling of the projections, which can > be much looser or much denser (locally and globally) than what would > be required. Dividing by the back projection of an image of ones > mitigates this effect. In theory, as long as the forward and back > projection operators are the adjoint of one another, it should not be > a problem for SART. In practice, it does make a difference. > > I hope it helps. Please let me know if it is still unclear; > > Cyril > On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward > projection, every pixel is > divided by the intersection length of the ray with the volume. > That is clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This > weighting step is not > performed when using a voxel-based back projection, as the > weights are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all > pixels have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply > this weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate > the pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range > from 0 to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually > happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 27 04:42:38 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 27 Feb 2015 10:42:38 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry . I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: > Hi, > > You can change the geometry. If changed correctly, most, if not all, the > iterative cone beam reconstruction will work. > > Best regards, > Louie > > Greetings from my iOS! > > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > > I think you need to add a new reconstruction filter for it. For the first > projection the object usually is placed so that the > > resulting projection image covers the upper half of the detector. And you > will need some additional handling (z-increment). > > I guess you could do a little work around with the current rtk. If you > only reconstruct an rectangular roi around > > the detector?s center where the perspective distortion (because of the > cone) is minimal. And then you add these > > seperate volumes to a final volume. This is just an idea. I do not know > how the result will look like. Think of it like a TDI > > but with a wider sensor array. > > > > I do not know the code in detail, but if it were possible to have seperate > geometry settings for every projection image it > > would be possible to model the helical trajectory by the changing geometry > without changing /adding code. > > > > But let?s see what grandmasters of RTK will suggest. > > > > Best regards, > > Robert > > > > > > *Von:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *Im Auftrag von *vahid ettehadi > via Rtk-users > *Gesendet:* Donnerstag, 26. Februar 2015 20:35 > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] Helical cone-beam reconstruction with RTK > > > > Dear RTK users, > > > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT > in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > > I would like to change the current source trajectory from circular to > helical. I was wondering is it possible to use the RTK for helical > reconstruction only with some simple modification? > > I don't know well about reconstruction process and I don't know which type > of modification is necessary to use RTK for a helical cone beam geometry. > So, any suggestion and recommendation would be appreciated. > > > > Sincerely, > > Vahid > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Fri Feb 27 14:24:14 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Fri, 27 Feb 2015 19:24:14 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: Message-ID: <47007992.1342548.1425065054134.JavaMail.yahoo@mail.yahoo.com> Hello,Thank you Robert, Louie and Simon, for your tips and recommendations. I will work on it and I will share the result or potential problems. I found the RTK more accurate and easy to use in compare with other open-source reconstruction tools such as Oscar and NiftyRec.? Thank you RTK team!Vahid On Friday, February 27, 2015 4:42 AM, Simon Rit wrote: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry. I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work.? Best regards,Louie Greetings from my iOS! On 26 Feb 2015, at 21:19, Robert Callie? wrote: Hello Vahid,I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that theresulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment).I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi aroundthe detector?s center where the perspective distortion (because of the cone) is minimal. And then you add theseseperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDIbut with a wider sensor array.?I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code.?But let?s see what grandmasters of RTK will suggest.?Best regards,Robert??????????????? ?Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK?Dear RTK users,??I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated.?Sincerely,Vahid?? _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Sun Feb 1 04:41:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 1 Feb 2015 10:41:03 +0100 Subject: [Rtk-users] RTK In-Reply-To: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> References: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> Message-ID: On Fri, Jan 30, 2015 at 10:19 AM, Robert Callie? wrote: > Hello Simon, > > thank you for the fast reply. > > > > ?Joseph's method samples the ray with one pixel per slice in the main > direction but it does not compute the intersection of the ray with each > voxel. Siddon's method does that. In fig 2 of [Xu and Mueller, 2006], Joseph > is referred to "slice interpolated" and Siddon to "box-line-integrated". > OK, thanks for that hint. I think it will maybe also has the same problem > with divergent rays and missing voxels during the reconstruction. Do you For sure. > have a link to a paper or source to this algorithm. So the algorithm may > work > > As following: > > - calculate intersection with the physical bounding volume (entry > exit points) > > - from entrypoint, determine the 4 voxels that surround this > entrypoint and bilinear interpolate the value at this position and sum it up > > - go to next plane (plane that is most ?perpendicular? to the > current center ray (focus to detector center) ? > > - at the end, the sum is normalized by the ray length ? > (length(exitpoint ? entrypoint)) > > Is that right ? Almost. Maybe I misunderstand your last step but it is actually multiplied by each step length. Normalization occurs during backprojection, not during forward projection. > > > > How can Joseph?s method be used for back projection ? If you write the method as a system matrix, simply take the transpose of it. For (S)ART, you will want to divide by the sum of the weights along one ray which is exactly what you mentionned, the ray length. > > > > ?This sounds very interesting, don't hesitate to share the code and/or the > publication! BTW, what is DDA? > > DDA stands for digital differential analyzer. I use this approach for a > voxel-based forward projector. When I started my project I was looking for a > fast and easy forward projector on voxel basis. > > I found an article about raytracing and acceleration structures where these > people used this 3d dda. They actually needed it to traverse the bounding > hierarchy to get to know what geometry > > the ray intersects with. I slightly modified it to get the intersecetion > length of a ray within a voxel by substraction of the current and previous > step width. I?v attached a zip file that contains this > > modification and the original source code. The original source code is from > www.scratchapixel.com and there is also an article about this topic > (http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-12-introduction-to-acceleration-structures/what-else/). Great, thanks. We'll have a look. Do you distribute this under a specific license? In other words, is there a risk that it would conflict with RTK license? (Apache 2, see website). > > If you have a look at my code you?ll maybe miss some matrix calculation > stuff etc. I use a scene based approach where I place the focus, object and > detector in a so called record. Each record represents the scene geometry at > a certain time, when a projection image was taken. > > Before reconstruction starts I calculate all these positions. I thought this > could be a good approach to decouple the actuall reconstruction algorithm > from the scene geometry. We'll let you know when we look at it if we have questions. > > > > > > ?But generally we use matching resolution between pixels and voxels so the > problem is minimal.? > > Do you mean, that you use a volume resolution that fits to the current > geometry setting and the detector?s pixel resolution ? Yes. > > > > ?Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > Not almost the same. What I mean seems to be simplier. Lets assume the > detector has tilted around the x-axis by 0.25 degrees. The object?s center > is at 0,0,0 and rotation axis is 0,1,0. In FDK you usually got a ray from > source to the voxel center and then you calculate > > the intersection of this ray at the detector plane. To avoid ray plane > intersection calculus, we can rotate the whole system by 0.25 degrees. Means > that the detectors normal now is parallel to the z axis.Of course the > rotation axis is not 0,1,0 any longer and the focus (xray source) > > also is a bit rotated. > > > > ?For the backprojection, we typically used voxel-based backprojection using > the center of the voxel which is faster than what you (seem to) use? > > I think here we mixed something up. This type of back projection is used for > FDK. All my questions were related to S-ART. I need to calculate the weights > > of a voxel for the back projection. To speed it up, I project its vertices > on the detector plane, calc the MEB and the send rays from within this MEB > through the > > voxel and caluclate the intersection length so those rays that will make my > weights. Some people argue that you can use the same backprojection as in FDK to speed up computations. See for example http://www.researchgate.net/profile/Gengsheng_Zeng/publication/12301525_Unmatched_projectorbackprojector_pairs_in_an_iterative_reconstruction_algorithm/links/00b495252b15fc4bb9000000.pdf > > > > > > Best regards, > > Robert > > > > > > P.S. Hello to all the other people here in the mailing list. > > > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Donnerstag, 29. Januar 2015 20:58 > An: Robert Callie? > Cc: rtk-users at openrtk.org > Betreff: Re: RTK > > > > Hi, > Thank you for your interest in RTK. Please use the mailing list for > questions that are of interest to anyone using RTK. > > There are many ways to model the direct problem (forward projection). > Without going into too many details (available in the publications of each > method) : > - "As far as I understand the goal of this approach is to calculate the > intersection length of a ray through a voxel, right ?" False. Joseph's > method samples the ray with one pixel per slice in the main direction but it > does not compute the intersection of the ray with each voxel. Siddon's > method does that. In fig 2 of [Xu and Mueller, 2006], Joseph is referred to > "slice interpolated" and Siddon to "box-line-integrated". > - "I can calculate the intersection length of the ray within a voxel by a > simple substraction, this runs very fast." This sounds very interesting, > don't hesitate to share the code and/or the publication! BTW, what is DDA? > > - Small voxels / pixels, "Did you find a way to handle this ? " We don't > handle this in RTK except if you consider that spatial regularisation (e.g., > total variation) will overcome this problem in a way. But generally we use > matching resolution between pixels and voxels so the problem is minimal. For > the backprojection, we typically used voxel-based backprojection using the > center of the voxel which is faster than what you (seem to) use. I think > that if these things are a problem for you, there is a nice solution called > distance driven (back-)projection (by De Man and Basu). I think it will do > exactly what you want. I haven't implemented it in RTK (yet). > > Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > I hope this helps. Let me know if sg is not clear in my answer! > Cheers, > Simon From riblettmj at mymail.vcu.edu Mon Feb 2 12:03:14 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 12:03:14 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF Message-ID: Hello RTK Users, I?m just getting started using RTK as part of my graduate research and was hoping that someone might be able to help me sort out an issue I?ve been having reconstructing a 3D CBCT image dataset while applying a 4D deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF has been generated by transformix (.mhd format). I followed, for the most part, the MCCBCTReconstruction example on the RTK Wiki. While reconstructing, rtkfdk reads in all of the projections to memory, begins the ?Reconstructing and Writing? phase and proceeds for a few seconds before hanging ? it doesn?t exit or fault, just drops to 0% CPU while retaining the projections in memory. By writing some basic debug messages into the source code, I?ve been able to determine that the issue lies somewhere at m_Deformation->Update() [Line 99 of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 makes it past the m_Deformation->SetFrame(iProj) line, but never makes it past the subsequent update. I?m wondering if this has anything to do with the size of the DVF generated by transformix: approximately 4.0GB (512x100x512x10 image, 4-channels, FLOAT). Just to provide a little more background information, I?m running RTK on a 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of memory running Ubuntu 14.04. RTK was built using the default ?Release? make configuration and linked to ITK 4.5.2. Elastix and Transformix are both the latest version, 4.7. Has anyone else run into a similar issue with reconstructing a similar image, or does anyone have any thoughts as to how to resolve this sort of issue? Thanks in advance! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 2 12:19:53 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 2 Feb 2015 18:19:53 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: Hi, You're the first RTK user I know to use it on Sun! Nice! If you've got 64 GB ram, that should be enough... although you could ask elastix to generate a smaller DVF, RTK linearly interpolates between vectors. You could even use B-spline coeffs directly but you'd have to create a new DVF. My guess is that there is a problem with the initialization of m_Deformation since the line you mention is the first time it's ever used in the class. Do you use the rtkfdk app? I would start by checking that the pointer is not null before this line, sg like: std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; If it equals 0, then there is something going with the deformation. You can check it in the main app, rtkfdk.cxx. Simon On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett wrote: > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From riblettmj at mymail.vcu.edu Mon Feb 2 13:44:54 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 13:44:54 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Simon, I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the added debug line you suggested and it doesn?t look like the pointer is null. Running it through gdb, I got the following info: m_Deformation=0x16ff820 (gdb) x 0x16ff820 0x16ff820: 0x011c51d0 (gdb) x 0x011c51d0 0x11c51d0 <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: 0x005fb874 (gdb) x 0x005fb874 0x5fb874 , 3u> >::CreateAnother() const>: 0xe5894855 (gdb) x 0xe5894855 0xe5894855: Cannot access memory at address 0xe5894855 I?m still waiting on the transformix DVF, but I?ll give that a try too when its done. Thanks again! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go ahead and check to see if the pointer is null and let you know. My current check is having transformix to generate a smaller DVF to see if that helps, so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > >> On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> > wrote: >>> Hello RTK Users, >>> >>> I?m just getting started using RTK as part of my graduate research and was >>> hoping that someone might be able to help me sort out an issue I?ve been >>> having reconstructing a 3D CBCT image dataset while applying a 4D >>> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >>> has been generated by transformix (.mhd format). I followed, for the most >>> part, the MCCBCTReconstruction example on the RTK Wiki. >>> >>> While reconstructing, rtkfdk reads in all of the projections to memory, >>> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >>> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >>> retaining the projections in memory. >>> >>> By writing some basic debug messages into the source code, I?ve been able to >>> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >>> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >>> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >>> past the subsequent update. I?m wondering if this has anything to do with >>> the size of the DVF generated by transformix: approximately 4.0GB >>> (512x100x512x10 image, 4-channels, FLOAT). >>> >>> Just to provide a little more background information, I?m running RTK on a >>> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >>> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >>> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >>> latest version, 4.7. >>> >>> Has anyone else run into a similar issue with reconstructing a similar >>> image, or does anyone have any thoughts as to how to resolve this sort of >>> issue? >>> >>> Thanks in advance! >>> >>> ? Matt >>> >>> __ >>> Matthew J. Riblett >>> Virginia Commonwealth University >>> Department of Radiation Oncology >>> Medical Physics Graduate Program >>> >>> Office: Sanger Hall, Room B1-013 >>> 401 College Street | P.O. Box 980058 >>> Richmond, Virginia 23298 >>> >>> VCU Email: riblettmj at vcu.edu >>> MCV Office Phone: +1.804.628.4858 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Feb 3 02:22:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Feb 2015 08:22:54 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: That's weird because SetFrame does nothing else than change the value of the member Frame. Are you sure it's on SetFrame that the crash occurs? On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett wrote: > Simon, > > I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the > added debug line you suggested and it doesn?t look like the pointer is null. > Running it through gdb, I got the following info: > > m_Deformation=0x16ff820 > > (gdb) x 0x16ff820 > 0x16ff820: 0x011c51d0 > (gdb) x 0x011c51d0 > 0x11c51d0 > <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: > 0x005fb874 > (gdb) x 0x005fb874 > 0x5fb874 3u>, 3u> >::CreateAnother() const>: 0xe5894855 > (gdb) x 0xe5894855 > 0xe5894855: Cannot access memory at address 0xe5894855 > > I?m still waiting on the transformix DVF, but I?ll give that a try too when > its done. > > Thanks again! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett > wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go > ahead and check to see if the pointer is null and let you know. My current > check is having transformix to generate a smaller DVF to see if that helps, > so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby > supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: > > Hi, > You're the first RTK user I know to use it on Sun! Nice! > If you've got 64 GB ram, that should be enough... although you could > ask elastix to generate a smaller DVF, RTK linearly interpolates > between vectors. You could even use B-spline coeffs directly but you'd > have to create a new DVF. > My guess is that there is a problem with the initialization of > m_Deformation since the line you mention is the first time it's ever > used in the class. Do you use the rtkfdk app? I would start by > checking that the pointer is not null before this line, sg like: > std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; > If it equals 0, then there is something going with the deformation. > You can check it in the main app, rtkfdk.cxx. > Simon > > On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett > wrote: > > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From riblettmj at mymail.vcu.edu Tue Feb 3 10:36:03 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Tue, 3 Feb 2015 10:36:03 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: <60DCF1BD-5960-4A62-AC13-42897049FDFF@mymail.vcu.edu> Simon, I think that it makes it past SetFrame and crashes on Update. Just to be sure, I put a debug message after SetFrame and it does make it to that point, so its got to be on the Update line. ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 3, 2015, at 2:22 AM, Simon Rit wrote: > > That's weird because SetFrame does nothing else than change the value > of the member Frame. Are you sure it's on SetFrame that the crash > occurs? > > On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett > wrote: >> Simon, >> >> I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the >> added debug line you suggested and it doesn?t look like the pointer is null. >> Running it through gdb, I got the following info: >> >> m_Deformation=0x16ff820 >> >> (gdb) x 0x16ff820 >> 0x16ff820: 0x011c51d0 >> (gdb) x 0x011c51d0 >> 0x11c51d0 >> <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: >> 0x005fb874 >> (gdb) x 0x005fb874 >> 0x5fb874 > 3u>, 3u> >::CreateAnother() const>: 0xe5894855 >> (gdb) x 0xe5894855 >> 0xe5894855: Cannot access memory at address 0xe5894855 >> >> I?m still waiting on the transformix DVF, but I?ll give that a try too when >> its done. >> >> Thanks again! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett >> wrote: >> >> Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go >> ahead and check to see if the pointer is null and let you know. My current >> check is having transformix to generate a smaller DVF to see if that helps, >> so the server is getting that done as we speak. >> >> You might also like to know that I?ve got RTK running on a Cray CX-1 (baby >> supercomputer) sitting next to the aforementioned Sun x4600-M2. :) >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 12:19 PM, Simon Rit >> wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> wrote: >> >> Hello RTK Users, >> >> I?m just getting started using RTK as part of my graduate research and was >> hoping that someone might be able to help me sort out an issue I?ve been >> having reconstructing a 3D CBCT image dataset while applying a 4D >> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >> has been generated by transformix (.mhd format). I followed, for the most >> part, the MCCBCTReconstruction example on the RTK Wiki. >> >> While reconstructing, rtkfdk reads in all of the projections to memory, >> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >> retaining the projections in memory. >> >> By writing some basic debug messages into the source code, I?ve been able to >> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >> past the subsequent update. I?m wondering if this has anything to do with >> the size of the DVF generated by transformix: approximately 4.0GB >> (512x100x512x10 image, 4-channels, FLOAT). >> >> Just to provide a little more background information, I?m running RTK on a >> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >> latest version, 4.7. >> >> Has anyone else run into a similar issue with reconstructing a similar >> image, or does anyone have any thoughts as to how to resolve this sort of >> issue? >> >> Thanks in advance! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Thu Feb 5 06:44:47 2015 From: wuchao04 at gmail.com (Chao Wu) Date: Thu, 5 Feb 2015 12:44:47 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Hi Simon, There is still an issue with gengetopt. The config file cannot be read. The problem seems to be at around line 62 in rtkMacro.h: char *configFile = args_info.config_arg; points configFile to the address storing the config file name, but next cmdline_parser_##ggo_filename##_free(&args_info); frees all string field of args_info, including args_info.config_arg, therefore the content pointed by configFile becomes invalid. Regards, Chao 2014-12-12 14:10 GMT+01:00 Simon Rit : > My fix did not work. Cyril (Mory) reported that multiple options were read > twice. I hope this new fix will work but don't hesitate to report other > issues with gengetopt. > Thanks again for you reports, > Simon > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > wrote: >> >> That makes sense, thanks for the quick usage explanation, and fix. >> (Disabling the override issue makes sense, and I didn't have time to trace >> through gengetopt. I thought I was missing something, as none of the >> non-flag arguments were being reset (to null, or default values, and thus >> thought 'override' meant something else!). >> >> Thanks again, glad the info was helpful. >> >> Steve >> >> >> On 14-12-10 4:01 AM, Simon Rit wrote: >> >> Hi, >> Thanks for the report, very useful information. I could reproduce the bug >> and I hope that I have fixed it. Briefly: >> - I have changed the code because Ben Champion reported memory leaks and I >> noticed that they occured in deprecated functions of gengetopt that I don't >> use anymore, >> - the way the new macro (as well as the previous one) is written is: first >> read the command line to find if a config file is passed, then read the >> config file and finally read the command line again to check that everything >> has been passed. >> - your fix was not perfect because we would not have checked that the >> required options were set, >> - it turns out that disabling the override option did the job. >> Everything sworks fine now but let met know if you notice something wrong >> again. Thanks again, >> Simon >> >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann >> wrote: >>> >>> A recent update to rtkMacro.h seems to have caused the ggo command line >>> processor to ignore command line flags. (i.e. I can't get any verbose output >>> with '-v'). >>> It seems to happen after making a second call to: >>> >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, &args_params) >>> >>> Removing this second call, has resolved the issue for me. >>> I'm not sure, however, what the intended use of the second call was for >>> (it occurs immediately after: >>> >>> args_params.check_required = 1; >>> >>> which I feel could just be moved above the first call, as it happens >>> regardless, but I may be missing something. >>> >>> I've attached my quickly modified rtkMacro.h for comparison to the latest >>> github commit. >>> >>> Anyhow, hopefully this info is useful, and doesn't only affect me. >>> >>> Steve >>> >>> Our system setup: >>> -Ubuntu 14.04 x64 >>> -gcc 4.8.2 >>> -cuda 6.5 >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 5 09:17:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 5 Feb 2015 15:17:34 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Indeed, it looks as if I had not tested it, I thought I had... This patch should fix it. Thanks for the report! Simon On Thu, Feb 5, 2015 at 12:44 PM, Chao Wu wrote: > Hi Simon, > > There is still an issue with gengetopt. The config file cannot be read. > The problem seems to be at around line 62 in rtkMacro.h: > char *configFile = args_info.config_arg; points configFile to the > address storing the config file name, but next > cmdline_parser_##ggo_filename##_free(&args_info); frees all string > field of args_info, including args_info.config_arg, therefore the > content pointed by configFile becomes invalid. > > Regards, > Chao > > 2014-12-12 14:10 GMT+01:00 Simon Rit : > > My fix did not work. Cyril (Mory) reported that multiple options were > read > > twice. I hope this new fix will work but don't hesitate to report other > > issues with gengetopt. > > Thanks again for you reports, > > Simon > > > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > > wrote: > >> > >> That makes sense, thanks for the quick usage explanation, and fix. > >> (Disabling the override issue makes sense, and I didn't have time to > trace > >> through gengetopt. I thought I was missing something, as none of the > >> non-flag arguments were being reset (to null, or default values, and > thus > >> thought 'override' meant something else!). > >> > >> Thanks again, glad the info was helpful. > >> > >> Steve > >> > >> > >> On 14-12-10 4:01 AM, Simon Rit wrote: > >> > >> Hi, > >> Thanks for the report, very useful information. I could reproduce the > bug > >> and I hope that I have fixed it. Briefly: > >> - I have changed the code because Ben Champion reported memory leaks > and I > >> noticed that they occured in deprecated functions of gengetopt that I > don't > >> use anymore, > >> - the way the new macro (as well as the previous one) is written is: > first > >> read the command line to find if a config file is passed, then read the > >> config file and finally read the command line again to check that > everything > >> has been passed. > >> - your fix was not perfect because we would not have checked that the > >> required options were set, > >> - it turns out that disabling the override option did the job. > >> Everything sworks fine now but let met know if you notice something > wrong > >> again. Thanks again, > >> Simon > >> > >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann > >> wrote: > >>> > >>> A recent update to rtkMacro.h seems to have caused the ggo command line > >>> processor to ignore command line flags. (i.e. I can't get any verbose > output > >>> with '-v'). > >>> It seems to happen after making a second call to: > >>> > >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, > &args_params) > >>> > >>> Removing this second call, has resolved the issue for me. > >>> I'm not sure, however, what the intended use of the second call was for > >>> (it occurs immediately after: > >>> > >>> args_params.check_required = 1; > >>> > >>> which I feel could just be moved above the first call, as it happens > >>> regardless, but I may be missing something. > >>> > >>> I've attached my quickly modified rtkMacro.h for comparison to the > latest > >>> github commit. > >>> > >>> Anyhow, hopefully this info is useful, and doesn't only affect me. > >>> > >>> Steve > >>> > >>> Our system setup: > >>> -Ubuntu 14.04 x64 > >>> -gcc 4.8.2 > >>> -cuda 6.5 > >>> > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> > >> > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Fri Feb 6 12:27:13 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Fri, 6 Feb 2015 18:27:13 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont -------------- next part -------------- A non-text attachment was scrubbed... Name: figure1.png Type: image/png Size: 28287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: figure2.png Type: image/png Size: 80102 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SheppLogan.txt URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 9 09:08:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Feb 2015 15:08:12 +0100 Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT wrote: > Hello rtk users, > > I try to use RTK for reconstruction in my lab but I encounter some > problems. > > I try to reconstruct a simulated spheroid. I join my phantom text file > (SheppLogan.txt). > > If I set source_y=0, I get a correct (I guess) reconstruction, see the > joined figure1.png. I use the followind set of commands : > > rtksimulatedgeometry -n 180 --sdd=508.1658133423730 > --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 > --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && > rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha > --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p > /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml > --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" > > But If I set source_y=15, I obtain some strange artefacts as you can see > on figure2.png. Do you know the origin of this pattern (the vertical one) ? > Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this > artefact doesn't exist. > > Thanks in advance and thanks for this nice toolkit. > > regards, > Mathieu Dupont > > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Thu Feb 12 04:25:12 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Thu, 12 Feb 2015 10:25:12 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <681578867.13033470.1423733112438.JavaMail.zimbra@cppm.in2p3.fr> Hi Simon, you are right, it works now. Thanks for your reactivity. ----- Mail original ----- De: "Simon Rit" ?: "Mathieu DUPONT" Cc: rtk-users at public.kitware.com Envoy?: Lundi 9 F?vrier 2015 15:08:12 Objet: Re: [Rtk-users] fdk artefact, sourceOffsetY Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT < mdupont at cppm.in2p3.fr > wrote: Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From lomahu at gmail.com Thu Feb 12 10:04:45 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 10:04:45 -0500 Subject: [Rtk-users] building CUDA Message-ID: HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 10:50:08 2015 From: theday79 at gmail.com (Yang K Park) Date: Thu, 12 Feb 2015 10:50:08 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <000801d046db$94f3eb60$bedbc220$@gmail.com> Hi Howard, Attached is my Cmake capture image for RTK using CUDA6.5. (I?m using the default option of RTK w/o any manual modification). Also, I?m using VS2013 / win7 64. I found your second option ?CUDA_ATTACH_VS_BUILD_RULE_TO_C ? is different from mine (CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE). And why don?t you use the newest version of CUDA (v6.5)? It may work fine regardless of the model of your NVIDIA graphic card (I?ve tested it for multiple computers w/ different graphic card models). CUDA6.5 is convenient to install since a single installation file will be enough which is including the graphic driver, CUDA toolkit, SDK, etc. (not sure this is same as 5.5). Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Howard Sent: Thursday, February 12, 2015 10:05 AM To: rtk-users at openrtk.org Subject: [Rtk-users] building CUDA HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Cuda_RTK_Cmake.PNG Type: image/png Size: 43604 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:16:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:16:17 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: Hi, Cmake automatically checks if you have a cuda compatible GPU. If it cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile applications. So there must be an issue with your graphic card. Check if you can compile and run has_cuda_gpu.c. Simon On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > HI, > > I encountered a problem when building CUDA applications. CUDA 5.5 was > installed on our system. I set the following in ccmake > > CUDA_64_BIT_DEVICE_CODE ON > CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > RTK_USE_CUDA ON > > I could build but no cuda applications were generated. In the bin folder I > saw libITKCudaCommon.a and librtkcuda.a. > > What did I miss? Anybody could shed light on this? Thanks, > > -howard > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From julien.jomier at kitware.com Thu Feb 12 11:23:10 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Thu, 12 Feb 2015 17:23:10 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <54DCD36E.5080903@kitware.com> To follow up, what do you mean by "no cuda applications were generated"? If you have the libraries compiled that means CMake found a working CUDA compatible device. -Julien On 12/02/2015 17:16, Simon Rit wrote: > Hi, > Cmake automatically checks if you have a cuda compatible GPU. If it > cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > applications. So there must be an issue with your graphic card. Check > if you can compile and run has_cuda_gpu.c. > Simon > > On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> HI, >> >> I encountered a problem when building CUDA applications. CUDA 5.5 was >> installed on our system. I set the following in ccmake >> >> CUDA_64_BIT_DEVICE_CODE ON >> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> RTK_USE_CUDA ON >> >> I could build but no cuda applications were generated. In the bin folder I >> saw libITKCudaCommon.a and librtkcuda.a. >> >> What did I miss? Anybody could shed light on this? Thanks, >> >> -howard >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:27:09 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:27:09 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: <54DCD36E.5080903@kitware.com> References: <54DCD36E.5080903@kitware.com> Message-ID: Actually no, librtkcuda is compiled if the cuda library is available but the applications are compiled if the cuda library AND a cuda compatible device are available... That's probably why you observe this. Simon On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier wrote: > To follow up, what do you mean by "no cuda applications were generated"? If > you have the libraries compiled that means CMake found a working CUDA > compatible device. > > -Julien > > > On 12/02/2015 17:16, Simon Rit wrote: >> >> Hi, >> Cmake automatically checks if you have a cuda compatible GPU. If it >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> applications. So there must be an issue with your graphic card. Check >> if you can compile and run has_cuda_gpu.c. >> Simon >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >>> >>> HI, >>> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >>> installed on our system. I set the following in ccmake >>> >>> CUDA_64_BIT_DEVICE_CODE ON >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >>> RTK_USE_CUDA ON >>> >>> I could build but no cuda applications were generated. In the bin folder >>> I >>> saw libITKCudaCommon.a and librtkcuda.a. >>> >>> What did I miss? Anybody could shed light on this? Thanks, >>> >>> -howard >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > From lomahu at gmail.com Thu Feb 12 12:24:12 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 12:24:12 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: Thanks all for your responses to my question. I did not initially set CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: [ 24%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt for reading. [ 25%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt for reading. As I said in my original post, we have CUDA installed on the system (cluster system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the cards would work well although I haven't confirmed that. -howard On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit wrote: > Actually no, librtkcuda is compiled if the cuda library is available > but the applications are compiled if the cuda library AND a cuda > compatible device are available... That's probably why you observe > this. > Simon > > On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > wrote: > > To follow up, what do you mean by "no cuda applications were generated"? > If > > you have the libraries compiled that means CMake found a working CUDA > > compatible device. > > > > -Julien > > > > > > On 12/02/2015 17:16, Simon Rit wrote: > >> > >> Hi, > >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> applications. So there must be an issue with your graphic card. Check > >> if you can compile and run has_cuda_gpu.c. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >>> > >>> HI, > >>> > >>> I encountered a problem when building CUDA applications. CUDA 5.5 was > >>> installed on our system. I set the following in ccmake > >>> > >>> CUDA_64_BIT_DEVICE_CODE ON > >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >>> RTK_USE_CUDA ON > >>> > >>> I could build but no cuda applications were generated. In the bin > folder > >>> I > >>> saw libITKCudaCommon.a and librtkcuda.a. > >>> > >>> What did I miss? Anybody could shed light on this? Thanks, > >>> > >>> -howard > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> _______________________________________________ > >> Rtk-users mailing list > >> Rtk-users at public.kitware.com > >> http://public.kitware.com/mailman/listinfo/rtk-users > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 12:42:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 18:42:15 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: That's more complicated. First, CUDA_HAVE_GPU is normally turned on automatically but maybe it's been turned off due to the problem you're encountering now. The problem you have is probably not specific to RTK, we don't develop FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an option CUDA_BUILD_CUBIN, maybe turn it off? If I were you, I'd try to create a small separate project with has_cuda_gpu.c and check whether it compiles. If it doesn't, try the cmake mailing list. Simon On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > Thanks all for your responses to my question. I did not initially set > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > [ 24%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > for reading. > > > [ 25%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > for reading. > > As I said in my original post, we have CUDA installed on the system (cluster > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > cards would work well although I haven't confirmed that. > > -howard > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit > wrote: >> >> Actually no, librtkcuda is compiled if the cuda library is available >> but the applications are compiled if the cuda library AND a cuda >> compatible device are available... That's probably why you observe >> this. >> Simon >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> wrote: >> > To follow up, what do you mean by "no cuda applications were generated"? >> > If >> > you have the libraries compiled that means CMake found a working CUDA >> > compatible device. >> > >> > -Julien >> > >> > >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> Hi, >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> applications. So there must be an issue with your graphic card. Check >> >> if you can compile and run has_cuda_gpu.c. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >>> >> >>> HI, >> >>> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >> >>> installed on our system. I set the following in ccmake >> >>> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >>> RTK_USE_CUDA ON >> >>> >> >>> I could build but no cuda applications were generated. In the bin >> >>> folder >> >>> I >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >>> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >>> >> >>> -howard >> >>> >> >>> _______________________________________________ >> >>> Rtk-users mailing list >> >>> Rtk-users at public.kitware.com >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >>> >> >> _______________________________________________ >> >> Rtk-users mailing list >> >> Rtk-users at public.kitware.com >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > > > From lomahu at gmail.com Thu Feb 12 13:37:39 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 13:37:39 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: When I did the following: CUDA_HAVE_GPU ON CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) building was successful. I could run rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk using cuda?) with successful reconstruction. It's done in < 15s, wow! A separate question: how to specify cuda for rtksart, rtkadmmwavelets, rtkadmmtotalvariations etc? Thanks, -howard On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit wrote: > That's more complicated. First, CUDA_HAVE_GPU is normally turned on > automatically but maybe it's been turned off due to the problem you're > encountering now. > The problem you have is probably not specific to RTK, we don't develop > FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an > option CUDA_BUILD_CUBIN, maybe turn it off? > If I were you, I'd try to create a small separate project with > has_cuda_gpu.c and check whether it compiles. If it doesn't, try the > cmake mailing list. > Simon > > On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > > Thanks all for your responses to my question. I did not initially set > > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > > > > [ 24%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > > for reading. > > > > > > [ 25%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > > for reading. > > > > As I said in my original post, we have CUDA installed on the system > (cluster > > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > > cards would work well although I haven't confirmed that. > > > > -howard > > > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > wrote: > >> > >> Actually no, librtkcuda is compiled if the cuda library is available > >> but the applications are compiled if the cuda library AND a cuda > >> compatible device are available... That's probably why you observe > >> this. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > >> wrote: > >> > To follow up, what do you mean by "no cuda applications were > generated"? > >> > If > >> > you have the libraries compiled that means CMake found a working CUDA > >> > compatible device. > >> > > >> > -Julien > >> > > >> > > >> > On 12/02/2015 17:16, Simon Rit wrote: > >> >> > >> >> Hi, > >> >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> >> applications. So there must be an issue with your graphic card. Check > >> >> if you can compile and run has_cuda_gpu.c. > >> >> Simon > >> >> > >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >> >>> > >> >>> HI, > >> >>> > >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 > was > >> >>> installed on our system. I set the following in ccmake > >> >>> > >> >>> CUDA_64_BIT_DEVICE_CODE ON > >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >> >>> RTK_USE_CUDA ON > >> >>> > >> >>> I could build but no cuda applications were generated. In the bin > >> >>> folder > >> >>> I > >> >>> saw libITKCudaCommon.a and librtkcuda.a. > >> >>> > >> >>> What did I miss? Anybody could shed light on this? Thanks, > >> >>> > >> >>> -howard > >> >>> > >> >>> _______________________________________________ > >> >>> Rtk-users mailing list > >> >>> Rtk-users at public.kitware.com > >> >>> http://public.kitware.com/mailman/listinfo/rtk-users > >> >>> > >> >> _______________________________________________ > >> >> Rtk-users mailing list > >> >> Rtk-users at public.kitware.com > >> >> http://public.kitware.com/mailman/listinfo/rtk-users > >> >> > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 13:47:54 2015 From: theday79 at gmail.com (Yang-Kyun Park) Date: Thu, 12 Feb 2015 13:47:54 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: hi howard, use following options for fwd and bkward projection --fp CudaRayCast --bp CudaVoxelBased Yang On Feb 12, 2015 1:37 PM, "Howard" wrote: > When I did the following: > > CUDA_HAVE_GPU ON > CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) > CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) > > building was successful. I could run > > rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk > using cuda?) > > with successful reconstruction. It's done in < 15s, wow! > > A separate question: how to specify cuda for rtksart, > rtkadmmwavelets, rtkadmmtotalvariations etc? > > Thanks, > -howard > > > > > > > > > > > On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> wrote: > >> That's more complicated. First, CUDA_HAVE_GPU is normally turned on >> automatically but maybe it's been turned off due to the problem you're >> encountering now. >> The problem you have is probably not specific to RTK, we don't develop >> FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an >> option CUDA_BUILD_CUBIN, maybe turn it off? >> If I were you, I'd try to create a small separate project with >> has_cuda_gpu.c and check whether it compiles. If it doesn't, try the >> cmake mailing list. >> Simon >> >> On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: >> > Thanks all for your responses to my question. I did not initially set >> > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: >> > >> > >> > [ 24%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > >> > [ 25%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > As I said in my original post, we have CUDA installed on the system >> (cluster >> > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are >> > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume >> the >> > cards would work well although I haven't confirmed that. >> > >> > -howard >> > >> > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> > wrote: >> >> >> >> Actually no, librtkcuda is compiled if the cuda library is available >> >> but the applications are compiled if the cuda library AND a cuda >> >> compatible device are available... That's probably why you observe >> >> this. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> >> wrote: >> >> > To follow up, what do you mean by "no cuda applications were >> generated"? >> >> > If >> >> > you have the libraries compiled that means CMake found a working CUDA >> >> > compatible device. >> >> > >> >> > -Julien >> >> > >> >> > >> >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> >> >> Hi, >> >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> >> applications. So there must be an issue with your graphic card. >> Check >> >> >> if you can compile and run has_cuda_gpu.c. >> >> >> Simon >> >> >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >> >>> >> >> >>> HI, >> >> >>> >> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 >> was >> >> >>> installed on our system. I set the following in ccmake >> >> >>> >> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >> >>> RTK_USE_CUDA ON >> >> >>> >> >> >>> I could build but no cuda applications were generated. In the bin >> >> >>> folder >> >> >>> I >> >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >> >>> >> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >> >>> >> >> >>> -howard >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Rtk-users mailing list >> >> >>> Rtk-users at public.kitware.com >> >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >>> >> >> >> _______________________________________________ >> >> >> Rtk-users mailing list >> >> >> Rtk-users at public.kitware.com >> >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> >> >> > >> > >> > >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 13 07:06:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Feb 2015 13:06:34 +0100 Subject: [Rtk-users] ADMMTVReconstruction In-Reply-To: <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> References: <548EA4E1.4090801@creatis.insa-lyon.fr> <54919EE9.3010406@creatis.insa-lyon.fr> <5492A8BB.2030209@creatis.insa-lyon.fr> <000901d02a50$1c14f470$543edd50$@uclouvain.be> <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> Message-ID: Hi, FYI, S?bastien and I have worked on the pipeline that was mentionned in this discussion. The pipeline is now available in the rtkProjectionsReader (see the diagram in the doc ). Every rtk application can use it from command line options. For example, I0 is automatically estimated if the option --i0=0 is used. Don't hesitate to report what is not clear or not working for you. Simon On Thu, Jan 8, 2015 at 4:04 PM, S?bastien Brousmiche < sebastien.brousmiche at uclouvain.be> wrote: > Hi Howard, > > > > Actually there are three values given per projection: I0, a filtered I0 > (RLS) and the FWHM of the background mode. > > You can just use the first value per projection. If ?output? is the buffer > contained in the file (-d) then use I0 = buffer(1:3:end); > > > > Read rtki0estimation.cxx in the application folder for more information. > I?m planning to add more info in the code later. > > > > Best, > > S?bastien > > > > > > *From:* Howard [mailto:lomahu at gmail.com] > *Sent:* jeudi 8 janvier 2015 15:57 > *To:* S?bastien Brousmiche > *Cc:* Simon Rit; rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Hi Sebastien, > > > > Thank you very much for your explanation. I used -d to write I0 > estimations to a file. I found there are >2000 numbers for ~600 > projections. I thought there would be one number for each projection, but > obviously the output numbers are not generated that way. Could you please > describe a bit more on the file format and how to use them? Or simply I > wait for your new mini-pipeline filter? > > > > Regards, > > -howard > > > > On Wed, Jan 7, 2015 at 3:01 AM, S?bastien Brousmiche < > sebastien.brousmiche at uclouvain.be> wrote: > > Hi Howard, > > > > There is an input parameter with the rtki0estimation application (-d) > which allows you to specify the output file with I0 estimates. > > > > The big file you mentioned contains the histograms of each image (65536 > values each) stored consecutively. The first value is the occurrence of > number 0 in your image, second.. 1 and so forth up to 65535. > > > > This application is not particularly interesting to be used in a pipeline. > > > > > Nevertheless, we are developing a mini-pipeline grouping typical > preprocessing filters. It is under validation and I?ll let you know as soon > as it is available for you. > > > > Best, > > S?bastien > > > > > > > > > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Howard > *Sent:* mercredi 7 janvier 2015 00:17 > *To:* Simon Rit > *Cc:* rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Happy New Year, Simon. > > > > Thank you for pointing to me the I0 estimate procedure.I saw an > application rtki0estimation > > under the Applications folder. Is this the tool you meant? I ran it using > all default parameters > > providing with the original projection data. What I obtained was a file: > i0est_histogram.csv. > > From the comments in rtki0estimation.ggo this file is the output with I0 > estimate. For 650 projections > > the file size is around 200MB. I used excel to open the file and found > that the beginning two numbers > > 64408 and 722024 then followed by 0's. In the middle there are some > nonzero numbers. Essentially > > all zeros. > > Since there is not much description of the application, so it is hard to > figure out easily what I am doing. > > I tried to read the source code, but it might be more useful if you can > give some hints on how to > > use it. > > > > Regards, > > -howard > > > > > > On Mon, Jan 5, 2015 at 1:49 AM, Simon Rit > wrote: > > Happy new year Howard, > Normally, this calibration is handled by the flat panel. It uses an > air projection and a dark (no beam) projection to compute the line > integral. However, there might be fluctuations in time of these two > projections. Some people do regular acquisitions of them to capture > the time fluctuations. Otherwise, a constant value might be a good > solution. S?bastien has recently implemented an automated > determination of this constant, maybe you should have a look: > > http://www.openrtk.org/Doxygen/classrtk_1_1I0EstimationProjectionFilter.html > It is already part of the mini-pipeline for ImagX / IBA projections > processing: > > http://www.openrtk.org/Doxygen/classrtk_1_1ImagXRawToAttenuationImageFilter.html > Simon > > > On Fri, Jan 2, 2015 at 10:17 PM, Howard wrote: > > Happy New Year, Cyril. > > > > I realized that our projection data is having some issues with air > > correction. We checked our calibration and it appeared fine. Do you know > by > > any chance whether there is a quick way of correcting that? I searched > > around and found people used a constant air norm image. > > > > Thanks very much, > > -howard > > > > On Thu, Dec 18, 2014 at 5:13 AM, Cyril Mory > > wrote: > >> > >> Hi Howard, > >> > >> I've taken a look at your data. > >> You can apply tv denoising on the out.mha volume and obtain a > >> significantly lower level of noise without blurring structures by using > the > >> following command : > >> rtktotalvariationdenoising -i out.mha -g 0.001 -o > >> tvdenoised/gamma0.001.mha -n 100 > >> > >> I was unable to obtain good results with iterative reconstruction from > the > >> projection data you sent, though. I think the main reason for this is > that > >> your projections have much-higher-than-zero attenuation in air. Your > >> calculation of i0 when converting from intensity to attenuation is > probably > >> not good enough. Try to correct for this effect first. Then you can > start > >> performing SART and Conjugate Gradient reconstructions on your data, and > >> once you get these right, play with ADMM. > >> > >> You might need to remove the table from the projections to be able to > >> restrict the reconstruction volume strictly to the patient, and speed > up the > >> computations. We can provide help for that too. > >> > >> Best regards, > >> Cyril > >> > >> > >> On 12/17/2014 05:02 PM, Howard wrote: > >> > >> Hi Cyril, > >> > >> I've sent you two files via wetransfer.com: one is the sparse > projection > >> set with geometry file and the other is the fdk reconstructed image > based on > >> full projection set. Please let me know if you have trouble receiving > them. > >> > >> Thanks very much for looking into this. > >> > >> -Howard > >> > >> On Wed, Dec 17, 2014 at 10:19 AM, Cyril Mory > >> wrote: > >>> > >>> Hi Howard, > >>> > >>> Thanks for the detailed feedback. > >>> The image getting blurry is typically due to a too high gamma. > Depending > >>> on you data, gamma can have to be set to a very small value (I use > 0.007 in > >>> some reconstructions on clinical data). Can you send over your volume > >>> reconstructed from full projection data, and I'll have a quick look ? > >>> > >>> There is a lot of instinct in the setting of the parameters. With time, > >>> one gets used to finding a correct set of parameters without really > knowing > >>> how. I can also try to reconstruct from your cbct data if you send me > the > >>> projections and the geometry. > >>> > >>> Best regards, > >>> Cyril > >>> > >>> > >>> On 12/17/2014 03:49 PM, Howard wrote: > >>> > >>> Hi Cyril, > >>> > >>> Thanks very much for your detailed and nice description on how to use > the > >>> admmtv reconstruction. I followed your suggestions and re-ran > >>> reconstructions using admmtotalvariation and admmwavelets with cbct > >>> projection data from a thoracic patient. > >>> > >>> I am reporting what I found and hope these will give you information > for > >>> further improvement. > >>> > >>> 1. I repeated admmtotalvariation with 30 iterations. No improvement was > >>> observed. As a matter of fact, the reconstructed image is getting a lot > >>> noiser compared to that using 3 iterations. The contrast is getting > worse as > >>> well. I tried to play around with window & level in case I was fooled > but > >>> apparently more iterations gave worse results. > >>> > >>> 2. Similarly I ran 30 iterations using admmwavelets. Slightly better > >>> reconstruction compared with total variation. > >>> > >>> 3. Then I went ahead to test if TV benefits us anything using the > >>> tvdenoising application on the fdk-reconstructed image reconstructed > from > >>> full projection set. I found that the more iterations, the more blurry > the > >>> image became. For example, with 50 iterations the contrast on the > denoised > >>> image is very low so that the vertebrae and surrounding soft tissue are > >>> hardly distinguishable. Changing gamma's at 0.2, 0.5, 1.0, 10 did not > seem > >>> to make a difference on the image. With 5 iterations the denoising > seems to > >>> work fairly well. Again, changing gamma's didn't make a difference. > >>> I hope I didn't misused the totalvariationdenoising application. The > >>> command I executed was: rtktotalvariationdenoising -i out.mha -o > >>> out_denoising_n50_gamma05 --gamma 0.5 -n 50 > >>> > >>> In summary, tdmmwavelets seems perform better than tdmmtotalvariation > but > >>> neither gave satisfactory results. No sure what we can infer from the > TV > >>> denoising study. I could send my study to you if there is a need. > Please let > >>> me know what tests I could run. Further help on improvement is > definitely > >>> welcome and appreciated. > >>> > >>> -Howard > >>> > >>> On Mon, Dec 15, 2014 at 4:07 AM, Cyril Mory > >>> wrote: > >>>> > >>>> Hello Howard, > >>>> > >>>> Good to hear that you're using RTK :) > >>>> I'll try to answer all your questions, and give you some advice: > >>>> - In general, you can expect some improvement over rtkfdk, but not a > >>>> huge one > >>>> - You can find the calculations in my PhD thesis > >>>> https://tel.archives-ouvertes.fr/tel-00985728 (in English. Only the > >>>> introduction is in French) > >>>> - Adjusting the parameters is, in itself, a research topic (sorry !). > >>>> Alpha controls the amount of regularization and only that (the > higher, the > >>>> more regularization). Beta, theoretically, should only change the > >>>> convergence speed, provided you do an infinite number of iterations > (I know > >>>> it doesn't help, sorry again !). In practice, beta is ubiquitous and > appears > >>>> everywhere in the calculations, therefore it is hard to predict what > effect > >>>> an increase/decrease of beta will give on the images. I would keep it > as is, > >>>> and play on alpha > >>>> - 3 iterations is way too little. I typically used 30 iterations. > Using > >>>> the CUDA forward and back projectors helped a lot maintain the > computation > >>>> time manageable > >>>> - The quality of the results depends a lot on the nature of the image > >>>> you are trying to reconstruct. In a nutshell, the algorithm assumes > that the > >>>> image you are reconstructing has a certain form of regularity, and > discards > >>>> the potential solutions that do not have it. This assumption partly > >>>> compensates for the lack of data. ADMM TV assumes that the image you > are > >>>> reconstructing is piecewise constant, i.e. has large uniform areas > separated > >>>> by sharp borders. If your image is a phantom, it should give good > results. > >>>> If it is a real patient, you should probably change to another > algorithm > >>>> that assumes another form of regularity in the images (try > rtkadmmwavelets) > >>>> - You can find out whether you typical images can benefit from TV > >>>> regularization by reconstructing from all projections with rtkfdk, > then > >>>> applying rtktotalvariationdenoising on the reconstructed volume (try > 50 > >>>> iterations and adjust the gamma parameter: high gamma means high > >>>> regularization). If this denoising implies an unacceptable loss of > quality, > >>>> stay away from TV for these images, and try wavelets > >>>> > >>>> I hope this helps > >>>> > >>>> Looking forward to reading you again, > >>>> Cyril > >>>> > >>>> > >>>> On 12/12/2014 06:42 PM, Howard wrote: > >>>> > >>>> I am testing the ADMM total variation reconstruction with sparse data > >>>> sample. I could reconstruct but the results were not as good as > expected. In > >>>> other words, it didn't show much improvement compared to fdk > reconstruction > >>>> using the same sparse projection data. > >>>> > >>>> The parameters I used in ADMMTV were the following: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --alpha 1 --beta 1000 -n 3 > >>>> > >>>> while the fdk reconstruction parameters are: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --pad 0.1 --hann 0.5 > >>>> > >>>> The dimensions were chosen to include the entire anatomy. 72 > projections > >>>> were selected out of 646 projections for a 360 degree scan for both > >>>> calculations. > >>>> > >>>> What parameters and how can I adjust (like alpha, beta, or > iterations?) > >>>> to improve the ADMMTV reconstruction? There is not much description > of this > >>>> application from the wiki page. > >>>> > >>>> Thanks, > >>>> > >>>> -howard > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Rtk-users mailing list > >>>> Rtk-users at public.kitware.com > >>>> http://public.kitware.com/mailman/listinfo/rtk-users > >>>> > >>>> > >>>> -- > >>>> -- > >>>> Cyril Mory, Post-doc > >>>> CREATIS > >>>> Leon Berard cancer treatment center > >>>> 28 rue La?nnec > >>>> 69373 Lyon cedex 08 FRANCE > >>>> > >>>> Mobile: +33 6 69 46 73 79 > >>> > >>> > >>> -- > >>> -- > >>> Cyril Mory, Post-doc > >>> CREATIS > >>> Leon Berard cancer treatment center > >>> 28 rue La?nnec > >>> 69373 Lyon cedex 08 FRANCE > >>> > >>> Mobile: +33 6 69 46 73 79 > >> > >> > >> -- > >> -- > >> Cyril Mory, Post-doc > >> CREATIS > >> Leon Berard cancer treatment center > >> 28 rue La?nnec > >> 69373 Lyon cedex 08 FRANCE > >> > >> Mobile: +33 6 69 46 73 79 > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > > > > > ------------------------------ > > [image: Image removed by sender.] > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > > > > > > ------------------------------ > > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: not available URL: From Robert.Calliess at gmx.de Tue Feb 24 03:56:15 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 24 Feb 2015 09:56:15 +0100 Subject: [Rtk-users] sart back projection, weighting steps Message-ID: An HTML attachment was scrubbed... URL: From cyril.mory at creatis.insa-lyon.fr Tue Feb 24 04:55:00 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Tue, 24 Feb 2015 10:55:00 +0100 Subject: [Rtk-users] sart back projection, weighting steps In-Reply-To: References: Message-ID: <54EC4A74.2010601@creatis.insa-lyon.fr> Hi Robert, I'm glad to know that most of the explanation text is understandable :) You might want to check this filter: http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html You can use the command line application "rtkbackprojections" with argument --bp to compare "Joseph" and "NormalizedJoseph". When performing a back projection with non-normalized Joseph, the projection values are "splat" (splat is the adjoint operator of interpolation) between the four nearest voxels in each volume plane the ray intersects. Nothing guarantees that every voxel will receive a contribution during this process. How many contributions a voxel receives is determined by the sampling of the projections, which can be much looser or much denser (locally and globally) than what would be required. Dividing by the back projection of an image of ones mitigates this effect. In theory, as long as the forward and back projection operators are the adjoint of one another, it should not be a problem for SART. In practice, it does make a difference. I hope it helps. Please let me know if it is still unclear; Cyril On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward projection, > every pixel is > divided by the intersection length of the ray with the volume. That is > clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This weighting > step is not > performed when using a voxel-based back projection, as the weights > are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all pixels > have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply this > weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate the > pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range from 0 > to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Thu Feb 26 14:35:06 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Thu, 26 Feb 2015 19:35:06 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely,Vahid? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Thu Feb 26 15:18:53 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Thu, 26 Feb 2015 21:18:53 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Message-ID: <00d901d05201$71a49200$54edb600$@gmx.de> Hello Vahid, I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI but with a wider sensor array. I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code. But let?s see what grandmasters of RTK will suggest. Best regards, Robert Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely, Vahid -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Thu Feb 26 16:33:46 2015 From: ghostcz at hotmail.com (louie L) Date: Thu, 26 Feb 2015 22:33:46 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <00d901d05201$71a49200$54edb600$@gmx.de> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work. Best regards, Louie Greetings from my iOS! > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the > resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). > I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around > the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these > seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI > but with a wider sensor array. > > I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it > would be possible to model the helical trajectory by the changing geometry without changing /adding code. > > But let?s see what grandmasters of RTK will suggest. > > Best regards, > Robert > > > Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users > Gesendet: Donnerstag, 26. Februar 2015 20:35 > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK > > Dear RTK users, > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? > I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. > > Sincerely, > Vahid > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From cyril.mory at creatis.insa-lyon.fr Fri Feb 27 03:45:24 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Fri, 27 Feb 2015 09:45:24 +0100 Subject: [Rtk-users] Fwd: Re: Aw: Re: sart back projection, weighting steps In-Reply-To: <54F02E7E.7080000@creatis.insa-lyon.fr> References: <54F02E7E.7080000@creatis.insa-lyon.fr> Message-ID: <54F02EA4.7010006@creatis.insa-lyon.fr> Hi Robert, No problem, glad to help. I think either I have'nt been clear enough, or you're getting confused, though :) Let me try again: In joseph back projection, for each PIXEL, you "draw a line" between the source and the pixel's center, and see which voxels it crosses. Your line crosses each slice of the volume at an intersection point. You determine what the interpolation weights would be if you were to interpolate at this intersection point. And these weights are indeed between 0 and 1. But instead of interpolating, you "splat", that means you update the four nearest voxels by adding (projection's pixel value * interpolationWeight) to each. And you move to the next slice. Once you've considered all rays, you're done. Nothing in this process guarantees that a voxel will receive any contribution. In fact, some receive none, and some too many. The backprojected volume you obtain is "biased". You could think of it as the product of what you really want (the projection's pixel values smeared out along the lines of rays) with a "sampling density map" (the cumulated splat weights each voxel has been updated with). If you back project a projection of ones, then your resulting volume is exactly this sampling density map, and you can divide by it to obtain what you really want. In voxel based back projection, for each voxel, you "draw a line" between the source and the voxel's center, see where it hits the 2D projection, and add the value of that pixel (or interpolated at this position between pixels) into the voxel. And that's it for this voxel, so each voxel gets updated once and only once. And if the projection contains only ones, then your volume gets filled with ones. Dividing by one isn't going to change anything, so you just don't do it. I hope it is clearer. Cyril On 02/26/2015 02:10 PM, "Robert Callie?" wrote: > Hello Cyril, > thank you for the fast reply and thank you for the support. > Indeed I have some more questions. For the normalization step > you on the one hand side create a projection image filled with "1" > and on the other hand side you create an empty (zero) volume and > then back project the image, ok. > >>How many contributions a voxel receives is determined by the > sampling of the projections > Yes, I have the same problems with a voxel-based back projector. But > don't you have > this problem also with joseph's method when you use it for the back > projection of the "1" projection > image ? It's not clear to me how this kind of back projection actually > works (or is calculated). > And if the projection image consists of pixels with value "1" then we > actually don't need it or do we ? > So far I understand, no matter if we perform the forward or back > projtion, the joseph projector calculates > the weightings of the four voxels that are "around" the current plane > intersection point. And this > weights are always between 0 and 1. > Or do I totally misunderstand the concept of this backprojection. > I hope I did not confused you. > best regards, > Robert > *Gesendet:* Dienstag, 24. Februar 2015 um 10:55 Uhr > *Von:* "Cyril Mory" > *An:* "Robert Callie?" , rtk-users at openrtk.org > *Betreff:* Re: [Rtk-users] sart back projection, weighting steps > Hi Robert, > > I'm glad to know that most of the explanation text is understandable :) > You might want to check this filter: > http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html > You can use the command line application "rtkbackprojections" with > argument --bp to compare "Joseph" and "NormalizedJoseph". > > When performing a back projection with non-normalized Joseph, the > projection values are "splat" (splat is the adjoint operator of > interpolation) between the four nearest voxels in each volume plane > the ray intersects. Nothing guarantees that every voxel will receive a > contribution during this process. How many contributions a voxel > receives is determined by the sampling of the projections, which can > be much looser or much denser (locally and globally) than what would > be required. Dividing by the back projection of an image of ones > mitigates this effect. In theory, as long as the forward and back > projection operators are the adjoint of one another, it should not be > a problem for SART. In practice, it does make a difference. > > I hope it helps. Please let me know if it is still unclear; > > Cyril > On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward > projection, every pixel is > divided by the intersection length of the ray with the volume. > That is clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This > weighting step is not > performed when using a voxel-based back projection, as the > weights are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all > pixels have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply > this weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate > the pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range > from 0 to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually > happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 27 04:42:38 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 27 Feb 2015 10:42:38 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry . I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: > Hi, > > You can change the geometry. If changed correctly, most, if not all, the > iterative cone beam reconstruction will work. > > Best regards, > Louie > > Greetings from my iOS! > > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > > I think you need to add a new reconstruction filter for it. For the first > projection the object usually is placed so that the > > resulting projection image covers the upper half of the detector. And you > will need some additional handling (z-increment). > > I guess you could do a little work around with the current rtk. If you > only reconstruct an rectangular roi around > > the detector?s center where the perspective distortion (because of the > cone) is minimal. And then you add these > > seperate volumes to a final volume. This is just an idea. I do not know > how the result will look like. Think of it like a TDI > > but with a wider sensor array. > > > > I do not know the code in detail, but if it were possible to have seperate > geometry settings for every projection image it > > would be possible to model the helical trajectory by the changing geometry > without changing /adding code. > > > > But let?s see what grandmasters of RTK will suggest. > > > > Best regards, > > Robert > > > > > > *Von:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *Im Auftrag von *vahid ettehadi > via Rtk-users > *Gesendet:* Donnerstag, 26. Februar 2015 20:35 > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] Helical cone-beam reconstruction with RTK > > > > Dear RTK users, > > > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT > in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > > I would like to change the current source trajectory from circular to > helical. I was wondering is it possible to use the RTK for helical > reconstruction only with some simple modification? > > I don't know well about reconstruction process and I don't know which type > of modification is necessary to use RTK for a helical cone beam geometry. > So, any suggestion and recommendation would be appreciated. > > > > Sincerely, > > Vahid > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Fri Feb 27 14:24:14 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Fri, 27 Feb 2015 19:24:14 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: Message-ID: <47007992.1342548.1425065054134.JavaMail.yahoo@mail.yahoo.com> Hello,Thank you Robert, Louie and Simon, for your tips and recommendations. I will work on it and I will share the result or potential problems. I found the RTK more accurate and easy to use in compare with other open-source reconstruction tools such as Oscar and NiftyRec.? Thank you RTK team!Vahid On Friday, February 27, 2015 4:42 AM, Simon Rit wrote: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry. I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work.? Best regards,Louie Greetings from my iOS! On 26 Feb 2015, at 21:19, Robert Callie? wrote: Hello Vahid,I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that theresulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment).I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi aroundthe detector?s center where the perspective distortion (because of the cone) is minimal. And then you add theseseperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDIbut with a wider sensor array.?I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code.?But let?s see what grandmasters of RTK will suggest.?Best regards,Robert??????????????? ?Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK?Dear RTK users,??I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated.?Sincerely,Vahid?? _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Sun Feb 1 04:41:03 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 1 Feb 2015 10:41:03 +0100 Subject: [Rtk-users] RTK In-Reply-To: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> References: <000f01d03c6d$d9897330$8c9c5990$@gmx.de> Message-ID: On Fri, Jan 30, 2015 at 10:19 AM, Robert Callie? wrote: > Hello Simon, > > thank you for the fast reply. > > > > ?Joseph's method samples the ray with one pixel per slice in the main > direction but it does not compute the intersection of the ray with each > voxel. Siddon's method does that. In fig 2 of [Xu and Mueller, 2006], Joseph > is referred to "slice interpolated" and Siddon to "box-line-integrated". > OK, thanks for that hint. I think it will maybe also has the same problem > with divergent rays and missing voxels during the reconstruction. Do you For sure. > have a link to a paper or source to this algorithm. So the algorithm may > work > > As following: > > - calculate intersection with the physical bounding volume (entry > exit points) > > - from entrypoint, determine the 4 voxels that surround this > entrypoint and bilinear interpolate the value at this position and sum it up > > - go to next plane (plane that is most ?perpendicular? to the > current center ray (focus to detector center) ? > > - at the end, the sum is normalized by the ray length ? > (length(exitpoint ? entrypoint)) > > Is that right ? Almost. Maybe I misunderstand your last step but it is actually multiplied by each step length. Normalization occurs during backprojection, not during forward projection. > > > > How can Joseph?s method be used for back projection ? If you write the method as a system matrix, simply take the transpose of it. For (S)ART, you will want to divide by the sum of the weights along one ray which is exactly what you mentionned, the ray length. > > > > ?This sounds very interesting, don't hesitate to share the code and/or the > publication! BTW, what is DDA? > > DDA stands for digital differential analyzer. I use this approach for a > voxel-based forward projector. When I started my project I was looking for a > fast and easy forward projector on voxel basis. > > I found an article about raytracing and acceleration structures where these > people used this 3d dda. They actually needed it to traverse the bounding > hierarchy to get to know what geometry > > the ray intersects with. I slightly modified it to get the intersecetion > length of a ray within a voxel by substraction of the current and previous > step width. I?v attached a zip file that contains this > > modification and the original source code. The original source code is from > www.scratchapixel.com and there is also an article about this topic > (http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-12-introduction-to-acceleration-structures/what-else/). Great, thanks. We'll have a look. Do you distribute this under a specific license? In other words, is there a risk that it would conflict with RTK license? (Apache 2, see website). > > If you have a look at my code you?ll maybe miss some matrix calculation > stuff etc. I use a scene based approach where I place the focus, object and > detector in a so called record. Each record represents the scene geometry at > a certain time, when a projection image was taken. > > Before reconstruction starts I calculate all these positions. I thought this > could be a good approach to decouple the actuall reconstruction algorithm > from the scene geometry. We'll let you know when we look at it if we have questions. > > > > > > ?But generally we use matching resolution between pixels and voxels so the > problem is minimal.? > > Do you mean, that you use a volume resolution that fits to the current > geometry setting and the detector?s pixel resolution ? Yes. > > > > ?Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > Not almost the same. What I mean seems to be simplier. Lets assume the > detector has tilted around the x-axis by 0.25 degrees. The object?s center > is at 0,0,0 and rotation axis is 0,1,0. In FDK you usually got a ray from > source to the voxel center and then you calculate > > the intersection of this ray at the detector plane. To avoid ray plane > intersection calculus, we can rotate the whole system by 0.25 degrees. Means > that the detectors normal now is parallel to the z axis.Of course the > rotation axis is not 0,1,0 any longer and the focus (xray source) > > also is a bit rotated. > > > > ?For the backprojection, we typically used voxel-based backprojection using > the center of the voxel which is faster than what you (seem to) use? > > I think here we mixed something up. This type of back projection is used for > FDK. All my questions were related to S-ART. I need to calculate the weights > > of a voxel for the back projection. To speed it up, I project its vertices > on the detector plane, calc the MEB and the send rays from within this MEB > through the > > voxel and caluclate the intersection length so those rays that will make my > weights. Some people argue that you can use the same backprojection as in FDK to speed up computations. See for example http://www.researchgate.net/profile/Gengsheng_Zeng/publication/12301525_Unmatched_projectorbackprojector_pairs_in_an_iterative_reconstruction_algorithm/links/00b495252b15fc4bb9000000.pdf > > > > > > Best regards, > > Robert > > > > > > P.S. Hello to all the other people here in the mailing list. > > > > > > Von: simon.rit at gmail.com [mailto:simon.rit at gmail.com] Im Auftrag von Simon > Rit > Gesendet: Donnerstag, 29. Januar 2015 20:58 > An: Robert Callie? > Cc: rtk-users at openrtk.org > Betreff: Re: RTK > > > > Hi, > Thank you for your interest in RTK. Please use the mailing list for > questions that are of interest to anyone using RTK. > > There are many ways to model the direct problem (forward projection). > Without going into too many details (available in the publications of each > method) : > - "As far as I understand the goal of this approach is to calculate the > intersection length of a ray through a voxel, right ?" False. Joseph's > method samples the ray with one pixel per slice in the main direction but it > does not compute the intersection of the ray with each voxel. Siddon's > method does that. In fig 2 of [Xu and Mueller, 2006], Joseph is referred to > "slice interpolated" and Siddon to "box-line-integrated". > - "I can calculate the intersection length of the ray within a voxel by a > simple substraction, this runs very fast." This sounds very interesting, > don't hesitate to share the code and/or the publication! BTW, what is DDA? > > - Small voxels / pixels, "Did you find a way to handle this ? " We don't > handle this in RTK except if you consider that spatial regularisation (e.g., > total variation) will overcome this problem in a way. But generally we use > matching resolution between pixels and voxels so the problem is minimal. For > the backprojection, we typically used voxel-based backprojection using the > center of the voxel which is faster than what you (seem to) use. I think > that if these things are a problem for you, there is a nice solution called > distance driven (back-)projection (by De Man and Basu). I think it will do > exactly what you want. I haven't implemented it in RTK (yet). > > Thanks for the last trick, I am aware of it (Riddell published it calling > this "Rectification"), I'm not sure that would change the computation time > by a large factor but I should check. I think you then need an additional > interpolation no to resample the "moved" object, no? > > I hope this helps. Let me know if sg is not clear in my answer! > Cheers, > Simon From riblettmj at mymail.vcu.edu Mon Feb 2 12:03:14 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 12:03:14 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF Message-ID: Hello RTK Users, I?m just getting started using RTK as part of my graduate research and was hoping that someone might be able to help me sort out an issue I?ve been having reconstructing a 3D CBCT image dataset while applying a 4D deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF has been generated by transformix (.mhd format). I followed, for the most part, the MCCBCTReconstruction example on the RTK Wiki. While reconstructing, rtkfdk reads in all of the projections to memory, begins the ?Reconstructing and Writing? phase and proceeds for a few seconds before hanging ? it doesn?t exit or fault, just drops to 0% CPU while retaining the projections in memory. By writing some basic debug messages into the source code, I?ve been able to determine that the issue lies somewhere at m_Deformation->Update() [Line 99 of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 makes it past the m_Deformation->SetFrame(iProj) line, but never makes it past the subsequent update. I?m wondering if this has anything to do with the size of the DVF generated by transformix: approximately 4.0GB (512x100x512x10 image, 4-channels, FLOAT). Just to provide a little more background information, I?m running RTK on a 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of memory running Ubuntu 14.04. RTK was built using the default ?Release? make configuration and linked to ITK 4.5.2. Elastix and Transformix are both the latest version, 4.7. Has anyone else run into a similar issue with reconstructing a similar image, or does anyone have any thoughts as to how to resolve this sort of issue? Thanks in advance! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 2 12:19:53 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 2 Feb 2015 18:19:53 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: Hi, You're the first RTK user I know to use it on Sun! Nice! If you've got 64 GB ram, that should be enough... although you could ask elastix to generate a smaller DVF, RTK linearly interpolates between vectors. You could even use B-spline coeffs directly but you'd have to create a new DVF. My guess is that there is a problem with the initialization of m_Deformation since the line you mention is the first time it's ever used in the class. Do you use the rtkfdk app? I would start by checking that the pointer is not null before this line, sg like: std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; If it equals 0, then there is something going with the deformation. You can check it in the main app, rtkfdk.cxx. Simon On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett wrote: > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From riblettmj at mymail.vcu.edu Mon Feb 2 13:44:54 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Mon, 2 Feb 2015 13:44:54 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: Message-ID: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Simon, I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the added debug line you suggested and it doesn?t look like the pointer is null. Running it through gdb, I got the following info: m_Deformation=0x16ff820 (gdb) x 0x16ff820 0x16ff820: 0x011c51d0 (gdb) x 0x011c51d0 0x11c51d0 <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: 0x005fb874 (gdb) x 0x005fb874 0x5fb874 , 3u> >::CreateAnother() const>: 0xe5894855 (gdb) x 0xe5894855 0xe5894855: Cannot access memory at address 0xe5894855 I?m still waiting on the transformix DVF, but I?ll give that a try too when its done. Thanks again! ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go ahead and check to see if the pointer is null and let you know. My current check is having transformix to generate a smaller DVF to see if that helps, so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > >> On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> > wrote: >>> Hello RTK Users, >>> >>> I?m just getting started using RTK as part of my graduate research and was >>> hoping that someone might be able to help me sort out an issue I?ve been >>> having reconstructing a 3D CBCT image dataset while applying a 4D >>> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >>> has been generated by transformix (.mhd format). I followed, for the most >>> part, the MCCBCTReconstruction example on the RTK Wiki. >>> >>> While reconstructing, rtkfdk reads in all of the projections to memory, >>> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >>> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >>> retaining the projections in memory. >>> >>> By writing some basic debug messages into the source code, I?ve been able to >>> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >>> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >>> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >>> past the subsequent update. I?m wondering if this has anything to do with >>> the size of the DVF generated by transformix: approximately 4.0GB >>> (512x100x512x10 image, 4-channels, FLOAT). >>> >>> Just to provide a little more background information, I?m running RTK on a >>> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >>> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >>> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >>> latest version, 4.7. >>> >>> Has anyone else run into a similar issue with reconstructing a similar >>> image, or does anyone have any thoughts as to how to resolve this sort of >>> issue? >>> >>> Thanks in advance! >>> >>> ? Matt >>> >>> __ >>> Matthew J. Riblett >>> Virginia Commonwealth University >>> Department of Radiation Oncology >>> Medical Physics Graduate Program >>> >>> Office: Sanger Hall, Room B1-013 >>> 401 College Street | P.O. Box 980058 >>> Richmond, Virginia 23298 >>> >>> VCU Email: riblettmj at vcu.edu >>> MCV Office Phone: +1.804.628.4858 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Feb 3 02:22:54 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Feb 2015 08:22:54 +0100 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: That's weird because SetFrame does nothing else than change the value of the member Frame. Are you sure it's on SetFrame that the crash occurs? On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett wrote: > Simon, > > I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the > added debug line you suggested and it doesn?t look like the pointer is null. > Running it through gdb, I got the following info: > > m_Deformation=0x16ff820 > > (gdb) x 0x16ff820 > 0x16ff820: 0x011c51d0 > (gdb) x 0x011c51d0 > 0x11c51d0 > <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: > 0x005fb874 > (gdb) x 0x005fb874 > 0x5fb874 3u>, 3u> >::CreateAnother() const>: 0xe5894855 > (gdb) x 0xe5894855 > 0xe5894855: Cannot access memory at address 0xe5894855 > > I?m still waiting on the transformix DVF, but I?ll give that a try too when > its done. > > Thanks again! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett > wrote: > > Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go > ahead and check to see if the pointer is null and let you know. My current > check is having transformix to generate a smaller DVF to see if that helps, > so the server is getting that done as we speak. > > You might also like to know that I?ve got RTK running on a Cray CX-1 (baby > supercomputer) sitting next to the aforementioned Sun x4600-M2. :) > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > On Feb 2, 2015, at 12:19 PM, Simon Rit > wrote: > > Hi, > You're the first RTK user I know to use it on Sun! Nice! > If you've got 64 GB ram, that should be enough... although you could > ask elastix to generate a smaller DVF, RTK linearly interpolates > between vectors. You could even use B-spline coeffs directly but you'd > have to create a new DVF. > My guess is that there is a problem with the initialization of > m_Deformation since the line you mention is the first time it's ever > used in the class. Do you use the rtkfdk app? I would start by > checking that the pointer is not null before this line, sg like: > std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; > If it equals 0, then there is something going with the deformation. > You can check it in the main app, rtkfdk.cxx. > Simon > > On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett > wrote: > > Hello RTK Users, > > I?m just getting started using RTK as part of my graduate research and was > hoping that someone might be able to help me sort out an issue I?ve been > having reconstructing a 3D CBCT image dataset while applying a 4D > deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF > has been generated by transformix (.mhd format). I followed, for the most > part, the MCCBCTReconstruction example on the RTK Wiki. > > While reconstructing, rtkfdk reads in all of the projections to memory, > begins the ?Reconstructing and Writing? phase and proceeds for a few seconds > before hanging ? it doesn?t exit or fault, just drops to 0% CPU while > retaining the projections in memory. > > By writing some basic debug messages into the source code, I?ve been able to > determine that the issue lies somewhere at m_Deformation->Update() [Line 99 > of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 > makes it past the m_Deformation->SetFrame(iProj) line, but never makes it > past the subsequent update. I?m wondering if this has anything to do with > the size of the DVF generated by transformix: approximately 4.0GB > (512x100x512x10 image, 4-channels, FLOAT). > > Just to provide a little more background information, I?m running RTK on a > 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of > memory running Ubuntu 14.04. RTK was built using the default ?Release? make > configuration and linked to ITK 4.5.2. Elastix and Transformix are both the > latest version, 4.7. > > Has anyone else run into a similar issue with reconstructing a similar > image, or does anyone have any thoughts as to how to resolve this sort of > issue? > > Thanks in advance! > > ? Matt > > __ > Matthew J. Riblett > Virginia Commonwealth University > Department of Radiation Oncology > Medical Physics Graduate Program > > Office: Sanger Hall, Room B1-013 > 401 College Street | P.O. Box 980058 > Richmond, Virginia 23298 > > VCU Email: riblettmj at vcu.edu > MCV Office Phone: +1.804.628.4858 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > From riblettmj at mymail.vcu.edu Tue Feb 3 10:36:03 2015 From: riblettmj at mymail.vcu.edu (Matthew J. Riblett) Date: Tue, 3 Feb 2015 10:36:03 -0500 Subject: [Rtk-users] Trouble Reconstructing 3D CBCT using 4D DVF In-Reply-To: References: <3C960C9E-9201-4B29-B1CF-5124266ABCDC@mymail.vcu.edu> Message-ID: <60DCF1BD-5960-4A62-AC13-42897049FDFF@mymail.vcu.edu> Simon, I think that it makes it past SetFrame and crashes on Update. Just to be sure, I put a debug message after SetFrame and it does make it to that point, so its got to be on the Update line. ? Matt __ Matthew J. Riblett Virginia Commonwealth University Department of Radiation Oncology Medical Physics Graduate Program Office: Sanger Hall, Room B1-013 401 College Street | P.O. Box 980058 Richmond, Virginia 23298 VCU Email: riblettmj at vcu.edu MCV Office Phone: +1.804.628.4858 > On Feb 3, 2015, at 2:22 AM, Simon Rit wrote: > > That's weird because SetFrame does nothing else than change the value > of the member Frame. Are you sure it's on SetFrame that the crash > occurs? > > On Mon, Feb 2, 2015 at 7:44 PM, Matthew J. Riblett > wrote: >> Simon, >> >> I rebuilt the rtkfdk app (actually all of RTK) in ?Debug? mode and with the >> added debug line you suggested and it doesn?t look like the pointer is null. >> Running it through gdb, I got the following info: >> >> m_Deformation=0x16ff820 >> >> (gdb) x 0x16ff820 >> 0x16ff820: 0x011c51d0 >> (gdb) x 0x011c51d0 >> 0x11c51d0 >> <_ZTVN3rtk28CyclicDeformationImageFilterIN3itk5ImageINS1_6VectorIfLj3EEELj3EEEEE+16>: >> 0x005fb874 >> (gdb) x 0x005fb874 >> 0x5fb874 > 3u>, 3u> >::CreateAnother() const>: 0xe5894855 >> (gdb) x 0xe5894855 >> 0xe5894855: Cannot access memory at address 0xe5894855 >> >> I?m still waiting on the transformix DVF, but I?ll give that a try too when >> its done. >> >> Thanks again! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 1:16 PM, Matthew J. Riblett >> wrote: >> >> Thanks for the quick reply Simon! I am using the rtkfdk app, and I will go >> ahead and check to see if the pointer is null and let you know. My current >> check is having transformix to generate a smaller DVF to see if that helps, >> so the server is getting that done as we speak. >> >> You might also like to know that I?ve got RTK running on a Cray CX-1 (baby >> supercomputer) sitting next to the aforementioned Sun x4600-M2. :) >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> On Feb 2, 2015, at 12:19 PM, Simon Rit >> wrote: >> >> Hi, >> You're the first RTK user I know to use it on Sun! Nice! >> If you've got 64 GB ram, that should be enough... although you could >> ask elastix to generate a smaller DVF, RTK linearly interpolates >> between vectors. You could even use B-spline coeffs directly but you'd >> have to create a new DVF. >> My guess is that there is a problem with the initialization of >> m_Deformation since the line you mention is the first time it's ever >> used in the class. Do you use the rtkfdk app? I would start by >> checking that the pointer is not null before this line, sg like: >> std::cout << "m_Deformation=" << m_Deformation.GetPointer() << std::endl; >> If it equals 0, then there is something going with the deformation. >> You can check it in the main app, rtkfdk.cxx. >> Simon >> >> On Mon, Feb 2, 2015 at 6:03 PM, Matthew J. Riblett >> wrote: >> >> Hello RTK Users, >> >> I?m just getting started using RTK as part of my graduate research and was >> hoping that someone might be able to help me sort out an issue I?ve been >> having reconstructing a 3D CBCT image dataset while applying a 4D >> deformation field ? I?m reconstructing with ~2400 projections and the 4D DVF >> has been generated by transformix (.mhd format). I followed, for the most >> part, the MCCBCTReconstruction example on the RTK Wiki. >> >> While reconstructing, rtkfdk reads in all of the projections to memory, >> begins the ?Reconstructing and Writing? phase and proceeds for a few seconds >> before hanging ? it doesn?t exit or fault, just drops to 0% CPU while >> retaining the projections in memory. >> >> By writing some basic debug messages into the source code, I?ve been able to >> determine that the issue lies somewhere at m_Deformation->Update() [Line 99 >> of code/rtkFDKWarpBackProjectionImageFilter.txx]. It appears that thread 0 >> makes it past the m_Deformation->SetFrame(iProj) line, but never makes it >> past the subsequent update. I?m wondering if this has anything to do with >> the size of the DVF generated by transformix: approximately 4.0GB >> (512x100x512x10 image, 4-channels, FLOAT). >> >> Just to provide a little more background information, I?m running RTK on a >> 32 core Sun Server (8x Quad-Core AMD Opteron 8356, 2.3Ghz) with 64GB of >> memory running Ubuntu 14.04. RTK was built using the default ?Release? make >> configuration and linked to ITK 4.5.2. Elastix and Transformix are both the >> latest version, 4.7. >> >> Has anyone else run into a similar issue with reconstructing a similar >> image, or does anyone have any thoughts as to how to resolve this sort of >> issue? >> >> Thanks in advance! >> >> ? Matt >> >> __ >> Matthew J. Riblett >> Virginia Commonwealth University >> Department of Radiation Oncology >> Medical Physics Graduate Program >> >> Office: Sanger Hall, Room B1-013 >> 401 College Street | P.O. Box 980058 >> Richmond, Virginia 23298 >> >> VCU Email: riblettmj at vcu.edu >> MCV Office Phone: +1.804.628.4858 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Thu Feb 5 06:44:47 2015 From: wuchao04 at gmail.com (Chao Wu) Date: Thu, 5 Feb 2015 12:44:47 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Hi Simon, There is still an issue with gengetopt. The config file cannot be read. The problem seems to be at around line 62 in rtkMacro.h: char *configFile = args_info.config_arg; points configFile to the address storing the config file name, but next cmdline_parser_##ggo_filename##_free(&args_info); frees all string field of args_info, including args_info.config_arg, therefore the content pointed by configFile becomes invalid. Regards, Chao 2014-12-12 14:10 GMT+01:00 Simon Rit : > My fix did not work. Cyril (Mory) reported that multiple options were read > twice. I hope this new fix will work but don't hesitate to report other > issues with gengetopt. > Thanks again for you reports, > Simon > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > wrote: >> >> That makes sense, thanks for the quick usage explanation, and fix. >> (Disabling the override issue makes sense, and I didn't have time to trace >> through gengetopt. I thought I was missing something, as none of the >> non-flag arguments were being reset (to null, or default values, and thus >> thought 'override' meant something else!). >> >> Thanks again, glad the info was helpful. >> >> Steve >> >> >> On 14-12-10 4:01 AM, Simon Rit wrote: >> >> Hi, >> Thanks for the report, very useful information. I could reproduce the bug >> and I hope that I have fixed it. Briefly: >> - I have changed the code because Ben Champion reported memory leaks and I >> noticed that they occured in deprecated functions of gengetopt that I don't >> use anymore, >> - the way the new macro (as well as the previous one) is written is: first >> read the command line to find if a config file is passed, then read the >> config file and finally read the command line again to check that everything >> has been passed. >> - your fix was not perfect because we would not have checked that the >> required options were set, >> - it turns out that disabling the override option did the job. >> Everything sworks fine now but let met know if you notice something wrong >> again. Thanks again, >> Simon >> >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann >> wrote: >>> >>> A recent update to rtkMacro.h seems to have caused the ggo command line >>> processor to ignore command line flags. (i.e. I can't get any verbose output >>> with '-v'). >>> It seems to happen after making a second call to: >>> >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, &args_params) >>> >>> Removing this second call, has resolved the issue for me. >>> I'm not sure, however, what the intended use of the second call was for >>> (it occurs immediately after: >>> >>> args_params.check_required = 1; >>> >>> which I feel could just be moved above the first call, as it happens >>> regardless, but I may be missing something. >>> >>> I've attached my quickly modified rtkMacro.h for comparison to the latest >>> github commit. >>> >>> Anyhow, hopefully this info is useful, and doesn't only affect me. >>> >>> Steve >>> >>> Our system setup: >>> -Ubuntu 14.04 x64 >>> -gcc 4.8.2 >>> -cuda 6.5 >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 5 09:17:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 5 Feb 2015 15:17:34 +0100 Subject: [Rtk-users] rtkMacro.h GGO issue In-Reply-To: References: <5487964D.5070601@robarts.ca> <5488AC96.3090803@robarts.ca> Message-ID: Indeed, it looks as if I had not tested it, I thought I had... This patch should fix it. Thanks for the report! Simon On Thu, Feb 5, 2015 at 12:44 PM, Chao Wu wrote: > Hi Simon, > > There is still an issue with gengetopt. The config file cannot be read. > The problem seems to be at around line 62 in rtkMacro.h: > char *configFile = args_info.config_arg; points configFile to the > address storing the config file name, but next > cmdline_parser_##ggo_filename##_free(&args_info); frees all string > field of args_info, including args_info.config_arg, therefore the > content pointed by configFile becomes invalid. > > Regards, > Chao > > 2014-12-12 14:10 GMT+01:00 Simon Rit : > > My fix did not work. Cyril (Mory) reported that multiple options were > read > > twice. I hope this new fix will work but don't hesitate to report other > > issues with gengetopt. > > Thanks again for you reports, > > Simon > > > > On Wed, Dec 10, 2014 at 9:27 PM, Steven Pollmann > > wrote: > >> > >> That makes sense, thanks for the quick usage explanation, and fix. > >> (Disabling the override issue makes sense, and I didn't have time to > trace > >> through gengetopt. I thought I was missing something, as none of the > >> non-flag arguments were being reset (to null, or default values, and > thus > >> thought 'override' meant something else!). > >> > >> Thanks again, glad the info was helpful. > >> > >> Steve > >> > >> > >> On 14-12-10 4:01 AM, Simon Rit wrote: > >> > >> Hi, > >> Thanks for the report, very useful information. I could reproduce the > bug > >> and I hope that I have fixed it. Briefly: > >> - I have changed the code because Ben Champion reported memory leaks > and I > >> noticed that they occured in deprecated functions of gengetopt that I > don't > >> use anymore, > >> - the way the new macro (as well as the previous one) is written is: > first > >> read the command line to find if a config file is passed, then read the > >> config file and finally read the command line again to check that > everything > >> has been passed. > >> - your fix was not perfect because we would not have checked that the > >> required options were set, > >> - it turns out that disabling the override option did the job. > >> Everything sworks fine now but let met know if you notice something > wrong > >> again. Thanks again, > >> Simon > >> > >> On Wed, Dec 10, 2014 at 1:39 AM, Steven Pollmann > >> wrote: > >>> > >>> A recent update to rtkMacro.h seems to have caused the ggo command line > >>> processor to ignore command line flags. (i.e. I can't get any verbose > output > >>> with '-v'). > >>> It seems to happen after making a second call to: > >>> > >>> cmdline_parser_##ggo_filename##_ext(argc, argv, &args_info, > &args_params) > >>> > >>> Removing this second call, has resolved the issue for me. > >>> I'm not sure, however, what the intended use of the second call was for > >>> (it occurs immediately after: > >>> > >>> args_params.check_required = 1; > >>> > >>> which I feel could just be moved above the first call, as it happens > >>> regardless, but I may be missing something. > >>> > >>> I've attached my quickly modified rtkMacro.h for comparison to the > latest > >>> github commit. > >>> > >>> Anyhow, hopefully this info is useful, and doesn't only affect me. > >>> > >>> Steve > >>> > >>> Our system setup: > >>> -Ubuntu 14.04 x64 > >>> -gcc 4.8.2 > >>> -cuda 6.5 > >>> > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> > >> > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Fri Feb 6 12:27:13 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Fri, 6 Feb 2015 18:27:13 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont -------------- next part -------------- A non-text attachment was scrubbed... Name: figure1.png Type: image/png Size: 28287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: figure2.png Type: image/png Size: 80102 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SheppLogan.txt URL: From simon.rit at creatis.insa-lyon.fr Mon Feb 9 09:08:12 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Feb 2015 15:08:12 +0100 Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT wrote: > Hello rtk users, > > I try to use RTK for reconstruction in my lab but I encounter some > problems. > > I try to reconstruct a simulated spheroid. I join my phantom text file > (SheppLogan.txt). > > If I set source_y=0, I get a correct (I guess) reconstruction, see the > joined figure1.png. I use the followind set of commands : > > rtksimulatedgeometry -n 180 --sdd=508.1658133423730 > --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 > --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && > rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha > --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p > /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml > --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" > > But If I set source_y=15, I obtain some strange artefacts as you can see > on figure2.png. Do you know the origin of this pattern (the vertical one) ? > Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this > artefact doesn't exist. > > Thanks in advance and thanks for this nice toolkit. > > regards, > Mathieu Dupont > > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdupont at cppm.in2p3.fr Thu Feb 12 04:25:12 2015 From: mdupont at cppm.in2p3.fr (Mathieu DUPONT) Date: Thu, 12 Feb 2015 10:25:12 +0100 (CET) Subject: [Rtk-users] fdk artefact, sourceOffsetY In-Reply-To: References: <1526536465.11272075.1423241358643.JavaMail.zimbra@cppm.in2p3.fr> <1328259911.11279947.1423243633512.JavaMail.zimbra@cppm.in2p3.fr> Message-ID: <681578867.13033470.1423733112438.JavaMail.zimbra@cppm.in2p3.fr> Hi Simon, you are right, it works now. Thanks for your reactivity. ----- Mail original ----- De: "Simon Rit" ?: "Mathieu DUPONT" Cc: rtk-users at public.kitware.com Envoy?: Lundi 9 F?vrier 2015 15:08:12 Objet: Re: [Rtk-users] fdk artefact, sourceOffsetY Hi Mathieu, Thanks for the observation. The truth is that we haven't tested thoroughly this kind of geometry because I generally prefer to keep the source in the central plane... Still, I have looked into the artifact that you pointed out, which is only visible with a narrow window / level, and found the cause which was a bug. I think this will fix it: https://github.com/SimonRit/RTK/commit/b0dd88821b751671d32ef0fa2f1ff2ae85a4083c Indeed, this only concerns FBP reconstruction, SART and other iterative algorithms should not be impacted. Let us know if you observe some other surprising artifacts. Thanks again, Simon On Fri, Feb 6, 2015 at 6:27 PM, Mathieu DUPONT < mdupont at cppm.in2p3.fr > wrote: Hello rtk users, I try to use RTK for reconstruction in my lab but I encounter some problems. I try to reconstruct a simulated spheroid. I join my phantom text file (SheppLogan.txt). If I set source_y=0, I get a correct (I guess) reconstruction, see the joined figure1.png. I use the followind set of commands : rtksimulatedgeometry -n 180 --sdd=508.1658133423730 --sid=242.7169928585076 --proj_iso_x=-53.500206362627239 --proj_iso_y=-10.768620138555379 --source_y=0 -o geometry.xml && rtkprojectgeometricphantom -g geometry.xml -o /tmp/tmpfs/projections.mha --spacing 1 --dimension 512 --phantomfile SheppLogan.txt && rtkfdk -v -p /tmp/tmpfs/ -r projections.mha -o /tmp/tmpfs/fdk_ccd.mha -g geometry.xml --spacing 0.07 --origin -20,14,-20 --dimension 600,600,600 --hardware="cuda" But If I set source_y=15, I obtain some strange artefacts as you can see on figure2.png. Do you know the origin of this pattern (the vertical one) ? Is it normal ? Or my geometry is completely wrong ? If I use rtksart, this artefact doesn't exist. Thanks in advance and thanks for this nice toolkit. regards, Mathieu Dupont _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From lomahu at gmail.com Thu Feb 12 10:04:45 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 10:04:45 -0500 Subject: [Rtk-users] building CUDA Message-ID: HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 10:50:08 2015 From: theday79 at gmail.com (Yang K Park) Date: Thu, 12 Feb 2015 10:50:08 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <000801d046db$94f3eb60$bedbc220$@gmail.com> Hi Howard, Attached is my Cmake capture image for RTK using CUDA6.5. (I?m using the default option of RTK w/o any manual modification). Also, I?m using VS2013 / win7 64. I found your second option ?CUDA_ATTACH_VS_BUILD_RULE_TO_C ? is different from mine (CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE). And why don?t you use the newest version of CUDA (v6.5)? It may work fine regardless of the model of your NVIDIA graphic card (I?ve tested it for multiple computers w/ different graphic card models). CUDA6.5 is convenient to install since a single installation file will be enough which is including the graphic driver, CUDA toolkit, SDK, etc. (not sure this is same as 5.5). Yang From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Howard Sent: Thursday, February 12, 2015 10:05 AM To: rtk-users at openrtk.org Subject: [Rtk-users] building CUDA HI, I encountered a problem when building CUDA applications. CUDA 5.5 was installed on our system. I set the following in ccmake CUDA_64_BIT_DEVICE_CODE ON CUDA_ATTACH_VS_BUILD_RULE_TO_C ON RTK_USE_CUDA ON I could build but no cuda applications were generated. In the bin folder I saw libITKCudaCommon.a and librtkcuda.a. What did I miss? Anybody could shed light on this? Thanks, -howard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Cuda_RTK_Cmake.PNG Type: image/png Size: 43604 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:16:17 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:16:17 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: Hi, Cmake automatically checks if you have a cuda compatible GPU. If it cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile applications. So there must be an issue with your graphic card. Check if you can compile and run has_cuda_gpu.c. Simon On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > HI, > > I encountered a problem when building CUDA applications. CUDA 5.5 was > installed on our system. I set the following in ccmake > > CUDA_64_BIT_DEVICE_CODE ON > CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > RTK_USE_CUDA ON > > I could build but no cuda applications were generated. In the bin folder I > saw libITKCudaCommon.a and librtkcuda.a. > > What did I miss? Anybody could shed light on this? Thanks, > > -howard > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From julien.jomier at kitware.com Thu Feb 12 11:23:10 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Thu, 12 Feb 2015 17:23:10 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: Message-ID: <54DCD36E.5080903@kitware.com> To follow up, what do you mean by "no cuda applications were generated"? If you have the libraries compiled that means CMake found a working CUDA compatible device. -Julien On 12/02/2015 17:16, Simon Rit wrote: > Hi, > Cmake automatically checks if you have a cuda compatible GPU. If it > cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > applications. So there must be an issue with your graphic card. Check > if you can compile and run has_cuda_gpu.c. > Simon > > On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> HI, >> >> I encountered a problem when building CUDA applications. CUDA 5.5 was >> installed on our system. I set the following in ccmake >> >> CUDA_64_BIT_DEVICE_CODE ON >> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> RTK_USE_CUDA ON >> >> I could build but no cuda applications were generated. In the bin folder I >> saw libITKCudaCommon.a and librtkcuda.a. >> >> What did I miss? Anybody could shed light on this? Thanks, >> >> -howard >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Feb 12 11:27:09 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 17:27:09 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: <54DCD36E.5080903@kitware.com> References: <54DCD36E.5080903@kitware.com> Message-ID: Actually no, librtkcuda is compiled if the cuda library is available but the applications are compiled if the cuda library AND a cuda compatible device are available... That's probably why you observe this. Simon On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier wrote: > To follow up, what do you mean by "no cuda applications were generated"? If > you have the libraries compiled that means CMake found a working CUDA > compatible device. > > -Julien > > > On 12/02/2015 17:16, Simon Rit wrote: >> >> Hi, >> Cmake automatically checks if you have a cuda compatible GPU. If it >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> applications. So there must be an issue with your graphic card. Check >> if you can compile and run has_cuda_gpu.c. >> Simon >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >>> >>> HI, >>> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >>> installed on our system. I set the following in ccmake >>> >>> CUDA_64_BIT_DEVICE_CODE ON >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >>> RTK_USE_CUDA ON >>> >>> I could build but no cuda applications were generated. In the bin folder >>> I >>> saw libITKCudaCommon.a and librtkcuda.a. >>> >>> What did I miss? Anybody could shed light on this? Thanks, >>> >>> -howard >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> > From lomahu at gmail.com Thu Feb 12 12:24:12 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 12:24:12 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: Thanks all for your responses to my question. I did not initially set CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: [ 24%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt for reading. [ 25%] Building NVCC (Device) object code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for multiple GPU code instances CMake Error at /hpc/packages/minerva-common/cmake/ 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 (file): file Internal CMake error when trying to open file: /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt for reading. As I said in my original post, we have CUDA installed on the system (cluster system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the cards would work well although I haven't confirmed that. -howard On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit wrote: > Actually no, librtkcuda is compiled if the cuda library is available > but the applications are compiled if the cuda library AND a cuda > compatible device are available... That's probably why you observe > this. > Simon > > On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > wrote: > > To follow up, what do you mean by "no cuda applications were generated"? > If > > you have the libraries compiled that means CMake found a working CUDA > > compatible device. > > > > -Julien > > > > > > On 12/02/2015 17:16, Simon Rit wrote: > >> > >> Hi, > >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> applications. So there must be an issue with your graphic card. Check > >> if you can compile and run has_cuda_gpu.c. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >>> > >>> HI, > >>> > >>> I encountered a problem when building CUDA applications. CUDA 5.5 was > >>> installed on our system. I set the following in ccmake > >>> > >>> CUDA_64_BIT_DEVICE_CODE ON > >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >>> RTK_USE_CUDA ON > >>> > >>> I could build but no cuda applications were generated. In the bin > folder > >>> I > >>> saw libITKCudaCommon.a and librtkcuda.a. > >>> > >>> What did I miss? Anybody could shed light on this? Thanks, > >>> > >>> -howard > >>> > >>> _______________________________________________ > >>> Rtk-users mailing list > >>> Rtk-users at public.kitware.com > >>> http://public.kitware.com/mailman/listinfo/rtk-users > >>> > >> _______________________________________________ > >> Rtk-users mailing list > >> Rtk-users at public.kitware.com > >> http://public.kitware.com/mailman/listinfo/rtk-users > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Feb 12 12:42:15 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 12 Feb 2015 18:42:15 +0100 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: That's more complicated. First, CUDA_HAVE_GPU is normally turned on automatically but maybe it's been turned off due to the problem you're encountering now. The problem you have is probably not specific to RTK, we don't develop FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an option CUDA_BUILD_CUBIN, maybe turn it off? If I were you, I'd try to create a small separate project with has_cuda_gpu.c and check whether it compiles. If it doesn't, try the cmake mailing list. Simon On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > Thanks all for your responses to my question. I did not initially set > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > [ 24%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > for reading. > > > [ 25%] Building NVCC (Device) object > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling for > multiple GPU code instances > CMake Error at > /hpc/packages/minerva-common/cmake/2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > (file): > file Internal CMake error when trying to open file: > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > for reading. > > As I said in my original post, we have CUDA installed on the system (cluster > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > cards would work well although I haven't confirmed that. > > -howard > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit > wrote: >> >> Actually no, librtkcuda is compiled if the cuda library is available >> but the applications are compiled if the cuda library AND a cuda >> compatible device are available... That's probably why you observe >> this. >> Simon >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> wrote: >> > To follow up, what do you mean by "no cuda applications were generated"? >> > If >> > you have the libraries compiled that means CMake found a working CUDA >> > compatible device. >> > >> > -Julien >> > >> > >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> Hi, >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> applications. So there must be an issue with your graphic card. Check >> >> if you can compile and run has_cuda_gpu.c. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >>> >> >>> HI, >> >>> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 was >> >>> installed on our system. I set the following in ccmake >> >>> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >>> RTK_USE_CUDA ON >> >>> >> >>> I could build but no cuda applications were generated. In the bin >> >>> folder >> >>> I >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >>> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >>> >> >>> -howard >> >>> >> >>> _______________________________________________ >> >>> Rtk-users mailing list >> >>> Rtk-users at public.kitware.com >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >>> >> >> _______________________________________________ >> >> Rtk-users mailing list >> >> Rtk-users at public.kitware.com >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> > > > From lomahu at gmail.com Thu Feb 12 13:37:39 2015 From: lomahu at gmail.com (Howard) Date: Thu, 12 Feb 2015 13:37:39 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: When I did the following: CUDA_HAVE_GPU ON CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) building was successful. I could run rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk using cuda?) with successful reconstruction. It's done in < 15s, wow! A separate question: how to specify cuda for rtksart, rtkadmmwavelets, rtkadmmtotalvariations etc? Thanks, -howard On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit wrote: > That's more complicated. First, CUDA_HAVE_GPU is normally turned on > automatically but maybe it's been turned off due to the problem you're > encountering now. > The problem you have is probably not specific to RTK, we don't develop > FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an > option CUDA_BUILD_CUBIN, maybe turn it off? > If I were you, I'd try to create a small separate project with > has_cuda_gpu.c and check whether it compiles. If it doesn't, try the > cmake mailing list. > Simon > > On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: > > Thanks all for your responses to my question. I did not initially set > > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: > > > > > > [ 24%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt > > for reading. > > > > > > [ 25%] Building NVCC (Device) object > > > code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o > > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling > for > > multiple GPU code instances > > CMake Error at > > /hpc/packages/minerva-common/cmake/ > 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 > > (file): > > file Internal CMake error when trying to open file: > > > > > /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt > > for reading. > > > > As I said in my original post, we have CUDA installed on the system > (cluster > > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are > > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume the > > cards would work well although I haven't confirmed that. > > > > -howard > > > > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> > > wrote: > >> > >> Actually no, librtkcuda is compiled if the cuda library is available > >> but the applications are compiled if the cuda library AND a cuda > >> compatible device are available... That's probably why you observe > >> this. > >> Simon > >> > >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier > >> wrote: > >> > To follow up, what do you mean by "no cuda applications were > generated"? > >> > If > >> > you have the libraries compiled that means CMake found a working CUDA > >> > compatible device. > >> > > >> > -Julien > >> > > >> > > >> > On 12/02/2015 17:16, Simon Rit wrote: > >> >> > >> >> Hi, > >> >> Cmake automatically checks if you have a cuda compatible GPU. If it > >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile > >> >> applications. So there must be an issue with your graphic card. Check > >> >> if you can compile and run has_cuda_gpu.c. > >> >> Simon > >> >> > >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: > >> >>> > >> >>> HI, > >> >>> > >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 > was > >> >>> installed on our system. I set the following in ccmake > >> >>> > >> >>> CUDA_64_BIT_DEVICE_CODE ON > >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON > >> >>> RTK_USE_CUDA ON > >> >>> > >> >>> I could build but no cuda applications were generated. In the bin > >> >>> folder > >> >>> I > >> >>> saw libITKCudaCommon.a and librtkcuda.a. > >> >>> > >> >>> What did I miss? Anybody could shed light on this? Thanks, > >> >>> > >> >>> -howard > >> >>> > >> >>> _______________________________________________ > >> >>> Rtk-users mailing list > >> >>> Rtk-users at public.kitware.com > >> >>> http://public.kitware.com/mailman/listinfo/rtk-users > >> >>> > >> >> _______________________________________________ > >> >> Rtk-users mailing list > >> >> Rtk-users at public.kitware.com > >> >> http://public.kitware.com/mailman/listinfo/rtk-users > >> >> > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From theday79 at gmail.com Thu Feb 12 13:47:54 2015 From: theday79 at gmail.com (Yang-Kyun Park) Date: Thu, 12 Feb 2015 13:47:54 -0500 Subject: [Rtk-users] building CUDA In-Reply-To: References: <54DCD36E.5080903@kitware.com> Message-ID: hi howard, use following options for fwd and bkward projection --fp CudaRayCast --bp CudaVoxelBased Yang On Feb 12, 2015 1:37 PM, "Howard" wrote: > When I did the following: > > CUDA_HAVE_GPU ON > CUDA_BUILD_CUBIN OFF ( this removed the errors I reported in last posting) > CUDA_HOST_COMPILATION_CPP ON (following Yang K Park's screenshot) > > building was successful. I could run > > rtkfdk --hardware cuda -r ... ((Is this the correct way of running fdk > using cuda?) > > with successful reconstruction. It's done in < 15s, wow! > > A separate question: how to specify cuda for rtksart, > rtkadmmwavelets, rtkadmmtotalvariations etc? > > Thanks, > -howard > > > > > > > > > > > On Thu, Feb 12, 2015 at 12:42 PM, Simon Rit < > simon.rit at creatis.insa-lyon.fr> wrote: > >> That's more complicated. First, CUDA_HAVE_GPU is normally turned on >> automatically but maybe it's been turned off due to the problem you're >> encountering now. >> The problem you have is probably not specific to RTK, we don't develop >> FindCUDA.cmake. I quickly checked FindCUDA.cmake and there if an >> option CUDA_BUILD_CUBIN, maybe turn it off? >> If I were you, I'd try to create a small separate project with >> has_cuda_gpu.c and check whether it compiles. If it doesn't, try the >> cmake mailing list. >> Simon >> >> On Thu, Feb 12, 2015 at 6:24 PM, Howard wrote: >> > Thanks all for your responses to my question. I did not initially set >> > CUDA_HAVE_GPU to ON. Now I turned it on, I got errors when doing make: >> > >> > >> > [ 24%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFDKBackProjectionImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > >> > [ 25%] Building NVCC (Device) object >> > >> code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o >> > nvcc fatal : Option '--cubin (-cubin)' is not allowed when compiling >> for >> > multiple GPU code instances >> > CMake Error at >> > /hpc/packages/minerva-common/cmake/ >> 2.8.12.2/share/cmake-2.8/Modules/FindCUDA/parse_cubin.cmake:38 >> > (file): >> > file Internal CMake error when trying to open file: >> > >> > >> /sc/orga/work/howard02/usr/local/RTK/RTK-bin/code/CMakeFiles/cuda_compile.dir//./cuda_compile_generated_rtkCudaFFTRampImageFilter.cu.o.cubin.txt >> > for reading. >> > >> > As I said in my original post, we have CUDA installed on the system >> (cluster >> > system). We have three version: 4.2.9, 5.5.22, and 6.0.37. The cards are >> > NVIDIA M2090 256GB memory and NVIDIA K20Xm of 256GB as well. I assume >> the >> > cards would work well although I haven't confirmed that. >> > >> > -howard >> > >> > On Thu, Feb 12, 2015 at 11:27 AM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> >> > wrote: >> >> >> >> Actually no, librtkcuda is compiled if the cuda library is available >> >> but the applications are compiled if the cuda library AND a cuda >> >> compatible device are available... That's probably why you observe >> >> this. >> >> Simon >> >> >> >> On Thu, Feb 12, 2015 at 5:23 PM, Julien Jomier >> >> wrote: >> >> > To follow up, what do you mean by "no cuda applications were >> generated"? >> >> > If >> >> > you have the libraries compiled that means CMake found a working CUDA >> >> > compatible device. >> >> > >> >> > -Julien >> >> > >> >> > >> >> > On 12/02/2015 17:16, Simon Rit wrote: >> >> >> >> >> >> Hi, >> >> >> Cmake automatically checks if you have a cuda compatible GPU. If it >> >> >> cannot run a simple test, CUDA_HAVE_GPU is OFF and it won't compile >> >> >> applications. So there must be an issue with your graphic card. >> Check >> >> >> if you can compile and run has_cuda_gpu.c. >> >> >> Simon >> >> >> >> >> >> On Thu, Feb 12, 2015 at 4:04 PM, Howard wrote: >> >> >>> >> >> >>> HI, >> >> >>> >> >> >>> I encountered a problem when building CUDA applications. CUDA 5.5 >> was >> >> >>> installed on our system. I set the following in ccmake >> >> >>> >> >> >>> CUDA_64_BIT_DEVICE_CODE ON >> >> >>> CUDA_ATTACH_VS_BUILD_RULE_TO_C ON >> >> >>> RTK_USE_CUDA ON >> >> >>> >> >> >>> I could build but no cuda applications were generated. In the bin >> >> >>> folder >> >> >>> I >> >> >>> saw libITKCudaCommon.a and librtkcuda.a. >> >> >>> >> >> >>> What did I miss? Anybody could shed light on this? Thanks, >> >> >>> >> >> >>> -howard >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Rtk-users mailing list >> >> >>> Rtk-users at public.kitware.com >> >> >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >>> >> >> >> _______________________________________________ >> >> >> Rtk-users mailing list >> >> >> Rtk-users at public.kitware.com >> >> >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> >> >> >> > >> > >> > >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 13 07:06:34 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Feb 2015 13:06:34 +0100 Subject: [Rtk-users] ADMMTVReconstruction In-Reply-To: <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> References: <548EA4E1.4090801@creatis.insa-lyon.fr> <54919EE9.3010406@creatis.insa-lyon.fr> <5492A8BB.2030209@creatis.insa-lyon.fr> <000901d02a50$1c14f470$543edd50$@uclouvain.be> <00ac01d02b54$698c3d30$3ca4b790$@uclouvain.be> Message-ID: Hi, FYI, S?bastien and I have worked on the pipeline that was mentionned in this discussion. The pipeline is now available in the rtkProjectionsReader (see the diagram in the doc ). Every rtk application can use it from command line options. For example, I0 is automatically estimated if the option --i0=0 is used. Don't hesitate to report what is not clear or not working for you. Simon On Thu, Jan 8, 2015 at 4:04 PM, S?bastien Brousmiche < sebastien.brousmiche at uclouvain.be> wrote: > Hi Howard, > > > > Actually there are three values given per projection: I0, a filtered I0 > (RLS) and the FWHM of the background mode. > > You can just use the first value per projection. If ?output? is the buffer > contained in the file (-d) then use I0 = buffer(1:3:end); > > > > Read rtki0estimation.cxx in the application folder for more information. > I?m planning to add more info in the code later. > > > > Best, > > S?bastien > > > > > > *From:* Howard [mailto:lomahu at gmail.com] > *Sent:* jeudi 8 janvier 2015 15:57 > *To:* S?bastien Brousmiche > *Cc:* Simon Rit; rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Hi Sebastien, > > > > Thank you very much for your explanation. I used -d to write I0 > estimations to a file. I found there are >2000 numbers for ~600 > projections. I thought there would be one number for each projection, but > obviously the output numbers are not generated that way. Could you please > describe a bit more on the file format and how to use them? Or simply I > wait for your new mini-pipeline filter? > > > > Regards, > > -howard > > > > On Wed, Jan 7, 2015 at 3:01 AM, S?bastien Brousmiche < > sebastien.brousmiche at uclouvain.be> wrote: > > Hi Howard, > > > > There is an input parameter with the rtki0estimation application (-d) > which allows you to specify the output file with I0 estimates. > > > > The big file you mentioned contains the histograms of each image (65536 > values each) stored consecutively. The first value is the occurrence of > number 0 in your image, second.. 1 and so forth up to 65535. > > > > This application is not particularly interesting to be used in a pipeline. > > > > > Nevertheless, we are developing a mini-pipeline grouping typical > preprocessing filters. It is under validation and I?ll let you know as soon > as it is available for you. > > > > Best, > > S?bastien > > > > > > > > > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Howard > *Sent:* mercredi 7 janvier 2015 00:17 > *To:* Simon Rit > *Cc:* rtk-users at openrtk.org > *Subject:* Re: [Rtk-users] ADMMTVReconstruction > > > > Happy New Year, Simon. > > > > Thank you for pointing to me the I0 estimate procedure.I saw an > application rtki0estimation > > under the Applications folder. Is this the tool you meant? I ran it using > all default parameters > > providing with the original projection data. What I obtained was a file: > i0est_histogram.csv. > > From the comments in rtki0estimation.ggo this file is the output with I0 > estimate. For 650 projections > > the file size is around 200MB. I used excel to open the file and found > that the beginning two numbers > > 64408 and 722024 then followed by 0's. In the middle there are some > nonzero numbers. Essentially > > all zeros. > > Since there is not much description of the application, so it is hard to > figure out easily what I am doing. > > I tried to read the source code, but it might be more useful if you can > give some hints on how to > > use it. > > > > Regards, > > -howard > > > > > > On Mon, Jan 5, 2015 at 1:49 AM, Simon Rit > wrote: > > Happy new year Howard, > Normally, this calibration is handled by the flat panel. It uses an > air projection and a dark (no beam) projection to compute the line > integral. However, there might be fluctuations in time of these two > projections. Some people do regular acquisitions of them to capture > the time fluctuations. Otherwise, a constant value might be a good > solution. S?bastien has recently implemented an automated > determination of this constant, maybe you should have a look: > > http://www.openrtk.org/Doxygen/classrtk_1_1I0EstimationProjectionFilter.html > It is already part of the mini-pipeline for ImagX / IBA projections > processing: > > http://www.openrtk.org/Doxygen/classrtk_1_1ImagXRawToAttenuationImageFilter.html > Simon > > > On Fri, Jan 2, 2015 at 10:17 PM, Howard wrote: > > Happy New Year, Cyril. > > > > I realized that our projection data is having some issues with air > > correction. We checked our calibration and it appeared fine. Do you know > by > > any chance whether there is a quick way of correcting that? I searched > > around and found people used a constant air norm image. > > > > Thanks very much, > > -howard > > > > On Thu, Dec 18, 2014 at 5:13 AM, Cyril Mory > > wrote: > >> > >> Hi Howard, > >> > >> I've taken a look at your data. > >> You can apply tv denoising on the out.mha volume and obtain a > >> significantly lower level of noise without blurring structures by using > the > >> following command : > >> rtktotalvariationdenoising -i out.mha -g 0.001 -o > >> tvdenoised/gamma0.001.mha -n 100 > >> > >> I was unable to obtain good results with iterative reconstruction from > the > >> projection data you sent, though. I think the main reason for this is > that > >> your projections have much-higher-than-zero attenuation in air. Your > >> calculation of i0 when converting from intensity to attenuation is > probably > >> not good enough. Try to correct for this effect first. Then you can > start > >> performing SART and Conjugate Gradient reconstructions on your data, and > >> once you get these right, play with ADMM. > >> > >> You might need to remove the table from the projections to be able to > >> restrict the reconstruction volume strictly to the patient, and speed > up the > >> computations. We can provide help for that too. > >> > >> Best regards, > >> Cyril > >> > >> > >> On 12/17/2014 05:02 PM, Howard wrote: > >> > >> Hi Cyril, > >> > >> I've sent you two files via wetransfer.com: one is the sparse > projection > >> set with geometry file and the other is the fdk reconstructed image > based on > >> full projection set. Please let me know if you have trouble receiving > them. > >> > >> Thanks very much for looking into this. > >> > >> -Howard > >> > >> On Wed, Dec 17, 2014 at 10:19 AM, Cyril Mory > >> wrote: > >>> > >>> Hi Howard, > >>> > >>> Thanks for the detailed feedback. > >>> The image getting blurry is typically due to a too high gamma. > Depending > >>> on you data, gamma can have to be set to a very small value (I use > 0.007 in > >>> some reconstructions on clinical data). Can you send over your volume > >>> reconstructed from full projection data, and I'll have a quick look ? > >>> > >>> There is a lot of instinct in the setting of the parameters. With time, > >>> one gets used to finding a correct set of parameters without really > knowing > >>> how. I can also try to reconstruct from your cbct data if you send me > the > >>> projections and the geometry. > >>> > >>> Best regards, > >>> Cyril > >>> > >>> > >>> On 12/17/2014 03:49 PM, Howard wrote: > >>> > >>> Hi Cyril, > >>> > >>> Thanks very much for your detailed and nice description on how to use > the > >>> admmtv reconstruction. I followed your suggestions and re-ran > >>> reconstructions using admmtotalvariation and admmwavelets with cbct > >>> projection data from a thoracic patient. > >>> > >>> I am reporting what I found and hope these will give you information > for > >>> further improvement. > >>> > >>> 1. I repeated admmtotalvariation with 30 iterations. No improvement was > >>> observed. As a matter of fact, the reconstructed image is getting a lot > >>> noiser compared to that using 3 iterations. The contrast is getting > worse as > >>> well. I tried to play around with window & level in case I was fooled > but > >>> apparently more iterations gave worse results. > >>> > >>> 2. Similarly I ran 30 iterations using admmwavelets. Slightly better > >>> reconstruction compared with total variation. > >>> > >>> 3. Then I went ahead to test if TV benefits us anything using the > >>> tvdenoising application on the fdk-reconstructed image reconstructed > from > >>> full projection set. I found that the more iterations, the more blurry > the > >>> image became. For example, with 50 iterations the contrast on the > denoised > >>> image is very low so that the vertebrae and surrounding soft tissue are > >>> hardly distinguishable. Changing gamma's at 0.2, 0.5, 1.0, 10 did not > seem > >>> to make a difference on the image. With 5 iterations the denoising > seems to > >>> work fairly well. Again, changing gamma's didn't make a difference. > >>> I hope I didn't misused the totalvariationdenoising application. The > >>> command I executed was: rtktotalvariationdenoising -i out.mha -o > >>> out_denoising_n50_gamma05 --gamma 0.5 -n 50 > >>> > >>> In summary, tdmmwavelets seems perform better than tdmmtotalvariation > but > >>> neither gave satisfactory results. No sure what we can infer from the > TV > >>> denoising study. I could send my study to you if there is a need. > Please let > >>> me know what tests I could run. Further help on improvement is > definitely > >>> welcome and appreciated. > >>> > >>> -Howard > >>> > >>> On Mon, Dec 15, 2014 at 4:07 AM, Cyril Mory > >>> wrote: > >>>> > >>>> Hello Howard, > >>>> > >>>> Good to hear that you're using RTK :) > >>>> I'll try to answer all your questions, and give you some advice: > >>>> - In general, you can expect some improvement over rtkfdk, but not a > >>>> huge one > >>>> - You can find the calculations in my PhD thesis > >>>> https://tel.archives-ouvertes.fr/tel-00985728 (in English. Only the > >>>> introduction is in French) > >>>> - Adjusting the parameters is, in itself, a research topic (sorry !). > >>>> Alpha controls the amount of regularization and only that (the > higher, the > >>>> more regularization). Beta, theoretically, should only change the > >>>> convergence speed, provided you do an infinite number of iterations > (I know > >>>> it doesn't help, sorry again !). In practice, beta is ubiquitous and > appears > >>>> everywhere in the calculations, therefore it is hard to predict what > effect > >>>> an increase/decrease of beta will give on the images. I would keep it > as is, > >>>> and play on alpha > >>>> - 3 iterations is way too little. I typically used 30 iterations. > Using > >>>> the CUDA forward and back projectors helped a lot maintain the > computation > >>>> time manageable > >>>> - The quality of the results depends a lot on the nature of the image > >>>> you are trying to reconstruct. In a nutshell, the algorithm assumes > that the > >>>> image you are reconstructing has a certain form of regularity, and > discards > >>>> the potential solutions that do not have it. This assumption partly > >>>> compensates for the lack of data. ADMM TV assumes that the image you > are > >>>> reconstructing is piecewise constant, i.e. has large uniform areas > separated > >>>> by sharp borders. If your image is a phantom, it should give good > results. > >>>> If it is a real patient, you should probably change to another > algorithm > >>>> that assumes another form of regularity in the images (try > rtkadmmwavelets) > >>>> - You can find out whether you typical images can benefit from TV > >>>> regularization by reconstructing from all projections with rtkfdk, > then > >>>> applying rtktotalvariationdenoising on the reconstructed volume (try > 50 > >>>> iterations and adjust the gamma parameter: high gamma means high > >>>> regularization). If this denoising implies an unacceptable loss of > quality, > >>>> stay away from TV for these images, and try wavelets > >>>> > >>>> I hope this helps > >>>> > >>>> Looking forward to reading you again, > >>>> Cyril > >>>> > >>>> > >>>> On 12/12/2014 06:42 PM, Howard wrote: > >>>> > >>>> I am testing the ADMM total variation reconstruction with sparse data > >>>> sample. I could reconstruct but the results were not as good as > expected. In > >>>> other words, it didn't show much improvement compared to fdk > reconstruction > >>>> using the same sparse projection data. > >>>> > >>>> The parameters I used in ADMMTV were the following: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --alpha 1 --beta 1000 -n 3 > >>>> > >>>> while the fdk reconstruction parameters are: > >>>> > >>>> --spacing 2,2,2 --dimension 250,100,250 --pad 0.1 --hann 0.5 > >>>> > >>>> The dimensions were chosen to include the entire anatomy. 72 > projections > >>>> were selected out of 646 projections for a 360 degree scan for both > >>>> calculations. > >>>> > >>>> What parameters and how can I adjust (like alpha, beta, or > iterations?) > >>>> to improve the ADMMTV reconstruction? There is not much description > of this > >>>> application from the wiki page. > >>>> > >>>> Thanks, > >>>> > >>>> -howard > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Rtk-users mailing list > >>>> Rtk-users at public.kitware.com > >>>> http://public.kitware.com/mailman/listinfo/rtk-users > >>>> > >>>> > >>>> -- > >>>> -- > >>>> Cyril Mory, Post-doc > >>>> CREATIS > >>>> Leon Berard cancer treatment center > >>>> 28 rue La?nnec > >>>> 69373 Lyon cedex 08 FRANCE > >>>> > >>>> Mobile: +33 6 69 46 73 79 > >>> > >>> > >>> -- > >>> -- > >>> Cyril Mory, Post-doc > >>> CREATIS > >>> Leon Berard cancer treatment center > >>> 28 rue La?nnec > >>> 69373 Lyon cedex 08 FRANCE > >>> > >>> Mobile: +33 6 69 46 73 79 > >> > >> > >> -- > >> -- > >> Cyril Mory, Post-doc > >> CREATIS > >> Leon Berard cancer treatment center > >> 28 rue La?nnec > >> 69373 Lyon cedex 08 FRANCE > >> > >> Mobile: +33 6 69 46 73 79 > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at public.kitware.com > > http://public.kitware.com/mailman/listinfo/rtk-users > > > > > > > ------------------------------ > > [image: Image removed by sender.] > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > > > > > > ------------------------------ > > > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection Antivirus avast! est > active. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: not available URL: From Robert.Calliess at gmx.de Tue Feb 24 03:56:15 2015 From: Robert.Calliess at gmx.de (=?UTF-8?Q?=22Robert_Callie=C3=9F=22?=) Date: Tue, 24 Feb 2015 09:56:15 +0100 Subject: [Rtk-users] sart back projection, weighting steps Message-ID: An HTML attachment was scrubbed... URL: From cyril.mory at creatis.insa-lyon.fr Tue Feb 24 04:55:00 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Tue, 24 Feb 2015 10:55:00 +0100 Subject: [Rtk-users] sart back projection, weighting steps In-Reply-To: References: Message-ID: <54EC4A74.2010601@creatis.insa-lyon.fr> Hi Robert, I'm glad to know that most of the explanation text is understandable :) You might want to check this filter: http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html You can use the command line application "rtkbackprojections" with argument --bp to compare "Joseph" and "NormalizedJoseph". When performing a back projection with non-normalized Joseph, the projection values are "splat" (splat is the adjoint operator of interpolation) between the four nearest voxels in each volume plane the ray intersects. Nothing guarantees that every voxel will receive a contribution during this process. How many contributions a voxel receives is determined by the sampling of the projections, which can be much looser or much denser (locally and globally) than what would be required. Dividing by the back projection of an image of ones mitigates this effect. In theory, as long as the forward and back projection operators are the adjoint of one another, it should not be a problem for SART. In practice, it does make a difference. I hope it helps. Please let me know if it is still unclear; Cyril On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward projection, > every pixel is > divided by the intersection length of the ray with the volume. That is > clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This weighting > step is not > performed when using a voxel-based back projection, as the weights > are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all pixels > have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply this > weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate the > pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range from 0 > to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Thu Feb 26 14:35:06 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Thu, 26 Feb 2015 19:35:06 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely,Vahid? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.calliess at gmx.de Thu Feb 26 15:18:53 2015 From: robert.calliess at gmx.de (=?UTF-8?Q?Robert_Callie=C3=9F?=) Date: Thu, 26 Feb 2015 21:18:53 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> Message-ID: <00d901d05201$71a49200$54edb600$@gmx.de> Hello Vahid, I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI but with a wider sensor array. I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code. But let?s see what grandmasters of RTK will suggest. Best regards, Robert Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK Dear RTK users, I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. Sincerely, Vahid -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghostcz at hotmail.com Thu Feb 26 16:33:46 2015 From: ghostcz at hotmail.com (louie L) Date: Thu, 26 Feb 2015 22:33:46 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: <00d901d05201$71a49200$54edb600$@gmx.de> References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work. Best regards, Louie Greetings from my iOS! > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that the > resulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment). > I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi around > the detector?s center where the perspective distortion (because of the cone) is minimal. And then you add these > seperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDI > but with a wider sensor array. > > I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it > would be possible to model the helical trajectory by the changing geometry without changing /adding code. > > But let?s see what grandmasters of RTK will suggest. > > Best regards, > Robert > > > Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users > Gesendet: Donnerstag, 26. Februar 2015 20:35 > An: rtk-users at public.kitware.com > Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK > > Dear RTK users, > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification? > I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated. > > Sincerely, > Vahid > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users From cyril.mory at creatis.insa-lyon.fr Fri Feb 27 03:45:24 2015 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Fri, 27 Feb 2015 09:45:24 +0100 Subject: [Rtk-users] Fwd: Re: Aw: Re: sart back projection, weighting steps In-Reply-To: <54F02E7E.7080000@creatis.insa-lyon.fr> References: <54F02E7E.7080000@creatis.insa-lyon.fr> Message-ID: <54F02EA4.7010006@creatis.insa-lyon.fr> Hi Robert, No problem, glad to help. I think either I have'nt been clear enough, or you're getting confused, though :) Let me try again: In joseph back projection, for each PIXEL, you "draw a line" between the source and the pixel's center, and see which voxels it crosses. Your line crosses each slice of the volume at an intersection point. You determine what the interpolation weights would be if you were to interpolate at this intersection point. And these weights are indeed between 0 and 1. But instead of interpolating, you "splat", that means you update the four nearest voxels by adding (projection's pixel value * interpolationWeight) to each. And you move to the next slice. Once you've considered all rays, you're done. Nothing in this process guarantees that a voxel will receive any contribution. In fact, some receive none, and some too many. The backprojected volume you obtain is "biased". You could think of it as the product of what you really want (the projection's pixel values smeared out along the lines of rays) with a "sampling density map" (the cumulated splat weights each voxel has been updated with). If you back project a projection of ones, then your resulting volume is exactly this sampling density map, and you can divide by it to obtain what you really want. In voxel based back projection, for each voxel, you "draw a line" between the source and the voxel's center, see where it hits the 2D projection, and add the value of that pixel (or interpolated at this position between pixels) into the voxel. And that's it for this voxel, so each voxel gets updated once and only once. And if the projection contains only ones, then your volume gets filled with ones. Dividing by one isn't going to change anything, so you just don't do it. I hope it is clearer. Cyril On 02/26/2015 02:10 PM, "Robert Callie?" wrote: > Hello Cyril, > thank you for the fast reply and thank you for the support. > Indeed I have some more questions. For the normalization step > you on the one hand side create a projection image filled with "1" > and on the other hand side you create an empty (zero) volume and > then back project the image, ok. > >>How many contributions a voxel receives is determined by the > sampling of the projections > Yes, I have the same problems with a voxel-based back projector. But > don't you have > this problem also with joseph's method when you use it for the back > projection of the "1" projection > image ? It's not clear to me how this kind of back projection actually > works (or is calculated). > And if the projection image consists of pixels with value "1" then we > actually don't need it or do we ? > So far I understand, no matter if we perform the forward or back > projtion, the joseph projector calculates > the weightings of the four voxels that are "around" the current plane > intersection point. And this > weights are always between 0 and 1. > Or do I totally misunderstand the concept of this backprojection. > I hope I did not confused you. > best regards, > Robert > *Gesendet:* Dienstag, 24. Februar 2015 um 10:55 Uhr > *Von:* "Cyril Mory" > *An:* "Robert Callie?" , rtk-users at openrtk.org > *Betreff:* Re: [Rtk-users] sart back projection, weighting steps > Hi Robert, > > I'm glad to know that most of the explanation text is understandable :) > You might want to check this filter: > http://www.openrtk.org/Doxygen/classrtk_1_1NormalizedJosephBackProjectionImageFilter.html > You can use the command line application "rtkbackprojections" with > argument --bp to compare "Joseph" and "NormalizedJoseph". > > When performing a back projection with non-normalized Joseph, the > projection values are "splat" (splat is the adjoint operator of > interpolation) between the four nearest voxels in each volume plane > the ray intersects. Nothing guarantees that every voxel will receive a > contribution during this process. How many contributions a voxel > receives is determined by the sampling of the projections, which can > be much looser or much denser (locally and globally) than what would > be required. Dividing by the back projection of an image of ones > mitigates this effect. In theory, as long as the forward and back > projection operators are the adjoint of one another, it should not be > a problem for SART. In practice, it does make a difference. > > I hope it helps. Please let me know if it is still unclear; > > Cyril > On 02/24/2015 09:56 AM, "Robert Callie?" wrote: > > Hello, > in the file rtkSARTConeBeamReconstructionFilter.h there is briefly > written how the > forward and back projection is performed. For the forward > projection, every pixel is > divided by the intersection length of the ray with the volume. > That is clear to me. > For the back projection applies the following text: > "each voxel of the back projection must be divided by the value it > would take if > a projection filled with ones was being reprojected. This > weighting step is not > performed when using a voxel-based back projection, as the > weights are all equal to one > in this case. When using a ray-based backprojector, typically > Joseph,it must be performed." > That means a temporary projection image is created where all > pixels have the value "1". So far I understand, > if we use a voxel based back projector we do not need to apply > this weighting step because the ray from source to voxel center > somewhere hits the detector plane and usually there we interpolate > the pixel value. But all of them are "1" so it's obsolete to > interpolate inbetween. > But if we use for instance the joseph back projector don't we > calculate the four weightings at the current volume planes the > ray intersects with ? So we already have weightings that range > from 0 to 1. I'm a little bit confused about the projection image > filled with "1". So how a this back projection of "1" actually > happens ? > I hope someone can help me with that. Thank you. > best regards, > Robert > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Feb 27 04:42:38 2015 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 27 Feb 2015 10:42:38 +0100 Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: <1542205952.29031.1424896787787.JavaMail.yahoo@mail.yahoo.com> <1541525769.682747.1424979306718.JavaMail.yahoo@mail.yahoo.com> <00d901d05201$71a49200$54edb600$@gmx.de> Message-ID: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry . I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: > Hi, > > You can change the geometry. If changed correctly, most, if not all, the > iterative cone beam reconstruction will work. > > Best regards, > Louie > > Greetings from my iOS! > > On 26 Feb 2015, at 21:19, Robert Callie? wrote: > > Hello Vahid, > > I think you need to add a new reconstruction filter for it. For the first > projection the object usually is placed so that the > > resulting projection image covers the upper half of the detector. And you > will need some additional handling (z-increment). > > I guess you could do a little work around with the current rtk. If you > only reconstruct an rectangular roi around > > the detector?s center where the perspective distortion (because of the > cone) is minimal. And then you add these > > seperate volumes to a final volume. This is just an idea. I do not know > how the result will look like. Think of it like a TDI > > but with a wider sensor array. > > > > I do not know the code in detail, but if it were possible to have seperate > geometry settings for every projection image it > > would be possible to model the helical trajectory by the changing geometry > without changing /adding code. > > > > But let?s see what grandmasters of RTK will suggest. > > > > Best regards, > > Robert > > > > > > *Von:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *Im Auftrag von *vahid ettehadi > via Rtk-users > *Gesendet:* Donnerstag, 26. Februar 2015 20:35 > *An:* rtk-users at public.kitware.com > *Betreff:* [Rtk-users] Helical cone-beam reconstruction with RTK > > > > Dear RTK users, > > > > > > I am using the RTK code to reconstruct the image for a bench-top micro-CT > in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK. > > I would like to change the current source trajectory from circular to > helical. I was wondering is it possible to use the RTK for helical > reconstruction only with some simple modification? > > I don't know well about reconstruction process and I don't know which type > of modification is necessary to use RTK for a helical cone beam geometry. > So, any suggestion and recommendation would be appreciated. > > > > Sincerely, > > Vahid > > > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From w_ettehadi at yahoo.com Fri Feb 27 14:24:14 2015 From: w_ettehadi at yahoo.com (vahid ettehadi) Date: Fri, 27 Feb 2015 19:24:14 +0000 (UTC) Subject: [Rtk-users] Helical cone-beam reconstruction with RTK In-Reply-To: References: Message-ID: <47007992.1342548.1425065054134.JavaMail.yahoo@mail.yahoo.com> Hello,Thank you Robert, Louie and Simon, for your tips and recommendations. I will work on it and I will share the result or potential problems. I found the RTK more accurate and easy to use in compare with other open-source reconstruction tools such as Oscar and NiftyRec.? Thank you RTK team!Vahid On Friday, February 27, 2015 4:42 AM, Simon Rit wrote: Hi, We haven't worked on helical (CB)CT and I haven't heard of anyone working on it. Others answers are correct: - it's easy to simulate helical CBCT by playing with the geometry. I guess compared to a circular geometry where only source-to-detector and source-to-isocenter distances matter, you'll have to adjust the SourceOffsetY and the ProjectionOffsetY. That should work for shepp logan type of simulations and forward projections of 3D images. - iterative reconstruction should work since we don't have any prior on the geometry except we use the displaced detector for weighting the central area when required. You probably want to do something similar in the direction of the axis of rotation to have smooth transitions between projections but it's theoretically not mandatory (we found the result is better in practice). - there is no analytical reconstruction available. Good luck and don't hesitate to contribute if you do some tests. Simon On Thu, Feb 26, 2015 at 10:33 PM, louie L wrote: Hi, You can change the geometry. If changed correctly, most, if not all, the iterative cone beam reconstruction will work.? Best regards,Louie Greetings from my iOS! On 26 Feb 2015, at 21:19, Robert Callie? wrote: Hello Vahid,I think you need to add a new reconstruction filter for it. For the first projection the object usually is placed so that theresulting projection image covers the upper half of the detector. And you will need some additional handling (z-increment).I guess you could do a little work around with the current rtk. If you only reconstruct an rectangular roi aroundthe detector?s center where the perspective distortion (because of the cone) is minimal. And then you add theseseperate volumes to a final volume. This is just an idea. I do not know how the result will look like. Think of it like a TDIbut with a wider sensor array.?I do not know the code in detail, but if it were possible to have seperate geometry settings for every projection image it would be possible to model the helical trajectory by the changing geometry without changing /adding code.?But let?s see what grandmasters of RTK will suggest.?Best regards,Robert??????????????? ?Von: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] Im Auftrag von vahid ettehadi via Rtk-users Gesendet: Donnerstag, 26. Februar 2015 20:35 An: rtk-users at public.kitware.com Betreff: [Rtk-users] Helical cone-beam reconstruction with RTK?Dear RTK users,??I am using the RTK code to reconstruct the image for a bench-top micro-CT in a circular cone-beam geometry. It works well with FDK algo. Thanks RTK.I would like to change the current source trajectory from circular to helical. I was wondering is it possible to use the RTK for helical reconstruction only with some simple modification?I don't know well about reconstruction process and I don't know which type of modification is necessary to use RTK for a helical cone beam geometry. So, any suggestion and recommendation would be appreciated.?Sincerely,Vahid?? _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users _______________________________________________ Rtk-users mailing list Rtk-users at public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: